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.

> > 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?

> > 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.

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?

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.

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

--
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]

Reply via email to