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.
Regards,
Jeff Bischoff
Kenneth L Kurz & Associates, Inc.
