<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 1:09 PM, Otto Behrens <span dir="ltr"><<a href="mailto:otto@finworks.biz" target="_blank">otto@finworks.biz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What you have here looks fine to me.<br>
<br>
So the next thing I can think of do is to use the debugger to figure<br>
out what is going on.<br>
<br>
I would set a breakpoint in WACallbackRegistry >> handle:. This method<br>
maps the names that are posted to the callbacks that are evaluated.<br>
So, this will tell you firstly what fields are posted and then if they<br>
map to the callback registry. If the field is not there, then you know<br>
it is not coming through from the browser. If the callback is not<br>
mapped, then we can try to figure that out from where the callback is<br>
created. This is getting deep into Seaside though...<br>
<span class="im HOEnZb"><br>
> I do have "plain" subclasses of WAComponent to an overall "MyAppComponent",<br>
> then all my app's components are subclassed from MyAppComponent. and I do<br>
> have `children` defined in my subclass and `renderContentOn`. MyAppComponent<br>
> provides a common set of small rendering helpers for formatting, and loads<br>
> common CSS files in `updateRoot` which the subcomponents can capture via<br>
> `super updateRoot: html`.<br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> Conceptually:<br>
><br>
><br>
> MyAppComponent subclass: ParentComponent [<br>
> new [<br>
> child := ChildComponent new<br>
> ]<br>
><br>
> children [ ^Array with: child ]<br>
><br>
> initialize [<br>
> super initialize.<br>
> self addDecoration: (WAFormDecoration new buttons: self buttons).<br>
> ]<br>
><br>
> renderContentOn: html [<br>
> "render parent items here..."<br>
><br>
> html render: child<br>
> ]<br>
><br>
> ...<br>
><br>
> I can provide more specifics if needed.<br>
><br>
>><br>
>><br>
>> > I'm not sure how to determine the version of Seaside I have. I am using<br>
>> > GNU<br>
>> > Smalltalk 3.2.91-b98173d, so it's whatever Seaside package revision<br>
>> > they've<br>
>> > included with that.<br>
>><br>
>> I have no idea how to check that with GNU; we're using<br>
>> Monticello/Metacello to load into Pharo and GemStone. And even in our<br>
>> environment it is difficult to figure out.<br>
>><br>
>> ><br>
>> > Regards<br>
>> > Mark<br>
>> ><br>
>> ><br>
>> > On 9/8/2015 6:25 AM, Otto Behrens wrote:<br>
>> >>><br>
>> >>> The parent input fields and subcomponent input fields are within the<br>
>> >>> same<br>
>> >>> html `form`. However, when I click the submit button (done at the<br>
>> >>> parent<br>
>> >>> level), only the input items rendered by the parent are recognized.<br>
>> >>> Any<br>
>> >>> inputs provided by the user through the embedded, rendered<br>
>> >>> subcomponent<br>
>> >>> are<br>
>> >>> ignored.<br>
>> >><br>
>> >> I would carefully look at the HTML that you produce here. And then<br>
>> >> make sure I don't have nested forms. Remember that if you use Chrome<br>
>> >> (and I suspect Firefox and others too), the HTML you see with the<br>
>> >> "inspect element" menu does not give you the real HTML. Chrome removes<br>
>> >> nested forms. Make sure you look at the raw HTML.<br>
>> >><br>
>> >> If you say "recognized" I assume you're talking about inputs posted<br>
>> >> with the submit, which translates into callbacks processed by Seaside.<br>
>> >> If so, your inputs are not in the same form tag or you have nested<br>
>> >> form tags.<br>
>> >><br>
>> >>> Is it possible to do what I'm attempting to do?<br>
>> >><br>
>> >> Yes, we're doing this a lot, so we can find out what's going on here.<br>
>> >><br>
>> >> Cheers<br>
>> >> Otto<br>
>> >> _______________________________________________<br>
>> >> seaside mailing list<br>
>> >> <a href="mailto:seaside@lists.squeakfoundation.org">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>
>> ><br>
>> > _______________________________________________<br>
>> > seaside mailing list<br>
>> > <a href="mailto:seaside@lists.squeakfoundation.org">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>
>> seaside mailing list<br>
>> <a href="mailto:seaside@lists.squeakfoundation.org">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>
><br>
> _______________________________________________<br>
> seaside mailing list<br>
> <a href="mailto:seaside@lists.squeakfoundation.org">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>
_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org">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>