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 Fri, 12 Jan 2001 09:39:37 GMT
> > > > > > <util:include-xsp uri="file:///something/included.xml"/>
> > > > > >
> > > > > > Works quite well - as soon as the class representation
> > > > > > of "included.xml" is generated.
> > >
> > > > > > Can anyone think of a way to generate it automatically?
> > > > > > Also changes in "included.xml" need to be recognized.
> > >
> > > 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 ;) ?


> > Since we're trying to use Cocoon more for WebApplications than
> > just for static sites we definitly need better support for forms!
> > (At complex error validation it was a pain!)
> >
> > So I started writing a form taglib.
> >
> >      ..
> >      <form:handler name="theorder">
> >        <form:form name="order"
> >
> uri="file:///E:/JRUN/servers/default/cocoon2/form/order.xml"
> >                   onerror="order"
> >                   next="show"
> >                   />
> >        <form:form name="show"
> >
> uri="file:///E:/JRUN/servers/default/cocoon2/form/show.xml"
> >                   onerror=""
> >                   next="submit"
> >                   />
> >        <form:form name="submit"
> >
> uri="file:///E:/JRUN/servers/default/cocoon2/form/submit.xml"
> >                   onerror=""
> >                   next=""
> >                   />
> >      </form:handler>
> >      ..
> >
> > This is how a set of forms are defined. The form:handler checks the POST
> > data and chooses (based on the input validation) the right form
> to be shown.
> > So we have the a main XSP page that includes another XSP page.
> > (Of course the including is hidden inside the form:taglib)
>
> What you are doing here is mixing service (controller) and presentation
> layer (view). My advice is *DON'T DO IT*. You'll soon find yourself in
> troubles and you are trying to solve it with the wrong approach because
> yyou are already too deep into it. Instead you should strictly separate
> these layers. This is one reason why the sitemap with the different
> components exists.

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.

> The approach I use is that I have XML/XSP files which represents the
> views of my application model (only read access). I write actions for
> the form data validation/processing and the write access to the model
> (actions in fact are for your business logic or at least adapt them).
> And finally let the actions communicate with the other components
> (matcher/selector/generator etc.) using the mechanisms the sitemap
> offers by returning map values from the actions and use them in src
> attributes for your generators. Or use a selector which has the
> knowledge between conditions your actions set and the resources that
> should be produced based upon these condiftion. That way you don't have
> to bind your action directly with your resources.

Could you give a more concrete example, please?

> > My first thought was to use xinclude to get those form-pages. But this
> > only works for static XML - not for XSP. (Actually I think this
> should be
> > changed! It is a better way than generator based including. I
> guess it fits
> > more into the C2 concept)
> > But still the fastest way is calling the XSP pages itself! They all have
> > a class representation when generated - why not using the class
> directly?!
> > Works fine - except for the auto generating of the dependencies...
> >
> > > Admittedly, my criticisms also apply to content aggregation -
> which we do
> > > need explicit support for, I agree.
>
> The handling of request (and parameters) for "internal" requests for
> content aggregation is an issue which is still not clear to me how we
> can/should solve it. Stefanos proposal was based on the fact that
> content aggregation is based on a defined structure (navigation +
> content) and can be solved by an specialized aggregating-generator. This
> might help but is not true in general (portals have another structure
> that form base apps a.s.o)
>
> >
> > Actually I'm a bit skeptical that sitemap aggregation will do
> > what people need... Or better: that this way of aggregation is
> intuitive.
> > I think content aggregation should be "pull" not "push" and sitemap
> > aggregation can only do "pull" at root element level (as far as I
> > understood)
>
> This is a general problem of understanding. Content aggregation at the
> sitemap level is a push, that's right, but content aggregation at the
> xinclude level is a pull.

That's why I like xinclude so much ;)

> What we need is an uniform mechanism to get at
> those contents directly in a form like:
>
>     URL url = new URL("cocoon://my/internal/uri");
>     url.setContentHandler(this);
>     url.getContent();
>
> With such a mechanism it would be easy to realize both (push and pull)
> variants and we don't have the need to reparse the response again.

Well, actually I don't see why such a mechanism help on this...

For "pull" there still needs to be a tag "insert here".
Not for "push". "push" could place the content at a (via XPath
defined) position or be at root level.
--
Torsten


Mime
View raw message