HTML into filePro processing tables--the EASY way!

Fairlight fairlite at fairlite.com
Fri Mar 4 05:16:54 PST 2005


Only Lerebours, Jose would say something like:
> 
> Sounds a lot like the processing table I wrote that parses 
> your HTML pages and inserts filePro fields (dummy and real).
> 
> My processing table allows you to create an HTML document
> using your favorite HTML editor.  To insert filePro fields,
> all you need to do is place &fp### or &fpA2Z (where ###
> is a fixed field and A2Z is any dummy field).  It works
> very well if I may say so.

I'd probably opt for ###expr### simply because I don't like the idea of
people mixing &fp### mentally with special entity characters (lack of a
final semicolon notwithstanding.

Why do you differentiate between "fixed" (I assume you mean "real") fields
and dummies, though?  I'm failing to grasp that one.  In either event, the
syntax would be the same.  Ditto for long declared variables.

I could add this ability, no problem.  Wouldn't surprise me if it
fell into the program before the weekend was over.  Although, I have
reservations--doing it with no checking at all for the legitimacy of the
expression (read: field/variable) is trivial.  Checking for a real field
requires specifying a database name whose map we should check.  That's
doable.  Checking for the legitimacy of a variable, not knowing where the
table is being called from...hmmm.  With long, declared variables, we
obviously can just toss in a declare extern for any we find.  That's not a
huge issue--we just have to grab those field names before writing the table
header code.  But how are dummies handled between calling/called tables,
specifically?  Is there a validity check?  I thought they stomp on each
other even though they're not declared global/extern, as I had a conflict
with someone else's code in another project in that fashion.

I'm not so sure I like this.  One one hand, it's easier to just change the
real document and reconvert to table when you need a change.  On the other
hand, it's a bit of a concern that people may do something like try using a
variable that doesn't exist, then wonder why their processing blew up.  :(
Granted, the onus is on the developer, but...  I just like things nailed
squarely to the wall, and this doesn't fall under that category.

I think -if- I add it, it will be with no checking.  It would simply
assume you know what you're doing.  

I presume that if it starts with a numeral, it must be a real field, and
if it's 2 or less characters, it's a dummy, else it's something we need to
declare as an extern?  If that's the deterministic logic, no problem.  I
could live with that, and it'd probably take me longer to toss a few things
at it to make sure it's solid than it would to write the code.

> This is the processing table you once said could be a 
> perfect partner for your OneGate script/module.

Yes, I use this with OG all the time, as do several clients.  Ever dink
around trying to import 17K of HTML and JS into processing, even in vi?  :(
Hence, the pain-reliever.  Snarf, slightly tweak, run.

> Of course, you define something a lot more sophisticated as it
> writes filePro processing tables to produce the HTML already
> created with the HTML editor.  My filePro processing table
> simply plugs in the filePro content and creates a new HTML
> table with the values added in.

A bit different model, yes.  It's not complex, but it's cool and saves on
time and effort in a big way.  

> Come to think of it, this program can be easily modified to
> be used as a "global called" table and have it produce the
> desired HTML document no matter where it is called from.
> Of course, it will take dumping all dummy variables in a 
> repository (unless it is limited to fixed fields only).

Yours, or mine?  In either event, I'd likely place the onus on the
developer to make sure that dummy and real fields exist, and I'd just
declare new externs for long variable names on the fly.  It makes the most
sense to me so far.

mark->
-- 
          *****   Fairlight Consulting's Software Solutions   *****
OneGate Universal CGI Gateway:                  http://onegate.fairlite.com/
FairPay PayPal Integration Kit:                 http://fairpay.fairlite.com/
RawQuery B2B HTTP[S] Client & CGI Debugger:     http://rawquery.fairlite.com/
Lightmail Mail Sending Agent:                   http://lightmail.fairlite.com/


More information about the Filepro-list mailing list