Databases in Flow

[Miles Elam <mi...@pcextremist.com>]

     Please forgive the staleness of this comment, but I haven't had net 
access at home for about a month.  >4,000 messages!?!  *sigh*  I feel 
like a heroin junkie without access to a steady hit and after long last, 
I overdose.  But I digress...

     This is in regard to the general sentiment that coding in 
JavaScript to the database in flow is automatically a bad thing, an 
anti-pattern, and that the functionality should only ever exist in Java 
objects.  Ummm...why?
     Don't get me wrong, I can think of many cases where encapsulation 
in an object is a great thing.  I can also think of many instances where 
an object would be unnecessary.  In fact, I've heard people speak of how 
a RDBMS->Object->property extraction, and variable injection to the 
pipelines is preferable in most cases.  Hunh?

     Let me see...write an object that equates to a glorified C struct, 
have that object (or a helper object) make a database call, put the 
values into aforementioned object, have the Flow script pull the values 
out of the object, and drop the values  into the sendPage function.  
OR...have the Flow make a database call and drop the values into the 
sendPage function.
     The first is useful in many situations where there is some 
commonality/reuse in the system with regard to this action, where 
distributability is required, some special processing occurs every time, 
and/or when you want to keep the source close to your chest.
     The second is useful when you only have one (or few) box, a single 
database, are basically publishing-oriented, want an easy try-debug 
environment without the extra compilation step, etc.  In the cases where 
stored procedures are being used in the database and several 
circumstances where transactions are used in the database, writing extra 
Java objects is fundamentally useless and adds unnecessary complexity.  
If I'm for example adding a user to a system via a stored procedure that 
takes care of duplicate usernames, invalid values, etc., what good is 
the Java object?  Sure, you could pass the SQL to the object from the 
JavaScript, but how is this better than having direct access to JDBC's 
callableStatement?

     Why the animosity toward JavaScript?  I don't hear people 
clamouring for ESQL's removal from XSP because SQL should only be made 
from within object calls.  Why?  Because XSP is compiled to a Java 
object and therefore "cleaner"?  Because the Java will be measurably faster?
     Show of hands!  Who believes that the choice of programming 
language will be the bottleneck in web database environments.  C'mon!  
You know who you are!
     Flow was supposed to make things easier.  If the intent in this 
mandatory object facade madness that people should be forced into good 
habits, I believe it to be misplaced.  If someone wants to try writing 
all of their app code in JavaScript without any benefit from EJBs or 
Avalon (which by the way, I am NOT advocating), it will be a very fast 
lesson in software development akin to the individual who decides to shy 
away from Cocoon and write their own simple XML/XSLT 
publishing/application environment because they want it "to be smaller 
and faster without all of the bloat."
     There's a difference between making the correct method more 
desirable (and therefore more likely to be used) and shutting the door 
on different approaches that (in my opinion) may very well be valid for 
the specific use case.

     If all I need is the result value from a stored procedure because 
the code in question exists in the database, how is my life enriched by 
having to write a separate object that needs to be maintained and 
distributed?  But that is the current state of events.  I had hope when 
I saw the Database object used for Petstore, but I fear that people are 
denigrating it because it's that icky JavaScript stuff.
     Coming from an ASP and JSP perspective, I can loudly give testament 
to rapid development of one-use or narrow-use database access via 
scripting.  While others are fiddling with their O-R mapping files, some 
of us have moved on the the next, probably more important task.  And we 
only have a single Flow function to deal with whereas others would have 
a Flow function, an O-R map, and a generated class file.

     Sorry for the vent, but once again, I've been without steady net 
access for a month and when I last left the forum, there weren't quite 
so many voices in favor of dumping a database-level Flow API -- 
something that would save me no end of time and effort both in the short 
term and the long term.

If I am mistaken in my impressions of others on this list because I 
skimmed far too quickly trying to catch up, my apologies.  If so, feel 
free to demand that I medicate myself.  If not, I'd like to talk about this.

- Miles Elam