HTML into filePro processing tables--the EASY way!

[Lerebours, Jose]

Mark posted:

> > 
> > 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 see I omitted the semicolon.  The actual field reference is

&fp###; and $fpA2Z;

Some server side scripting languages use # signs as part of their
syntax.  HTML uses # sings ...  I chose &fp as a prefix simply 
because it uses the & character which is used for special 
characters and fp to denote filePro. I think this is pretty safe
and it would be easy to search for any &fp within your HTML page
whenever you want.

> 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.  

You cannot print a long variable so I am not concerned with it been
used in the HTML page.  Want its content?  Place it in a regular dummy
field!

> 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 

Right now, my processing works as a subroutine.  I suggested that
it could be converted to a global called table and that dummy
fields would need to be dumped into a repository.  Easy!

> 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.
> 

If the page is designed with an none existent dummy field, it
will be replace with a blank since all fields are actually
defined.  The question is, weather or not a value was assigned.

> 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.  :(

Process will not blow up, they will just get a BLANK since all
variables are defined 

dim dummvars(676):aa ; dim onevars(26):a  ;  dim self(999):1

These arrays account for all variables aa through zz and 
a through z.  Of course, all possible real fields as well.


> 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.
> 

It is kind of like that!  Any development tool assumes that you
know what you are doing.  Since the arrays cover all possible 
variables and all possible fields, the only problem you will run
into is "nothing prints".

[ snip ]

> 
> > 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.
> 

Mine!  Again, no problem if wrong field/variable is used, they are
all declared.  Of course, it is the developer responsibility to 
use proper field and to assign expected values to those fields.

Regards;



Jose Lerebours