[cgiapp] best practicess: CGI::App RAD generator

[Peter Masiar <suppressed>]

I am not a OO guru, so I am not sure how to do it, or even if it is possible.
But...

In my previous job, we have smart huge macro, which was helping
immensely with RAD (Rapid App Development).
It was like BREAD (Browse/Read/Edit/Add/Delete) methodology 
mentioned in this mail-list before.

Our apps mostly started from BROWSE mode, allowing to find quickly
record to update, then went to VIEW (read-only) to see more data fields.
EDIT or DELETE was allowed only from VIEW. Data locking was resolved, too.

I was thinking, if it will be possible for a real OO guru -- not me :-( 
to create something, which will read a hash with all parameters,
and dynamically interpret this hash to create SQL statements
and juggle runmodes as is needed.

Some class from which I can inherit to make it all happen. ;-)

Parameter hash will have: 
   * table name
   for browse 
      * sort order
      * fields to display
   for view/edit/delete
      * key (or keys)
   * fields to display
   * read/only fields, if any
   * view template. If blank, just generate all fields in 1 column (RAD)
   * etc.

Each table had std fields LOCKED_BY, LOCKED_DATE, CHANGED_BY, CHANGED_DATE,
used to locking/unlocking, and to set who last changed data.
These were displayed by default at view page bottom (easy to find out
whom to blame when bad data, and check/expire lock if needed).

Nice part was, instead of generating this code, with all the methods
expanded as text file (source code), as standard code generators do, 
our system used parameters on-the-fly.
There was no generated source code to maintain, only file with parameters.
So next time, when you needed to add table field, you did not have to 
add it into proper places in generated source code manually, 
or regenerate the whole thing. Just change parameters.

In time it evolved, has many callbacks (BEFORE-VIEW, BEFORE-CREATE,
BEFORE-DELETE, etc) to handle exceptions and special cases.
We used procedures with special names, and if existed in parameter file,
code was called in proper places in generator. 
We placed this custom procedures in parameter file 
(so yes, parameter file _was_ source code), 
but standard BREAD functions, locking, error reporting were outside. 

This was done using macro, not objects, but (not being OO guru)
I still hope it is possible.

You can see how this improved speed in RAD. 
Creating prototype was easy, and once created, you can enhance it later,
adding form, cpecial-case procedures, etc.

We also had dictionary of labels, which held two text labels for each
data field: side-label for view/edit, and "top" label for browse,
which could be used for nice screen names when no template was provided.

And yes, of course, we had GUI initiator capable to initially create 
parameter files from table structure, and initiate templates 
with field names from dictionary (so we could assume 
_some_ template always existed).
GUI initiatior also created all special callback procedure names 
(comented out), because IMHO it is easier to delete/uncomment, 
than recall correct proc name (and type and mis-spell).

Of course, GUI initiator and dictionary from this last paragraphs 
are optional... ;-)

Yes, I am aware this approach will use huge amount of agreed-upon table names,
field names, runmode names, procedure names, etc. *A Lot* of them.
Will be tightly integrated with CGI::App.
And not, it was not in perl, it was done in PROGRESS 4GL database language.

This is what I hope to have sometimes in the future. Real CGI::App RAD.
And open-source, this time.

Is it possible? Am I dreaming? Am I OO ignorant?
Opinions? Flames? ;-)

Thank you for your attention.

-- 
Peter Masiar, 

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed