cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <tcu...@dff.st>
Subject RE: generator based including
Date Sun, 14 Jan 2001 15:13:15 GMT
> > > > > Those are exactly what the roles of XSPGenerator are supposed
> > > > > to be, no?
> > > > > Compiling and dependency tracking.
> > > >
> > > > Yeah, that's what I thought. So the util:include-xsp adds the given
> > > > file to the dependency list of the requested page. I thought this
> > > > would be enough... obviously it is not! :(
> > 
> > Even if this will not make it into C2...
> > ...shouldn't it work this way - in theory ;) ?

Please - answer :) PLEASE, I WANNA KNOW ;)



> > Why do I mix it? Because of the form:handler tag inside the
> > including page?
> > I don't know if this really true, because all the handler does
> > is handing the data over to the elements class representation.
> > 
> >         <form:textbox name="ord_firstname"
> > class="st.dff.desire.forms.order.ord_firstname" width="10">
> >           <caption>First name</caption>
> >         </form:textbox>
> > 
> > This is how a textbox is defined. The class does all the validating
> > and business logic. If the element object says "posted data was not
> > valid" then the handler will not step to the next form.
> > That's how it works with my form:taglib.
> 
> This is what I tried to explain. Validating form data is not the concern
> of an XSP page. They are simply not designed to do that in a correct way
> because XSP page are the views in the MVC model. An XSP page was
> designed to generate the view of a resource, nothing more, nothing less.

But the XSP page doesn't do the data validation! It just generates the
view of the element! The validation happens in a separate class that
has no real connection to the XSP page (it is nothing more but a binding)!


> Look at other web app frameworks like Turbine or Struts. They do it
> exactly the same way because of that. Turbine separates between Screens
> and Actions and an Action is able to determine the next Screen to
> display. Struts uses a Servlet as the controller and delegates
> processing to Actions as well (you see same name for the same thing) and
> forward to the JSP that produces the next page. 

I admit from a logical point of view that what I called form:handler
could (or even should) be in the sitemap. Although (or because) it just
selects the view! The validation happens somewhere else.

But then let me understand this and let us get more into detail..

Let's say I have main page "wizard" that has two forms in it.
A login form and a order form (whatever)

  wizard page
    +- login form +- login view
    |             +- logout view
    |
    +- order form +- page1 view
                  +- page2 view
                  +- submit view

With views like this:

login:
   <form action="process-loginform">
     <input name="process" type="hidden" value="viewlogout"/>
     <input type="submit"/>
   </form>

logout:
   <form action="process-loginform">
     <input name="process" type="hidden" value="viewlogin"/>
     <input type="submit"/>
   </form>

page1:
   <form action="process-orderform">
     <input name="process" type="hidden" value="viewpage2"/>
     <input type="submit"/>
   </form>

page2:
   <form action="process-orderform">
     <input name="process" type="hidden" value="viewsubmit"/>
     <input type="submit"/>
   </form>   
submit:
   Thanks!

So my sitemap is:

   <map:match pattern="forms/wizard">
     <map:act set="login"/>
     <map:act set="order"/>
     <map:generate type="serverpages" src="docs/samples/forms/wizard.xsp"/>
     <map:transform src="stylesheets/dynamic-page2html.xsl"/>
     <map:serialize/>
   </map:match>

With two action sets:

 <map:act set="login">
    <map:act type="doLogout" action="viewlogin"/>
    <map:act type="doLogin" action="viewlogout"/>
    <map:generate src="{nextview}"/>
 </map:act>

 <map:act set="order">
    <map:act type="checkPage1" action="viewpage2"/>
    <map:act type="checkPage2" action="viewsubmit"/>
    <map:generate src="{nextview}"/>
 </map:act>

And then implement the actions "doLogout","doLogin",
"checkPage1","checkPage2" which all return a "nextview"

Did I get this right?
--
Torsten

Mime
View raw message