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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to