cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [Flow] Preparing the vote - long!
Date Mon, 23 Jun 2003 22:30:03 GMT
on 6/22/03 5:06 AM Christian Haul wrote:

> Stefano Mazzocchi wrote:
>>on 6/20/03 2:01 PM Christian Haul wrote:
>>>Reinhard Pötz wrote:
>>>>* Component loading                                          *
>>>>>I see two different types of components in Cocoon today:
>>>>>1) general components (example: SaxParser)
>>>>>2) sitemap components (example: FOPSerializer)
>>>>>I think the flow should have access only to the first family.
>>>Fine. Although I don't see the possible abuse here.
>>Having access to sitemap components would allow the flow writer to
>>assemble pipelines at runtime, which is the closest thing I to abuse of
>>cocoon internals I can think of.
> Oh I see -- but that would require some hard core hacking. 


> Someone who 
> is determined enough to do that will probably find another way even with 
> this restriction.

True as well, but not having access to it will make it a little bit harder.

> Although I don't like to mention it, action are dual use and by removing 
> special support and restricting access to non-sitemap components they 
> are completely banned. 

Yes, that's the intention.

> Yes, a sitemap component could refer to a regular 
> component to do the job, but....

I understand your concerns, expecially since you place lots of efforts
in actions, but let me ask you a question:

shouldn't those general actions be abstracted into general components
that contain business logic instead of using a sitemap-specific
behavioral contract?

By imposing a constraint, there will be a need to refactor those actions
out and clean them up.

If we have a callAction() method, people will lazily use that and that
business-logic orientation refactoring will never happen.


View raw message