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
