What's the Problem about flow. It's also very simple with coocon.
Because a page that redirect doesn't output anything, why
you dont't use a simple JSP page. from there you can redirect
to an XML/XSP page with output.

Christoph Gaffga


----- Original Message -----
From: "Ulrich Mayring" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 11, 2001 3:37 PM
Subject: Re: AW: [C2] Redirects


> Berin Loritsch wrote:
> >
> > Oh, you aren't being fair.  Just because it is too easy to do in
> > scripting frameworks, doesn't mean we should allow the same abuse
> > of redirects in Cocoon.  You just have to think harder.
>
> Well, it's a design decision. I expect from a web publishing framework
> that it allows me to build web applications. And redirects are IMHO a
> big part of it, they provide program flow. I don't see how a framework
> could suffer, if it offers redirects - nobody is forced to use the
> redirects, but it should be possible. If you know of another way to do
> program flow, please tell me. But web apps are based on HTTP requests
> and thus, if I want to do a new thing, I have to make a new HTTP
> request.
>
> > Regarding logic in the sitemap, I whole-heartedly agree.  Business logic
> > does not belong in the sitemap.  Period.  If you do that, your business
> > logic is at the mercy of the sitemap administrator.
>
> Program flow is a large part of business logic :)
>
> > Regarding the proprietary format: there was no standard for this type of
> > thing.  If you show us a standard on URI space management that keeps the
> > filesystem and the URI space orthagonal, we will definitely look at
integrating
> > it.  Unfortunately, this is something that is up to whatever framework
> > you use.
>
> Cocoon1 provides a simple way to code program flow into the XML pages
> themselves. This is not proprietary if done with logicsheets, because
> the XML files themselves are just an interface, that could be
> implemented differently if moving outside the Cocoon world. URI space
> management should not get in the way of program flow, these are IMHO two
> different issues.
>
> > Also regarding the proprietary format:  Cocoon can be used accross many
> > servlet engines.  This reduces the risk of using Cocoon.  If you decide
> > to switch frameworks, well you have the overhead of removing one
> > infrastructure and implementing a new one.  I don't care how "standard"
> > something is--there is always some point of a little rework that needs
> > to be done.
>
> It's not up to me what framework our business partners use. But I have
> to able to communicate with them - the Sitemap is an inappropriate
> format for this communication. It's too low-level, we need to think in
> concepts :-)
>
> > I believe redirects as a result of business logic belong in Actions.
That
> > logic can be a result of a parameter or whatever--but I don't think the
sitemap
> > is the place for it.  But given your previous arguments that you would
argue
> > that Actions are also proprietary.
>
> Not if they provide a neutral interface like XSP taglibs do. Hey, Avalon
> is full of interfaces :)
>
> > Does the solution I provided above work for you?  By tying your logic to
session
> > beans, you have a portable infrastructure that minimizes dependance on
some aspects
> > of Cocoon.
>
> I like XSP taglibs, because XML is more a standard than Beans. I can't
> give Beans to folks not using Java, but I can give them XML.
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>


---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Reply via email to