Re: Docs or examples for modular database actions?
Thomas Nichols <nx10mail <at> yahoo.co.uk>
2003-12-01 09:29:27 GMT
At 18:03 29/11/2003 +0100, Christian Haul wrote:
>Thomas Nichols wrote:
>>>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
So I am finding.
>>> and am wondering if we
>>>should provide a _second_, less powerful but simpler interface to esql:
>>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.
Ok, in that case it sounds useful.
>>Unless you can mix the old and new code together, though, this represents
>>yet another choice between simplicity and power, of which there are
>Indeed. But maybe the current ESQL usage is a little too complex to just
>list the contents of a table?
I didn't find it so, but then I'm reasonably familiar with SQL.
>>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
Agreed - generally horrid.
> b) different results (eg errors)
>lead to different pages or ask for redirects which makes the pages too
>complex to maintain.
You mean the process flow is defined within XSPs? Ok, I can see this is a
>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.
I'll check this out more carefully.
>>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
I already am