Re: AW: [C2] Redirects
At 12:21 PM +0200 11/7/01, Ulrich Mayring wrote: Doing a 'grep -r sendRedirect * | wc -l' on the above app I get 104. Does this mean I have to write 104 actions? Or is it possible to write a generic redirect action If they are all totally different sendRedirect tests, used only once in individual xsp pages, you may need to write a comprehensive set of actions. But I expect in reality it will be a lot less than 104. (without seeing your application. :-) ) Perhaps 80 or so. I think in its current state Cocoon2 ties me up too much, I want more freedom :-) This reminds me of something I brought up in the dev list a while ago, compiling Cocoon 2 Actions from XSP TagLibs. XSP Actions would not output anything, you'd just use them to control stuff. (Like Redirects ;) In two projects I've worked on, Crudlet and FP TagLibs, it would make sense to do stuff like validating, writing (to Bean or XML) in an Action, while reserving output functions to XML or XSP Generators; controlled by the SiteMap. Unlike the Cocoon 1 approach which is to join them together. I often have found myself in a situation with Cocoon 1 of being forced to have the form hander from the previous page and the form generator for the next page in the same file. In Cocoon 2 you can have the reverse (which makes more sense to me), a URL along with runtime information selects a pipeline to do those separate jobs, moving control from XSP to the SiteMap. Being able to make Actions using XSP TagLibs allows existing XSP languages a route into the 'ideal' way of working with Cocoon 2, where they have developed out of the usage patterns in Cocoon 1. If the same TagLib languages could be used in both 'realms', Actions and XSP; it would be easy to author TagLib languages that allowed Actions and Generators to communicate. Also it could allow a wider range of people to develop Actions and make it easier to maintain a larger number of them. regards Jeremy -- ___ Jeremy Quinn Karma Divers webSpace Design HyperMedia Research Centre mailto:[EMAIL PROTECTED]http://www.media.demon.co.uk phone:+44.[0].20.7737.6831pager:[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]
Re: AW: [C2] Redirects
On Sun, 15 Jul 2001, Jeremy Quinn wrote: Being able to make Actions using XSP TagLibs allows existing XSP languages a route into the 'ideal' way of working with Cocoon 2, where they have developed out of the usage patterns in Cocoon 1. Why not drop Actions altogether and instead put XSP taglibs in that place? It's all just Java, so why should we have two places to do our custom logic? From what I hear Actions allow more than XSP (redirects etc.), but XSP taglibs have the better interface (XML). So just put XSP in the place, where Actions are right now and we'd all be fine? Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung - 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]
Re: AW: [C2] Redirects
On Sun, 15 Jul 2001, giacomo wrote: On Sun, 15 Jul 2001, Uli Mayring wrote: Why not drop Actions altogether and instead put XSP taglibs in that place? It's all just Java, so why should we have two places to do our custom logic? From what I hear Actions allow more than XSP (redirects etc.), but XSP taglibs have the better interface (XML). What do you mean by better interface (XML)?. Giacomo That XSP has an XML interface and thus is decoupled from the implementation. I can give my XSP files to someone, who does not use Java or Cocoon, and he can implement it with whatever tools he likes to use. XML is ubiquitous on all platforms, everything that exposes itself to the world should have an XML interface these days. Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung - 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]
Re: AW: [C2] Redirects
Uli, have you thought about redesigning the SOAP taglib (logicsheet?) so that it is portable to C2? I would need to have it running fairly soon and am ready to put in some eforts :-) With regards to the auth taglib, I would still suggest that you look into the RequestIntercepter implementation of the Context Based Security spec. It is 100% portable (between C1 and C2 of course :-) Drasko --- Uli Mayring [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2001, Berin Loritsch wrote: I think you may already be used to not getting the output stream in Cocoon 1. In Cocoon1 it is actually possible to get the OutputStream, I'm using that in my soap taglib. My auth taglib makes heavy use of redirects (such as redirecting you to the login page, if you try to access a protected page and have not authenticated). So these two taglibs, which I use a lot in my Cocoon1 apps, are not portable to Cocoon2. Back when XSP taglibs first appeared, it was said that their advantage is that implementations can change, the interface remains the same. Of course now that XSP itself works differently, this advantage is gone. It's always a trade-off between backwards compatibility and new features. I'm sorry to hear that the XSP model was not deemed fit to last across different versions of Cocoon - I wonder if it will change again for Cocoon3. Perhaps the answer lies elsewhere: implement XSP as an Avalon block, add some parts of Tomcat, Xerces and Xalan as blocks and I won't need Cocoon anymore to build web applications. That's the beauty of OpenSource, that these things are possible. The objects you seek are all in the Map objectModel passed in to your pages. for XSP, the Request, Context, and Response objects are stored as class variables. Through them, you can get your Session and Cookie objects as usual. other than sendRedirect and getting a reference to the output stream, nothing should be hidden from you. Ok, thanks for the info, Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung - 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] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - 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]
Re: AW: [C2] Redirects
Drasko Kokic wrote: Uli, have you thought about redesigning the SOAP taglib (logicsheet?) so that it is portable to C2? I would need to have it running fairly soon and am ready to put in some eforts :-) With regards to the auth taglib, I would still suggest that you look into the RequestIntercepter implementation of the Context Based Security spec. It is 100% portable (between C1 and C2 of course :-) Well, Berin said it is not possible to do redirects in XSP, now you're saying this is possible after all? The problem with the SOAP taglib is that it needs access to the output stream. A SOAP service may not only return XML, it may also return a PDF or something else, that needs to be returned as is to the user, i.e. without any further processing by Cocoon. 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]
Re: AW: [C2] Redirects
Drasko Kokic wrote: Uli, have you thought about redesigning the SOAP taglib (logicsheet?) so that it is portable to C2? I would need to have it running fairly soon and am ready to put in some eforts :-) With regards to the auth taglib, I would still suggest that you look into the RequestIntercepter implementation of the Context Based Security spec. It is 100% portable (between C1 and C2 of course :-) I believe the CVS for Cocoon 2.1 has SOAP support using the Axis jar. You may want to verify It was included in Cocoon 2.1 due to its newness and it not being tested yet. As to the Context Based Security spec, do you have a URL? I am interested in looking at it. Drasko --- Uli Mayring [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2001, Berin Loritsch wrote: I think you may already be used to not getting the output stream in Cocoon 1. In Cocoon1 it is actually possible to get the OutputStream, I'm using that in my soap taglib. My auth taglib makes heavy use of redirects (such as redirecting you to the login page, if you try to access a protected page and have not authenticated). So these two taglibs, which I use a lot in my Cocoon1 apps, are not portable to Cocoon2. Back when XSP taglibs first appeared, it was said that their advantage is that implementations can change, the interface remains the same. Of course now that XSP itself works differently, this advantage is gone. It's always a trade-off between backwards compatibility and new features. I'm sorry to hear that the XSP model was not deemed fit to last across different versions of Cocoon - I wonder if it will change again for Cocoon3. Perhaps the answer lies elsewhere: implement XSP as an Avalon block, add some parts of Tomcat, Xerces and Xalan as blocks and I won't need Cocoon anymore to build web applications. That's the beauty of OpenSource, that these things are possible. The objects you seek are all in the Map objectModel passed in to your pages. for XSP, the Request, Context, and Response objects are stored as class variables. Through them, you can get your Session and Cookie objects as usual. other than sendRedirect and getting a reference to the output stream, nothing should be hidden from you. Ok, thanks for the info, Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung S/MIME Cryptographic Signature
AW: [C2] Redirects
Hi, we had several month ago a lengthy discussion about this redirection thing. These are the two major reasons for removing the redirect from the xsp: 1. Working in a servlet environment and doing redirects is not that easy. If you do a redirect when something is written already to the output it is strictly forbidden by the servlet api. As when the XSP is executed there might be something already written to the output, the redirect might not work in some cases. 2. We believe that the web application flow has nothing to do with the content. As the XSP is building content it is the wrong place for redirects. The right place for application flow and redirects is the sitemap in c2. So you can make redirects in the sitemap using the map:redirect-to element or you can write your custom action which can do a redirect. Carsten Open Source GroupsunShine - b:Integrated Carsten Ziegeler, SN AG, Klingenderstrasse 5, D-33100 Paderborn www.sundn.de mailto: [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Anders Lindh [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 11. Juli 2001 08:18 An: [EMAIL PROTECTED] Betreff: [C2] Redirects I'm sending this again as I didn't get an answer last time... Hi, I know this issue has been discussed many times earlier on this list, but I couldn't find a conclusion to why response.sendRedirect has been removed from XSPResponseHelper (supposedly has to do with SAX?). Are there any known work-arounds for this? I really need to be able to issue redirects from XSP pages, and not from the sitemap. Migrating from C1 becomes so much more complicated when XSP redirects are not available... Thanks, - Anders Lindh - 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]
AW: [C2] Redirects
Anders Lindh wrote: Migrating from C1 becomes so much more complicated when XSP redirects are not available... I agree. There's no way I can port my old Cocoon1 apps without redirects being available conditionally (i.e. depending on user input). Perhaps this is possible with the Sitemap, but I don't know how. You should definitly have a look into actions... -- Torsten This works perfectly using actions. I solved a problem where the stylesheet for a document depends on a field in the database using actions. I think you can solve nearly everything with the action concept, though its on the first sight a bit more complicated than in cocoon 1 (but it's better designed now). Stefan - 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]
Re: AW: [C2] Redirects
On 11.Jul.2001 -- 10:08 AM, Ulrich Mayring wrote:
Carsten Ziegeler wrote:
The right place for application flow and redirects is the sitemap in
c2. So you can make redirects in the sitemap using the map:redirect-to
element or you can write your custom action which can do a redirect.
But how to do that conditionally then? Here's some code from one of my
Cocoon1 apps:
String param = request.getParameter(param);
if (param == null||param.equals())
response.sendRedirect(error.xml?apperror=1526);
This redirects the user to an error page, if his input is not ok. I have
lines like this in most of my XSP pages. Another example:
if (status.startsWith(active)) {
// Send notification mail
response.sendRedirect(mail/NOTIFY_CUSTOMER.xml);
else if (status.startsWith(begin)) {
// Send error fax
response.sendRedirect(fax/NOTIFY_CUSTOMER.xml);
Doing a 'grep -r sendRedirect * | wc -l' on the above app I get 104.
Does this mean I have to write 104 actions? Or is it possible to write a
generic redirect action - in that case it should be included in the
distribution :)
Have a look at the form validation action and request parameter value
selctor(*) provided with cocoon2
Chris.
(*) will appear today in HEAD
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
-
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]
Re: AW: [C2] Redirects
Hi Ulrich,
I've found that over time, my sitemap testing has moved from focusing
on technical nitty gritty to focusing on concepts. Its a subtle
difference, but it makes conditional checking for your examples below
a little easier.
On Wed, 11 Jul 2001, Ulrich Mayring wrote:
But how to do that conditionally then? Here's some code from one of my
Cocoon1 apps:
String param = request.getParameter(param);
if (param == null||param.equals())
response.sendRedirect(error.xml?apperror=1526);
You could do this in the sitemap testing the value of param for null
or , and then using map:redirect-to.
map:select type=param-test
map:when test=
map:redirect-to uri=error.xml?apperror=1526/
/map:when
!-- and so on --
/map:select
All you need there is a selector which will bring the request
parameter 'param' into scope for testing. Not to difficult to write (I
posted an interpreter based param selector to the list
october/november last year).
Generically speaking, you can do this kind of test/redirect with any
resource. Selectors can test anything.
Note, for parameter testing, I might not follow this approach - if you
need to test 10 form values for example. (as you can see, you'll end
up with an extensive sitemap containing too much detail - this is what
I was describing above, with my shift from describing technical detail
in sitemap pipelines, to concepts).
I would write a validation action.
map:match ...
map:act type=validate/
!-- and so on, assuming validation works --
/map:match
And use the Redirector element of the action API. Then your code above
goes into the validation action you write (almost exactly as it is
above), with the call being redirector.redirect(..); instead of
response.sendRedirect(..).
What you've done above will work, you just need to relocate the code
out of your xsp page, into an action class. Optionally, you could
also write a c2 generic or application specific validator class to
reuse code. (there's already a generic formvalidatoraction in the c2
source now).
Now, be aware there is a trade off here, sending a redirect from
within an action will mean you'll have control flow code outside of
the sitemap.
An alternative is to return a value from your action to the sitemap
for testing and then sitemap redirection.
map:match ...
map:act type=validate/
map:select type=validatortester
map:when test=invalid
map:redirect-to uri=.../
/map:when
map:otherwise
!-- and so on, assuming validation works --
/map:otherwise
map:select
/map:match
In this case you'll need to write an action and a selector.
As you can see, the trade off here is in sitemap size, complexity
and readability. I am not baised to either, as I see benefits in both
approaches. The other developers might see this differently. The
choice is up to you.
This redirects the user to an error page, if his input is not ok. I have
lines like this in most of my XSP pages. Another example:
if (status.startsWith(active)) {
// Send notification mail
response.sendRedirect(mail/NOTIFY_CUSTOMER.xml);
else if (status.startsWith(begin)) {
// Send error fax
response.sendRedirect(fax/NOTIFY_CUSTOMER.xml);
Doing a 'grep -r sendRedirect * | wc -l' on the above app I get 104.
Does this mean I have to write 104 actions? Or is it possible to write a
generic redirect action
If they are all totally different sendRedirect tests, used only once
in individual xsp pages, you may need to write a comprehensive set of
actions. But I expect in reality it will be a lot less than 104.
(without seeing your application. :-) )
Hope that helps.
Cheers,
Marcus
--
.
,,$, Marcus Crafter
;$' ':Computer Systems Engineer
$: : Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$,_/\ :' 60327 Frankfurt Germany
' /(
\_' Email : [EMAIL PROTECTED]
.Business Hours : +49 69 9757 200
:
-
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]
Re: AW: [C2] Redirects
Marcus Crafter wrote: [...] Ok, thanks a lot for your info. I now understand it is possible, but extremely complicated and verbose to do redirects in Cocoon2 :-) I've found that over time, my sitemap testing has moved from focusing on technical nitty gritty to focusing on concepts. Its a subtle difference, but it makes conditional checking for your examples below a little easier. I'm all for thinking in concepts, but here comes my old gripe again: the Sitemap is a proprietary format, I don't want to put concepts into proprietary structures. Concepts are things that need to be communicated to other departments, to other companies, to end users - you want a generic XML structure for that, not a Cocoon-specific thing. Now, be aware there is a trade off here, sending a redirect from within an action will mean you'll have control flow code outside of the sitemap. IMHO control flow does not belong in the Sitemap at all, because it is a proprietary structure. It's ok to use proprietary structures as implementations of generic interfaces - but it's not good to tie developers to a specific, proprietary implementation of a generic concept. Doing a 'grep -r sendRedirect * | wc -l' on the above app I get 104. Does this mean I have to write 104 actions? Or is it possible to write a generic redirect action If they are all totally different sendRedirect tests, used only once in individual xsp pages, you may need to write a comprehensive set of actions. But I expect in reality it will be a lot less than 104. (without seeing your application. :-) ) Perhaps 80 or so. I think in its current state Cocoon2 ties me up too much, I want more freedom :-) 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]
RE: AW: [C2] Redirects
Doing a 'grep -r sendRedirect * | wc -l' on the above app I get 104. Does this mean I have to write 104 actions? Or is it possible to write a generic redirect action If they are all totally different sendRedirect tests, used only once in individual xsp pages, you may need to write a comprehensive set of actions. But I expect in reality it will be a lot less than 104. (without seeing your application. :-) ) We are using a system with an EJB container in the background, and use cocoon to build a user interface. And it really works well. The problem is that our redirects often depend on more complex stuff than just a parameter value, our business logic (the beans) take care of as much as possible (including verifying more complex input), leaving the xsp pages quite lean and mean. How can this be done with the C2 sitemap architecture (actions?), as easily as possible? We may not have 104 redirects, but enough not to write an action for each... - Anders Lindh - 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]
Re: AW: [C2] Redirects
Anders Lindh wrote: Doing a 'grep -r sendRedirect * | wc -l' on the above app I get 104. Does this mean I have to write 104 actions? Or is it possible to write a generic redirect action If they are all totally different sendRedirect tests, used only once in individual xsp pages, you may need to write a comprehensive set of actions. But I expect in reality it will be a lot less than 104. (without seeing your application. :-) ) We are using a system with an EJB container in the background, and use cocoon to build a user interface. And it really works well. The problem is that our redirects often depend on more complex stuff than just a parameter value, our business logic (the beans) take care of as much as possible (including verifying more complex input), leaving the xsp pages quite lean and mean. How can this be done with the C2 sitemap architecture (actions?), as easily as possible? We may not have 104 redirects, but enough not to write an action for each... I generally advocate writing actions as generically as possible. I also generally advocate trying not to use redirects. I know that sometimes it is not possible--but basically it forces me to think about elegant solutions without using a hammer to do a screwdriver's job. Redirects have specific side affects to them: * You have a brand new Request object, so anything you wanted to pass via Request attributes is gone. The consequence is more information has to be stored in the Session object. * You are changing your URL. Sometimes this is the desired affect, so I can't fault it. Other times, it is more desirable to mount a whole form to one URL, and iterate through the pages there. The advantage is that noone can short-circuit the form. * The biggest issue: not all web servers perform redirects equally. I had issues using redirects in early versions of Cocoon2 and IBM WebSphere 3.5.2. WebSphere refused to redirect properly. Many times it is a configuration issue, but in this case, the Servlet Container was buggy and did not transform the URL correctly. If you think of ways to minimize redirects, then you can minimize the number of Actions you have to write. Another possibility is to create your own protocol. You wrap your business logic in session beans (like you are supposed to do anyway), and call them from an Action. If an Exception is thrown, you redirect. Actions can be parameterized so you can specify three parameters (bean, method, redirect-to) and the one (1) Action will handle all the dirty work for you. S/MIME Cryptographic Signature
Re: AW: [C2] Redirects
Berin Loritsch wrote: If you think of ways to minimize redirects, then you can minimize the number of Actions you have to write. Heh, this reminds me of the discussion a few days ago, where I was criticized for saying: Don't use Internet Explorer and you won't incur the IE/Cocoon/PDF problem. Now we're saying: Don't use redirects and you won't incure Cocoon2's redirect problem. :-) Another possibility is to create your own protocol. You wrap your business logic in session beans (like you are supposed to do anyway), and call them from an Action. If an Exception is thrown, you redirect. Actions can be parameterized so you can specify three parameters (bean, method, redirect-to) and the one (1) Action will handle all the dirty work for you. Using exceptions to control program flow? I think they should be reserved for error-handling. I'm not necessarily a big fan of redirects, but there is no other way currently to control web program flow and now Cocoon2 is taking that away as well :) 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]
RE: AW: [C2] Redirects
Ok, thanks a lot for your info. I now understand it is possible, but extremely complicated and verbose to do redirects in Cocoon2 :-) 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. I have to agree on the first point. Migration from C1 to C2 is everything else than compile run, just because of this one thing. I agree that using actions in the sitemap is a more clean solution, and yes, I agree that program flow shouldn't be dictated in xsp pages. But couldn't this one little feature be implemented (with warnings, and some restrictions) just so that C1 users could play around with C2 and enjoy the new features? I'd really appreciate it... - Anders - 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]
Re: AW: [C2] Redirects
Anders Lindh wrote: Ok, thanks a lot for your info. I now understand it is possible, but extremely complicated and verbose to do redirects in Cocoon2 :-) 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. I have to agree on the first point. Migration from C1 to C2 is everything else than compile run, just because of this one thing. I agree that using actions in the sitemap is a more clean solution, and yes, I agree that program flow shouldn't be dictated in xsp pages. But couldn't this one little feature be implemented (with warnings, and some restrictions) just so that C1 users could play around with C2 and enjoy the new features? I'd really appreciate it... One of the issues is technical in nature. Because of the SAX stream approach that Cocoon 2 uses, the XSP page is being serialized AS it is being parsed. What is happening is that each SAX event (startDocument, startElement, etc), is being propogated through the entire SAX chain and being transformed as they are called. Once the root element has been propogated, there is no turning back. This is the blessing and curse of SAX based pipelines. It also has caused us to rethink how we do things. What we came up with is truly better in the long run. Be happy that we didn't keep redirects _only_ in the sitemap (as was originally proposed). I championed the cause to allow them in Actions as well. Beyond that, I highly doubt that it is technically feasible to allow them in XSP--and reliably expect them to work. S/MIME Cryptographic Signature
RE: AW: [C2] Redirects
I agree. It is fine to discourage use of redirects, but dictating it to everyone by arbitrarily removing it from the framework is, in my opinion, a poor choice. Trust us to make mature choices about what constitutes good design, even while educating us on a better way. I think the point is also well taken that, hey, redirects are a part of the current state of the art in web programming. Most programming languages have some dangerous constructs (e.g., #become: in Smalltalk); maybe you avoid it like the plague, but once in a long while, the benefits outweigh the problem, so you use it. So please, give us redirects even if you tell us not to use it. -Christopher Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: RE: AW: [C2] Redirects Ok, thanks a lot for your info. I now understand it is possible, but extremely complicated and verbose to do redirects in Cocoon2 :-) 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. I have to agree on the first point. Migration from C1 to C2 is everything else than compile run, just because of this one thing. I agree that using actions in the sitemap is a more clean solution, and yes, I agree that program flow shouldn't be dictated in xsp pages. But couldn't this one little feature be implemented (with warnings, and some restrictions) just so that C1 users could play around with C2 and enjoy the new features? I'd really appreciate it... - Anders - 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]
Re: AW: [C2] Redirects
Ulrich Mayring wrote:
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 agree. I don't think the Sitemap is the propper place for it.
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 :)
The interface they provide is:
interface Action {
Map act(Redirector redirector, SourceResolver resolver, Map objectMap, String
source, Parameters parm);
}
So a Cocoon Redirector, SourceResolver, and objectMap are passed. The source is the
value passed in act type=action src=passed-in/, and the Parameters are the
Avalon Parameters object. You can see that an Action is somewhat Cocoon centric.
You can provide your own generic interface, and use those in a Controller Action.
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.
That is a problem inherent in JSP, ASP, and ColdFusion. Each has their own proprietary
way of handling logic. XSP is the first scripting language that allows you to
use logicsheets defined in other languages--but any time you use the xsp:logic/ tag,
you lose portability accross languages.
Also, XSP is only used in AxKit and Cocoon at this time. You are still fairly limited
in your frameworks you can choose.
Lastly, you can set up Actions that respond to an XML document. Check out the action
with the longest name: AbstractComplimentaryConfigurableAction. It provides a
mechanism
for you to specify a run-time Configuration setup (i.e. an XML file you specify as a
parameter). It loads and caches the XML in the form of an Avalon Configuration object.
Your action can now do very dynamic things and the XML representation of the logic
is in a portable XML file.
S/MIME Cryptographic Signature
Re: AW: [C2] Redirects
On 11.Jul.2001 -- 05:06 PM, Anders Lindh wrote: One of the issues is technical in nature. Because of the SAX stream approach that Cocoon 2 uses, the XSP page is being serialized AS it is being parsed. What is happening is that each SAX event (startDocument, startElement, etc), is being propogated through the entire SAX chain and being transformed as they are called. Once the root element has been propogated, there is no turning back. Ok.. Could you clarify a bit how and in what order things are done in Cocoon. What exactly does Cocoon do with a xsp page (that has been compiled into a java class)? The compiled java class constructs a SAX document, which in turn is XSLT processed if needed. Right? Isn't this the basic flow of things? Only that there's no SAX document. While the XSP still generates SAX events (document nodes), others are transformed and some are already serialized and send to the client. Everything happens concurrently. Thus when 50% (1%, 99%) of the document have already reached the client what semantics should a redirect have? C2 had a send-redirect in the response taglib. And if you were lucky, the redirect was issued while the servlet engine's send buffer was only filling up and nothing has been delivered, yet. Most of the time the redirect never reached the client or two documents were concatenated (i.e. IE) Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 - 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]
Re: AW: [C2] Redirects
Berin Loritsch wrote: No, I'm saying, don't use redirects when another tool will work better. I'm challenging the concept that you _have_ to use redirects to control program flow. Ok, you're saying I should select my logic from inside Beans. I don't use Beans for various reasons and think I shouldn't be forced to just to do program flow. Redirects are part of HTTP, they were invented to be used as a standard way to do program flow. I prefer this to proprietary methods, but of course others may think differently. I'm not necessarily a big fan of redirects, but there is no other way currently to control web program flow and now Cocoon2 is taking that away as well :) That is a common misconception. Program flow is dependant on selecting the propper web resource. I think it's better to select Web resources via HTTP, not via Beans or other non-Web techniques. If you have one URI for a whole form flow, you can use an action to return the name of the resource you want to select. Yes, but I don't want to have one URI for my whole application. I want to break it down into re-usable parts, in Web apps I like modular designs better than monolithic ones. That means that at the same URI you will have a number resources. Many times for web applications (at least the ones I write) you have one entry point, and you are forcing a flow on the user. These are prime examples of what I was talking about. Here is a possible sitemap entry: Unfortunately, a look at my Visio charts tells me that I have many entry points and a lot of sharing between workflows. Most scripting languages (like JSP, ASP, ColdFusion) have made us think that redirects are the only way of handling program flow. That is because that is the only mechanism they gave you. Cocoon challenges that assumption just as it challenges the assumption that your URI space has to match the filesystem. Well, at least Cocoon allows me to match URI space with the filesystem, while it doesn't allow me to handle program flow via redirects. At least not without a major redesign of my application. It's hard for me to argue your points, because I can't really just sit down and try it out - I'd have to completely redesign my applications just to verify your ideas. Unfortunately I don't have the time to do that currently, so I can only argue from a theoretical point. Maybe Cocoon2 can do what I need after all, but it'll have to wait until I find more time. By the time that happens we'll have a complete Avalon-based infrastructure here running all our internal processes with the exception of the Cocoon1 apps and the SOAP services. That would probably be a good time to re-visit Cocoon2, perhaps it can even be installed as a .sar application by then :) 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]
Re: AW: [C2] Redirects
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]
Re: AW: [C2] Redirects
Ulrich Mayring wrote: Christopher Painter-Wakefield wrote: I think the point is also well taken that, hey, redirects are a part of the current state of the art in web programming. Not only that, redirects are part of the HTTP standard. So they should be the first thing that is supported by a web app framework and better mechanisms could be introduced additionally. But I think where there's a standard, it should be possible to use it. I mean, it *is* possible to use redirects in the Sitemap and in Actions, but unfortunately not in XSP. Redirects are not possible largely due to the SAX pipeline. Read my other mails for details. This leads me to the question: what else is not possible in XSP? If the request object were fully exposed like in Cocoon1, then redirects would work. So is the request object not accessible anymore in Cocoon2's XSP? What about the session and response object? The Request and Session objects are wrapped with Cocoon objects--so that we can have the same application work wether in a Servlet environment, a Command Line environment, or an Avalon environment. The abstraction allows you to handle a number of situations. The abstraction is based on the HttpServlet spec. You can get to the Request, Response, and Session objects as usual. You may not sendRedirect() from the version you get, or obtain a reference to the output stream. I think you may already be used to not getting the output stream in Cocoon 1. The output stream is explicitly set in Serializers and Readers. The objects you seek are all in the Map objectModel passed in to your pages. for XSP, the Request, Context, and Response objects are stored as class variables. Through them, you can get your Session and Cookie objects as usual. other than sendRedirect and getting a reference to the output stream, nothing should be hidden from you. S/MIME Cryptographic Signature
Re: AW: [C2] Redirects
Ulrich Mayring wrote: Berin Loritsch wrote: That is a problem inherent in JSP, ASP, and ColdFusion. Each has their own proprietary way of handling logic. XSP is the first scripting language that allows you to use logicsheets defined in other languages--but any time you use the xsp:logic/ tag, you lose portability accross languages. Well, I don't need the xsp:logic/ element, I can define my own custom taglibs. Then I can give the XML file to someone else and he can implement my custom tags using his personal framework. He can implement it in PHP, JSP or whatever else he fancies. Also, XSP is only used in AxKit and Cocoon at this time. You are still fairly limited in your frameworks you can choose. Yeah, but how many JSP frameworks are out there? How many PHP frameworks? I don't think the situation with XSP is particularly bad compared to other projects. The difference is that XSP provides a generic XML interface. Lastly, you can set up Actions that respond to an XML document. Check out the action with the longest name: AbstractComplimentaryConfigurableAction. It provides a mechanism for you to specify a run-time Configuration setup (i.e. an XML file you specify as a parameter). It loads and caches the XML in the form of an Avalon Configuration object. If I understand this correctly, the Avalon Configuration object is kind of a simplified XML structure without deeper nesting, right? It can fully represent an XML structure, but it ignores namespaces and you cannot traverse UP the hierarchy--only down. This is by design, so that Components that create Components can pass a reference to a child Configuration and the child Component cannot get information about the parent Component. It's the Inversion of Control principle. The XML can be however deep you need it--and have attributes as well. Your action can now do very dynamic things and the XML representation of the logic is in a portable XML file. This sounds interesting. If it works and is easy to use, it's undoubtedly better than XSP redirects. I'll try it when I have a few weeks :) Sounds good ;) S/MIME Cryptographic Signature
Re: AW: [C2] Redirects
On Wed, 11 Jul 2001, Berin Loritsch wrote: I think you may already be used to not getting the output stream in Cocoon 1. In Cocoon1 it is actually possible to get the OutputStream, I'm using that in my soap taglib. My auth taglib makes heavy use of redirects (such as redirecting you to the login page, if you try to access a protected page and have not authenticated). So these two taglibs, which I use a lot in my Cocoon1 apps, are not portable to Cocoon2. Back when XSP taglibs first appeared, it was said that their advantage is that implementations can change, the interface remains the same. Of course now that XSP itself works differently, this advantage is gone. It's always a trade-off between backwards compatibility and new features. I'm sorry to hear that the XSP model was not deemed fit to last across different versions of Cocoon - I wonder if it will change again for Cocoon3. Perhaps the answer lies elsewhere: implement XSP as an Avalon block, add some parts of Tomcat, Xerces and Xalan as blocks and I won't need Cocoon anymore to build web applications. That's the beauty of OpenSource, that these things are possible. The objects you seek are all in the Map objectModel passed in to your pages. for XSP, the Request, Context, and Response objects are stored as class variables. Through them, you can get your Session and Cookie objects as usual. other than sendRedirect and getting a reference to the output stream, nothing should be hidden from you. Ok, thanks for the info, Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung - 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]
Re: AW: [C2] Redirects
On Wed, 11 Jul 2001, Berin Loritsch wrote: If I understand this correctly, the Avalon Configuration object is kind of a simplified XML structure without deeper nesting, right? It can fully represent an XML structure, but it ignores namespaces and you cannot traverse UP the hierarchy--only down. This is by design, so that Components that create Components can pass a reference to a child Configuration and the child Component cannot get information about the parent Component. It's the Inversion of Control principle. Ok, off-topic, rant warning: I may sound a bit naive, but I think design patterns and OOP are largely buzzwords. In the real world nobody can understand this code, but its creator. There is too much information in the structure and too little in the actual code, not to speak of the documentation, which is usually skipped. Some people go to great lengths to define interfaces and abstract classes to make re-use as easy as possible and then they rarely ever re-use any code. Hey, all the interfaces and abstract classes in Cocoon1 are for the trashcan now - the time thinking about them should have been spent writing documentation. Sorry for the rant, but I currently have to fix a behemoth of abstraction, where the actual code has become so small, that it's hard to find and hard to test - with the result being that it hasn't been tested and is full of obscure bugs. And then the whole thing runs under Avalon, which is extremely hard to debug itself :) Still, maybe I should think less about Cocoon2 and more about Avalon. Yeah, sometimes I have crazy ideas :) Please don't take my criticism the wrong way, I'm here because the Apache group consistently turns out fantastic code. I just have my opinions and if you read this list, you'll notice that I'm usually quite alone with them :) Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung - 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]
