You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2003/02/03 15:10:45 UTC
SQL Editor
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)
OriginalDBActions (obsolete ? )
ModularDBActions (Actions are not liked by many)
SQL Inserts/Updates using SQLTransformer (maybe not capable of the job
due to complexities of the multiple Table updating required ? )
SQL Inserts/Updates using ESQL TagLib (complex and difficult to
maintain ? )
OutputModules+FlowScript (too unknown ? )
Out of this list, the ability of ModularDBActions to make multiple
row/table modifications into a discreet transaction makes it sound the
most attractive.
As for OutputModules+FlowScript, is that even a reality yet?
Thanks for any advice.
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
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
Re: SQL Editor
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
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 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. 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 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
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.
> 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.
> 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
> 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.
>
> As for OutputModules+FlowScript, is that even a reality yet?
I dont know. Sorry :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, Feb 3, 2003, at 16:43 Europe/London, Daniel Fagerstrom wrote:
>>
>> SQL Inserts/Updates using SQLTransformer (maybe not capable of the
>> job due to complexities of the multiple Table updating required ? )
>
> We are using the SQLTransformer for all insert/updates etc on the
> company that I work for. For more complex update actions involving
> transactions the current implementation is not usable as it opens a
> new connection for each execute-query element. I have written a patch
> that http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16718 that
> solves that problem.
>
>
That is interesting
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jeremy Quinn wrote:
> 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)
> OriginalDBActions (obsolete ? )
> ModularDBActions (Actions are not liked by many)
> SQL Inserts/Updates using SQLTransformer (maybe not capable of the job
> due to complexities of the multiple Table updating required ? )
We are using the SQLTransformer for all insert/updates etc on the
company that I work for. For more complex update actions involving
transactions the current implementation is not usable as it opens a new
connection for each execute-query element. I have written a patch that
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16718 that solves that
problem.
/Daniel Fagerstrom
> SQL Inserts/Updates using ESQL TagLib (complex and difficult to maintain
> ? )
> OutputModules+FlowScript (too unknown ? )
>
>
> Out of this list, the ability of ModularDBActions to make multiple
> row/table modifications into a discreet transaction makes it sound the
> most attractive.
>
> As for OutputModules+FlowScript, is that even a reality yet?
>
>
> Thanks for any advice.
>
> regards Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, Feb 3, 2003, at 14:28 Europe/London, Ugo Cei wrote:
> It goes something like this (this is a flowscript fragment for
> retrieving a business entity, having "id" as it's POID [1], into a
> bean, associating it with a form, posting it to the user, awaiting
> submission, validating and storing):
>
> session = sessionFactory.openSession();
> var entity = new BusinessEntity();
> session.load(entity, id);
> session.close();
> var form = getForm("entity-form", entity,
> "context://flows/workflow-schema.xml");
> while (true) {
> form.save(cocoon.environment.getObjectModel(), "request");
> sendPageAndWait("entity-form", {});
> form.populate(cocoon.environment.getObjectModel());
> form.validate("phase");
> if (form.getViolations() != null && form.getViolations().size() > 0)
> {
> continue;
> }
> break;
> }
> session = sessionFactory.openSession();
> session.saveOrUpdate(entity);
> session.flush();
> session.close();
>
Dear Ugo,
I have been writing the text below to try explain to a colleague how
your sample FlowScript works, while we try to work out which technique
to use for our own editing issues.
Would you mind having a look over it to see if I understand properly?
Incidentally, is getForm() your own method? I cannot find it ....
XForm + Flow:
* your URL requesting to edit some data in an SQLDB, is mapped by the
Cocoon's Sitemap to call your 'edit' FlowScript method, providing it
with the 'id' of the data you want to edit, the 'class' of JavaBean to
hold it and the 'src' of the Validation Schema to use.
* 'edit' instantiates a new Bean of 'class' filling it with the data
you want to edit, from the 'Object Persistence' layer, using the 'id'.
* This 'Object Persistence' layer (something like 'Hibernate', 'Apache
OJB', 'Sun's JDO' etc.), uses an XML file that maps Bean Properties to
SQL Tables and Columns. (???? how is this set up ????)
* 'edit' instantiates a new Form Object using the Bean as the Model and
the 'src' as the Schema.
* [start-loop] 'edit' puts this Form into the Request, then calls a
Pipeline in the Sitemap to send a Response back to the user using this
Request, meanwhile waiting for the HTML Form to be posted back in a new
Request. This is a Continuation.
* the Pipeline that is called, while 'edit' is waiting, generates an
XForm, which represents the editing interface for the user.
* the XForm is transformed by the XFormTransformer, which fills the
XForm, using XPath expressions in the XForm fields, with the data from
the Bean in Form in the Request.
* the XForm is transformed by XSLT into HTML and sent to the user.
* the user edits the data in the HTML Form and submits it back to the
Continuation (your waiting 'edit' FlowScript).
* the Sitemap tells 'edit' to continue where it left off with the new
Request of modified form data.
* 'edit' updates the Bean with the Request data, using the
RequestParameter names as XPaths. Then Validates the Bean.
* if the Validation failed, 'edit' goes back to [start-loop] above.
* if the Validation succeeded, the Bean is Persisted back to the SQL DB
by the 'Object Persistence' layer.
Have I got it?
Or even anywhere close? ;)
many thanks
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Antonio Gallardo wrote:
> I will start my next Cocoon application soon. Of course I dont want to
> lose some of these great new stuff. I am considering the use of JavaBeans
> as was recommended in this thread.
>
> I was researching about the JavaBeans and XDoclet.... Well currently I
> found some interesting tools:
>
> UML Case that generato XMI files at:
> http://uml.sourceforge.net/index.php
>
> and UML2EJB at:
> http://uml2ejb.sourceforge.net/
>
> I think that using this tools we can get the JavaBeans and more!
For an object-relational bridge, there is also an Apache project: OJB
http://db.apache.org/ojb/
IIRC it also has an Avalon Component version.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
I will start my next Cocoon application soon. Of course I dont want to
lose some of these great new stuff. I am considering the use of JavaBeans
as was recommended in this thread.
I was researching about the JavaBeans and XDoclet.... Well currently I
found some interesting tools:
UML Case that generato XMI files at:
http://uml.sourceforge.net/index.php
and UML2EJB at:
http://uml2ejb.sourceforge.net/
I think that using this tools we can get the JavaBeans and more!
Are someone tried this applications?
Thanks for your comments in advance.
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Ugo Cei <u....@cbim.it>.
Antonio Gallardo wrote:
> Then I need to find other tool that can create the Beans and easily
> mantain it. You suggested Hibernate. Can you provide a website when I can
> learn more about Hibernate?
http://hibernate.bluemars.net/
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
hi:
As you suggested, then I think there is not need to go to deeply to UML.
Sometimes I get too deeply in things. :-(
What I was trying to find is a way to easy mantain the EJB. Druid
(http://druid.sourceforge.net/) can can generate the following code based
on a SQL model:
//==============================================================================
//=== CanjeEstado.java Build:174
//==============================================================================
package my.package.myapplication;
import java.util.*;
//==============================================================================
public class ags_CanjeEstado
{
public static final String CAN_ID = "can_id";
public static final String TEC_ID = "tec_id";
public static final String USR_ID = "usr_id";
public static final String CES_TIEMPO = "ces_tiempo";
//---------------------------------------------------------------------------
//---------------------------------------------------------------------------
private int can_id;
private int tec_id;
private int usr_id;
private timestamp ces_tiempo;
//---------------------------------------------------------------------------
public int getCan_id() { return can_id; }
public void setCan_id(int can_id)
{
checkDirty(this.can_id, can_id);
this.can_id = can_id;
}
//---------------------------------------------------------------------------
public int getTec_id() { return tec_id; }
public void setTec_id(int tec_id)
{
checkDirty(this.tec_id, tec_id);
this.tec_id = tec_id;
}
//---------------------------------------------------------------------------
public int getUsr_id() { return usr_id; }
public void setUsr_id(int usr_id)
{
checkDirty(this.usr_id, usr_id);
this.usr_id = usr_id;
}
//---------------------------------------------------------------------------
public timestamp getCes_tiempo() { return ces_tiempo; }
public void setCes_tiempo(timestamp ces_tiempo)
{
checkDirty(this.ces_tiempo, ces_tiempo);
this.ces_tiempo = ces_tiempo;
}
}
//==============================================================================
As I wrote before, this class is based on a SQL table. There is no attach
to a form. Of course some forms can use more tables simultaneously. There
is the gap I saw with Druid.
>From your meail I got that Beans are form based, not Database based.
Then I need to find other tool that can create the Beans and easily
mantain it. You suggested Hibernate. Can you provide a website when I can
learn more about Hibernate?
Best Regards,
Antonio Gallardo
Ugo Cei dijo:
> Antonio Gallardo wrote:
>
>> Master,
>
> Disciple, ;-)
>
>> Can you show us the light? As I posted before I never used beans. But
>> after seeing some comments here. I feel as something is missing to me.
>> I want to do Java Beans. I use jEdit to work. :-)
>
> I suspect that you might be confusing plain Java Beans and Enterprise
> Java Beans (EJBs).
>
> I'm talking about the former here. This is a bean:
>
> public class Customer {
> private Long id;
> private String name;
> private Address address;
>
> public Long getId() { return id; }
> public void setId(Long id) { this.id = id; }
> public String getName() { return name; }
> public void setName(String name) { this.name = name; }
> public Address getAddress() { return address; }
> public void setAddress(Address address) { this.address = address; }
> }
>
> If you have this kind of object, you can:
>
> - easily persist it via Hibernate (or any other O/R mapping tool) to one
> or more relational tables
>
> - easily access its attributes from the flow:
>
> var cust = new Customer();
> cust.name = 'Acme Inc.';
> log.debug("Customer name = " + cust.name);
>
> - easily bind it to a form:
>
> var form = new Form(formId, cust);
>
> - easily refer to its attributes, using XPath syntax, in the form
> descriptor:
>
> <xf:textbox ref="/name">
>
> - easily retrieve its attributes in the view (XSP) using XPath syntax:
>
> <jpath:value-of select="cust/name"/>
>
>>>If I were lazier, I'd even use XDoclet to generate the Hibernate
>>> mapping files from javadoc comments in the source.
>>
>>
>> This is interesting too. How it works?
>
> Using Hibernate, you have to declare how your objects map to relational
> tables in a "mapping document" (XML file). With XDoclet, you get to
> automatically generate your mapping files from Javadoc-like comments in
> the source. I haven't uesd it yet, so I cannot tell you more about this.
>
> Ugo
>
> --
> Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
> P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
> Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Ugo Cei <u....@cbim.it>.
Jeremy Quinn wrote:
> Do the XMLForm Components (Action & Transformer) get used in your
> Sitemap, or are the calls to 'form' methods from your FlowScript the
> only references that are required?
Transformer: yes.
Actions: no.
I use the transformer to do form/model population and validation just
like it is intended. I don't use actions to control the flow.
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, Feb 4, 2003, at 14:39 Europe/London, Ugo Cei wrote:
> Antonio Gallardo wrote:
>
>> Master,
>
> Disciple, ;-)
I am beginning to grok, Master ;)
<big-snip-of-bits-I-am-getting/>
I don't understand yet the interaction between the XMLForm
infrastructure and Flow.
Do the XMLForm Components (Action & Transformer) get used in your
Sitemap, or are the calls to 'form' methods from your FlowScript the
only references that are required?
Thanks for your help
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Ugo Cei <u....@cbim.it>.
Antonio Gallardo wrote:
> Master,
Disciple, ;-)
> Can you show us the light? As I posted before I never used beans. But
> after seeing some comments here. I feel as something is missing to me. I
> want to do Java Beans. I use jEdit to work. :-)
I suspect that you might be confusing plain Java Beans and Enterprise
Java Beans (EJBs).
I'm talking about the former here. This is a bean:
public class Customer {
private Long id;
private String name;
private Address address;
public Long getId() { return id; }
public void setId(Long id) { this.id = id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public Address getAddress() { return address; }
public void setAddress(Address address) { this.address = address; }
}
If you have this kind of object, you can:
- easily persist it via Hibernate (or any other O/R mapping tool) to one
or more relational tables
- easily access its attributes from the flow:
var cust = new Customer();
cust.name = 'Acme Inc.';
log.debug("Customer name = " + cust.name);
- easily bind it to a form:
var form = new Form(formId, cust);
- easily refer to its attributes, using XPath syntax, in the form
descriptor:
<xf:textbox ref="/name">
- easily retrieve its attributes in the view (XSP) using XPath syntax:
<jpath:value-of select="cust/name"/>
>>If I were lazier, I'd even use XDoclet to generate the Hibernate
>>mapping files from javadoc comments in the source.
>
>
> This is interesting too. How it works?
Using Hibernate, you have to declare how your objects map to relational
tables in a "mapping document" (XML file). With XDoclet, you get to
automatically generate your mapping files from Javadoc-like comments in
the source. I haven't uesd it yet, so I cannot tell you more about this.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Ugo Cei dijo:
> Jeremy Quinn wrote:
>> What I meant was that in order to get to the point where you have the
>> whole process controlled by such a simple flowscript you had to do
>> lots of other very complex stuff to sit behind it.
>
> Not at all. Form population and validation is from XMLForms, persistence
> is Hibernate, and flow is ... well ... flow. The only code I've written
> is simple flowscripts of the kind you've seen and a few simple beans,
> mostly a bunch of properties with getters and setters which, by the way,
> are generated by the editor (jEdit or Eclipse).
Master,
Can you show us the light? As I posted before I never used beans. But
after seeing some comments here. I feel as something is missing to me. I
want to do Java Beans. I use jEdit to work. :-)
> If I were lazier, I'd even use XDoclet to generate the Hibernate
> mapping files from javadoc comments in the source.
This is interesting too. How it works?
Antonio Gallardo
>
> Believe me, you can't get simpler than that.
>
> Ugo
>
>
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, Feb 3, 2003, at 22:58 Europe/London, Ugo Cei wrote:
> Jeremy Quinn wrote:
>> What I meant was that in order to get to the point where you have the
>> whole process controlled by such a simple flowscript you had to do
>> lots of other very complex stuff to sit behind it.
>
> Not at all. Form population and validation is from XMLForms,
> persistence is Hibernate, and flow is ... well ... flow. The only code
> I've written is simple flowscripts of the kind you've seen and a few
> simple beans, mostly a bunch of properties with getters and setters
> which, by the way, are generated by the editor (jEdit or Eclipse). If
> I were lazier, I'd even use XDoclet to generate the Hibernate mapping
> files from javadoc comments in the source.
>
> Believe me, you can't get simpler than that.
This is sounding very interesting!
I have downloaded Hibernate and am reading the docs.
If you get the chance to send me some snippets that aid my
understanding of how this goes together, I would be most grateful.
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Ugo Cei <u....@cbim.it>.
Jeremy Quinn wrote:
> What I meant was that in order to get to the point where you have the
> whole process controlled by such a simple flowscript you had to do lots
> of other very complex stuff to sit behind it.
Not at all. Form population and validation is from XMLForms, persistence
is Hibernate, and flow is ... well ... flow. The only code I've written
is simple flowscripts of the kind you've seen and a few simple beans,
mostly a bunch of properties with getters and setters which, by the way,
are generated by the editor (jEdit or Eclipse). If I were lazier, I'd
even use XDoclet to generate the Hibernate mapping files from javadoc
comments in the source.
Believe me, you can't get simpler than that.
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, Feb 3, 2003, at 18:19 Europe/London, Ugo Cei wrote:
> Jeremy Quinn wrote:
>
>> I see what you mean, but is this not merely hiding a lot of
>> complexity that you have had to put elsewhere?
>
> I don't get your point. Isn't all of OOP about hiding complexity? ;-)
Yea, sorry, I did not explain that very well ....
What I meant was that in order to get to the point where you have the
whole process controlled by such a simple flowscript you had to do lots
of other very complex stuff to sit behind it.
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Ugo Cei <u....@cbim.it>.
Jeremy Quinn wrote:
> I see what you mean, but is this not merely hiding a lot of complexity
> that you have had to put elsewhere?
I don't get your point. Isn't all of OOP about hiding complexity? ;-)
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, Feb 3, 2003, at 14:28 Europe/London, Ugo Cei wrote:
> Jeremy Quinn wrote:
>> 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)
>> OriginalDBActions (obsolete ? )
>> ModularDBActions (Actions are not liked by many)
>> SQL Inserts/Updates using SQLTransformer (maybe not capable of the
>> job due to complexities of the multiple Table updating required ? )
>> SQL Inserts/Updates using ESQL TagLib (complex and difficult to
>> maintain ? )
>> OutputModules+FlowScript (too unknown ? )
>
> XMLForm + FlowScript + some persistence framework.
>
> If you don't use beans for your business entities, you should ;-).
Whoa! ;)
I would not know what a 'business entity' is .... or whether our data
should be one ....
> The application I'm currently working on uses Hibernate for mapping
> objects to an RDBMS, Flow for the application flow control and XMLForm
> for data entry and validation.
>
> It goes something like this (this is a flowscript fragment for
> retrieving a business entity, having "id" as it's POID [1], into a
> bean, associating it with a form, posting it to the user, awaiting
> submission, validating and storing):
>
> session = sessionFactory.openSession();
> var entity = new BusinessEntity();
> session.load(entity, id);
> session.close();
> var form = getForm("entity-form", entity,
> "context://flows/workflow-schema.xml");
> while (true) {
> form.save(cocoon.environment.getObjectModel(), "request");
> sendPageAndWait("entity-form", {});
> form.populate(cocoon.environment.getObjectModel());
> form.validate("phase");
> if (form.getViolations() != null && form.getViolations().size() > 0)
> {
> continue;
> }
> break;
> }
> session = sessionFactory.openSession();
> session.saveOrUpdate(entity);
> session.flush();
> session.close();
>
> IMHO, you can't beat the elegance and clarity of this approach.
I see what you mean, but is this not merely hiding a lot of complexity
that you have had to put elsewhere?
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Ugo Cei <u....@cbim.it>.
Jeremy Quinn wrote:
> 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)
> OriginalDBActions (obsolete ? )
> ModularDBActions (Actions are not liked by many)
> SQL Inserts/Updates using SQLTransformer (maybe not capable of the job
> due to complexities of the multiple Table updating required ? )
> SQL Inserts/Updates using ESQL TagLib (complex and difficult to maintain
> ? )
> OutputModules+FlowScript (too unknown ? )
XMLForm + FlowScript + some persistence framework.
If you don't use beans for your business entities, you should ;-). The
application I'm currently working on uses Hibernate for mapping objects
to an RDBMS, Flow for the application flow control and XMLForm for data
entry and validation.
It goes something like this (this is a flowscript fragment for
retrieving a business entity, having "id" as it's POID [1], into a bean,
associating it with a form, posting it to the user, awaiting submission,
validating and storing):
session = sessionFactory.openSession();
var entity = new BusinessEntity();
session.load(entity, id);
session.close();
var form = getForm("entity-form", entity,
"context://flows/workflow-schema.xml");
while (true) {
form.save(cocoon.environment.getObjectModel(), "request");
sendPageAndWait("entity-form", {});
form.populate(cocoon.environment.getObjectModel());
form.validate("phase");
if (form.getViolations() != null && form.getViolations().size() > 0) {
continue;
}
break;
}
session = sessionFactory.openSession();
session.saveOrUpdate(entity);
session.flush();
session.close();
IMHO, you can't beat the elegance and clarity of this approach.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, Feb 3, 2003, at 15:02 Europe/London, Geoff Howard wrote:
>> -----Original Message-----
>> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>> Sent: Monday, February 03, 2003 9:11 AM
>> To: cocoon-dev@xml.apache.org
>> Subject: SQL Editor
>>
>>
>> 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)
>> OriginalDBActions (obsolete ? )
>> ModularDBActions (Actions are not liked by many)
>
> I have always thought this was only in the context of using Actions for
> flow control.
ie. too much nesting?
> Could someone who dislikes actions (Stefano?) give a quick
> update of where Actions fit into the 2.1 era future of Cocoon now that
> flow is beginning to come of age? And maybe a quick update of where
> they
> could go in the more distant future?
>
> I recently started using the ModularDBActions and found them _very_
> powerful,
> and real time-savers for about 80% of my needs.
That is good to hear, expect lots of dumb questions from me then ;)
thanks
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: SQL Editor
Posted by Geoff Howard <co...@leverageweb.com>.
> -----Original Message-----
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> Sent: Monday, February 03, 2003 9:11 AM
> To: cocoon-dev@xml.apache.org
> Subject: SQL Editor
>
>
> 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)
> OriginalDBActions (obsolete ? )
> ModularDBActions (Actions are not liked by many)
I have always thought this was only in the context of using Actions for
flow control. Could someone who dislikes actions (Stefano?) give a quick
update of where Actions fit into the 2.1 era future of Cocoon now that
flow is beginning to come of age? And maybe a quick update of where they
could go in the more distant future?
I recently started using the ModularDBActions and found them _very_
powerful,
and real time-savers for about 80% of my needs.
Geoff Howard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQL Editor
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, Feb 3, 2003, at 14:26 Europe/London, Luca Morandini wrote:
> I know this has become sort of a joke but... why don't you use stored
> procedures ?
> Yes, MySQL hasn't them, but PostgresSQL has them, and so do many other
> proprietary DBMSes.
>
Unfortunately we already have MySQL in place.
And being pretty green with SQL, would not know a stored procedure from
my elbow ;)
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: SQL Editor
Posted by Luca Morandini <lu...@tin.it>.
Jeremy,
I know this has become sort of a joke but... why don't you use stored procedures ?
Yes, MySQL hasn't them, but PostgresSQL has them, and so do many other proprietary DBMSes.
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> Sent: Monday, February 03, 2003 3:11 PM
> To: cocoon-dev@xml.apache.org
> Subject: SQL Editor
>
>
> 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)
> OriginalDBActions (obsolete ? )
> ModularDBActions (Actions are not liked by many)
> SQL Inserts/Updates using SQLTransformer (maybe not capable of the job
> due to complexities of the multiple Table updating required ? )
> SQL Inserts/Updates using ESQL TagLib (complex and difficult to
> maintain ? )
> OutputModules+FlowScript (too unknown ? )
>
>
> Out of this list, the ability of ModularDBActions to make multiple
> row/table modifications into a discreet transaction makes it sound the
> most attractive.
>
> As for OutputModules+FlowScript, is that even a reality yet?
>
>
> Thanks for any advice.
>
> regards Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org