Btw. just a short status update on the ajax side of things,
We are working actively on it as I speak but I cannot commit anything
from Ganesh and Alexs code since I still wait for the confirmation of
the ICLA regarding Ganesh Jung (Alex is already confirmed)
So what are we doing:
a) I prepared a clear api and impl divide, which is bound by
configuration, the api basically just calls the impl class
wich is integrated via myfaces configuration options (and hence
overridable from the outside)
b) we have three layers currently api, impl and adapters for the request
and response handling
all of them are pluggable so that they can be replaced by other
implementations via configuration (dojo or something else)
As soon as I get the missing ICLA acknowledgement and I have some time
(which is thursday and friday) I will be able to commit all of this into
the apache repo...
So expect a bigger commit on the javascript side soon!
Werner
Matthias Wessendorf schrieb:
yes, correct.
I think I should pay more attention to the (so called) open mailing list
(which is seriously only semi-open)
-Matthias
On Tue, Apr 7, 2009 at 10:37 AM, Werner Punz <[email protected]> wrote:
Wonderful news...
I will rework the javascript ajax apis this week on thursday.
Generally there is not too much work on the api side to do
a helper function has been added.
Werner
Simon Lessard schrieb:
Hi all,
This is a simple post to inform you that the final JSF 2.0 draft was
released yesterday
(http://jcp.org/aboutJava/communityprocess/pfd/jsr314/index.html) and that
the 2.0 branch is in sync with it (at least to my knowledge). Not everything
is integrated of course, but all API classes and methods should be there
(except enums for component attributes, I hope we can "pluginize" those). If
you check the code you can find different kinds of TODO:
// TODO: IMPLEMENT HERE
Means the logic should be coded inline where the comment is. Can be found
in both API and IMPL.
// TODO: IMPLEMENT IMPL
Means the logic should be implemented in myfaces-impl while the api side
most likely throws an UnsupportedOperationException. Can be found in API
only.
// TODO: PLUGINIZE
Means the class might be generable by maven plugin, but adding the
metadta/code for it to work as yet to be done. This is mainly for the new
enums for component attributes, the TODO is in the UIComponent class.
// TODO: VALIDATE
Means the code should be reviewed against the spec or the use case should
be thought about to determine if the algorithm used is correct. Can be found
in both API and IMPL.
// TODO: DEFINE
Means the spec is silent on the algorithm or the constant values. Found in
API, currently only in ExceptionQueuedEventContext I think. I'll go to the
EG with it.
// TODO: REPORT
Means that I must raise something I consider invalid as an issue to the
EG. Found in both API and IMPL.
// TODO: REFACTOR
Means the code should be moved to a more logical spot. Found in Facelets
mainly where I had to move some code around so that it would compile with
the new API.
// TODO: PROFILE
Means I think an alternative algorithm could be faster, but think more
thourough thinking should be put to it. Mostly found in Facelets and its
extensive use of Arrays.binarySearch instead of faster but more memory
consuming HashMap.
Help on any part is welcome, but what's left of error handling (validating
where exceptions should be shallowed or rethrown and some missing
ErrorHandler code) and component tree visitiing was reserved for Google SoC
I think so let not deal with those for now.
Thanks,
~ Simon
