Out of curiosity, why is TrPage._autoSubmit named with an underscore,
shouldn't it be exposed as an API method? I would think people may
want to call it if they want to submit their own component using an
event other than the default one for the control.
On 9/5/07, Danny Robinson <[EMAIL PROTECTED]> wrote:
> OK, so this seems to work for me. No scriptlet required, and less
> parameters.
>
> <input id="_id22" class="af_inputText_content" type="text" size ="5"
> onchange="TrPage._autoSubmit('_id22',event,1);return true;
> " name="_id22"/>
>
> TrPage._autoSubmit = function(inputId, event, validate)
> {
> if (_agent.isIE)
> {
> // in many forms there is a hidden field named "event"
> // Sometimes IE gets confused and sends us that instead of
> // the true event, so...
> if (event["type"] == "hidden")
> event = window.event;
> }
>
> var target = event.target || event.srcElement;
> if (!target)
> return;
>
> var form = _getForm(target);
> if (!form)
> return;
>
> // Assume input is valid
> var isValid = true;
>
> // Validate the current input
> if (validate)
> isValid = _validateInput(event);
>
> if (isValid)
> {
> var params = new Object();
> params.event = "autosub";
> params.source = inputId;
>
> _submitPartialChange(form.id, validate, params);
>
> }
> }
>
>
> On 9/4/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > On 9/4/07, Danny Robinson <[EMAIL PROTECTED]> wrote:
> > >
> > > > I think that autoSubmit code should automatically call _validateInput
> > > > on its own - that is, we probably need a new JS method that will:
> > > > - run _validateInput() on the target field
> > > > - run the equivalent of the existing adfspu code
> > > >
> > > > Maybe TrPage._autoSubmit()?
> > >
> > > ... and refactor the AutoSubmitUtils class to call this method instead?
> >
> > Yep.
> >
> > > > BTW, I think we should start making a habit of putting variables
> > > > like _TrEventBasedValidation on the TrPage object - even
> > > > without a JS API, just using the JS object itself as a way to
> > > > stash variables without polluting the top-level namespace.
> > > > And I know this is a clear case of throwing stones and living in
> > > > glass houses, as it were. :)
> > >
> > > Agreed, it wasn't permanent, just there to allow enable/disable of the
> > > feature while it evolves. Will move anything similar to TrPage in
> future.
> >
> > Cool, makes total sense.
> >
> > -- Adam
> >
> >
> > > > -- Adam
> > > >
> > > > On 9/4/07, Danny Robinson < [EMAIL PROTECTED]> wrote:
> > > > > pinging for responses.
> > > > >
> > > > >
> > > > > On 8/29/07, Danny Robinson < [EMAIL PROTECTED] > wrote:
> > > > > > Folks,
> > > > > >
> > > > > > Need some pointers here. I've mainly got the event based c/s
> > > validation
> > > > > working fine. However, this morning we uncovered an issue that
> needs
> > > some
> > > > > of your feedback. Basically, we're registering the
> > > _validateInput(event)
> > > > > method against onchange programmatically from within the
> > > _addValidators()
> > > > > method (which I think is the direction we want to take for event
> > > > > registration). Note - you can try this out by inserting
> > > > > _TrEventBasedValidation=true; into a script at the top of your page.
> > > > > >
> > > > > > This works just great, until you use autoSubmit="true", which
> causes
> > > the
> > > > > SimpleInputTextRenderer (and others) to render the autoSubmit script
> via
> > > > > onchange="_adfspu(...);return true;". This obviously fires the
> > > autoSubmit
> > > > > code prior to the _validateInput and hence causes the server-side
> > > validators
> > > > > to be used.
> > > > > >
> > > > > > So, does anyone have a suggested workaround to this? Should
> > > > > autoSubmit="true" render the _adfspu() call differently, if so how
> could
> > > we
> > > > > ensure validators registered prior to autoSubmit event handlers?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Danny
> > > > > >
> > > > > > --
> > > > > > Chordiant Software Inc.
> > > > > > www.chordiant.com
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Chordiant Software Inc.
> > > > > www.chordiant.com
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Chordiant Software Inc.
> > > www.chordiant.com
> >
>
>
>
> --
>
> Chordiant Software Inc.
> www.chordiant.com
