> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> From: "Konstantin Piroumian" <[EMAIL PROTECTED]>
> > > From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> > > Ok, then can someone please explain me what resources are for?
> >
> > Is it possible to use actions inside of a resource? If no then with
> > <map:forward /> you'll have that possibilty. If yes, then I
> don't know
> > any other difference between a resource and an 'internal-only'
> > pipeline.
>
> Resources can be incomplete pipelines.
Ok. So we can state that the only difference is that resources are not
matched with requests. Right?
>
> > > I don't like redirects at all, because they tend to
> spread logic in
> > > parts of the sitemap; these pipelines are part of a
> algorithm only
> > > in the developers
> > > mind.
> > > No explicit contract, and it's difficult to maintain.
> > >
> > > redirects==GOTO
> > > GOTO==bad
> > > --> redirect==bad
> >
> > Agree for real redirects. They should be avoided when
> possible. But...
> >
> > >
> > > The flowmap will eliminate needs for redirects, like
> whiles and ifs
> > > eliminated the need for gotos.
> >
> > ... I don't think that flowmap will remove internal redirects
> > completely - it will simply replace them by selectors. A simple
> > scenario can look like
> > this:
> >
> > <map:match pattern="flow-input">
> > <map:act type="ProcessFlowEvent">
> > <map:select type="flow-state">
> > <map:when test="in-process">
> > <map:call resource="show-page">
> > <map:parameter name="current-page"
> > value="{page}" />
> > </map:call>
> > </map:when>
> > <map:when test="finished">
> > <map:call resource="show-success-page" />
> > </map:when>
> > ...
> > </map:act>
> > <!-- Perform this if 'null' was returned -->
> > <map:call resource="default-page" />
> > </map:match>
> >
> > (Hm... not very simple, though)
> > <map:forward-to /> or <map:redirect-to uri="cocoon:/" /> are simply
> > ways
> to
> > use pipelines as resources and nothing else (no real
> redirects!). So,
> > you could use matchers for displaying some of the pages in
> the above
> > example.
>
> This is not done with the javascript flow stuff.
> Ovidiu, how would you write it?
Yes, really how would you do it? As I remember, there was mentioned that
flow script interacts with the sitemap and the sitemap interacts with the
flow script. It's very interesting how it looks like in a real life sample.
>
> > > I'm -1 for this, unless you can show me that the flow
> system is not
> > > able to supplant the need for redirects.
> >
> > You cannot be -1 for this, because it is already implemented in the
> > treeprocessor sitemap ;). I'm just proposing a more obvious
> name for
> > <map:redirect-to uri="cocoon:/" /> as it is confusing and
> the reason
> > of raising this here were messages in Cocoon Users List.
>
> It's there now because the flow stuff is not there yet, but I
> would be very happy to see redirects go away.
Btw, real redirects will be needed in any case when you would need to
redirect the user somewhere out of the current webapp context, some external
resource.
>
> I'm -1 for your proposal, since it basically states as a
> contract something that IMO should be discouraged.
>
> IIRC the redirect was deprecated in favor of the call stuff,
> am I correct?
Yes, you are correct. But call cannot be used with pipelines and, IMO, it's
an unnecessary limitation.
>
> Originally Cocoon didn't have explicit redirects, because it
> seemed they weren't necessary to publish sites. But then it
> was started to be used heavily as a webapp creation system,
> and hence the Action and redirects and so on.
>
> Now that there is a flow system, we should force ourselves
> IMO to use the clean flow solution instead of internal redirect hacks.
Any other opinions?
>
> You like declarative? Then try to make a charting stylesheet
> in xsl like brother John did, and we will see if you still like it ;-P
Charting in XSL? Sounds terrific ;)
Konstantin
>
> --
> Nicola Ken Barozzi [EMAIL PROTECTED]
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
