dynamic import types

[Brian K. White]

Well, there's 521 fields, and it's a 550 line table and growing so far, 
so I ain't doing duplicate assignments! haha! :)

The call table I was envisioning was just a tiny one or two line one 
just to do the import command, just so that multiple import commands 
didn't physically appear inside the same process table, just so that the 
syntax checker doesn't give me any lip about them. The program flow does 
not invoke more than one of the possible choices within any given entire 
clerk session, but I guess the syntax checker can't know that and can't 
allow the possibility. And I just realized even if I tried that, it 
would probably just balk because no import line appeared anywhere. What 
if I wanted to build a circle of tables that used CHAIN? Would it 
prevent me? (Idle question. I'm not spending time answering it, so I 
damned sure am not asking anyone else to except maybe purely 
rhetorically/academically.)

I guess I could do 3 duplicate tables that have the import and the 
assignments, with no logic on the assignments, just the bare minimum to 
copy all the fields. That would even be tolerably maintainable, because 
they would all just be copies of each other with a tiny change at the 
top, and they would hardly ever change anyway, only when the structure 
of the import file changes. On those days, I'd just have to tweak on of 
the 3 copies, copy over the other two and tweak the import commands 
again. Then I could do all the logic in the main table. Eh, it could 
probably work and wouldn't be too bad, if I still wanted to do that. I 
would have to do the same 3-table thing for the export (response back to 
the one who submitted the file for import), but the response file in 
this case is trivial. In fact, for the response I could skip using 
export and just write the data in the 3 different formats manually with 
writeline(), and no need for any call tables, because it's only like 3 
fields, and writing even json or xml is 900 times simpler than reading it.

Anyway it's not a big deal really. I just initially thought it was a 
natural. The entire table is the same in all 3 cases save for about 2 
bytes difference. Silly to have to copy an entire 500-600 line table 
just because ultimately one little flag might be "\t" or might be "|". 
And would be nice to be able to write the consumer-facing api docs to 
say "you can submit in any of these formats..."

What really makes it no big deal is I realize now I never should have 
even bothered trying this, in this case. Because I already knew I was 
planning to add json and xml to the list of choices eventually, and I 
already knew I was not going to bother doing those in filpro.

Since *those* would be 500,000 times simpler to do out in the web-facing 
script language than in filepro, it means it's actually kind of wrong to 
do handle those 3 options in filepro even if I could. Since I already 
know I'm not going to handle *all* of my eventual branches in filepro, 
consistency and sanity says, don't do *any* of them in filepro. Instead, 
pick one format to talk to filepro, and do all translating options 
together in the same place in front of it.

So in the end I have decided that it might be an interesting question 
academically, but for my current job it was a silly question I shouldn't 
have bothered even trying in the first place, and I CAN present the 
consumer-facing choices I wanted.

Thanks for the skullduggery. :)

-- 
bkw

On 4/24/2017 11:47 PM, Bruce Easton via Filepro-list wrote:
> Yeah - like export, referencing the same file would only work if you use
> different aliases.  So if I had a screen where I capture the full file
> path and either "csv" or "tab" (to use two of your types), and those
> were sent to a called table via global vars in an input table, then the
> called table could capture from the appropriate import file, but you'd
> have to make a set of assignments for each file type:
>
> Then: declare extern api_data_format
>      If:
> Then: declare extern impFile
>      If: api_data_format ne "csv"
> Then: goto trytab
> rptidc If:     'csv file processing
> Then: import word idc = (impFile)
>      If: not idc
> Then: goto closidc
>      If:
> Then: lookup newdat = impdata@  r=free  -e
>      If:
> Then: newdat(1)=idc(1); newdat(2)=idc(2); goto rptidc
> closidc If: newdat
> Then: close newdat
>      If:
> Then: end
> trytab If: api_data_format ne "tab"
> Then: end
> rptidt     'tab file processing
> Then: import ascii idt = (impFile)  f=\t r=\n
>      If: not idt
> Then: goto closidt
>      If:
> Then: lookup newdat = impdata@  r=free  -e
>      If:
> Then: newdat(1)=idt(1); newdat(2)=idt(2); goto rptidt
> closidt If: newdat
> Then: close newdat
>      If:
> Then: end
>
> I guess a possible advantage would be if there is a variation in the
> layout between file types, then you'd need the extra set of assignments
> anyway.  And if you had several different clients who supplied the same
> data, but with differently ordered layouts, I suppose something like the
> code above could work if, for the free-record lookups, you declared an
> array against it, and before assigning, referenced a filepro file that
> would be keyed by client and provided the hash of field assignments for
> each client and field.  In that case, you could capture and pass the
> client code into here and still run this same code.  I guess also in
> such a case the assignments would be more like:
>
> Then: lookup reffile = (clihash)  k=(clicode) i=A -ng
>      If: not reffile
> Then; goto dunrefl
>      If: reffile(1) ne clicode
> Then: goto dunrefl
> Then: nn=reffile(3)
> If: reffile(2) eq "1"
> Then: arr[nn]=idc(1)
> If: reffile(2) eq "2"
> Then: arr[nn]=idc(2)
> Then: getnext reffile; goto refloo
> dunrefl
> .
> . etc. , where "arr" is dimensioned against "newdat", where nn would
> loop (getnext) from 1 to the highest field# in the reference file for
> the client (in say field 3 there) and would indicate the target field to
> be assigned.
>
> reffile could look like:
>
> Client(1)    imp fld#(2)   asign_to(3)
> XYZ          1              1
> XYZ          2              3
> ABC          1              3
> ABC          2              2
>
> Or, like you say - go with separate called tables.
>
>
>
>
>
> On 4/24/17 7:21 PM, Brian K. White via Filepro-list wrote:
>>
>>   If: api_data_format eq "csv"
>> Then: import word idf = (impFile)
>>   If: api_data_format eq "pipe_delimited"
>> Then: import ascii idf = (impFile) f=| r=\n
>>   If: api_data_format eq "tab_delimited"
>> Then: import ascii idf = (impFile) f=\t r=\n
>>
>>
>> import ascii idf = (impFile) f=| r=\n
>>                             ^
>> Merge name incompatibility.
>> Word processor or spreadsheet merge has been given two different names.
>>
>> Dangit, is there a nice way around this or do I have to give up on
>> this idea and just pick one?
>>
>> I mean yeah I suppose I could write 3 tiny tables and CALL the right
>> one, or write out a temp version of the full table and chain to it or
>> something, but I mean short of unnecessarily Goldbergian things like
>> that. Actually the call idea might not be too bad after all, as long
>> as no one else is CALLing this table itself, which I am pretty sure
>> about but not 100% sure about. It does contain some comments that
>> imply passing long variables back to a parent, but that could just be
>> poorly written comments, especially since they appear above a stack of
>> explicit DECLARE LOCAL, hello, local... not extern or global or
>> unspecified. Anyway not interesting, sorry.
>>
>> Then: declare fpit, fpid
>>   If: api_data_format eq "csv"
>> Then: fpit = "word" ; fpid = ""
>>   If: api_data_format eq "pipe_delimited"
>> Then: fpit = "ascii" ; fpid = "f=| r=\n"
>>   If: api_data_format eq "tab_delimited"
>> Then: fpit = "ascii" ; fpid = "f=\t r=\n"
>>   If:
>> Then: import (fpit) idf = (impFile) (fpid)
>>
>>
>> import (fpit) idf= (impFile) (fpid)
>>        ^
>> Process contains a syntax error at position indicated.
>>
>> ...I guess not that way ;)  I kind knew that wouldn't work, just worth
>> a shot since it was easy to try.
>>
>> ... well, I am receiving these data files via php cgi script, so I can
>> do the translation both ways in there, the same way I'm already doing
>> for line endings. Take in whatever, feed only one consistent format to
>> filepro. This would just be more of the same. So I guess it's no loss
>> to pick one format for use inside the table after all. The exterior
>> facing api would still allow any, which is all that matters.
>>
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>