On Mon, Sep 10, 2012 at 11:12 AM, Chris Cunnington
<smalltalktelevision at gmail.com> wrote:

> Yea, I see it now. My mistake. Would it be possible to get a form example?
>
> ALAppHtml5Canvas is overriding ALHtml5Canvas, so all the stuff in ALInputTag
> looks overriden. That leaves  #callback: and #send:to: alone in
> ALAppHtml5Canvas?

Ok, the main thing to note here is that form handling is more of proof
of concept than a working feature right now. It shows that the
approach works, but it hasn't been fleshed out much. The basic
structure is this:

AL-Html5 provides basic HTML5 rendering. That is, an API for
generating HTML programmatically, with all the tags and attributes
implemented. It's largely auto-generated, from a simple declarative
representation of the HTML scheme that I put together based on the
spec. (See ALHtml5Generator.)

Then, AL-HtmlApp implementes the Seaside "secret sauce" on top of
that. This is basically ties html rendering into the mechanisms
provided by locators, so that urls and form field names that do the
right thing are automatically generated.
AL-HtmlApp subclasses the generic HTML tags in AL-Html5 to add this
extra functionality, and so you have ALAppATag, ALAppFormTag and
ALAppInputTag, along with ALAppHtml5Canvas to make sure that these
specialized tags get used during rendering.

ALAppInputTag doesn't actually override anything, so all the stuff in
ALInputTag is still available. It just adds #callback: and #send:to:,
which allow for blocks or message sends to be bound to the input, and
handle the data submitted by the user.

Where Altitude differs from Seaside is this: Where Seaside uses a
single url/resource to handle all interactions from a given rendering
of the page, Altitude creates separate resources wherever possible. So
on pages that have multiple forms, each of them has a different action
url, each pointing to an ALFormResource created specifically for that
form.

There's also a bit of a hitch. The form's action attribute comes at
the beginning of the form, but the url for the resource isn't known
until the form has been rendered. So instead of streaming the HTML to
the browser as it's rendered (the way we normally do), we buffer the
HTML until the form is closed, register the form resource, set the
form's action attribute, then flush the HTML to the socket. That's
what ALAppFormTag>>with: and ALAppHtmlCanvas>>useForm:during: are
about.

So, basically, forms with text inputs work pretty well, but I haven't
done any work to implement other types of fields. In particular, file
uploads probably won't work, because I haven't implemented a parser
for multi-part MIME data. It's not a priority, because modern web apps
don't use forms much anyway.

Colin