on 5/27/03 4:06 AM Sylvain Wallez wrote:
>>Object getComponent(id) -> obtains the component indicated by the given ID > > Why don't you use the traditional lookup() name ? Also, release() is > missing. So what about lookupComponent(id) and releaseComponent(id)? release() is missing on purpose. It follows the same principle of "malloc considered harmful" that Java uses for garbage collection. [and the principle that Avalon 5 is supposed to use] as for changing the name from "get" to "lookup" I'm neutral on this. > An important question, also : how does component management fit with > continuations ? if you store your component in a variable, that instance is kept into the continuation object. > Can a component be frozen by a continuation and unfrozen > in a different environment ? it's not the component that is frozen into the continuation, but it's instance. a continuation cannot freeze the state of a java component. > We could have some hooks that automatically > relase components when a continuation is frozen, but then what about > stateful components ? Ricardo told me that the EJB community has already discussed these issues extensively (not for continuations, but for stateful components). Ricardo, anything to add here? >>void callAction(name,map) -> invoques the action indicated by the given >>name and pass the given map as model >> >>NOTE: I personally believe that the getComponent() method removes all >>needs for the callAction() method. I foresee a future where the >>callAction() method will be deprecated. I would personally go the extra >>mile and avoid having it there altogether, but since there is no easy >>way to plugin new avalon components at runtime (at least, not as easier >>as plugging in different actions into the sitemap), I'm in favor of >>leaving it for now, until 'real blocks' will make it unnecessary. > > Same feeling. So what about removing it now ? We can also consider that > the current state of things is that components are "semi-pluggable" : we > cannot add new classes to the classpath dynamically, but we can declare > new components, and particularily actions, dynamically just by changing > the sitemap. So I don't see the real need for callAction(). I'm all in favor or removing this. What do others think? >>Session getSession() >> >>NOTE: both Ricardo and I believe that the flow should always be >>associated with a Session. Thus the use of the semantics "getSession" >>instead of "createSession". We are, in fact, against the concept of >>having the flow behave differently we the session has been created or >>it's has not been. This implicit behavior is potentially very dangerous > >>from a user perspective and should be avoided. > >>Moreover, it has been pointed out how continuations can be see as a way >>to "extend" sessions rather than replacing them. This would allow us to >>reuse the session-handling machinery already in place for things like >>load-balancing and fault-tollerance. > > Fault-tolerance, AFAIK, require session attributes to be serializable. > So by attaching continuations to a session we allow load-balancing, but > we still have a problem with fault tolerance. Correct. Thanks for correcting me on this. >>NOTE: methods that were left out where >> >>- input/output module support >>- script load support >> >>the reason for the first goes together with callAction(). Input/output >>modules were designed to overcome limitations in the scriptability of >>the sitemap. >> >>The reason for removing load() is because we want to avoid people from >>loading scripting dynamically. This goes in parallel with the >>anti-pattern of dynamic pipeline construction. >> >>WARNING: removing load() does *NOT* imply that you have to force all >>your flow in one big file. The way to fragment your flow into different >>files is to use several <map:script> elements in the <map:flow> section >>of the sitemap. >> > > Load support is IMO required because JS lacks an import statement. Not > having it means we'll have to write a <map:script> for the script we > want to use, but also for *all the scripts it depends on*, recursively. > This will be very difficult to manage. Hmmm, I see your point, but let me point something out. In the future, I foresee something like <map:flow> <map:script src="block:whatever:/flow/flow.js"/> <map:script src="cocoon:/myDynamicFlow.js"/> <map:script src="myStaticFlow.js"/> </map:flow> since we agreed that blocks only expose a URI space controlled by the sitemap (they don't expose resources directly!) you can use a reader to get the flow to the dependent block, or you can use a pipeline to generate your flow (for example, traducing a workflow written using a markup language into the equivalent flow instructions). Here you have all the machinery you need to compose your flows as you like. Recursively. The difference between the above and load() is thin but real: while load() has to be executed at runtime, the <map:script> calls can be done at sitemap assembly time. It could have a big impact on runtime performance of the flowscripts. > >>-------- properties --------- >> >>cocoon.request -> the request object >>cocoon.response -> the response object >>cocoon.log -> the log object >> >>NOTE: the absence of the context object is intentional! we couldn't come >>up with a reasonable need for such an object at the flow level. So, for >>the principle of 'less is more', we don't consider it. Be aware that if >>you want to propose its addition, you have to come up with a reason for it. >> > > > A simple reason : the context object (the environment one) gives access > to context parameters defined in web.xml. In many situations, this is > where parameters depending on the deployment environment are located, as > it allows the sysadmin to use it's favorite app server GUI to set them > and avoids editing cocoon.xconf. (yes, I've seen some installs being > totally screwed up because the sysadmin didn't knew what a well-formed > XML file was). Ok, this is exactly the real-life good point I was looking for. +1 for adding context. Do you need read/write or read-only could be sufficient? (I would go for read-only) >>--------------------------------------------------------------------------- >>The Request Object >>--------------------------------------------------------------------------- >> >>The Request object is the one who has been pruned the most from the >>Cocoon Environment. The sections that were pruned were: >> >>- URI handling >>- Session handling >> >>Session handling has been removed in favor of the cocoon object and URI >>handling has been removed because unnecessary. I'm aware this is a big >>statement, please see below of why this is so. >> >> > > > I don't have a good use case for URI handling just now, but I find this > a strong limitation and I'm pretty sure we'll add it in the future... Adding things doesn't hurt. > <snip/> > >>--------------------------------------------------------------------------- >>The Log Object >>--------------------------------------------------------------------------- >> >>This is a convenience method to access the cocoon logger. It could be >>the same of doing >> >>cocoon.getComponent(...) >> > > Huh ? A logger is not a component. Why not? > >> --- o --- >> >>That's it. >> >>This is, IMO, what the FOM requires. Nothing less, nothing more. But let >>me explain why I consider flow-driven URI handling harmful. >> >>Today, once you mount your web application, you don't know where it >>resides. In order to keep your webapp relocatable on your URI space, >>either you keep everything relative (including the many horrible >>../../../ which is easy to get wrong) or you re-invert the control by >>finding out yourself where you have been mounted and tweak URI accordingly. >> >>I strongly dislike both approaches because they are error prone. >> >>IMO, it should be cocoon to transparently adapt the URI right before >>serializing the output to the client. >> >>How? >> >>Using a link-translating protocol. >> >>Example: >> >><html> >> <head> >> ... >> <link src="link:/styles/main.css" ...> >> >>is then transformed accordingly (and transparently) by the sitemap right >>before the serializer. >> > > > This is a good idea, but IMO such a link transformation should be stated > explicitely in the sitemap. Too much magic kills the confidence, and > unecessary transformations kill the performance ;-) Yes. But the problem here is that the sitemap will be come super-verbose since you'll have to add such a transformer all over the place. Well, in my post-2.1 RT on sitemap additions, I will outline the concept of "macro components", basically allow you to create an 'overloaded serializer' which is, in fact, a composition of a transformer and a serializer. Something like <map:serializers> <map:serializer name="xhtml"> <map:transformer name="link-translate"/> <map:serializer/> <-- this is the equivalent of super() </map:serializer> </map:serializer> NOTE: the above is meaningful in a subsitemap where "xhtml" was already defined, so the above is a "wrapper" around the original component. Alternatively you could have something like <map:serializers> <map:serializer name="xhtml"> <map:transformer src="..."/> <map:serializer src="..."/> </map:serializer> </map:serializer> where the components that constitute the fragment are not accessible independently, but only aggregated in the macro component. The above removes the magic and increases readability. In fact, it can be applied to all pipeline components (generators, transformers and serializers). > What about the Avalon context ? Is it omitted on purpose ? yes. do you envision a need for it? -- Stefano.
