I still haven't gotten observe_field to work very reliably. Are
others having problems with it too? It would be one thing if I
couldn't get it to work at all: then I would simply have to track down
what I was doing wrong. Instead, it seems to be working, but working
very erratically. Is it Firebug's fault that I seem to see the
observation events fired very late sometimes and right away other
times? Again, my processor is doing very little else, and this is all
on localhost.
On Feb 24, 4:04 pm, Eric Ongerth <[EMAIL PROTECTED]> wrote:
> Update. Usually I buffer all my <%def>s because I'm almost always
> using them functionally in places where the output needs to be held
> until it's time to insert it. In this case, however, I tried
> unbuffering the trial() def and pow, the Ajax fires like it should.
>
> ..sort of. Actually, it's very erratic and I'm wondering why. In my
> real application, there's not just the two test fields, but six
> fields, only one of which is observed. I click the button, the form
> appears. Now if I enter text for each field starting with the first
> field, and progressing from one field to the next via the Tab key, the
> observer call fires as soon as I Tab out of the observed field. So
> far so good. But it does not fire if I leave the field via shift-
> Tab. It does not fire if I mouse-click straight into that observed
> fourth field and fill it and then Tab forward out of it. Basically it
> *only* fires if I fill in the form like a good little boy, starting
> with the first field and putting something in every field, never going
> back and never jumping around. How useful is that?
>
> So there must still be something I'm missing. I've got my _with
> property set properly, so when the call does get made, the POST header
> is coming through correctly. I've tried frequency=0, frequency=
> various positive numbers between 0 and 1. What is causing the
> inconsistent behavior?
>
> Also, sometimes the Ajax call takes a good two seconds or more to
> fire, and my system is not under any sort of load right now (this is
> all being done on the home workstation with very little network
> activity). Sometimes several of the calls seem to get backed up and
> then they all fire in rapid sequence after a delay of several
> seconds. This is not so great. The purpose of observing this field
> is, if the user enters certain values, two more fields need to be
> added to the form. If there's that much delay it's definitely not the
> smoothness for which I sought Ajax. Should I try changing this one
> operation to synchronous?
>
> More thanks.
> Eric
>
> On Feb 24, 3:48 pm, Eric Ongerth <[EMAIL PROTECTED]> wrote:
>
> > Two cases... one works, one does not, and the difference seems to be
> > that in Case 2 (non-working) the form is displayed in the view only
> > after the user clicks a button that triggers an
> > update_element_function to show the form. So there seems to be
> > something I'm not understanding -- maybe about filtering or escaping?
> > -- which is preventing the observer from working. Too bad no error
> > messages in the non-working case, just silence where I expect an Ajax
> > call. The following are in a Mako template with the standard pylons
> > helpers %included at the top.
>
> > <%def name="trial()" buffered="True">
> > ${h.form_remote_tag(
> > url=h.url_for(
> > controller="FVal",
> > action="add",
> > feature_id=999,
> > parentFVal_id=666),
> > complete=h.evaluate_remote_response(),
> > method="POST")}
> > test feature main:
> > ${h.text_field(name="main value")}
> > ${h.text_field(name="foo")}
> > % if True:
> > ${h.observe_field(
> > "foo",
> > with_="{foo:value}",
> > url=h.url_for(
> > controller="FVal",
> > action="alter_input_form"))}
> > % endif
> > ${h.submit("save", name="commit")}
> > ${h.end_form()}
> > </%def>
>
> > this version WORKS:
> > ${trial()}
>
> > but this one DOES NOT WORK: (no Ajax call ever happens)
> > <div id="whatever">
> > ${h.button_to_function(
> > "Test",
> > h.update_element_function(
> > "whatever",
> > action="update",
> > content=(trial())))}
> > </div>
>
> > I'm looking at the results via Firebug. As far as I can tell, both
> > versions generate the same HTML and same javascript. The only
> > difference I can see is that in the 2nd case, the form is not put on
> > the page until the user clicks the "Test" button.
>
> > Why should the update_element_function somehow result in breaking the
> > Ajax of the observe_field function? The form in each case is
> > identical:
>
> > <form onsubmit="new Ajax.Request('/FVal/add?
> > feature_id=999&parentFVal_id=666', {asynchronous:true,
> > evalScripts:true, method:'POST', onComplete:function(request)
> > {eval(request.responseText)}, parameters:Form.serialize(this)});
> > return false;" method="post" action="/FVal/add?
> > feature_id=999&parentFVal_id=666">
> > test feature main:
> > <input type="text" name="main value" id="main value"/>
> > <input type="text" name="foo" id="foo"/>
> > <script type="text/javascript">
> > //<![CDATA[
> > new Form.Element.EventObserver('foo', function(element, value) {new
> > Ajax.Request('/FVal/alter_input_form', {asynchronous:true,
> > evalScripts:true, parameters:{foo:value}})})
> > //]]>
> > </script>
> > <input type="submit" value="save" name="commit"/>
> > </form>
>
> > And specifically, the Form.Element.EventObserver generated in both
> > cases is identical.
>
> > So there's gotta be something I'm missing!
> > Any insight would be most welcome, thanks.
>
> > Eric
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
