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.
True. > 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. -- Stefano.
