Hello,
I was trying to understand the need for an 'autosub' event on the client
and the reason for an AutoSubmitEvent on the server and could only
conclude that this may be redundant. Here's what I observe
1. Whenever TrPage._autoSubmit is called, which is when an editable
value holder is 'a
Hi Pavitra,
Pavitra Subramaniam wrote:
2. On the server side code in FormElementRenderer (and some of its
sub-classed renderers) we call detectAutoSubmit() method that
explicitly looks for the 'autoSub' event and queues an
AutoSubmitEvent. Since there are typically no listeners registered f
Why isn't the ValueChangeEvent sufficient for the partial triggers?
-- Blake Sullivan
Gabrielle Crawford said the following On 1/14/2010 9:02 AM PT:
Hi Pavitra,
Pavitra Subramaniam wrote:
2. On the server side code in FormElementRenderer (and some of its
sub-classed renderers) we call det
On 1/14/2010 9:02 AM, Gabrielle Crawford wrote:
Hi Pavitra,
Pavitra Subramaniam wrote:
2. On the server side code in FormElementRenderer (and some of its
sub-classed renderers) we call detectAutoSubmit() method that
explicitly looks for the 'autoSub' event and queues an
AutoSubmitEvent. Since
By default, any server event triggered by a component will ppr the
components for which it is a partial trigger, so as long as the
ShowDetailItem is already broadcasting a disclosure event, I don't know
why we would need an AutoSubmitEvent as well in order for PPR to work.
We might need these
Sorry, for some reason I thought you were talking about other fields on
the page triggering a valuechangeevent, so I was confused, but I agree
the valueChangeEvent on the autosubmitted component will work.
Thanks,
Gab
Pavitra Subramaniam wrote:
On 1/14/2010 9:02 AM, Gabrielle Crawford wrote:
On 1/14/2010 10:28 AM, Blake Sullivan wrote:
By default, any server event triggered by a component will ppr the
components for which it is a partial trigger, so as long as the
ShowDetailItem is already broadcasting a disclosure event, I don't know
why we would need an AutoSubmitEvent as well in o
On 1/14/2010 10:28 AM, Blake Sullivan wrote:
By default, any server event triggered by a component will ppr the
components for which it is a partial trigger, so as long as the
ShowDetailItem is already broadcasting a disclosure event, I don't know
why we would need an AutoSubmitEvent as well in o
Pavitra Subramaniam wrote:
I also noticed the following comment in the inner class,
FormElementRenderer$AutoSubmitEvent,
/**
* Dummy class purely to get subforms to recognize that
* an event has occurred
*/
static private final class AutoSubmitEvent extends FacesEvent
{
.
Pavitra and I talked about this some more last night. It looks like the
AutoSubmitEvent is delivered so that the subforms know which subform, if
any triggered the post so that the subforms know whether to process
their children. However, the way that this is done seems overly
complicated, wit
On 1/14/2010 12:41 PM, Gabrielle Crawford wrote:
However subforms decide whether they are the 'submitted' subform based
on queued events, take a look at UIXSubformTemplate. Almost all events
are queued in the apply request values phase, even if they aren't
delivered until a later phase. An excep
Hi Pavitra,
I'm fine with any change that don't regress subforms. Basically the test
cases should generally include the fields in 3 areas: subform A, subform
B, and fields not in any subform, so for example in test 'a' below, you
only mention one subform, I would test it like this:
a. valueC
12 matches
Mail list logo
