cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: SQL Editor
Date Mon, 03 Feb 2003 18:23:01 GMT

On Monday, Feb 3, 2003, at 14:50 Europe/London, Antonio Gallardo wrote:

> Jeremy Quinn dijo:
>> Hi Guys
>>
>> I am looking into implementing a forms-based editor for a complex set
>> of inter-related SQL Tables (with lots of gruesome link tables etc.).
>>
>> What is currently considered the best technique to be using in Cocoon
>> right now?
>>
>> XMLForm (we don't use Beans)
>
> I think this is a good point. Many people thinks that XMLForms are 
> related
> to Beans. In particular (as a Cocoon user), I follow this thread too
> little, but there is a feel that XMLForms are very tighted related with
> beans. Why? I know that current implementation are only speaking about
> beans and is currently too complex. :-(

I hope Ivelin was not offended by that comment of mine (even though he 
knows he does not own the code ;)

Beans are an extremely relevant way of working in some situations we 
used beans in CRUDlet.org a while ago, talking to JavaSpaces. But I do 
not believe they are relevant to the current job.

> I dont know nothing about beans. I just know that this is a technique
> trying to address the issue of mixed code and tags using JSP.

a Bean is just a coding convention, no?

> Please
> correct, if I am wrong. I will be glad to understand this in a better 
> way.
> :-) I feel that XMLForms will rocks and is a very good approach for the
> webapp.

I agree, hopefully one day it will be easier to see how to use all that 
work that has gone into XMLForm implementation in a wider range of 
situations.

>
> I think the XMLForms cannot be only used with Beans. If I am correct
> undertanding all this mix, XMLForms are an implementation of the XForms
> that currently define the W3C. That means there is a related 
> description
> about the form and his properties.... Writing this come to my mind the
> genexus technology ( http://www.genexus.com ). I assisted to some
> presentations + all the education of this tool in beginning 2002... In
> Genexus you concentrate on defining the forms. Genexus take care of
> writing the Database and all the application. The target programming
> language can be choosed, well I will not explain here what all this do.
> The point is, based on the form you specify, Genexus generates the code
> you need to serve the form.
>
> Maybe some of this we need here. I suggested that a good starting point
> can be the OpenSource project called Druid:
> http://sourceforge.net/projects/druid

Maybe I misunderstand this reference, but we already have an existing 
set of populated (≈5k records) Tables.

>
> If all this is true XMLForm, can be used with Modular Database Actions.
> But currently there is only the beans implementation.
>
> My question is: Is planned a future release of XMLForm supposting 
> Database
> actions?
>
> Comments are welcome! :-D
>
>> OriginalDBActions (obsolete ? )
>
> Maybe yes? But for some simple works Original Database Action can 
> helps.
> As long as I know there are still a valid way. They are not deprecated
> stuff.
>
>> ModularDBActions (Actions are not liked by many)
>
> Who cares? ;-) I think currently is the best option test probed.
> Currently, I use it with XSP FormValidator. Actually, this is the 
> easiest
> way to follow.

OK

>
>> SQL Inserts/Updates using SQLTransformer (maybe not capable of the job
>> due to complexities of the multiple Table updating required ? )
>
> Yes, there is a very complex issue when you are trying to use some 
> nested
> queries (master-detail forms) You must take create special styleshets 
> to
> build the nested query). Personally I dont tested this way, but the
> complexity is clear form the book of Carsten and matthew.

Sorry Guys! Not read it ;)

>
>> SQL Inserts/Updates using ESQL TagLib (complex and difficult to
>> maintain ? )
>
> I feel not a good way to follow... complex and difficult to maintain
>
>> OutputModules+FlowScript (too unknown ? )
>
> Still not released. But people working hard on it. Maybe this is not

a steep learning curve that I must face one day ....

>
>> Out of this list, the ability of ModularDBActions to make multiple
>> row/table modifications into a discreet transaction makes it sound the
>> most attractive.
>
> I agree. I am using this technique with XSP FormValidator. ModularDB
> Actions makes a good work when you are faced to write a master-detail 
> form
> in one page.

I wanted to avoid XSP if possible, partly because there would be such a 
temptation to work around any difficulties issues with bits Java code, 
something the people I pass onto will not be able to maintain. (And I 
definitely do not have time to write a logicsheet ;)


Many thanks for your feedback

regards Jeremy

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message