You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/06/10 14:01:57 UTC
Sitemap: flow and interpreters
While inspecting the current sitemap (tree builder) code for flow,
I'm wondering about the support for different languages.
The basic question first: do we want to support more than one flow
language per sitemap?
If yes, imho this isn't supported yet. It's possible to register
scripts for different interpreters in a single sitemap. But as
each flow node (containing the scripts) registeres itself at
the tree processor and as the treeprocessor uses a simple map
to store them, the last node wins. In addition there isn't a way
to tell the call function node which language it should use.
I think we should either allow only one script language per sitemap
or we should fix the current code. I prefer the second solution.
WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Sitemap: flow and interpreters
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Glen Ezkovich wrote:
>
>>The fix appears easy, but is something broken? Has someone expressed
>>the desire to use two languages in a single sitemap or is this just
>>an instance of feature creep?
>
> I tend to agree, so I think we should for now just forbid to write
> different map:flow sections in a single sitemap (by different I mean
> that they use a different interpreter). If someone wants to use more
> than one language we can add that easily.
agree
>
>
>>My fear is that this may lead to
>>conflicts in function naming that we will need to resolve in the
>>future.
>>On the other hand your proposal for a SitemapEnvironment
>>object seems like a smart refactoring.
>
> Ok :)
in spite of being a specialist in this area of Cocoon, I think it makes sense.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Sitemap: flow and interpreters
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Jun 12, 2005, at 1:18 AM, Ralph Goers wrote:
> Glen Ezkovich wrote:
>
>
>>
>>
>>> 2-Should we want to encourage people to write Javaflow instead
>>> of JSFlow?
>>>
>>
>>
>> No. While I plan on using Javaflow going forward, JSFlow makes
>> flow available to Javascript programers (web masters).
>>
>
> Interesting that you should say that because that is exactly the
> reason why we would use Javaflow. We believe the controller and
> model are the responsibility of the software engineer and should be
> in the deployed webapp, while the view is the responsibility of the
> web guys. Thus, using Java keeps the web guys from being tempted
> into mucking with the controller.
>
This is my view as well. However, I realize that there are some
people and teams working with Cocoon who are not Java developers. As
much as I would like to see everyone do things the right way (my
way), I would rather educate them, then force them. As I recall the
pet shop example uses all Javascript (except for ScriptableConnection
or some such). There are sites that are developed by multimember
teams and there are sites that are developed by individuals.
Sometimes that individual is a web guy. I don't want to make them
feel like a second class citizen by telling them that Javascript is
not good enough to use when developing with Cocoon. Even if it is
just a scripting language ;-)
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: Sitemap: flow and interpreters
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> Glen Ezkovich wrote:
>
>>
>>
>>> 2-Should we want to encourage people to write Javaflow instead of
>>> JSFlow?
>>
>>
>>
>> No. While I plan on using Javaflow going forward, JSFlow makes flow
>> available to Javascript programers (web masters).
>
>
> Interesting that you should say that because that is exactly the reason
> why we would use Javaflow. We believe the controller and model are the
> responsibility of the software engineer and should be in the deployed
> webapp, while the view is the responsibility of the web guys. Thus,
> using Java keeps the web guys from being tempted into mucking with the
> controller.
It highly depends on the company specific development processes. So far I've
seen both approaches.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Sitemap: flow and interpreters
Posted by Ralph Goers <Ra...@dslextreme.com>.
Glen Ezkovich wrote:
>
>
>> 2-Should we want to encourage people to write Javaflow instead of
>> JSFlow?
>
>
> No. While I plan on using Javaflow going forward, JSFlow makes flow
> available to Javascript programers (web masters).
Interesting that you should say that because that is exactly the reason
why we would use Javaflow. We believe the controller and model are the
responsibility of the software engineer and should be in the deployed
webapp, while the view is the responsibility of the web guys. Thus,
using Java keeps the web guys from being tempted into mucking with the
controller.
>
>
> Glen Ezkovich
> HardBop Consulting
> glen at hard-bop.com
>
Ralph
Re: Sitemap: flow and interpreters
Posted by Antonio Gallardo <ag...@agssa.net>.
On Sab, 11 de Junio de 2005, 21:05, Glen Ezkovich dijo:
>
> On Jun 11, 2005, at 7:53 PM, Antonio Gallardo wrote:
>
>> On Sab, 11 de Junio de 2005, 10:34, Carsten Ziegeler dijo:
>>
>>> Glen Ezkovich wrote:
>>>
>>>>
>>>> The fix appears easy, but is something broken? Has someone expressed
>>>> the desire to use two languages in a single sitemap or is this just
>>>> an instance of feature creep?
>>>>
>>> I tend to agree, so I think we should for now just forbid to write
>>> different map:flow sections in a single sitemap (by different I mean
>>> that they use a different interpreter). If someone wants to use more
>>> than one language we can add that easily.
>>>
>>
>> This made me think about the future:
>>
>> 1-Exists or will exists the need to migrate JSflow to javaFlow (legal,
>> convenience, user desire or whatever)?
>
> Easing migration would be more of concern if my answer to #2 were
> yes. There are workarounds that I think would be more appropriate
> such as separate sitemaps for migrating to JavaFlow.
Well, there is a fact we need still need to solve around rhino. On the
other side, I hear there are some troubles using Bcel inside JVM-code for
java 1.5 (I never tried, perhaps it was only FUD).
>> 2-Should we want to encourage people to write Javaflow instead of
>> JSFlow?
>
> No. While I plan on using Javaflow going forward, JSFlow makes flow
> available to Javascript programers (web masters).
>
>> 3-Need to be a web glue for flow code too?
>
> Don't know yet. What is the use case?
We know JSFlow exists longer than JavaFlow. A usecase can be people
wanting to use already tested JSFlow while writting newer code using
JavaFlow.
> I just think its prudent to wait until there is a real need before we
> add a feature that may introduce complexities.
I agree. I just wanted to give some ideas of why this should be good. I
don't feel the need of support both flow scripts right now and dunno if in
the future I will need both on the same sitemap. Perhaps the answer is
never.
In anycase if this is too much complicated to implement or a waste of time
(including runtime), I believe we will find better way to migrate if
needed.
Best Regards,
Antonio Gallardo
Re: Sitemap: flow and interpreters
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Jun 11, 2005, at 7:53 PM, Antonio Gallardo wrote:
> On Sab, 11 de Junio de 2005, 10:34, Carsten Ziegeler dijo:
>
>> Glen Ezkovich wrote:
>>
>>>
>>> The fix appears easy, but is something broken? Has someone expressed
>>> the desire to use two languages in a single sitemap or is this just
>>> an instance of feature creep?
>>>
>> I tend to agree, so I think we should for now just forbid to write
>> different map:flow sections in a single sitemap (by different I mean
>> that they use a different interpreter). If someone wants to use more
>> than one language we can add that easily.
>>
>
> This made me think about the future:
>
> 1-Exists or will exists the need to migrate JSflow to javaFlow (legal,
> convenience, user desire or whatever)?
Easing migration would be more of concern if my answer to #2 were
yes. There are workarounds that I think would be more appropriate
such as separate sitemaps for migrating to JavaFlow.
> 2-Should we want to encourage people to write Javaflow instead of
> JSFlow?
No. While I plan on using Javaflow going forward, JSFlow makes flow
available to Javascript programers (web masters).
> 3-Need to be a web glue for flow code too?
Don't know yet. What is the use case?
I just think its prudent to wait until there is a real need before we
add a feature that may introduce complexities.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: Sitemap: flow and interpreters
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
>
>> 2-Should we want to encourage people to write Javaflow instead of
>> JSFlow?
>
>
> no, I think offering both options is enough. People can decide
> themselves.
>
Actually, I think we need a third option, but I don't know what it is.
I've heard the desire to have something that is like the sitemap in that
is a "configuration file" (i.e. it is XML) but is more programmable. I
suppose something like Jelly, although I doubt I'd ever recommend using
Jelly itself. Basically its as if they want the sitemap, but with the
ability to stick if/else, for, while, etc. statements in it and be able
to call Java business methods from it.
Ralph
Re: Sitemap: flow and interpreters
Posted by Reinhard Poetz <re...@apache.org>.
Antonio Gallardo wrote:
> On Sab, 11 de Junio de 2005, 10:34, Carsten Ziegeler dijo:
>
>>Glen Ezkovich wrote:
>>
>>>The fix appears easy, but is something broken? Has someone expressed
>>>the desire to use two languages in a single sitemap or is this just
>>>an instance of feature creep?
>>
>>I tend to agree, so I think we should for now just forbid to write
>>different map:flow sections in a single sitemap (by different I mean
>>that they use a different interpreter). If someone wants to use more
>>than one language we can add that easily.
>
>
> This made me think about the future:
>
> 1-Exists or will exists the need to migrate JSflow to javaFlow (legal,
> convenience, user desire or whatever)?
After marking Javaflow as stable I guess the majority will use Javaflow, but
there will still be the need for Flowscript. It depends on the software
development process of an organization.
> 2-Should we want to encourage people to write Javaflow instead of JSFlow?
no, I think offering both options is enough. People can decide themselves.
> 3-Need to be a web glue for flow code too?
Do you mean that flows of different languages can communicate with each other?
If this is your questions, I'd say that session attributes are good enough. This
is by the way also our answer how two flowscripts (--> only one language) can
exchange information.
> If the answer of one of the questions is true, then we should allow them
> to coexists. If not, there is not need at all.
As long as we don't hear our users complaining we shouldn't try to find
solutions for a maybe non-exisiting problem.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Sitemap: flow and interpreters
Posted by Antonio Gallardo <ag...@agssa.net>.
On Sab, 11 de Junio de 2005, 10:34, Carsten Ziegeler dijo:
> Glen Ezkovich wrote:
>>
>> The fix appears easy, but is something broken? Has someone expressed
>> the desire to use two languages in a single sitemap or is this just
>> an instance of feature creep?
> I tend to agree, so I think we should for now just forbid to write
> different map:flow sections in a single sitemap (by different I mean
> that they use a different interpreter). If someone wants to use more
> than one language we can add that easily.
This made me think about the future:
1-Exists or will exists the need to migrate JSflow to javaFlow (legal,
convenience, user desire or whatever)?
2-Should we want to encourage people to write Javaflow instead of JSFlow?
3-Need to be a web glue for flow code too?
If the answer of one of the questions is true, then we should allow them
to coexists. If not, there is not need at all.
Best Regards,
Antonio Gallardo.
Re: Sitemap: flow and interpreters
Posted by Carsten Ziegeler <cz...@apache.org>.
Glen Ezkovich wrote:
>
> The fix appears easy, but is something broken? Has someone expressed
> the desire to use two languages in a single sitemap or is this just
> an instance of feature creep?
I tend to agree, so I think we should for now just forbid to write
different map:flow sections in a single sitemap (by different I mean
that they use a different interpreter). If someone wants to use more
than one language we can add that easily.
> My fear is that this may lead to
> conflicts in function naming that we will need to resolve in the
> future.
> On the other hand your proposal for a SitemapEnvironment
> object seems like a smart refactoring.
Ok :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Sitemap: flow and interpreters
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Jun 11, 2005, at 8:41 AM, Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote:
>
>> Le 11 juin 05, à 11:30, Carsten Ziegeler a écrit :
>>
>>
>>> ...Ok, so we should decide if we want to support more than one flow
>>> language per sitemap, first...
>>>
>>
>>
>> Is there a need for this? It might lead to some confusion, and IIUC
>> there's always the workaround of using several sitemaps if someone
>> needs several flow languages simultaneously.
>>
>>
> I honestly don't know. The problem I see is that you are allowed to
> define several scripts with different languages per sitemap, but
> the map:call addresses always the last map:flow node.
>
>
>> So I'm not sure if it's worth the effort (but I don't know how big
>> the
>> effort is ;-)
>>
>>
> I think fixing this is very easy, just a few minor changes and that's
> it. The other solution is to allow only one map:flow node per sitemap.
> But I think we should do one or the other.
The fix appears easy, but is something broken? Has someone expressed
the desire to use two languages in a single sitemap or is this just
an instance of feature creep? My fear is that this may lead to
conflicts in function naming that we will need to resolve in the
future. On the other hand your proposal for a SitemapEnvironment
object seems like a smart refactoring.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: Sitemap: flow and interpreters
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> Le 11 juin 05, à 11:30, Carsten Ziegeler a écrit :
>
>>...Ok, so we should decide if we want to support more than one flow
>>language per sitemap, first...
>
>
> Is there a need for this? It might lead to some confusion, and IIUC
> there's always the workaround of using several sitemaps if someone
> needs several flow languages simultaneously.
>
I honestly don't know. The problem I see is that you are allowed to
define several scripts with different languages per sitemap, but
the map:call addresses always the last map:flow node.
> So I'm not sure if it's worth the effort (but I don't know how big the
> effort is ;-)
>
I think fixing this is very easy, just a few minor changes and that's
it. The other solution is to allow only one map:flow node per sitemap.
But I think we should do one or the other.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Sitemap: flow and interpreters
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 11 juin 05, à 11:30, Carsten Ziegeler a écrit :
> ...Ok, so we should decide if we want to support more than one flow
> language per sitemap, first...
Is there a need for this? It might lead to some confusion, and IIUC
there's always the workaround of using several sitemaps if someone
needs several flow languages simultaneously.
So I'm not sure if it's worth the effort (but I don't know how big the
effort is ;-)
-Bertrand
Re: Sitemap: flow and interpreters
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>
> You're right that only one flow language can be used within one sitemap.
> Additionally to your reasons, there are two others:
>
> - we need access to the flow controller of a sitemap
> (to make e.g. Flowscript calls like
> var x = cocoon.blocks.blockXYZ.myFunc()
> possible)
> - IIRC there is some sort of hack to identify the called method
> in the JavaInterpreter.callFunction() method. If two registered
> Javaflow classes have equally named methods, you can't use
> both of them in your sitemap as one of them (I think the first)
> is used
>
Ok, so we should decide if we want to support more than one flow
language per sitemap, first.
Then I think we should create something like a "sitemap environment"
object, containing the processor, the service manager etc. for the
current sitemap. Currently we have a getCurrentXY() method for each
object. We could all combine these information into a single
accessor object. And then we should include all available interpreters
in this object as well.
WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Sitemap: flow and interpreters
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> While inspecting the current sitemap (tree builder) code for flow,
> I'm wondering about the support for different languages.
>
> The basic question first: do we want to support more than one flow
> language per sitemap?
>
> If yes, imho this isn't supported yet. It's possible to register
> scripts for different interpreters in a single sitemap. But as
> each flow node (containing the scripts) registeres itself at
> the tree processor and as the treeprocessor uses a simple map
> to store them, the last node wins. In addition there isn't a way
> to tell the call function node which language it should use.
>
> I think we should either allow only one script language per sitemap
> or we should fix the current code. I prefer the second solution.
>
> WDYT?
You're right that only one flow language can be used within one sitemap.
Additionally to your reasons, there are two others:
- we need access to the flow controller of a sitemap
(to make e.g. Flowscript calls like
var x = cocoon.blocks.blockXYZ.myFunc()
possible)
- IIRC there is some sort of hack to identify the called method
in the JavaInterpreter.callFunction() method. If two registered
Javaflow classes have equally named methods, you can't use
both of them in your sitemap as one of them (I think the first)
is used
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de