Re: Cocoon Hackathon at ApacheCon
Bertrand Delacretaz wrote: Le 1 avr. 05, à 08:40, Torsten Curdt a écrit : [X] yepp, I am in Most certainly - I'll be coming back from holidays and the exact date is not fixed yet. Same for me, and [X] I like polls so much that I answered anyway ;) Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon Hackathon at ApacheCon
[x] there is a chance I gonna make it Upayavira
Re: Cocoon Hackathon at ApacheCon
Bertrand Delacretaz wrote: Le 1 avr. 05, à 08:40, Torsten Curdt a écrit : [X ] yepp, I am in Most certainly - I'll be coming back from holidays and the exact date is not fixed yet. Same here as well. /Daniel
Re: Cocoon Hackathon at ApacheCon
On Fri, Apr 01, 2005 at 08:40:57AM +0200, Torsten Curdt wrote: [X] there is a chance I gonna make it Giacomo -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: Cocoon Hackathon at ApacheCon
On Apr 1, 2005 8:40 AM, Torsten Curdt [EMAIL PROTECTED] wrote: [X ] there is a chance I gonna make it -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
JIRA
Have I missed the discussion about possible moving to JIRA? If not is there anything in favour/against it? I would personally love to see cocoon use JIRA. Bugzilla does not look user friendly to me. -- Leszek Gawron MobileBox [EMAIL PROTECTED] http://www.mobilebox.pl
AW: Accessing BrowserSelector results from an Action
Hi Stefan,
On Mar 31, 2005, at 11:19 AM, Stefan Pietschmann wrote:
At the moment I'm using the selector in the sitemap, to tell my action
which
browser is currently requesting:
map:select type=browser
map:when test=desktop
map:act type=updateModel
map:parameter name=format value=xHTML/
/map:act
/map:when
map:when test=pocketcolor
map:act type=updateModel
map:parameter name=format value=cHTML/
/map:act
/map:when
map:when test=pocket
map:act type=updateModel
map:parameter name=format value=cHTML/
/map:act
/map:when
[...]
/map:select
Well, instead of passing a different parameter value for each case it
would
be much easier for me if I could save this map:select, just specify my
action once and somehow access the BrowserSelector value from within my
Action.
How can I access the values the BrowserSelector has chosen?
Well, the whole point of a Selector is to have multiple branches. If
that's not what you want, then you don't want a selector :-)
Hehe, I know, but this is not the only point we're using the selector, so
it's needed nonetheless ;)
Try this... make sure you have the following in your cocoon.xconf:
component-instance
class=org.apache.cocoon.components.modules.input.HeaderAttributeModule
name=header
/
Then, in your sitemap:
act type=updateModel
parameter name=format value={header:User-Agent} /
/act
Great, i'm gonna try this.
Thanx a lot.
HTH,
-ml-
Re: Cocoon Hackathon at ApacheCon
Torsten Curdt wrote: [X] yepp, I am in Whiteboard/flipchart, internet ...what else do we need? All rendezvous based naturally :) Cheers, M!
Rationalising CForms Flowscript Params
Hi All rant During the process of stabilising CForms could we please consider rationalising the parameters sent to forms.js from the sitemap? This really bugs me : map:call function=handleForm map:parameter name=function value=myFunction/ map:parameter name=form-definition value=model.xml/ map:parameter name=bindingURI value=binding.xml/ Can we come up with better matching names for these please ? Names that have a similar case and/or hyphenation scheme? form-function, form-model, form-binding form-function, form-definition, form-binding formFunction, formModel, formBinding formFunction, formModelURI, formBindingURI function, modelURI, bindingURI etc etc. I do not really mind what they are, but they should at least look as if they are within the same concern. I propose that the old names are used if the new ones were not supplied but a deprecation notice is logged, then later they can be taken out. /rant Thanks regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: JIRA
Leszek Gawron wrote: Have I missed the discussion about possible moving to JIRA? If not is there anything in favour/against it? -0.5: Bugzilla is more then enough. If you factor in jira downtime, Bugzilla is a clear win ;-) Vadim
Re: Rationalising CForms Flowscript Params
On 1 Apr 2005, at 15:33, Sylvain Wallez wrote:
Jeremy Quinn wrote:
Hi All
rant
During the process of stabilising CForms could we please consider
rationalising the parameters sent to forms.js from the sitemap?
This really bugs me :
map:call function=handleForm
map:parameter name=function value=myFunction/
map:parameter name=form-definition value=model.xml/
map:parameter name=bindingURI value=binding.xml/
Can we come up with better matching names for these please ?
Names that have a similar case and/or hyphenation scheme?
form-function, form-model, form-binding
form-function, form-definition, form-binding
formFunction, formModel, formBinding
formFunction, formModelURI, formBindingURI
function, modelURI, bindingURI
etc etc.
I do not really mind what they are, but they should at least look as
if they are within the same concern.
I propose that the old names are used if the new ones were not
supplied but a deprecation notice is logged, then later they can be
taken out.
I propose that the handleForm shall be deleted, as IMO it really
doesn't make sense to specify all this information in the sitemap ;-)
Compare this :
map:call function=handleForm
map:parameter name=function value=myFunction/
map:parameter name=form-definition value=model.xml/
map:parameter name=bindingURI value=binding.xml/
/map:call
function myFunction(form) {
form.showForm(blah);
}
and this, which does exactly the same:
map:call function=myFunction/
function myFunction() {
var form = new Form(model.xml);
form.createBinding(binding.xml);
form.showForm(blah);
}
I personally never used this handleForm function and consider it as
some old legacy.
Hmmm, I disagree.
I never like to embed names of files or pipelines in flowscript
functions.
I always pass these in from the sitemap.
This way, the sitemap is the place where all paths, filenames, uris are
managed, or the location that consistently retrieves these from a
config, via input-modules.
I do not like to spread this around as it makes refactoring more
difficult.
regards Jeremy
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
smime.p7s
Description: S/MIME cryptographic signature
Re: Rationalising CForms Flowscript Params
Sylvain Wallez wrote: Jeremy Quinn wrote: This really bugs me : map:call function=handleForm map:parameter name=function value=myFunction/ map:parameter name=form-definition value=model.xml/ map:parameter name=bindingURI value=binding.xml/ I propose that the handleForm shall be deleted, as IMO it really doesn't make sense to specify all this information in the sitemap ;-) snip/ I personally never used this handleForm function and consider it as some old legacy. +1; and same here. Vadim
Portal Tools
Hi All I am trying to use the Portal Tools to edit a Layout, but get this error in the Console: Cannot create XML element with name 'FOM JavaScript GLOBAL SCOPE/file:/Users/jerm/Development/Checkouts/Apache/Cocoon/ BRANCH_2_1_X/build/webapp/samples/blocks/portal/tools/plugins/ copletManagement/sitemap.xmap:27:35' : NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. It seems to originate from org/apache/cocoon/webapps/session/context/RequestSessionContext.java. Has anybody got a solution? Thanks regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Rationalising CForms Flowscript Params
Am Freitag, 1. April 2005 16:52 schrieb Jeremy Quinn:
On 1 Apr 2005, at 15:33, Sylvain Wallez wrote:
Jeremy Quinn wrote:
Hi All
rant
During the process of stabilising CForms could we please consider
rationalising the parameters sent to forms.js from the sitemap?
This really bugs me :
map:call function=handleForm
map:parameter name=function value=myFunction/
map:parameter name=form-definition value=model.xml/
map:parameter name=bindingURI value=binding.xml/
Can we come up with better matching names for these please ?
Names that have a similar case and/or hyphenation scheme?
form-function, form-model, form-binding
form-function, form-definition, form-binding
formFunction, formModel, formBinding
formFunction, formModelURI, formBindingURI
function, modelURI, bindingURI
etc etc.
I do not really mind what they are, but they should at least look as
if they are within the same concern.
I propose that the old names are used if the new ones were not
supplied but a deprecation notice is logged, then later they can be
taken out.
I propose that the handleForm shall be deleted, as IMO it really
doesn't make sense to specify all this information in the sitemap ;-)
Compare this :
map:call function=handleForm
map:parameter name=function value=myFunction/
map:parameter name=form-definition value=model.xml/
map:parameter name=bindingURI value=binding.xml/
/map:call
function myFunction(form) {
form.showForm(blah);
}
and this, which does exactly the same:
map:call function=myFunction/
function myFunction() {
var form = new Form(model.xml);
form.createBinding(binding.xml);
form.showForm(blah);
}
I personally never used this handleForm function and consider it as
some old legacy.
Hmmm, I disagree.
I never like to embed names of files or pipelines in flowscript
functions.
I always pass these in from the sitemap.
This way, the sitemap is the place where all paths, filenames, uris are
managed, or the location that consistently retrieves these from a
config, via input-modules.
I do not like to spread this around as it makes refactoring more
difficult.
regards Jeremy
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
hi,
i really agree with jeremy ...
maybe my opinion is not so important here because i do not made too many
experiences with cocoon yet, but i really like the parameters with
map:call function=handleForm ...
it is nice to use wild cards * and {1} and so on in the pipeline to create the
filenames and other pilelines i need. i like the flexibility i get.
in some cases i was so keen and added some other parameters just for my own
purposes like
map:match pattern=form3-*-*.flow
map:parameter name=templateURI value=form3-d-pipeline-{1}-{2}/
map:parameter name=successURI value=form3-s-pipeline/
so it is really very easy using one pipeline for many things and change with
some little efforts.
maybe we can have not less but more parameters with names like jeremy said?
regards beate
--
Re: Portal Tools
Hi, Cannot create XML element with name 'FOM JavaScript GLOBAL SCOPE/file:/Users/jerm/Development/Checkouts/Apache/Cocoon/ BRANCH_2_1_X/build/webapp/samples/blocks/portal/tools/plugins/ copletManagement/sitemap.xmap:27:35' : NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. It happens if you save the profile iirc. It seems to originate from org/apache/cocoon/webapps/session/context/RequestSessionContext.java. Has anybody got a solution? I've had a quick look into this problem with Carsten some time ago, but we have not found a soloution and then it slipped my attention :-/ But due to some tests this error should not cause any (major) problems. Maybe I'll have some time next week to fix this. -- * best regards * Jens Maukisch
Re: Rationalising CForms Flowscript Params
Jeremy Quinn wrote: On 1 Apr 2005, at 15:33, Sylvain Wallez wrote: snip/ I personally never used this handleForm function and consider it as some old legacy. Hmmm, I disagree. I never like to embed names of files or pipelines in flowscript functions. I always pass these in from the sitemap. This way, the sitemap is the place where all paths, filenames, uris are managed, or the location that consistently retrieves these from a config, via input-modules. I do not like to spread this around as it makes refactoring more difficult. Then I suggest you come up with consistent parameters naming and change this function yourself :-), I'm not against keeping it. Vadim
Remove xdocs/plan/samples.xml?
AFAIU, samples refactoring is done. Should we remove the page? Vadim
DO NOT REPLY [Bug 26107] - Logicsheet docs fail to mention that namespaces must be declared at top level
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26107. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26107 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 18:57 --- fixed -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 26107] - Logicsheet docs fail to mention that namespaces must be declared at top level
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26107. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26107 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: JIRA
Leszek Gawron lgawron at apache.org writes: Have I missed the discussion about possible moving to JIRA? If not is there anything in favour/against it? I would personally love to see cocoon use JIRA. Bugzilla does not look user friendly to me. Bugzilla might not look up to date and so less user friendly, but IMO it is much more user friendly than the other tools. In contrary to JIRA in bugzilla I find what I'm searching for ... Joerg
Re: Rationalising CForms Flowscript Params
Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On 1 Apr 2005, at 15:33, Sylvain Wallez wrote:
snip/
I personally never used this handleForm function and consider it
as some old legacy.
Hmmm, I disagree.
I never like to embed names of files or pipelines in flowscript
functions.
I always pass these in from the sitemap.
This way, the sitemap is the place where all paths, filenames, uris
are managed, or the location that consistently retrieves these from a
config, via input-modules.
I do not like to spread this around as it makes refactoring more
difficult.
In that case you can still pass map:parameter name=blah
value=forms/{1}.xml and use cocoon.parameters.blah in the flowscript.
But I admit that from a lines of code POV, this becomes more verbose
than the current situation.
Then I suggest you come up with consistent parameters naming and
change this function yourself :-), I'm not against keeping it.
+1 :-)
And since we're at changing this, it would be good to attach this
function to the Form Javascript class to prevent any name clashes.
map:call function=Form.handleForm
map:parameter whatever but consistent/
/map:call
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Rationalising CForms Flowscript Params
beatejung wrote:
hi,
i really agree with jeremy ...
maybe my opinion is not so important here because i do not made too many
experiences with cocoon yet, but i really like the parameters with
map:call function=handleForm ...
it is nice to use wild cards * and {1} and so on in the pipeline to create the
filenames and other pilelines i need. i like the flexibility i get.
in some cases i was so keen and added some other parameters just for my own
purposes like
map:match pattern=form3-*-*.flow
map:parameter name=templateURI value=form3-d-pipeline-{1}-{2}/
map:parameter name=successURI value=form3-s-pipeline/
You can access any parameter you want in the flowscript using
cocoon.parameter.blah, so you do not really /need/ the handleForm
function. But we can consider keeping it (with more consistent names) as
a convenience for a common need.
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: core logging
Jorg Heymans wrote: It would be nice to have an easy to trace logfile where one can follow sequentially how a request is processed, what main components are involved, when they are called, how they affect the response etc (basically the things you can find out with a debugger). There is SimpleSitemapExecutor in 2.2 - probably that's what you want. This would also make it easier for beginning cocooners to learn the core cocoon concepts (sitemap,matchers,gen|tran|ser|act,flow,forms) and how they play together. Can something like this be implemented with clever logging targets only? As far as I see in 2.1 messages such as: DEBUG (2005-04-01) 12:29.15:698 [sitemap] (/) PoolThread-4/PreparableMatchNode: Matcher 'wildcard' matched prepared pattern '' at file:/C:/Work/Apache/cocoon-2.1.X/build/webapp/sitemap.xmap:525:27 all go to [sitemap] target at DEBUG level - which makes filtering hard :-) Vadim
Re: Rationalising CForms Flowscript Params
On 1 Apr 2005, at 17:21, Vadim Gritsenko wrote: Jeremy Quinn wrote: On 1 Apr 2005, at 15:33, Sylvain Wallez wrote: snip/ I personally never used this handleForm function and consider it as some old legacy. Hmmm, I disagree. I never like to embed names of files or pipelines in flowscript functions. I always pass these in from the sitemap. This way, the sitemap is the place where all paths, filenames, uris are managed, or the location that consistently retrieves these from a config, via input-modules. I do not like to spread this around as it makes refactoring more difficult. Then I suggest you come up with consistent parameters naming and change this function yourself :-), I'm not against keeping it. OK Vadim :) If there are other people using this function, I would rather have a consensus on what the changes are. I do not actually mind if the consensus is to deprecate the function, but I do think it is a bad idea to recommend keeping paths etc in flowscripts . regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Portal Tools
On 1 Apr 2005, at 16:58, Jens Maukisch wrote: Hi, Cannot create XML element with name 'FOM JavaScript GLOBAL SCOPE/file:/Users/jerm/Development/Checkouts/Apache/Cocoon/ BRANCH_2_1_X/build/webapp/samples/blocks/portal/tools/plugins/ copletManagement/sitemap.xmap:27:35' : NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. It happens if you save the profile iirc. It seems to originate from org/apache/cocoon/webapps/session/context/RequestSessionContext.java. Has anybody got a solution? I've had a quick look into this problem with Carsten some time ago, but we have not found a soloution and then it slipped my attention :-/ But due to some tests this error should not cause any (major) problems. Maybe I'll have some time next week to fix this. Thanks for your reply Jens. Yes, I realise now that the functionality still works, regardless of that error message. I did have Cocoon crash a short while ago, and thought this issue was the cause, but now it seems I was wrong. regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Rationalising CForms Flowscript Params
On 1 Apr 2005, at 18:28, Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On 1 Apr 2005, at 15:33, Sylvain Wallez wrote:
snip/
I personally never used this handleForm function and consider it
as some old legacy.
Hmmm, I disagree.
I never like to embed names of files or pipelines in flowscript
functions.
I always pass these in from the sitemap.
This way, the sitemap is the place where all paths, filenames, uris
are managed, or the location that consistently retrieves these from
a config, via input-modules.
I do not like to spread this around as it makes refactoring more
difficult.
In that case you can still pass map:parameter name=blah
value=forms/{1}.xml and use cocoon.parameters.blah in the
flowscript.
Of course.
I was primarily reacting to your suggestion to encode filenames in
flowscript :-)
As I said to Vadim, if the consensus is to remove handleForm, I do not
really mind.
But I admit that from a lines of code POV, this becomes more verbose
than the current situation.
Then if handleForm is to be retained, it should maybe contain
error-checking to make sure that the sitemap has indeed supplied these
parameters properly, thereby hopefully reducing verbosity in the
handler function itself. Part of what triggered this rant, was that a
colleague complained at unhelpful error messages when they left out one
of the parameters.
Then I suggest you come up with consistent parameters naming and
change this function yourself :-), I'm not against keeping it.
+1 :-)
And since we're at changing this, it would be good to attach this
function to the Form Javascript class to prevent any name clashes.
map:call function=Form.handleForm
map:parameter whatever but consistent/
/map:call
Good idea.
regards Jeremy
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !
smime.p7s
Description: S/MIME cryptographic signature
Re: [RT] composition vs. inheritance in blocks
Daniel Fagerstrom wrote: Concerning the skin I find it somewhat burocratic to need to define a new block for beeing able to extend it but I'm ok with it for the time beeing, we will see when we start to use the things. Cool. What I would prefer would be to do something like: MyPortal Sitemap ... pipeline match pattern=load-user-profile ... /match match pattern=skin/one-special.css read src=styles/css/one-special.css/ /match mount uri-prefix=skin src=blocks://skin/ mount uri-prefix= src=blocks://portal/ /pipline ... --- o0o --- So what do you think about this? Did you really mean the above or you meant mount uri-prefix=skin src=block:skin:/// mount uri-prefix= src=block:portal:/// ? in that case, and the above is your sitemap mount at /, how do you avoid the conflict emerging by the fact that somebody else has mount another implementation of the skin block on /skin ? Daniel, I perfectly understand why you want those features, but I have a bigger goal: allow blocks to be really polymorphic, not just an easier deploy tool. With that in mind, the complexity increases, if you are composing your block out of several others (if you have just one block or you just use ones that provide java components, that is not the case). explicit mounting of blocks yields mount collision nightmares: blocks should be mount implicitly and thru the block manager (sort of a mount-table on steroids). explicit mounting works fine only if you are in control of all the dependencies, but this cannot be assumed, since blocks should be downloadable from the outside as well and might bring new dependencies. This said, I can't stop the above from happening: even if we have implicit mounting, you can go ahead and 'remount' it explicitly as you did above. The fact is that it's not needed if you do the following: pipeline match pattern=load-user-profile ... /match match pattern=skin/one-special.css read src=styles/css/one-special.css/ /match mount-blocks/ /pipline and the above is the sitemap of MyPortal that extends Portal and it's mount on / and requires Skin that is mount on '/skin'. Note however, how if you mount 'Skin' on '/style', the above breaks! The way I designed it to avoid this problem is: MyPortal - extends Portal - requires Skin - mount on / - pipeline match pattern=load-user-profile ... /match /pipeline MySkin - extends Skin - mount on /styles/ -- pipeline match pattern=one-special.css read src=styles/css/one-special.css/ /match /pipeline Since mount exists and block: will be a Source protocol, it's impossible to stop you from doing explicit block mounting into your own block URL space. Note that this scatters the URL control in many files, instead of centralizing it at the block management level. I personally won't use it for the above reasons, but if it floats your boat, go ahead. My point remains: we don't need multiple inheritance of blocks to achieve what you need! -- Stefano.
Proposed fix: crazy infinite loop w/ ft:continuation-id
Hi, I tried passing the continuation ID as a hidden form parameter, using ft:continuation-id>. Until now, I've always put continuation IDs in the URI, but in this application I really need to do it this way (and if I can get this to work right, I'm going to do it this way again in the future!). The problem is that after the continuation is resumed, the response to that request is generated by an internal redirect (via sendPage()) of the request, which is of course matched against the sitemap, but since the request still contains the continuation-id parameter, it hits on that matcher and re-invokes the continuation, and it's dj vu all over again, forever and ever, amen. So, (you smugly say :-), I should just move my continuation-id matcher to the end of the pipeline, so that it only matches if nothing else did. Well, the way I have designed the page flow in this app which I think is the Right Way, BTW absolutely depends on always matching on a continuation-id parameter in the flow-originating request, and having this in turn work in a sane manner. And there is absolutely no use whatsoever for the continuation-id parameter, once the continuation has been resumed. I don't think I should have to redesign my page flow to something worse, just to work around an onerous constraint on matching the continuation-id! :-) See below for an example scenario, representative of the sort of page flow I'm implementing. But first, the proposed fix: I've added this method to the oac.environment.Request interface: public void killContinuation(); In an HttpRequest, this sets a flag which causes getParameter(continuation-id) to return null. This is a workaround for the lack of a removeParameter() method in HttpServletRequest (the delegate). Now, over to the flowscript side of CForms... in Form.prototype.showForm(), after the call to sendPageAndWait(), I call cocoon.request.killContinuation(). Works like a charm. No more infinitous loopage! So, my questions: Is this a good fix? There isn't some better one that I am missing, is there? My fix might seem like hacky special-case-ism. But it also seems like adding a general removeParameter() method to these wrappers, while certainly possible (it'd just be a HashSet), would be overkill to solve a general problem that doesn't really exist (after all there is a reason that HttpServletRequest has gotten along nicely all this time without such a method). But maybe I'm wrong about that, and someone will tell my why I really should add this as a removeParameter() method... WDYT? I've prototyped this in the v2 version of Form, but I'll add it to v1 and v3 before submitting a patch. -=-=-=--= A simple example of why I need this: Suppose we are doing lightweight authentication i.e., using pure flowscript, w/o the AuthFW. This is super-simple, but to break it way down in excruciating detail: 1) The user requests a protected resource /foo. 2) The sitemap dispatches to a flowscript controller function that handles this request 3) Since this is a protected resource, the controller calls a flowscript authorize() function 3) The user isn't logged in, so authorize() invokes a login form (a CForms form). (N.B.: the browser is not redirected to the login page. The address bar shows /foo). 3) The users fills out and submits the form, which is a form action=> so it requests /foo again, this time with some (additional?) POST parameters: userName, password, and continuation-id. 4) The continuation matcher in the sitemap hits, and the continuation is resumed. 5) The login was successful, so the authorize() function returns (otherwise, it just loops and reissues the login form, i.e. return == success). 6) The caller of of authorize() proceeds and generates the reply to the request for /foo. 7) The browser receives the reply and renders the page. The address bar shows /foo, the resource that was originally requested. Notes: (3) is the essential reason why I need this change. If /foo is requested with a continuation-id POST parameter, the continuation must be resumed. (7) Has important implications. I say the address bar shows '/foo', but what I really mean is that /foo was the URI in the reply. We may not care what the user sees in their address bar, but the other thing this controls is the browser's interpretation of relative links, and we may care very much about this! A side benefit of this more flow-oriented approach is that the application becomes a little more crisply responsive, since we're not issuing external redirects all over the place in order to get various pages rendered.
Re: Proposed fix: crazy infinite loop w/ ft:continuation-id
Mark Lundquist wrote:
I tried passing the continuation ID as a hidden form parameter, using
ft:continuation-id. Until now, I've always put continuation IDs in the
URI, but in this application I really need to do it this way (and if I
can get this to work right, I'm going to do it this way again in the
future!).
The problem is that after the continuation is resumed, the response to
that request is generated by an internal redirect (via sendPage()) of
the request, which is of course matched against the sitemap, but since
the request still contains the continuation-id parameter, it hits on
that matcher and re-invokes the continuation, and it's /dj vu/ all
over again, forever and ever, amen.
So, (you smugly say :-), I should just move my continuation-id matcher
to the end of the pipeline, so that it only matches if nothing else did.
Well, the way I have designed the page flow in this app which I think
is the Right Way, BTW absolutely depends on always matching on a
continuation-id parameter in the flow-originating request, and having
this in turn work in a sane manner. And there is absolutely no use
whatsoever for the continuation-id parameter, once the continuation has
been resumed. I don't think I should have to redesign my page flow to
something worse, just to work around an onerous constraint on matching
the continuation-id! :-)
See below for an example scenario, representative of the sort of page
flow I'm implementing.
But first, the proposed fix:
I've added this method to the oac.environment.Request interface:
public void killContinuation();
In an HttpRequest, this sets a flag which causes
getParameter(continuation-id) to return null. This is a workaround for
the lack of a removeParameter() method in HttpServletRequest (the
delegate).
Now, over to the flowscript side of CForms... in
Form.prototype.showForm(), after the call to sendPageAndWait(), I call
cocoon.request.killContinuation().
Works like a charm. No more infinitous loopage!
So, my questions:
Is this a good fix? There isn't some better one that I am missing, is
there?
No, it's horrible.
My fix might seem like hacky special-case-ism. But it also seems like
adding a general removeParameter() method to these wrappers, while
certainly possible (it'd just be a HashSet), would be overkill to solve
a general problem that doesn't really exist (after all there is a reason
that HttpServletRequest has gotten along nicely all this time without
such a method). But maybe I'm wrong about that, and someone will tell my
why I really should add this as a removeParameter() method... WDYT?
I've prototyped this in the v2 version of Form, but I'll add it to v1
and v3 before submitting a patch.
-=-=-=--=
A simple example of why I need this: Suppose we are doing lightweight
authentication i.e., using pure flowscript, w/o the AuthFW. This is
super-simple, but to break it way down in excruciating detail:
1) The user requests a protected resource /foo.
2) The sitemap dispatches to a flowscript controller function that
handles this request
3) Since this is a protected resource, the controller calls a flowscript
authorize() function
3) The user isn't logged in, so authorize() invokes a login form (a
CForms form). (*N.B.:* the browser is /not/ redirected to the login
page. The address bar shows /foo).
3) The users fills out and submits the form, which is a form action=
so it requests /foo again, this time with some (additional?) POST
parameters: userName, password, and continuation-id.
4) The continuation matcher in the sitemap hits, and the continuation is
resumed.
5) The login was successful, so the authorize() function returns
(otherwise, it just loops and reissues the login form, i.e. return ==
success).
Note: flow function can not return. It can do sendPage,redirect - but it can't
simply return.
6) The caller of of authorize() proceeds and generates the reply to the
request for /foo.
7) The browser receives the reply and renders the page. The address bar
shows /foo, the resource that was originally requested.
I see several possible ways of solving your issue without crazy hacks.
* Move view rendering into the internal-only pipeline. That's how it
(usually) should be with the flow.
* If you don't like above, issue a redirect in the step (5) - you'll
loose continuation ID parameter in the process.
* Third option. The best approach to implement your login scenario
is to write custom auth action. If user is authenticated, you
return a map, sitemap shows the view (nested in the map:act).
If he is not, you return null and sitemap shows the login form
(you can use flow and forms there as it is now):
map:act type=myauth
map:match pattern=*
!-- generate page here --
/map:match
/map:act
map:call function=login
continuation-id={request-param:continuation}/
Vadim
Re: Proposed fix: crazy infinite loop w/ ft:continuation-id
This is how I work with hidden continuation ids since my form posts.
You can select based upon the request:method - continuing only on POST:
map:select type=oacl-simple
map:parameter name=value value={request:method}/
map:when test=GET
map:call function=functionName
map:parameter name=searchType
value={0} /
/map:call
/map:when
map:when test=POST
map:call
continuation={request-param:continuation-id}
/
/map:when
/map:select
Regards,
Eric
Vadim Gritsenko wrote:
Mark Lundquist wrote:
I tried passing the continuation ID as a hidden form parameter, using
ft:continuation-id. Until now, I've always put continuation IDs in
the URI, but in this application I really need to do it this way (and
if I can get this to work right, I'm going to do it this way again in
the future!).
The problem is that after the continuation is resumed, the response
to that request is generated by an internal redirect (via sendPage())
of the request, which is of course matched against the sitemap, but
since the request still contains the continuation-id parameter, it
hits on that matcher and re-invokes the continuation, and it's /dj
vu/ all over again, forever and ever, amen.
So, (you smugly say :-), I should just move my continuation-id
matcher to the end of the pipeline, so that it only matches if
nothing else did.
Well, the way I have designed the page flow in this app which I
think is the Right Way, BTW absolutely depends on always matching
on a continuation-id parameter in the flow-originating request, and
having this in turn work in a sane manner. And there is absolutely
no use whatsoever for the continuation-id parameter, once the
continuation has been resumed. I don't think I should have to
redesign my page flow to something worse, just to work around an
onerous constraint on matching the continuation-id! :-)
See below for an example scenario, representative of the sort of page
flow I'm implementing.
But first, the proposed fix:
I've added this method to the oac.environment.Request interface:
public void killContinuation();
In an HttpRequest, this sets a flag which causes
getParameter(continuation-id) to return null. This is a workaround
for the lack of a removeParameter() method in HttpServletRequest (the
delegate).
Now, over to the flowscript side of CForms... in
Form.prototype.showForm(), after the call to sendPageAndWait(), I
call cocoon.request.killContinuation().
Works like a charm. No more infinitous loopage!
So, my questions:
Is this a good fix? There isn't some better one that I am missing,
is there?
No, it's horrible.
My fix might seem like hacky special-case-ism. But it also seems
like adding a general removeParameter() method to these wrappers,
while certainly possible (it'd just be a HashSet), would be overkill
to solve a general problem that doesn't really exist (after all there
is a reason that HttpServletRequest has gotten along nicely all this
time without such a method). But maybe I'm wrong about that, and
someone will tell my why I really should add this as a
removeParameter() method... WDYT?
I've prototyped this in the v2 version of Form, but I'll add it to
v1 and v3 before submitting a patch.
-=-=-=--=
A simple example of why I need this: Suppose we are doing
lightweight authentication i.e., using pure flowscript, w/o the
AuthFW. This is super-simple, but to break it way down in
excruciating detail:
1) The user requests a protected resource /foo.
2) The sitemap dispatches to a flowscript controller function that
handles this request
3) Since this is a protected resource, the controller calls a
flowscript authorize() function
3) The user isn't logged in, so authorize() invokes a login form (a
CForms form). (*N.B.:* the browser is /not/ redirected to the login
page. The address bar shows /foo).
3) The users fills out and submits the form, which is a form
action= so it requests /foo again, this time with some
(additional?) POST parameters: userName, password, and continuation-id.
4) The continuation matcher in the sitemap hits, and the continuation
is resumed.
5) The login was successful, so the authorize() function returns
(otherwise, it just loops and reissues the login form, i.e. return ==
success).
Note: flow function can not return. It can do sendPage,redirect - but
it can't simply return.
6) The caller of of authorize() proceeds and generates the reply to
the request for /foo.
7) The browser receives the reply and renders the page. The address
bar shows /foo, the resource that was originally requested.
I see several possible ways of solving your issue without crazy hacks.
* Move view rendering into the internal-only pipeline. That's how it
(usually) should be with the flow.
* If you don't like
Re: Proposed fix: crazy infinite loop w/ ft:continuation-id
Hi,
I saw that approach in the samples, but thought it would be nice to be
able to navigate the site passing parameters with POST sometimes, so
instead I came up with this:
map match ...
map:select type=request-parameter
map:parameter name=parameter-name value=continuation-id/
map:when test={request-param:continuation-id}
map:call continuation={request-param:continuation-id}/
/map:when
map:otherwise
map:call function...
If the continuation parameter is not present, the test returns null, and
goes to otherwise, which calls the form handler. If the parameter
exists (regardless of whether GET/POST) it calls the continuation.
Just a thought...
Ben Pope.
Eric E. Meyer wrote:
This is how I work with hidden continuation ids since my form posts.
You can select based upon the request:method - continuing only on POST:
map:select type=oacl-simple
map:parameter name=value value={request:method}/
map:when test=GET
map:call function=functionName
map:parameter name=searchType
value={0} /
/map:call
/map:when
map:when test=POST
map:call
continuation={request-param:continuation-id}
/
/map:when
/map:select
Regards,
Eric
Re: Cocoon Hackathon at ApacheCon
[X] there is a chance I gonna make it -pete
Re: Cocoon Hackathon at ApacheCon
Well, try to answer my question before you go? LOL On Apr 1, 2005 5:07 PM, peter royal [EMAIL PROTECTED] wrote: [X] there is a chance I gonna make it -pete
