I was firing commands from Memo fields, line by line (no If-Endif/While
Loop/Case based commands obviously) for years before EXECSCRIPT() came
along.  The biggest reason was to allow me to fine tune behavior of my main
code without recompiling an app.  Imagine my delight when Ed had looked at
my technique and told me about VFP7 having EXECSCRIPT().  Works like a
champ, although the VFP7 debugger craps out when I SET STEP ON in called
code via EXECSCRIPT() and can't find its way back home.  VFP8/9 fixed that
problem.  And with VFP8/9 EXECSCRIPT() I do process If-Endif/While/Case
based commands with ease.

I have even gotten to the point where I use database tables with fields that
contain various configuration values to build on-the-fly code from my Memo
fields that are then fired off via EXECSCRIPT().  Works great.  I spend far
less time testing inside a project, recompiling, & chasing down various
versions of code.  I tell my clients it is a Database-Centric method of
designing my solutions.  They all seem to think it sounds advanced,
therefore must be worth a grunt at least.  And with the code within the Memo
fields I really couldn't care less if someone sees it.  The real horsepower
is in the .app/.exe files, although I do not protect that with ReFox or
anything.  Perhaps I should, eh?  heh-heh...

Gil

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of john harvey
> Sent: Sunday, February 04, 2007 2:28 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [WEB] Storing code in tables
>
>
> My WASP program uses memo fields to store code, so that when you make a
> selection from a dropdown, the code fires from the memo field. It
> allows me
> to add code without recompiling the exe, and since it is running on a fat
> client, I don't worry about it. People act like they work for the
> NSA or CIA
> and there are spooks out there trying to read the IR from their
> screens. If
> that is the case, then I think maybe a different strategy might
> be in order,
> and find a room with windows.
>
> John
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Kenneth Kixmoeller/fh
> Sent: Sunday, February 04, 2007 12:49 PM
> To: Profox
> Subject: [WEB] Storing code in tables
>
> Hey - --  -
>
> Since I see y'all chatting...
>
> I am working on my framework for designing Web applications using
> PHP, and in this case, MySQL. One of the goals I have had for a long
> time in my development (in any language) is to keep things flexible
> by putting lots of stuff in tables. This includes metadata tables
> which specify ordinary validation rules: mandatory?, typical formats,
> encrypted?, stuff like that. The typical ones result in a function
> call to a utility object embedded in a data object: IsValidFormat
> (<string>,"Telephone"), for example. For exceptional validation, this
> includes a field for a bit-o'-code for custom validation or table-
> level validation.
>
> Also, for the same flexibility reason, my framework design keeps page-
> related information, including display code in a table, too. This is
> never core code like login validation or data object definitions,
> only again, function calls to data and UI objects. All of the class
> definition code is kept in files, not tables, off of the Web tree.
>
> When I posted a question related to this strategy in a PHP group, I
> got an individual who said that this strategy is very dangerous, and
> (in so many words) I'm an idiot for even contemplating it. Mind you,
> he only knew the "code in tables" part, without the level of detail
> above. I subsequently supplied it, but so far without response.
>
> Whadaya think? Is this an ill-conceived strategy?
>
> Ken
>
>
[excessive quoting removed by server]

_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to