Re: FOM implementation
on 6/26/03 2:13 PM Reinhard Pötz wrote: > >>-Original Message- >>From: Pier Fumagalli [mailto:[EMAIL PROTECTED] >>Sent: Thursday, June 26, 2003 12:22 PM >>To: [EMAIL PROTECTED] >>Subject: Re: FOM implementation >> >> >>"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: >> >> >>>1) addEventListener/removeEventListener >>> >>>[...] >>> >>>Given the state of the FOM, I would also be ready to >> >>comment them out >> >>>(for now) and go on with more important things until we >> >>have time to >> >>>define a basic event model for the flow (basically, what events are >>>generated and when). >> >>As they are future additions (and therefore don't modify the >>signature of the FOM), I'd prefer to comment them out, and >>re-add them when ready. > > > +1 Ok, cool. I'll comment them out in code and update the wiki accordingly. -- Stefano.
RE: FOM implementation
> -Original Message- > From: Pier Fumagalli [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 26, 2003 12:22 PM > To: [EMAIL PROTECTED] > Subject: Re: FOM implementation > > > "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > > > 1) addEventListener/removeEventListener > > > > [...] > > > > Given the state of the FOM, I would also be ready to > comment them out > > (for now) and go on with more important things until we > have time to > > define a basic event model for the flow (basically, what events are > > generated and when). > > As they are future additions (and therefore don't modify the > signature of the FOM), I'd prefer to comment them out, and > re-add them when ready. +1 Reinhard
Re: FOM implementation
At 11:27 PM 6/25/2003, Stefano wrote: on 6/21/03 10:55 AM Christopher Oliver wrote: 2) getComponent() returns an avalon component which is not a sitemap component. Basically, it has to ask to the cocoon component manager to return the component identified with the given role and check if it doesn't implement "SitemapModelComponent", in which case an exception should be thrown. What do you think? I'm going to ask again about reusing code currently in actions - we talked about this before but I think I can explain a little better what I was thinking. (see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105407572313285&w=2) Scenario: you have code in actions and want to quickly migrate to flow, abandoning the "action contract" (the null/map return from act() ) but don't want to recode all existing actions to do so. If each action already has public methods which it called internally from act() (perhaps because you wanted to be ready for a transition to flow) you already have your generic avalon component suitable for use in the flow - just don't call act, but your various other methods. Since the discussion linked above, it seems that getComponent() is now taking a role as it's id - this was at some point not a given. So how do you locate your component (ex-action) if it does not provide a specific ROLE, but just inherits it from some superclass? I see two options: - go back and add a specific ROLE to each component? involves (admittedly trivial) modification to each class and recompiling them all. Does this mean it must go in cocoon.xconf (surely this must be "yes") - look it up via the sitemap hint - but that is probably not possible/desirable in flow? I guess a third option is adding getAction() (instead of callAction() ) ?? Geoff
Re: FOM implementation
"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > 1) addEventListener/removeEventListener > > [...] > > Given the state of the FOM, I would also be ready to comment them out > (for now) and go on with more important things until we have time to > define a basic event model for the flow (basically, what events are > generated and when). As they are future additions (and therefore don't modify the signature of the FOM), I'd prefer to comment them out, and re-add them when ready. Pier
Re: FOM implementation
on 6/21/03 10:55 AM Christopher Oliver wrote: > OK. I didn't implement the following, so if you or anyone else would > like to, please go ahead: > > Cocoon.addEventListener() > Cocoon.removeEventListener(); > Cocoon.getComponent() > > Can someone explain the purpose and behavior of these operations? I finally had the time to look into the FOM today and I saw your comments. Please allow me to explain my intentions with the above methods: 1) addEventListener/removeEventListener the Servlet API introduces in version 2.3 an event model which is basically connected to remouval of session values. The servlet API version 2.4 (yet to be finalized) introduced a number of new events, even if, to be honest, many of them are utterly useless and were probably introduced for symmetry (something which I dislike, but anyway) the two methods above describe a hook to connect event listeners (implemented as flow functions) to the events that the flow could generate. Now, the flow event model is yet to be defined, so those methods are useless for now. Given the state of the FOM, I would also be ready to comment them out (for now) and go on with more important things until we have time to define a basic event model for the flow (basically, what events are generated and when). 2) getComponent() returns an avalon component which is not a sitemap component. Basically, it has to ask to the cocoon component manager to return the component identified with the given role and check if it doesn't implement "SitemapModelComponent", in which case an exception should be thrown. What do you think? -- Stefano.
Re: FOM implementation
on 6/21/03 10:55 AM Christopher Oliver wrote: > OK. I didn't implement the following, so if you or anyone else would > like to, please go ahead: > > Cocoon.addEventListener() > Cocoon.removeEventListener(); > Cocoon.getComponent() > > Can someone explain the purpose and behavior of these operations? I finally had the time to look into the FOM today and I saw your comments. Please allow me to explain my intentions with the above methods: 1) addEventListener/removeEventListener the Servlet API introduces in version 2.3 an event model which is basically connected to remouval of session values. The servlet API version 2.4 (yet to be finalized) introduced a number of new events, even if, to be honest, many of them are utterly useless and were probably introduced for symmetry (something which I dislike, but anyway) the two methods above describe a hook to connect event listeners (implemented as flow functions) to the events that the flow could generate. Now, the flow event model is yet to be defined, so those methods are useless for now. Given the state of the FOM, I would also be ready to comment them out (for now) and go on with more important things until we have time to define a basic event model for the flow (basically, what events are generated and when). 2) getComponent() returns an avalon component which is not a sitemap component. Basically, it has to ask to the cocoon component manager to return the component identified with the given role and check if it doesn't implement "SitemapModelComponent", in which case an exception should be thrown. What do you think? -- Stefano.
Re: FOM implementation
OK. I didn't implement the following, so if you or anyone else would like to, please go ahead: Cocoon.addEventListener() Cocoon.removeEventListener(); Cocoon.getComponent() Can someone explain the purpose and behavior of these operations? Thanks, Chris Upayavira wrote: Chris, Fantastic! What a productive evening! It's good to know where this revised FOM is, should I find anything that's not right. I'll try to switch my flow apps over to it and get trying it out. Regards, Upayavira On 20 Jun 2003 at 1:42, Christopher Oliver wrote: I had some time this evening so I created a prototype implementation of current FOM design (as documented by Reinhard on the Cocoon Wiki) and checked it into the scratchpad. To try it out add another flow interpreter to cocoon.xconf, like this: ... resource://org/apache/cocoon/components/flow/javascri pt/fom/fom_system.js true 4000 And then select it in your sitemap like this: Feel free to hack away, Chris
Re: FOM implementation
Chris, Fantastic! What a productive evening! It's good to know where this revised FOM is, should I find anything that's not right. I'll try to switch my flow apps over to it and get trying it out. Regards, Upayavira On 20 Jun 2003 at 1:42, Christopher Oliver wrote: > I had some time this evening so I created a prototype implementation > of current FOM design (as documented by Reinhard on the Cocoon Wiki) > and checked it into the scratchpad. To try it out add another flow > interpreter to cocoon.xconf, like this: > ... > class="org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScript > Interpreter" name="FOM_JavaScript"> > > resource://org/apache/cocoon/components/flow/javascri > pt/fom/fom_system.js > true > 4000 > > > > And then select it in your sitemap like this: > > > > > > Feel free to hack away, > > Chris > > >
FOM implementation
I had some time this evening so I created a prototype implementation of current FOM design (as documented by Reinhard on the Cocoon Wiki) and checked it into the scratchpad. To try it out add another flow interpreter to cocoon.xconf, like this: ... resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js true 4000 And then select it in your sitemap like this: Feel free to hack away, Chris
