myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wessendorf <>
Subject Re: [JSF 2.0] Final draft available, branch synchronized
Date Tue, 07 Apr 2009 13:17:26 GMT
yes, correct.

I think I should pay more attention to the (so called) open mailing list
(which is seriously only semi-open)


On Tue, Apr 7, 2009 at 10:37 AM, Werner Punz <> 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
>> ( 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:
>> Means the logic should be coded inline where the comment is. Can be found
>> in both API and 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.
>> 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.
>> 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.
>> 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.
>> Means that I must raise something I consider invalid as an issue to the
>> EG. Found in both API and IMPL.
>> 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.
>> 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

Matthias Wessendorf


View raw message