myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Bischoff <>
Subject Re: [announcement] new sandbox component: submitOnEvent
Date Mon, 16 Oct 2006 14:01:41 GMT

>> I notice you didn't need to forceID the submit buttons on the example.
>> Do we run into any ID trouble with subviews, forms, subforms, etc?
> Shouldn't be a problem. I use the JSF computed client-id, and if there
> isn't a bug in this computation (there were in the past ;-) ) it should
> work.

Okay, so if they are in the same context then it works without a 
forceid. But, devil's advocate, what happens if say the button is in a 
subform or subview, and the submitOnEvent tag is not. Is there any 
support for this? The button would then have a different client id 
prefix. Tomahawk buttons have a similar "actionFor" attribute, and in 
that case the syntax is like ":MyMainForm:MySubView:MySubForm". Are 
arguments in a form similar to this valid in the submitOnEvent component?

>> <h:outputLabel for="text2" value="submit via link on enter"/>
>> <h:inputText id="text2" value="#{submitOnEvent.strings.text2}"
>> onkeypress="javascript:notifyOriginalEvent()">
>>      <s:submitOnEvent for="submitLink" />
>> </h:inputText>
>> How does it know that onEnter() is the event to submit on?
> Well, my first idea was to create a "submitOnEnter" component, then, we
> decided to allow a broader use-case and allow to configure the event,
> following the "convention-before-configuration" paradigm all default
> values of the submitOnEvent are so that it will trigger "onkeypress" and
> the "enter" key.
> Yea, I admit it is somehow confusing, but once you know this it is a
> real time saver ;-)

The convention is not so confusing, now that it is documented. It was 
simply hard trying to deduce it from the examples alone. Thanks for 
getting that page up so fast.


Jeff Bischoff
Kenneth L Kurz & Associates, Inc.

View raw message