[Seaside] Accepting input from parent & child components

Mark Bratcher mdbratch at gmail.com
Wed Sep 9 15:51:28 UTC 2015


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, jtuchel at objektfabrik.de <
jtuchel at objektfabrik.de> wrote:

> 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
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
> --
> -----------------------------------------------------------------------
> Objektfabrik Joachim Tuchel          mailto:jtuchel at objektfabrik.de
> 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
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150909/23123c2c/attachment-0001.htm


More information about the seaside mailing list