Accepting input from parent & child components
Locked
 
|
Hello
I have a WAComponent that displays some input fields, and it renders a child component that displays additional, related input fields. For example, if I'm having the user edit an invoice, there are general items on the invoice (like special terms of payment, etc) and then there are invoice line items, which are rendered and input via a subcomponent. The parent input fields and subcomponent input fields are within the same html `form`. However, when I click the submit button (done at the parent level), only the input items rendered by the parent are recognized. Any inputs provided by the user through the embedded, rendered subcomponent are ignored. I bought and have been reading Dynamic Web Development With Seaside, but it does not address this case. Is it possible to do what I'm attempting to do? Thank you Mark _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> The parent input fields and subcomponent input fields are within the same
> html `form`. However, when I click the submit button (done at the parent > level), only the input items rendered by the parent are recognized. Any > inputs provided by the user through the embedded, rendered subcomponent are > ignored. I would carefully look at the HTML that you produce here. And then make sure I don't have nested forms. Remember that if you use Chrome (and I suspect Firefox and others too), the HTML you see with the "inspect element" menu does not give you the real HTML. Chrome removes nested forms. Make sure you look at the raw HTML. If you say "recognized" I assume you're talking about inputs posted with the submit, which translates into callbacks processed by Seaside. If so, your inputs are not in the same form tag or you have nested form tags. > Is it possible to do what I'm attempting to do? Yes, we're doing this a lot, so we can find out what's going on here. Cheers Otto _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thank you for the prompt reply, Otto.
I did a "view source" and only found one `<form ...>` very early in the file, and one `</form>` near the very end. So I believe there is only one form tag in the HTML. Also, I didn't not before, than I'm using the WAFormDecoration in the parent, if that matters. By "recognize", I mean that I'm not seeing evidence that the callbacks for changed fields in the child are being triggered. I'm not sure how to determine the version of Seaside I have. I am using GNU Smalltalk 3.2.91-b98173d, so it's whatever Seaside package revision they've included with that. Regards Mark On 9/8/2015 6:25 AM, Otto Behrens wrote: >> The parent input fields and subcomponent input fields are within the same >> html `form`. However, when I click the submit button (done at the parent >> level), only the input items rendered by the parent are recognized. Any >> inputs provided by the user through the embedded, rendered subcomponent are >> ignored. > I would carefully look at the HTML that you produce here. And then > make sure I don't have nested forms. Remember that if you use Chrome > (and I suspect Firefox and others too), the HTML you see with the > "inspect element" menu does not give you the real HTML. Chrome removes > nested forms. Make sure you look at the raw HTML. > > If you say "recognized" I assume you're talking about inputs posted > with the submit, which translates into callbacks processed by Seaside. > If so, your inputs are not in the same form tag or you have nested > form tags. > >> Is it possible to do what I'm attempting to do? > Yes, we're doing this a lot, so we can find out what's going on here. > > Cheers > Otto > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> By "recognize", I mean that I'm not seeing evidence that the callbacks for
> changed fields in the child are being triggered. So if you set breakpoints in the callbacks, you are sure that they are not triggered? So I am hearing that you are using plain old subclasses of WAComponent? And you override #children in your subclass? And then #renderContentOn:? What do you call to render your sub components? A better idea of your code structure or snippets of it may help. > I'm not sure how to determine the version of Seaside I have. I am using GNU > Smalltalk 3.2.91-b98173d, so it's whatever Seaside package revision they've > included with that. I have no idea how to check that with GNU; we're using Monticello/Metacello to load into Pharo and GemStone. And even in our environment it is difficult to figure out. > > Regards > Mark > > > On 9/8/2015 6:25 AM, Otto Behrens wrote: >>> >>> The parent input fields and subcomponent input fields are within the same >>> html `form`. However, when I click the submit button (done at the parent >>> level), only the input items rendered by the parent are recognized. Any >>> inputs provided by the user through the embedded, rendered subcomponent >>> are >>> ignored. >> >> I would carefully look at the HTML that you produce here. And then >> make sure I don't have nested forms. Remember that if you use Chrome >> (and I suspect Firefox and others too), the HTML you see with the >> "inspect element" menu does not give you the real HTML. Chrome removes >> nested forms. Make sure you look at the raw HTML. >> >> If you say "recognized" I assume you're talking about inputs posted >> with the submit, which translates into callbacks processed by Seaside. >> If so, your inputs are not in the same form tag or you have nested >> form tags. >> >>> Is it possible to do what I'm attempting to do? >> >> Yes, we're doing this a lot, so we can find out what's going on here. >> >> Cheers >> Otto >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I do have "plain" subclasses of WAComponent to an overall "MyAppComponent", then all my app's components are subclassed from MyAppComponent. and I do have `children` defined in my subclass and `renderContentOn`. MyAppComponent provides a common set of small rendering helpers for formatting, and loads common CSS files in `updateRoot` which the subcomponents can capture via `super updateRoot: html`.
Conceptually: MyAppComponent subclass: ParentComponent [ new [ child := ChildComponent new ] children [ ^Array with: child ] initialize [ super initialize. self addDecoration: (WAFormDecoration new buttons: self buttons). ] renderContentOn: html [ "render parent items here..." html render: child ] ... I can provide more specifics if needed.
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
What you have here looks fine to me.
So the next thing I can think of do is to use the debugger to figure out what is going on. I would set a breakpoint in WACallbackRegistry >> handle:. This method maps the names that are posted to the callbacks that are evaluated. So, this will tell you firstly what fields are posted and then if they map to the callback registry. If the field is not there, then you know it is not coming through from the browser. If the callback is not mapped, then we can try to figure that out from where the callback is created. This is getting deep into Seaside though... > I do have "plain" subclasses of WAComponent to an overall "MyAppComponent", > then all my app's components are subclassed from MyAppComponent. and I do > have `children` defined in my subclass and `renderContentOn`. MyAppComponent > provides a common set of small rendering helpers for formatting, and loads > common CSS files in `updateRoot` which the subcomponents can capture via > `super updateRoot: html`. > > > Conceptually: > > > MyAppComponent subclass: ParentComponent [ > new [ > child := ChildComponent new > ] > > children [ ^Array with: child ] > > initialize [ > super initialize. > self addDecoration: (WAFormDecoration new buttons: self buttons). > ] > > renderContentOn: html [ > "render parent items here..." > > html render: child > ] > > ... > > I can provide more specifics if needed. > >> >> >> > I'm not sure how to determine the version of Seaside I have. I am using >> > GNU >> > Smalltalk 3.2.91-b98173d, so it's whatever Seaside package revision >> > they've >> > included with that. >> >> I have no idea how to check that with GNU; we're using >> Monticello/Metacello to load into Pharo and GemStone. And even in our >> environment it is difficult to figure out. >> >> > >> > Regards >> > Mark >> > >> > >> > On 9/8/2015 6:25 AM, Otto Behrens wrote: >> >>> >> >>> The parent input fields and subcomponent input fields are within the >> >>> same >> >>> html `form`. However, when I click the submit button (done at the >> >>> parent >> >>> level), only the input items rendered by the parent are recognized. >> >>> Any >> >>> inputs provided by the user through the embedded, rendered >> >>> subcomponent >> >>> are >> >>> ignored. >> >> >> >> I would carefully look at the HTML that you produce here. And then >> >> make sure I don't have nested forms. Remember that if you use Chrome >> >> (and I suspect Firefox and others too), the HTML you see with the >> >> "inspect element" menu does not give you the real HTML. Chrome removes >> >> nested forms. Make sure you look at the raw HTML. >> >> >> >> If you say "recognized" I assume you're talking about inputs posted >> >> with the submit, which translates into callbacks processed by Seaside. >> >> If so, your inputs are not in the same form tag or you have nested >> >> form tags. >> >> >> >>> Is it possible to do what I'm attempting to do? >> >> >> >> Yes, we're doing this a lot, so we can find out what's going on here. >> >> >> >> Cheers >> >> Otto >> >> _______________________________________________ >> >> seaside mailing list >> >> [hidden email] >> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > >> > >> > _______________________________________________ >> > seaside mailing list >> > [hidden email] >> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
It looks like the latest ported Seaside for GNU Smalltalk is a little behind the latest official version. The WACallbackRegistry >> handle: selector doesn't exist (I'm looking at a Seaside-Core.st file). But you've pointed me in the right direction, so I can start digging into the Seaside code that I do have and figure out where it breaks down. On Tue, Sep 8, 2015 at 1:09 PM, Otto Behrens <[hidden email]> wrote: What you have here looks fine to me. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by otto
Otto - thanks for the clues.
I believe I've narrowed it down now to an issue in my own code somewhere. Your hints were quite handy to lead me there. Regards Mark On 9/8/2015 1:09 PM, Otto Behrens wrote: > What you have here looks fine to me. > > So the next thing I can think of do is to use the debugger to figure > out what is going on. > > I would set a breakpoint in WACallbackRegistry >> handle:. This method > maps the names that are posted to the callbacks that are evaluated. > So, this will tell you firstly what fields are posted and then if they > map to the callback registry. If the field is not there, then you know > it is not coming through from the browser. If the callback is not > mapped, then we can try to figure that out from where the callback is > created. This is getting deep into Seaside though... > >> I do have "plain" subclasses of WAComponent to an overall "MyAppComponent", >> then all my app's components are subclassed from MyAppComponent. and I do >> have `children` defined in my subclass and `renderContentOn`. MyAppComponent >> provides a common set of small rendering helpers for formatting, and loads >> common CSS files in `updateRoot` which the subcomponents can capture via >> `super updateRoot: html`. >> >> >> Conceptually: >> >> >> MyAppComponent subclass: ParentComponent [ >> new [ >> child := ChildComponent new >> ] >> >> children [ ^Array with: child ] >> >> initialize [ >> super initialize. >> self addDecoration: (WAFormDecoration new buttons: self buttons). >> ] >> >> renderContentOn: html [ >> "render parent items here..." >> >> html render: child >> ] >> >> ... >> >> I can provide more specifics if needed. >> >>> >>>> I'm not sure how to determine the version of Seaside I have. I am using >>>> GNU >>>> Smalltalk 3.2.91-b98173d, so it's whatever Seaside package revision >>>> they've >>>> included with that. >>> I have no idea how to check that with GNU; we're using >>> Monticello/Metacello to load into Pharo and GemStone. And even in our >>> environment it is difficult to figure out. >>> >>>> Regards >>>> Mark >>>> >>>> >>>> On 9/8/2015 6:25 AM, Otto Behrens wrote: >>>>>> The parent input fields and subcomponent input fields are within the >>>>>> same >>>>>> html `form`. However, when I click the submit button (done at the >>>>>> parent >>>>>> level), only the input items rendered by the parent are recognized. >>>>>> Any >>>>>> inputs provided by the user through the embedded, rendered >>>>>> subcomponent >>>>>> are >>>>>> ignored. >>>>> I would carefully look at the HTML that you produce here. And then >>>>> make sure I don't have nested forms. Remember that if you use Chrome >>>>> (and I suspect Firefox and others too), the HTML you see with the >>>>> "inspect element" menu does not give you the real HTML. Chrome removes >>>>> nested forms. Make sure you look at the raw HTML. >>>>> >>>>> If you say "recognized" I assume you're talking about inputs posted >>>>> with the submit, which translates into callbacks processed by Seaside. >>>>> If so, your inputs are not in the same form tag or you have nested >>>>> form tags. >>>>> >>>>>> Is it possible to do what I'm attempting to do? >>>>> Yes, we're doing this a lot, so we can find out what's going on here. >>>>> >>>>> Cheers >>>>> Otto >>>>> _______________________________________________ >>>>> seaside mailing list >>>>> [hidden email] >>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> >>>> _______________________________________________ >>>> seaside mailing list >>>> [hidden email] >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by mbratch
Mark,
in addition to all the good advice Otto has given you already, I'd like to point you to a few additional ideas/thoughts that might help. First of all, the web browser has no idea about the structure of your Seaside Components, it only receives a Tree of DOM elements it acts upon. This may be obvious, but it is important to remember every time you need to find out what's wrong in cases like yours. Since you are on GNU, I guess debugging is a bit harder than on most other Smalltalk environments. But even if I am wrong, you should take a deep look at the debugging/developer tools of your Web browser. You can take a deeper look at your DOM, but you can also get traces of the HTTP requests/responses that travel back and forth between your Seaside Server and the Browser. So if you expect the input of an input element to be sent to the server, it is always a good idea to have a look at the POST request that gets sent by the browser. Say you entered "Hello" into a textinput element, see if it's being sent to the server before you do anything else. Just open the dev tools and inspect the POST request. You shoudl finde something like "&56=Hello" in your POST request. If not, the problem is very likely in your rendering code: your input field is not inside of the form tag, most likely. Then you should take a closer look at the DOM and your rendering code once you see what's wrong. An interesting mosaic piece may be that the "56" in the POST request is the content of the "name" attribute of the html tag (something linke <input type="text" name="56">) that was generated by Seaside. 56 in this example is also the key for the Callback Block in the Callbacks Dictionary on the server side. If the POST request contains your field and its contents but the setter method on the server side is not called (Breakpoint or self halt), then your wiring of the input field is wrong in your renderContentOn: Maybe a typo in the callback block, or, if you used #on:of:, in the attribute name. Note that Seaside simply ignores keys that it cannot find in the CallbackRegistry. Hope these thoughts help you understand a little more about your situation. Finally I'd like to ask you to let us know what your problem was and how you fixed it. We need more of these "what went wrong and how could it be solved" descriptions. One example: If you forget a "super initialize" in a WAComponent subclass, you end up with a very strange error message that doesn't really help (don't remember exactly, sorry! I think I blogged about it a few years ago...) during rendering. The solution is just to add the super call, but finding it takes a lot of time. HTH Joachim Am 08.09.15 um 01:39 schrieb Mark Bratcher: > Hello > > I have a WAComponent that displays some input fields, and it renders a > child component that displays additional, related input fields. For > example, if I'm having the user edit an invoice, there are general > items on the invoice (like special terms of payment, etc) and then > there are invoice line items, which are rendered and input via a > subcomponent. > > The parent input fields and subcomponent input fields are within the > same html `form`. However, when I click the submit button (done at the > parent level), only the input items rendered by the parent are > recognized. Any inputs provided by the user through the embedded, > rendered subcomponent are ignored. > > I bought and have been reading Dynamic Web Development With Seaside, > but it does not address this case. > > Is it possible to do what I'm attempting to do? > > Thank you > Mark > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:[hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Joachim Thanks for the tips. I'm using GNU and am very familiar with a variety of debugging techniques, and with the inspection abilities of the web browsers. Way back in time, I've done a lot of embedded system work and debugging before there was ever any kind of visual tools. :) Also I'm aware that the web browser has no knowledge of Smalltalk or Seaside and is just responding to the generated HTML (or XHTML). I've done quite a bit of Ruby on Rails work. The problem ended up being something quite stupid that I should have checked before, and that is I wasn't "cascading" my data save to the component level after the user hit save and the inputs were validated. So I was saving the parent information, but not the child information. It just didn't occur to me until I saw what was happening "on the back side" coming from what Seaside was doing in response to my callbacks, etc. Once I saw that Seaside was registering the callbacks fine, and the callbacks were actually called, I put it together in my mind. Again, it was a circuitous route to get to what ended up being a silly oversight. In the process, though, I've learned a lot about the internals of Seaside. :) Thanks again for your attention and assistance. I really appreciate the responsiveness of the Seaside community. Mark On Wed, Sep 9, 2015 at 7:11 AM, [hidden email] <[hidden email]> wrote: Mark, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |