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