myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <>
Subject Re: MyFaces 2.0 J4Fry first comments
Date Thu, 02 Apr 2009 09:32:19 GMT
Ok additional comments,
once the listener interface is again integrated
we probably can move most of the visual code out of the core
into listeners reusable by the user.

input field disabling enabling
progress display etc...

The result would be that the core is reduced down to the xhr handling
and event handling,

the visual aspects then would be listeners usable within the
jsf2 api!


Werner Punz schrieb:
> Ok I have checked the j4fry code.
> So far it looks pretty good to me, well documented and clean and has 
> worked around a few pitfalls, however some things have to be changed.
> I personally would recommend to move the connection between jsf2.js and
> the j4fry code into an adapter class, like I did with my code.
> The reason is, the adapter class is needed to isolate jsf2 specifics 
> from the underlying implementation details. Stuff like progress displays 
> or invalidation of controls and custom options,
> should be handled within the adapters as long as they are not specified
> explicitely.
> The adapter also can isolate jsf2 from the underlying transport and ppr 
> mechanisms to a certain degree and allows other frameworks to exchange 
> the transports if the need arises!
> (which again would give us an advantage over the RI which has everything 
> hardcoded into one big class)
> So the calling hierarchy is jsf2 api <-> framework adapter with a clear 
> well defined interface <-> implementation
> This also allows us to exchange the underlying frameworks with a simple 
> switch (like I did for Trinidad and my own implementation)
> The implementation can call back into jsf2 (it should not if possible
> the adapter should) but jsf2 should not call directly into the 
> implementation it should call the adapter!
> Also not found in the public specs but in the latest ri is a listener
> mechanism which notifies the listeners in various stages of the 
> lifecycle, I assume since the RI has them as public APIs that those are 
> in later non public specs. I implemented those for exactly this reason, 
> you basically can copy paste it from me.
> Also for the J4Fry specific additonal options, can anyone check in the 
> latest specs if frameworks are allowed to offer additional functionality 
> via custom options?
> Those should be moved into one single submap under the myfaces namespace 
> to avoid namespace collissions with public options set by the user!
> Those can be processed and mapped on adapter level, I guess!
> So far my first comments on the j4fry code :-)
> And last but not least: Namespaces they should be moved over to the 
> myfaces umbrella, and the comments have to be translated to english.
> And please donĀ“t get me wrong, the code quality is excellent! I really 
> like what I have seen so far...

View raw message