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
