on 6/27/03 4:47 AM Sylvain Wallez wrote: > Carsten Ziegeler wrote: > > >>Reinhard Pötz wrote: >> >> >> >>>The Cocoon object of the FOM has the method >>> >>> Component getComponent(id) >>> >>>It should return any component but no sitemap components. This means we >>>only return components defined in the roles file(s). How can we check if >>>it is an "allowed" component? >>> >>>Any ideas? >>> >>> >> >>I think the simplest solution is to use the correct component manager that holds >>only the components configured in roles/cocoon.xconf. This is the component manager >>of the o.a.c.Cocoon object. >>Each sitemap as its own component manager for the sitemap component, they are linked >>in a hierarchy to the above mentioned one. >> >> > > > Sorry if I missed something (was offline for several days -- lots of > emails to read), but why is it necessary to make a distinction between > sitemap components and other components ? > > What could be the possible use of e.g. a transformer in a flowscript?
None. That's exactly why we don't want you to try to figure out one ;-) > I > can't see one... So why build complicated fences to prevent something > that is IMO doesn't even make sense ? Because our users are creative abusers. > Furthermore, and this is what triggered this answer, restricting > getComponent() to the top-level CM goes strongly against the upcoming > blocks and the fact that <map:components> is nothing but a regular > ..xconf declaration. Careful. FOM describes a contract basically: you ask for component with the given ID and you get it. How? this is another concern and the flow writer doesn't care. When real blocks will be there, the implementation of the FOM getComponent() method will have to change. Back-compatibly, that is. But I wouldn't worry for this right now. I also have another suggestion: use the higher component manager but just check if the returned component implements SitemapModelComponent and if so return null or raise an exception. Slower to reject calls for invalid components, but takes <map:components> into consideration. What do you think? -- Stefano.
