ALFormResource disappeared from AL-Application-Core?

> On Mon, Sep 10, 2012 at 11:12 AM, Chris Cunnington
> <[hidden email]> 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
>
>

> On Mon, Sep 10, 2012 at 11:12 AM, Chris Cunnington
> <[hidden email]> 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
>