cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DURDINA Michal <>
Subject Declarative XMLForm
Date Thu, 24 Apr 2003 17:32:19 GMT
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 parameters
of <map:act> as in XMLForm.

      <map:action name="WizardController"
        <command name="" to-view="start"/>
        <command name="prev" from-view="deployment" to-view="userIdentity"/>
        <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" 
          <command name="start" type="constructor" to-view="userIdentity"/>
          <command name="next" from-view="userIdentity"
          <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"/>         

Basically this action takes parameter "command" (from sitemap), finds a rule
for the command and according to rule it serves the view, which is specified
by attribute 'to-view' in the declaration of the command.

Moreover, commands can be model-aware (child of model element) what invokes
validation mechanism from XMLForm ( after populating the request
parameters to the model. The model is defined similarly to original XMLForm

The type attribute of the command can be of 'constructor' or 'destructor'
what defines additional model handling by the command (creating new model on
session, disposing model from session).

This is how the invocation looks like:

      <map:match pattern="wizard*">
        <map:act type="WizardController">
          <map:parameter name="command"
          <map:generate src="wizard/{view}.xml"/>
          <map:transform type="xmlform" label="xml"/>
          <map:transform type="xalan" src="stylesheets/wizard2html.xsl"/>
          <map:serialize type="html" label="debug"/>

Command parameter can be either request parameter (like in XMLForm) or part
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 Form
model implementation from XMLForm and thus it is possible to change the
validator and use the same form model capabilities like in XMLForm(JavaBean,
DOM, ...).

This solution in my opinion leads to something more than just a form
handling tool because it represents the full controller implementation over
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 strong
point due to its maintainability and readability. Only place for Java coders
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

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.


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