dev@jsf-extensions.java.net

RE: [JSF-EXT] New support for FacesEvent added

From: Ed Burns <ed.burns_at_sun.com>
Date: Wed, 9 Aug 2006 12:01:14 -0700

>>>>> 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