On 6/20/02 1:21 AM, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> Ovidiu Predescu wrote:
>
>> 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?
The approach you mention will also match things like "calculator", which is
probably not what we want.
Vadim already pointed out the first approach works fine, which I think is
what we need.
>>>> 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.
Sorry, you're right, I misunderstood what you have in mind. This would be
the right approach to differentiate between things.
>> 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?
Yes, we can use either this approach, or a separate mapping file, or a
programmatic way to specify the mapping between a variable name in a
function and a request parameter. I think the approach you mention above is
the easiest however.
>> 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 :)
OK, I got your point.
>>> 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.
Kevin O'Neill <[EMAIL PROTECTED]> has volunteered to start collecting
some of the old email threads and assemble them in a more or less coherent
document, which describes the main ideas.
>>>> 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*. :)
Yep, I've tried it.
But the code is crappy, and there's no documentation to explain the ideas.
The only place where these ideas are presented is on the mailing list, and
there the messages span across multiple months. I don't expect *my* TODO
list to suddenly become everybody else's. There is simply no critical mass
of developers that understand the ideas and the code enough for this to
happen. This is the reality of any open source project, the original
developer has to drive it to a certain point until people pick it up from
there.
> 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 :(
I concur to these statements ;)
Best regards,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
