cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DURDINA Michal <durd...@asset.sk>
Subject RE: Declarative XMLForm
Date Sun, 27 Apr 2003 09:36:24 GMT
First of all, this probably should not happen in well designed view, because
all command invocations should be represented only by links/buttons.
Therefore instead of "customize color" checkbox, there should be a button
"Customize color" for invoking a customization command (i.e. custcolor)
which will lead to customization view and of one button "Finish" to invoke
finish command which will lead to confirm view or whatever.
Example
<command name="custcolor" from-view="configuration"
to-view="customize-color"/>
<command name="finish" from-view="configuration" to-view="confirmation"/>

If you need to handle special view selection, which couldn't be handled just
by prev_view+command pair distinction then you need to implement
user-defined method for the command and chose the next view there.
Example

<command name="next" from-view="configuration" method="chooseView"
to-view="confirmation"/>

public String chooseView(String command, String fromView, String toView,
String role, Object model) {

  // there's only one 'toView' atribute thus it doesn't make much sense to
use it this case

  if (getRequest().getParameter("customizecolor") == null)
    return "confirmation"
  else
    return "customize-color";
}

Any other view selection than based on command+from-view requires to extend
command declaration (as proposed in
http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormViewAbstractionDraft) but I
am affraid that 


. There should be one button (command) to "Finish" and another 

> -----Original Message-----
> From: ivelin [mailto:ivelin@apache.org]
> Sent: Friday, April 25, 2003 2:24 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Declarative XMLForm
> 
> 
> 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"
> 
> 
> 
> -=Ivelin=-
> ----- Original Message -----
> From: "DURDINA Michal" <durdina@asset.sk>
> To: <cocoon-dev@xml.apache.org>
> 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
> parameters
> > 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"
> 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"
> >           validator-engine="http://www.ascc.net/xml/schematron"
> > validation-schema="schematron/wizard-xmlform-sch-report.xml">
> >           <command name="start" type="constructor"
> to-view="userIdentity"/>
> >           <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
> 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 (Form.java) after 
> populating the request
> > parameters to the model. The model is defined similarly to original
> XMLForm
> > parameters.
> >
> > 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"
> > 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
> 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
> > 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 - durdina@asset.sk
> > ASSET Soft a.s.,
> > Kosicka 56, Bratislava, 821 08
> > Slovakia, Europe
> >
> >
> 

Mime
View raw message