cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: [RT] Flowmaps
Date Wed, 19 Jun 2002 22:32:48 GMT
On 6/18/02 2:32 AM, "Torsten Curdt" <tcurdt@dff.st> wrote:

>> 4. Stefano's callPipeline() function. Is this equivalent to
>> sendPageAndContinue(), which is already implemented in the flow layer? It
>> essentially allows you to have a page processed through a pipeline, and
>> continue the execution of the script. BTW, I think your sitemap snippet has
>> a bug in it, shouldn't it have the <map:match> names swapped?
>> 
>> Also in your callPipeline(), how does the output parameter get used? It
>> should be the task of the sitemap pipeline where the file is written. Am I
>> missing something?
> 
> what about loading stuff from a pipeline? an stream does not look very useful
> in our little XML world

Not sure I understand what you mean by this, can you elaborate?

>> 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.
> 
> that's one of the things that scares me off most!! this actually smells to be
> a security issue. (Think of a machine alway starting new continuation objects
> until or VM is out of memory...) We need a max limit of continuations like
> there is for sessions too. (Same problem also applies to sessions)
> 
> And we need a continuation-"janitor" to expire them...

Yes, these are on my TODO list (which BTW I think I forgot it in the
schecoon directory ;)

>> 6. Multi-page forms are not dominating, and continuation based compared to
>> even driven (GUI-like) programming approaches.
>> 
>> I used to program GUIs a lot, I think for certain things, event-driven is
>> better than using continuations. I do think however that continuations have
>> a place, especially for multi-page forms. Now I think it depends a lot on
>> the application, whether these forms are prevalent or not.
> 
> What do think makes multi-page forms special in terms of not using an event
> driven approach? Somehow I'd consider the precept approach going this
> direction... a pressed button is mapped to a java function... not exactly
> event-driven but more like that...

The fact that you can say what's going on in the application by just looking
at a function is, I think, the most appealing thing about using
continuations. Sure you can achieve the same thing in an event driven type
of approach, but the flow is just scattered across multiple
functions/methods.

>> Since these functions share the same global variables, it's very
>> easy to share data between them. You can share data using the session
>> object, but with explicit variables is much easier to follow what's going
>> on.
> 
> true. but one could bind references to session variables so you can work with
> them as they were local. But you would have to set this up... but it's
> possible...
> 
> Even in java...

Yes, I know is possible.

>> If you don't care about sharing data between actions, then there's probably
>> little value describing your action logic in a flow script. Other than the
>> fact that you don't have to write Java code, which means compile, build war
>> file, restart tomcat. With flow scripts, you just modify the script file
>> and resend the request: the script is automatically reloaded and parsed by
>> Cocoon, there's no need to restart anything.
> 
> Well, this also depends on the servlet engine. If you have your actions in
> WEB-INF/classes at least resin does fine and even auto-compiles them for
> you!!

Without reloading the whole Web app? I'd be surprised if this is the case,
since your app may be inconsistent if only some classes are loaded, but not
the others.

>> 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.
> 
> <map:match pattern="calc/kont/*">
> 
> Did I miss somehting?

How do you extract the continuation id if it's embedded in a request
parameter?

>> 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?
> 
> I think it would be cool not have it in the sitemap (or only in the root
> sitemap) so things happen more automagically... like with sessions

Hm, interesting thought. I think it makes sense, we can have a default
setup, and if the user doesn't care to change the default, it is used.
Otherwise, the user can customize it for his/her tastes.

> [...]
>
>> Torsten's example uses a heavily xmlform type of approach, where the data
>> to be validated is kept in a Java object or a DOM tree.
> 
> Well, don't wanna be picky - but the precept approach ;-)

Yes, sorry, I keep forgetting this :(

>> This is one way of
>> doing things; another one would be to use explicit variables which, at the
>> end of the validation, could be written in the database directly, or used
>> to construct a object hierarchy which is then saved in the database using
>> JDO, EJBs or whatever other means.
> 
> that's the hell I'd like to escape!! for a simple form that's no problem. But
> as soon as you have 30 variables this becomes a mess! Since we are always
> working with XML structures an instance / DOM is much easier / convenient to
> handle - especially if you want to perform validation against it!

In this case, you can simply edit the DOM tree, as you described in your
example. You just use the flow layer to keep track of where you are in the
form.

>> The validation could be done directly in
>> JavaScript, instead of a Schema approach. The code that does the validation
>> could then be used on the client side as well.
> 
> Arrgh! don't push me into hell again ;-) This sounds like "you just need to
> code the logic of whole form" that's exaclty what should considered "bad
> practise" for larger forms!
> You can really boost productivity expressing it in XML - only depends on the
> XML structure ;-)

Perhaps, I didn't have problems with this. With the right set of validation
functions, coding them in JavaScript is just as easy as describing the
schema and the constraints.

>> As Stefano mentioned, the flow layer is an infrastructure which can be used
>> to create higher level abstractions. Here are some things I am currently
>> looking at, which can improve the usability of the flow script engine:
>> 
>> - 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");
> 
> As christian pointed out - that's a major security whole!!! And be avoided!
> BTW: same goes for examples floating around using the request logicsheet with
> esql where request parameters are directly used in the esql query! EVIL!

I already replied on this one. The idea is not to define variables on the
fly, but to have predefined variables in your script bound to form
parameters. This shouldn't pose any security problem. A similar thing is
done in various other frameworks I'm aware of.

>>   // 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
> 
> you could consider an special array for that... like GLOBALS["var"] in PHP.
> (or a varibale prefix)
> 
> With flowscript it could even be persistent...

Yes, you can always access request parameters using request.getParameter().
What I was suggesting is a way to bind _predefined_ variables in your script
to request parameters. The framework would then take care of automatically
assigning values to variables, before the continuation is restarted.

>> - 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.
> 
> I'm looking forward on this one!!! Tell me 8-))

I don't have much details to give you right now, as I'm still trying to
figure out the best way to do it. But the general idea is to have the
validation code done in a separate file, which could be used as is both on
the client and server side. On the server side you just include this file in
your flow script and call the functions to do the necessary validation. For
the client side, you make the file available through the sitemap, so the
same validation can happen in the browser.

>> 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.
> 
> but that means go back one step in the continuation execution tree (or
> something) ...but what if that's not the same? What if you want to actually
> "do something" and then go back one step!?

An example for such a scenario would be very good, could you provide one?

>> As I mentioned in some other message, the continuations created during the
>> execution will form a tree, or a list if the user never presses the back
>> button and starts on a different path. At any given point you can access
>> the continuations above you in the tree, which identify the past pages, by
>> using the "select" attribute in <jpath:continuation>.
> 
>> 12. Torsten: sub-flows, flow-2-flow, what are these? Is assembly of
>> functions that represent independent flows enough?
> 
> Ok...
> 
> sub-flow: imagine you have a form and in it a branch to a different flow...
> you could map it as an indepent flow - but actually it's a sub-flow. If we
> implement this "sub-flow" by just switching to another flow and then come
> back to the orignial flow. One flow needs to pass variables to the other
> flow! that's what I meant by flow-2-flow communication!
> 
> see what I mean?

I think I do. As I said in the last email, what is wrong with a function
call? Generally you have a high-level function implementing the flow for a
particular portion of your application. From this function you can call any
function you like, including one that does its own thing, and sends a bunch
of pages to the user. When this function finishes, you get back in the flow
you left.

And since you're using a programming language, you can pass any variables
you like to a function. Or you can make use of global variables. Or you can
make use of objects, and have those variables be instance variables, and the
functions be methods of the object, so you can directly access any instance
variable from any method.

> [...]
> 
>> 16. Sylvain: should flow scripts be inherited by sub-sitemaps?
>> 
>> I'm not sure of the security implications of allowing them to be inherited:
>> what should be the behavior if a developer alters definitions from an
>> inherited flow script?
> 
> that's again the discussion we had with blocks ;-)
> I think it should be possible! Otherwise you have to declare your flowscript
> in each sub-sitemap - and we have dozens of them!

Yes, maybe, I'm not sure. I think we need to experiment with it for a while.

> [...]
> 
>> Variables in this global variable space will act as session variables. To
> 
> what does that mean exactly? you mean they are persistent... but local to the
> continuation's object, arent't they?

Yes, they are persistent, well, as long as the continuation object is
around. They are indeed local to the continuation object. And each user has
his own set of values for these global vars.

>> facilitate communication between applications or share constant values
>> between users of the same application, an application and a global space
>> will be introduced.
> 
> so this could be used for flow-2-flow communication?!

Now, I saw what you meant by sub-flow, but what is flow-2-flow?

>> 20. My job - thanks Stefano for bringing it up. Here's my shameless plug :)
>> If you think of using Cocoon for building Web apps or Web services, and you
>> need support in doing so, I am providing consultancy for doing it, anytime,
>> anywhere.
> 
> Aren't you still working for HP?

So far, yes, but I don't know if I will next week ;)

Cheers,
Ovidiu

-- 
Ovidiu Predescu <ovidiu@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message