> From: Donald Ball [mailto:[EMAIL PROTECTED]] > > hi guys, long time no see. if anyone's curious where i've been, see the > apologetic post to cocoon-dev i just sent in. now, on to my questions. :)
Welcome back! I will try answer you questions... > 1. a long while back, we had some discussion on whether or not one should > be able to send a redirect from an xsp page. i'd thought the eventual > consensus was that we should, :) > but i guess i was wrong, since the response > logicsheet doesn't seem to provide any way to send a redirect, Nope. > nor does the Response interface provide a redirect method. Same here. > however, one of the c2 docs _does_ reference such a method: Outdated. Want to fix them? :) > http://xml.apache.org/cocoon/userdocs/concepts/actions.html > > compares and contrasts xsp pages and actions. the xsp page it contains has > the following snippet: <snip/> > the alleged messiness of the code notwithstanding (;)), it seems to be a > common development idiom to want to redirect the user to a different url > or pipeline if something goes awry in an xsp page (the user can't login to > the database, the user doesn't have permission to do something, etc.) if > one cannot send a redirect from an xsp page in c2, can one switch > pipelines based on a flow control statement in an xsp page? Nope, it's too late: train already left the station, pipeline is already assembled. But. I should say that there are *other* ways of tricking: put include transformer after your XSP and generate <include/> when something is goes wrong. Yes, it's not same as redirect, but it's definitely something. > naturally, i can see that one could refactor and use actions to do the > pipeline switching Pipeline selection is the term in use :) > and/or redirecting instead, but i still can't see any > good reason to prohibit early exit from a pipeline, via sendRedirect or > sendError from any component, including xsp pages. In most cases response is already committed! And it is too late to add a header to response. > it's not always > desirable to factor to split the flow control stuff out of xsp pages into > actions. or is it? It is desirable from long perspective view... > 2. in developing my own standalone j2ee webapps using trax, i quickly > realized that if you don't know at what url your webapp is going to be > mounted, you can't use absolute links to resources in your webapp, e.g. > images, javascript libraries, etc. but strictly using relative paths in > your xslt stylesheets when referencing those resources is not only a real > pita, it's impossible if that stylesheet if used in the construction of > urls that appear at different depths in the urlspace. the easy solution is > to parameterize the stylesheet with the context path information: > > <xsl:param name="contextPath"/> > <img src="{$contextPath}/images/foo.png"/> > > i presume c2 does not already parameterize stylesheets with this datum by > default. Nope, but (with sitemap syntax modified recently) you easily can add this to all pipelines: <map:pipeline> <map:act type="my-get-context-path-action"> <!-- all pipelines goes here --> </map:act> </map:pipeline> > does anyone know how you would easily add that parameter to all, > or a certain class, of xslt transformations? Nothing of this kind > also, i presume that others > have encountered this problem. is there an alternate solution anyone has > used that's better? I'm thinking about a transformer that converts context:// into absolute http://. May be not the best way, but definitely will work (and there is some URL encoding transformer already in the (IIRC) scratchpad) > > - Donald Regards, Vadim --------------------------------------------------------------------- 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]>
