cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Flowmaps
Date Thu, 20 Jun 2002 08:21:19 GMT
Ovidiu Predescu wrote:

>On 6/18/02 7:59 AM, "Sylvain Wallez" <sylvain.wallez@anyware-tech.com>
>wrote:
>
<snip/>

>>So what about a simple <map:flows> composed of named <map:flow>, or even
>>a <map:controllers> composed of <map:controller> ?
>>    
>>
>
>I would agree with you here. <map:flows> as the container and <map:flow> for
>a particular flow, seem like better names.
>  
>

Cool.

>>Also, the <map:script> element is intimately tied to the fact that the
>>enclosing <map:flowscript> is of the JavaScript language, and this
>>strongly looks like a component configuration. So once again, is there a
>>fundamental difference between actions, matchers, etc, and flows ?
>>
>>I really don't think so, and consider a flow to be a new kind of sitemap
>>component with the associated primitives in the sitemap language. This
>>feeling is also encouraged by the fact that we all agree that there
>>should be no symmetry between the sitemap and flow, and that the sitemap
>>is the main entry point that drives everything else.
>>
>>So we could have :
>><map:components>
>><map:generators>
>>  ...
>></map:generators>
>>...
>><map:flows>
>>  <map:flow name="calculator"
>>src="org.apache.cocoon.components.flow.JavaScriptInterpreter">
>>    <!-- specific configuration for JavaScriptInterpreter -->
>>    <script src="calc.js"/>
>>  </map:flow>
>></map:flows>
>></map:components>
>>
>><map:pipelines>
>>...
>>
>>Thoughts ?
>>    
>>
>
>Your assumption is that the flow scripts are visible to all the
>applications. I don't think this is reasonable. Just think of an ISP who
>deploys Cocoon, people running their Web app want to be isolated from
>everybody else. How can we achieve this if we describe flow scripts as
>components, inheritable in all the Cocoon blocks that implement user apps?
>

You seem to have misunderstood what I meant about visibility : a flow 
isn't globally visible, but could be visible - just as other components 
- in the sitemap that declared it and all its subsitemaps. If an ISP 
wants to hide a particular flow, then this flow should be declared in an 
ISP-private subsitemap of the main sitemap.

This "hide on a branch" strategy is the one used by Tomcat classloaders 
to hide the servlet engine classes from the webapp classes, and it works 
quite well.

Note that the same visibility problems currently applies to components 
we already have : if an ISP-private datasource or a sensitive action is 
declared in cocoon.xconf or the main subsitemap, they are globally 
visible. Declaring them in a subsitemap hides them from other sitemap 
branches.


>>>Each named flow script declared in <map:flowscripts> could and should be
>>>independent on the others. Each script should have different set of global
>>>variables, which is different from another script, and of course, is
>>>different each user gets his/her own set of values for these variables.
>>>      
>>>
>>This IMO enforces the fact that they are individual component instances.
>>    
>>
>
>But it doesn't prevent other flow scripts deployed in the same Cocoon
>instance to reverse engineer scripts deployed by somebody else (think of the
>ISP scenario).
>  
>

Sorry, I don't understand what you mean here. Is this related to 
filesystem access ?

<snip/>

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




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


Mime
View raw message