<div dir="ltr">Joachim<div><br></div><div>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.</div><div><br></div><div>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. :)</div><div><br></div><div>Thanks again for your attention and assistance. I really appreciate the responsiveness of the Seaside community.</div><div><br></div><div>Mark</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 7:11 AM, <a href="mailto:jtuchel@objektfabrik.de">jtuchel@objektfabrik.de</a> <span dir="ltr"><<a href="mailto:jtuchel@objektfabrik.de" target="_blank">jtuchel@objektfabrik.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mark,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Hope these thoughts help you understand a little more about your situation.<br>
<br>
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.<br>
<br>
HTH<br>
<br>
Joachim<br>
<br>
<br>
<br>
Am 08.09.15 um 01:39 schrieb Mark Bratcher:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hello<br>
<br>
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.<br>
<br>
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.<br>
<br>
I bought and have been reading Dynamic Web Development With Seaside, but it does not address this case.<br>
<br>
Is it possible to do what I'm attempting to do?<br>
<br>
Thank you<br>
Mark<br>
<br></div></div><span class="">
_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org" target="_blank">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
<br>
</span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
-----------------------------------------------------------------------<br>
Objektfabrik Joachim Tuchel mailto:<a href="mailto:jtuchel@objektfabrik.de" target="_blank">jtuchel@objektfabrik.de</a><br>
Fliederweg 1 <a href="http://www.objektfabrik.de" rel="noreferrer" target="_blank">http://www.objektfabrik.de</a><br>
D-71640 Ludwigsburg <a href="http://joachimtuchel.wordpress.com" rel="noreferrer" target="_blank">http://joachimtuchel.wordpress.com</a><br>
Telefon: <a href="tel:%2B49%207141%2056%2010%2086%200" value="+4971415610860" target="_blank">+49 7141 56 10 86 0</a> Fax: <a href="tel:%2B49%207141%2056%2010%2086%201" value="+4971415610861" target="_blank">+49 7141 56 10 86 1</a></font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org" target="_blank">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
</div></div></blockquote></div><br></div>