myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Bischoff <jbisch...@klkurz.com>
Subject Re: [announcement] new sandbox component: submitOnEvent
Date Thu, 19 Oct 2006 14:58:34 GMT
Hey all,

I believe I have answered my own question. I have reviewed the source 
code for the submitOnEvent component, and I can see that Mario is using 
the UIComponent.findComponent() method to locate the component 
referenced by the "for" attribute. That find method uses an algorithm 
described here [1].

Based on my reading of this description, I believe the short answer to 
my question is "Yes!!". If you use a simple "for" attribute like 
"submitButton", it will look in that same naming container. If, however, 
you prefix it like ":MyMainForm:MySubView:MySubForm:submitButton", you 
can specify precisely in which naming container to search for 
"submitButton", in this case "MyMainForm:MySubView:MySubForm".

Mario:

I like how you are doing the search at render-time. Since my solutions 
to this use-case were all simple client-side javascript functions, I 
never thought of that option. It's not that much harder to do in 
javascript, but this is better I think.

If I first test to ensure the more complicated use-case works as 
expected, do you mind if I update that wiki page with this additional 
detail about the options for use of the "for" attribute?

[1] 
http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/javax/faces/component/UIComponent.html#findComponent(java.lang.String)

Regards,

Jeff Bischoff
Kenneth L Kurz & Associates, Inc.

Jeff Bischoff wrote:
> 
>>> 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.
> 
> 
> 
> 
> 



Mime
View raw message