This is good-- discussion, not 'wait until I have everything checked in and implemented' and then not responding to any succeeding questions.
R2
Is interesting, but in implementation, this isn't even something that's provided as normal within the JSF for actions/listeners/etc. What about just changing the event method signature on the component to:
onXXXX(FacesContext ctx, Object... args)
In any case, I don't think it requires creation of FacesEvent mediators given the points in (R3).
R3
So you'd like to implement a queue of events on the client to be delivered up to the server-- but an event is only valid at the specific instance of creation, hence also capturing the state of the rest of the page along with the event. Maybe you are doing that already?
Events such as ValueChangeEvent and ActionEvent are already implemented within the components that own them and are pertinent to the component mediator, not against the business model itself. So I'm not sure exposing the existing event types in different ways is necessary.
In your implementation of R3, couldn't you do this with one generic event given R2? I guess I'm trying to avoid all of the extra development/configuration by utilizing conventions on method signatures vs. extra adaptors (it works everywhere else in JSF/SAF/RoR).
>>>>>> On Wed, 09 Aug 2006 14:25:26 -0400, jacob_at_hookom.net said:
>
>JH> I've never worked on a project where developers make drastic API
>JH> changes without first chatting with other committers, and then
>JH> turning around and saying it's only partially done-- after
>JH> committing it?
>
>My approach is to check in early and often. I did the initial work on a
>branch, then merged with the trunk. I was transparent with my checkins.
>Of course, everything is open to change right now. In other words,
>everything in DynaFaces is only partially done.
>
>Jacob, you seem to have become busy in your day job, and thus I moved
>forward with an implementation to be a springboard for discussion. This
>seems to have worked :)
>
>JH> We could've told you up front that manually
>JH> requiring event declaration is not practical:
>
>Please see my requirements below and please suggest an alternative.
>
>JH> <context-param>
>JH> <param-name>com.sun.faces.extensions.avatar.FacesEvents</param-name>
>JH> <param-value>
>JH> SuggestEvent:com.enverio.jsf.SuggestEvent:com.enverio.jsf.UISuggest
>JH> </param-value>
>JH> </context-param>
>
>JH> And creating a dependency between the component developer's naming
>JH> scheme and the component user's web.xml
>
>JH> Enverio.SuggestEvent = function(clientId, phaseId) {
>JH> this.base = DynaFaces.FacesEvent;
>JH> this.base("SuggestEvent", clientId, phaseId);
>JH> }
>
>Ok, let's talk requirements.
>
>I see three requirements here. From browser JavaScript...
>
>R1. have the ability to invoke a named method on an arbitrary component,
> nestable within iteration. This method takes FacesContext, or
> FacesContext and UIComponent as arguments.
>
>R2. have the ability to invoke a MethodExpression that refers to an
> arbitrary method on an arbitrary component, nestable within
> iteration. The arguments to this method can come directly from
> JavaScript and can be converted using the existing Faces converter
> system.
>
>R3. have the ability to queue an arbitrary FacesEvent subclass, including
> ValueChangeEvent and ActionEvent, as well as user defined FacesEvent
> subclasses, passing arguments for the event constructor from JavaScript.
>
>You, Jacob, already implemented R1 for JavaOne. I added a small
>refinement detailed in an earlier email.
>
>R2 is unimplemented, and really just an idea I had.
>
>R3 is implemented but I am open to other designs that meet the
>requriement. In order to meet R3, we need some way to instantiate and
>initialize the FacesEvent subclass given only some information from
>JavaScript. Rather than having *all* of the information sent with every
>Ajax transaction, I decided to allow the JS to only send an eventId, and
>the ctor parameters (in addition to the PhaseId and the event source).
>The server is given a priori knowledge of how to take an eventId and
>turn it into a Constructor instance that can be called and passed the
>ctor arguments from JavaScript.
>
>Now, please don't threaten to leave the project, or fork the code or
>otherwise abort collaboration without first sharing what you think is a
>better way to meet these requirements.
>
>Ed
>
>--
>| ed.burns_at_sun.com | {home: 407 869 9587, office: 408 884 9519 OR x31640}
>| homepage: | http://purl.oclc.org/NET/edburns/
>| aim: edburns0sunw | iim: ed.burns_at_sun.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
>For additional commands, e-mail: dev-help_at_jsf-extensions.dev.java.net
>