[jsr-314-open] Fwd: So what's left for 2.0?

[Andy Schwartz]

Pete Muir wrote On 3/11/2009 11:48 AM ET:
>
> Begin forwarded message:
>
>> *From: *Dan Allen <dan.j.allen at gmail.com <mailto:dan.j.allen at gmail.com>>
>> *Date: *11 March 2009 15:19:09 GMT
>> *To: *Pete Muir <pmuir at bleepbleep.org.uk
>> <mailto:pmuir at bleepbleep.org.uk>>
>> *Subject: **Re: So what's left for 2.0?*
>>
>> On Wed, Mar 11, 2009 at 10:20 AM, Andy Schwartz
>> <andy.schwartz at oracle.com <mailto:andy.schwartz at oracle.com>> wrote:
>>
>>     For consistency I think we want to move f:validateBean over to a
>>     wrapping strategy that is closer to f:ajax, but want to hear
>>     Dan's take on this.  (Dan - I can help walk you through the
>>     f:ajax implementation if you have questions about this.)
>>
>>
>> I'm fine with this. It will take out some ambiguity and it aligns
>> with <s:validateAll> which we have used in Seam. We should still
>> support the validator nested within EditableValueHolder of course as
>> an override, which is consistent with <f:ajax> too.

Yep, sounds good.

>> I think the next step is to define in text the override strategy. I
>> can do this if you want me to move forward with it.

Sure, that would be great.

>> (The disable attribute on validator should be renamed to disabled or
>> vice-versa for <f:ajax>; I like the verb better)

For <f:ajax>, we went with "disabled" to be consistent with the
"disabled" attribute that shows up on components like h:commandButton,
which I suppose is just being consistent with (passing these through to)
HTML.

>>
>> If we go with the nesting strategy, I want to move forward with my
>> idea of making the branch validator a prototype that is cloned on to
>> each child EditableValueHolder. That way we can support validators
>> that are StateHolders (i.e., have properties like regex).

This sounds reasonable.  At the moment AjaxBehavior is immutable - so I
think we end up applying a single AjaxBehavior instance to all wrapped
components.  However, as part of this item:

> - The AjaxBehavior API still needs some cleanup in order to make it
> usable for programmatic cases (eg. need to add typesafe accessors)

I think we need to make AjaxBehavior mutable (ie. we need to provide
type-safe accessors), in which case, we need to change our strategy of
sharing a single instance across components.

Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090311/e1b23076/attachment.html