Ovidiu Predescu wrote:
> > Hmmm, call me picky, but what's wrong with
> >
> > <map:flowscripts default="calculator">
> > <map:flowscript name="calculator" src="calc.js"
> > language="javascript"/>
> > </map:flowscripts>
>
> Because my calculator implementation may be composed of multiple script
> files. This is not the case in this simple example, but I may need to split
> the implementation for clarity in multiple files. Having the ability to
> specify multiple files by adding <map:script> as needed solves the problem.
Ah, got it. Cool, makes sense.
> > Many ask to make continuations ID as transparent as session IDs. Do you
> > think this is possible/desirable?
>
> I think it is both desirable and possible. I think the responsibility for
> deciding this should be in the sitemap, and only in one place.
Totally agree. That would be the perfect scenario. Do you people have
any ideas on how we can achieve this in practice?
> >> Also in your callPipeline(), how does the output parameter get used?
> >
> > That's the key issue: many people, in the past, pointed out that they
> > would like to reuse the concept of cocoon pipelines to create stuff but
> > send it somewhere else, not back to the client.
> >
> > Currently, there is no way for a pipeline stage to call another pipeline
> > *detaching* it from the client output stream and attaching it a
> > different output stream. I would like the flowscript to be able to do
> > that.
>
> Yes, that's right! HP's SOAP server based on Cocoon had to do some really
> nasty things to achieve this. I see what you mean, and it should be
> possible.
Great, I think so too.
> >> It
> >> should be the task of the sitemap pipeline where the file is written. Am I
> >> missing something?
> >
> > It's *not* the sitemap concern to know where the output stream is. If
> > you look at how the sitemap is implemented, it's the sitemap caller's
> > concern to provide the output stream. Servlets call the sitemap engine
> > passing the ResponseOutputStream and the CLI calls the sitemap engine
> > passing FileOutputStreams.
> >
> > But the granularity is all or nothing. I would like to be able to call a
> > pipeline 'detaching it' from the output stream that the container
> > passed.
> >
> > Why? simply because it allows very creative uses of cocoon pipelines and
> > would instantly stop all those requests for 'forking pipelines' that
> > keep bugging me in the back of my mind.
>
> OK, I get it! That's indeed a nice feature to have.
Yep, this will sure make Cocoon fly :)
> >> 5. Ivelin points out the potential of stale continuations.
> >>
> >> I think this is indeed a real issue. One way to avoid it is to have
> >> continuations automatically expire after a time of inactivity, or do
> >> deactivate them manually in the flow script. The first approach is something
> >> I considered, and there are some hooks in the current code, but more support
> >> code needs to be written. The second approach can be implemented today: you
> >> can invalidate not only a single continuation, but the whole subtree of
> >> continuations which start from it. You just need to keep a hold on the
> >> continuation at the top of the tree, and invoke invalidate() on it.
> >
> > Speaking of which, would it good to have a 'continuation' object in the
> > FOM?
>
> It is already there, together with the data object. Check-out the jpath.xsl
> logicsheet to see how this works.
uh, impressive :)
> >> 8. Vadim's idea about making the syntax easier.
> >>
> >> I think the idea of having something as simple as:
> >>
> >> <map:match pattern="calc/*">
> >> <map:flow method="calculator" continuation="{1}" />
> >> </map:match>
> >>
> >> makes a lot of sense. Using different matchers, the continuation id can be
> >> extracted from the request parameters, cookies, you name it. The only
> >> problem with it is that is a bit inflexible in terms of the URI design. If
> >> I'd like to have calc/kont/*, there's no easy way to specify it.
> >>
> >> So I'd say we can have two alternative ways of writing this: using the above
> >> proposal and what is already implemented, for power users that want more
> >> control. How about this?
> >
> > Sorry, but I lost you here.
>
> I think the idea is to have something which just works by default, with no
> configuration necessary. In addition to this, more experienced developers
> can use the current method, which is more complex. Vadim's proposal is for
> the first method. What is already implemented in the current code is the
> second method.
Ah, ok. Just one point, the code above:
<map:match pattern="calc/*">
<map:flow method="calculator" continuation="{1}" />
</map:match>
would not match "calc/" (at least, in the past I had problems with this,
maybe behavior changed today, I'm not sure), probably
<map:match type="regexp" pattern="calc/?(.*)">
<map:flow method="calculator" continuation="{1}"/>
</map:match>
is a better way to handle it. What do you think?
> >> 9. Reinhard asks what happens if two different flow scripts have a function
> >> with a similar name name.
> >>
> >> Since the flow scripts have their own variable space (not now due to some
> >> problems in the current implementation), there shouldn't be any problem.
> >> Each flow script can use its own variable and function names, without
> >> worrying about possible conflicts with other scripts.
> >
> > Yes, and also I was thinking about having something like
> >
> > <map:call flow="calculator" method="calculator"/>
> >
> > that provides sort of namespacing and avoids collisions.
>
> In the new scheme I'm working on, there's no potential for collisions, each
> flow script has its own namespace, separated from the others.
Internally, yes, but how would you specify which flowscript you want to
call between all those you have declared in your sitemap?
For example
<map:flowscripts default="a">
<map:flowscript name="a">
<map:script src="first.js" language="javascript"/>
<map:script src="second.js" language="javascript"/>
</map:flowscript>
<map:flowscript name="b">
<map:script src="first.js" language="javascript"/>
<map:script src="third.js" language="javascript"/>
</map:flowscript>
</map:flowscripts>
as you can see, both flowscripts include the same script 'first.js', so
the function calls between the two overlap completely. Let us assume
that the function 'blah' is described in 'first.js', then you call it
with
<map:flow function="blah" continuation="..."/>
and it defaults to the 'a' flowscript (since the
map:flowscripts/@default attribute states so). But how would you call
the 'blah' function of the 'b' flowscript?
I would follow the same pattern we use for components and use
<map:flow flowscript="b" function="blah" continuation="..."/>
I see no transparent ways to do this.
> > [...]
> >
> >> - automatic binding of JavaScript variables to form values. This would allow
> >> you to declare something like:
> >>
> >> var username, password;
> >>
> >> // Send a page to collect the user name and the password
> >> sendPage("login.html");
> >>
> >> // When the user fills in the form and presses the submit button, the
> >> // script restarts here. The flow engine automatically binds the username
> >> // and password to the values submitted in the form.
> >>
> >> // make use of username and passwd here
> >
> > I didn't know PHP had problems with this approach, but it smells a lot
> > anyway. I'm always afraid of implicity behavior, expecially when it's
> > user-triggerable.
> >
> > This is not automatically a security hole, but it could become one since
> > you are letting potential attackers one step closer to your door. And
> > you are making things hidden so harder to spot.
> >
> > I would be against anything so implicit.
>
> No, no, I wanted to say something completely different. I replied to this
> topic already, but I'll repeat it here to be clear.
>
> The automatic binding happens under the strict control of the programmer.
> What I was thinking to have is the ability to map a request parameter to a
> script variable, _if_ the programmer requests so for a particular variable.
> How the mapping is done is completely under the control of the programmer.
Ah, I get your point. You want to do something like what IE does with
DOM in DHTML:
document.blah
is equivalent of
document.getElementById("blah");
so that instead of doing
cocoon.getRequest().getParameter("password");
you call something like
request.password
directly. Is that your point?
> >> - automatic validation of form values on both server and client side. This
> >> should allow the same piece of JavaScript validation code to be executed
> >> both on the server and client side. More on this later.
> >>
> >> 11. With respect to how to put a back button on a page, I think I replied to
> >> this some time ago. The idea is to use the <jpath:continuation select="1"/>
> >> which selects the previous continuation.
> >
> > I agree with Torsten: I'd like to keep the flow layer detached from the
> > jpath logicsheet. (I would also use -1 as well to indicate backwards)
>
> Again, I was only lazy to come up with a new logicsheet, so I reused things
> in the same logicsheet.
>
> The counting starts from a node in the tree and goes upwards, that was the
> reason why the number is positive. To me this makes more sense than using
> negative numbers, but I have no strong opinions.
I think you saw this from a development point of view, from a user point
of view, the flow of the continuation goes with the arrow of time, so
you go "back" to retrieve your past continuation. And "1" seems to imply
a step 'forward' in the arrow of time (which doesn't make any sense and
would confuse people at first, at least, that's what happened to me...
but I'm by far not the average Cocoon user :)
> >> 13. Piroumian asks how to cancel a continuation.
> >>
> >> As I mentioned in several ocasions, sendPage() returns the saved
> >> continuation. If you want to cancel the continuation just invoke on it the
> >> invalidate() method. It will cancel all the receiver and all the
> >> continuations that inherit from it.
> >
> > Cool. Ovidiu, we *definately* need more docs on what you wrote. It's
> > simply too undocumented right now... don't need to be XML-ized edited or
> > anything, just bare raw but with juicy info inside, we'll make them
> > better ourselves.
>
> Yes, I know it's undocumented. I spent a lot of time describing the ideas on
> emails, but didn't actually takes those and put in a document. I'll try to
> come up with some docs, but there are simply too many things to work on at
> the same time ;)
I would kindly suggest you to escape your 'ego trap' and start writing
crude docs before anything else. I know it would be very nice if you
could provide us with all we asked for already implemented, but then you
become the bottleneck and the community suffers from this.
Instead, if you provide even a very basic description of what we have
there (don't worry, doesn't need to be coherent or well written, just
contain the information for the other developers to catch up on your
work), work can parallelize.
Hope you get my point.
> >> 14. Another question Piroumian has is how to validate against business
> >> logic. Since JavaScript is tightly integrated with Java, you can call Java
> >> logic from the flow script to do the business logic validation. This way you
> >> can invoke whatever logic you want. If this is too generic, then provide
> >> some use case and I'll try to sketch a solution.
> >
> > I think you should provide a real-life example of use of a java data
> > model to show how java can be called from the flowscript.
>
> This too is on my TODO list ;)
Ok, please, make *your* TODO list *ours*. :)
And don't worry if you don't have time, nobody really does... and who
does is wasting it to work on something so stupid as Cocoon instead of
appreciating what they have in their life, myself first :(
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
