thanks werner!


On Wed, Apr 8, 2009 at 2:53 PM, Simon Lessard <[email protected]> wrote:
> Wonderful news!
>
> On Wed, Apr 8, 2009 at 4:14 AM, Werner Punz <[email protected]> wrote:
>>
>> 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
>>>>
>>>
>>>
>>>
>>
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Reply via email to