cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ivelin" <>
Subject Re: Declarative XMLForm
Date Fri, 25 Apr 2003 12:24:13 GMT
Certainly an interesting alternative, provided that command/view combination
defines unique output most of the time.
How would you code additional dependencies.
For example if command is "next" and view is "configuration", then
1) if "customize color" option is selected, display view "costomize color"
2) otherwise skip straight to "customization complete"

----- Original Message -----
From: "DURDINA Michal" <>
To: <>
Sent: Thursday, April 24, 2003 12:32 PM
Subject: Declarative XMLForm

> Hello,
> I just finished first iteration of developing the new action
> XMLFormController. It implements another solution to XMLForm and it is
> intended to be alternative to AbstractXMLFormAction.
> XMLFormController is similar to AbstractXMLFormAction but it does not
> require to code the flow between pages in perform() method.
> It extends ConfigurableComposerAction and hence it is configured only once
> in declaration of the action in <map:components> instead of using
> of <map:act> as in XMLForm.
>       <map:action name="WizardController"
> src="org.apache.cocoon.samples.xmlform.XMLFormController">
>         <command name="" to-view="start"/>
>         <command name="prev" from-view="deployment"
>         <command name="prev" from-view="system" to-view="deployment"/>
>         <command name="prev" from-view="confirm" to-view="system"/>
>         <model id="form-feedback"
> class="org.apache.cocoon.samples.xmlform.UserBean" scope="session"
>           validator-engine=""
> validation-schema="schematron/wizard-xmlform-sch-report.xml">
>           <command name="start" type="constructor"
>           <command name="next" from-view="userIdentity"
> to-view="deployment"/>
>           <command name="next" from-view="deployment" to-view="system"/>
>           <command name="next" from-view="system" to-view="confirm"/>
>           <command name="next" type="destructor" method="send2db"
> from-view="confirm" to-view="end"/>
>         </model>
>       </map:action>
> Basically this action takes parameter "command" (from sitemap), finds a
> for the command and according to rule it serves the view, which is
> by attribute 'to-view' in the declaration of the command.
> Moreover, commands can be model-aware (child of model element) what
> validation mechanism from XMLForm ( after populating the request
> parameters to the model. The model is defined similarly to original
> parameters.
> The type attribute of the command can be of 'constructor' or 'destructor'
> what defines additional model handling by the command (creating new model
> session, disposing model from session).
> This is how the invocation looks like:
>       <map:match pattern="wizard*">
>         <map:act type="WizardController">
>           <map:parameter name="command"
> value="{request-param:cocoon_xmlform_command}"/>
>           <map:generate src="wizard/{view}.xml"/>
>           <map:transform type="xmlform" label="xml"/>
>           <map:transform type="xalan" src="stylesheets/wizard2html.xsl"/>
>           <map:transform
> src="context://stylesheets/system/xmlform2html.xslt"/>
>           <map:serialize type="html" label="debug"/>
>         </map:act>
>       </map:match>
> Command parameter can be either request parameter (like in XMLForm) or
> of url which is sometimes desirable i.e.:
>       <map:match pattern="wizard/*">
>         <map:act type="WizardController">
>           <map:parameter name="command" value="{1}"/>
> To achieve this I needed to make only few hacks to xmlform2html.xsl (all
> backward compatible) and implement the action. The new action uses the
> model implementation from XMLForm and thus it is possible to change the
> validator and use the same form model capabilities like in
> DOM, ...).
> This solution in my opinion leads to something more than just a form
> handling tool because it represents the full controller implementation
> all pages on one object i.e. it serves all pages for maintaining the
> customers (view, filter, add, edit, delete, ...) and it encapsulates the
> whole area of pages under management of only one action (i.e. mapped to
> http://host/webapp/customers/*.html). The declarativeness is another
> point due to its maintainability and readability. Only place for Java
> is now the implementation of user-defined methods (command attribute
> 'method') that are responsible for querying the database and handling flow
> in error states (no data found - go somewhere else than usual).
> Signature for user-defined method is currently (it is still evolving :):
>   public String perform(String command, String fromView, String toView,
> String role, Object model)
> Method should return the next view to show, usualy 'toView' parameter is
> returned.
> Tell me please your opinion on such a functionality of this controller, I
> have many other ideas and going to implement them. We will build the web
> layer for our new project on this approach so it is sure that I will spend
> much more time on it. I would like to share it in the cocoon comunity so
> tell me if you are interested and what suggestions you have.
> Regards,
> Michal
> PS: Attached source containes 'untidy' version of XMLFormController :)
> -- MisoD --
> Michal Durdina -
> ASSET Soft a.s.,
> Kosicka 56, Bratislava, 821 08
> Slovakia, Europe

View raw message