cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Sylvain.The...@swisscom.com>
Subject RE: XMLForm: view/edit functions
Date Wed, 23 Apr 2003 15:47:03 GMT
Hi Adrian,

Thanks for your description.

>My approach at the time was to separate page structure (form) from page
>data, joined together by a <map:aggregate/> sitemap element.
***similar to XMLForm that allow to separate data (in a JavaBean or XML file) and views.

>For the data fragment, I had 3 different sources - from the database
>(record-read, used for view/edit), from a static XML file (for new defaults)
>and from the request object (re-insert submitted parameters for error
>handling). 
***I have only one source for the data: a database. To access to this database, I have implemented
a object-relationnal mapping with a tool called OJB.

>The fields in the form were bound to the data using attributes containing
>XPath expressions
***like XMLForm.

The first thing (and my main problem) I need is a mechanism that add a link or a button containing
the "path" (ex. http://view?id=215) to the page displayed.
I think I have 2 solutions:
- add the link or button directly in the XMLForm view => I think that I need to create
new tags and modify the XMLFormTransformer
- add the link or button with the xsl stylesheet => I need to modify the stylesheet

I don't know which solution is better or harder.

I think that I don't have only one solution.
I'm trying to find the best solution in the "idea of XMLForm".


Regards
Sylvain


-----Message d'origine-----
De: Geissel, Adrian [mailto:adrian.geissel@ecb.int]
Date: mercredi, 23. avril 2003 09:09
À: 'cocoon-dev@xml.apache.org'
Objet: RE: XMLForm: view/edit functions


Hi Sylvain,
While I have not explicitly used XForms / XMLForms, I have built something
similar a couple of years back (haven't we all at some point?).

My approach at the time was to separate page structure (form) from page
data, joined together by a <map:aggregate/> sitemap element. This allowed me
to combine them in different contexts. 

For the data fragment, I had 3 different sources - from the database
(record-read, used for view/edit), from a static XML file (for new defaults)
and from the request object (re-insert submitted parameters for error
handling). 

The 'form' fragment was an XSP with two modes - read-only (view) or
read-write (new/edit). The reason for XSP was to allow certain fields to be
hiddem / annotated or changed structurally. 

The fields in the form were bound to the data using attributes containing
XPath expressions into the data fragment, which the xalan:evaluate extension
(now also available in EXSLT) was used to dereference. 

Once combined, the master XSLT worked the combined XML stream and to react
to the form structure to produce the (almost: i18n/CSS to come) final
layout. 

In (amateur) ASCII form, the pipelines were something like:

                                            +----new/xxx.xml
   http://xxx.new    <----<form2html.xslt>--A
                                            +----form/xxx.xsp?edit=Y


   --- called from search result listings, similar to your scenario

                                            +----read/xxx.xsp?id=123
   http://xxx.view   <----<form2html.xslt>--A
                                            +----form/xxx.xsp?edit=N

                                            +----read/xxx.xsp
   http://xxx.edit   <----<form2html.xslt>--A
                                            +----form/xxx.xsp?edit=Y


  --- called when a database update action failed 

                                            +----error/xxx.xsp
   http://xxx.upd    <----<form2html.xslt>--A
                                            +----form/xxx.xsp?edit=Y


To conclude - the approach worked a treat for easy to produce / maintain
forms and data sources, but the form2html.xslt file was rather complicated
(although reasonably performant, given its purpose), but this was acceptable
for the application and the team - afterall, it only had a single purpose
;-)

I hope this helps. or gives some ideas,
/Adrian


> From: Sylvain.Thevoz@swisscom.com [mailto:Sylvain.Thevoz@swisscom.com]
> Sent: Wednesday 23 April 2003 08:10
> To: cocoon-dev@xml.apache.org
> Subject: XMLForm: view/edit functions
> 
> 
> Hello,
> 
> I'm using XMLForm to implement a web application where data 
> are stored in a database.
> Main "functions" for an application that manage data are: add 
> - delete - search - view/edit.
> The "functions" add, delete and search are (relatively) easy 
> to implement with XMLForm.
> 
> My problem is how to implement the view/edit functions (from 
> a search result).
> 
> My goal:
> 
> When I search data the result looks like:
> 
> Id	name		type
> --	----		----
> 1	test1		type1
> 3	test5		type3
> 8	test45	type1
> 
> The idea is to add a link or a button to the result like:
> 
> Id	name		type
> --	----		----
> 1	test1		type1		view	edit
> 3	test5		type3		view	edit
> 8	test45	type1		view 	edit
> 
> The view and edit button/link should contain information 
> about the item (the Id) and allow to view/edit the item (in 
> another view or another XMLForm application).
> 
> Is anyone has an experience about this?
> 
> Thanks
> Sylvain
> 

Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither
be binding nor construed as constituting a commitment by the ECB except where provided for
in a written agreement.
This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised
disclosure, use or dissemination, either in whole or in part, is prohibited.
If you have received this e-mail in error, please notify the sender immediately via e-mail
and delete this e-mail from your system.


Mime
View raw message