BTW I've been reading docs on SOFIA recently
From salmonllc.com? Looks interesting on paper - RAD for J2EE...
Yep. Although I believe Cocoon is well up to the job ;-)
and am wondering if we should provide a _second_, less powerful but simpler interface to esql:
<ol> <esql:simple-query connection="pool-name" from="list of tables" [where="some expression"] [order="list of attributes"]>
<li><esql:get-string name="foo"/></li>
</esql:simple-query> </ol>
and have the attribute names collected from the nested esql:get-... tags. Maybe even allow for nesting and grouping in there but no paging, no conditional result blocks etc.
compare to the current, more verbose version
<ol> <esql:connection> <esql:pool>pool-name</esql:pool> <esql:execute-query> <esql:query>select * from list-of-tables where expression order by list-of-atttributes</esql:query> <esql:results> <esql:row-results> <li><esql:get-string name="foo"/></li> </esql:row-results> </esql:results> </esql:execute-query> </esql:connection> </ol>
Thoughts?
Chris.
The <esql:row-results> approach took me a little time to get my head around - and the alternative syntax is a good deal simpler. Would this be an alternative syntax, with the old syntax still supported?
It's not really "old" vs "new" -- it would be an additional tag that would expand to the very same code as the current combination. Hence, it could be fully combined with all other esql tags that may appear inside a esql:row-results. Well, that would be the plan.
Unless you can mix the old and new code together, though, this represents yet another choice between simplicity and power, of which there are several already :-)
Indeed. But maybe the current ESQL usage is a little too complex to just list the contents of a table?
To be honest, I don't have a problem with embedding SQL SELECTs directly into the XSP or logicsheet. The row-results logic, once grasped, is also straightforward enough. More of an issue is the insert/update/delete logic. In your GT2003 slides, IIUC, you recommended against doing these using ESQL or SQLTransformer: this is my instinct also, but what are your reasons? And could these problems be overcome by an alternate "simple ESQL" interface? If so, that would to me make a more compelling reason for an "ESQL Simple" interface.
Nope. What I don't like about manipulating tables from XSP is that a) application logic appears on the page b) different results (eg errors) lead to different pages or ask for redirects which makes the pages too complex to maintain.
Actions are a good step in the right direction if used correctly.
Honestly, the flow + o/r apprach is so much more elegant for complex logic. Especially if you add CocoonForms aka Woody to it.
Cocoon has the best architecture I've worked with for a very long time - thanks for all your work.
Thank you! Now go and spread the word :-)
Chris.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
