Thank you for the explanations, Colin. You mention that text inputs work pretty well.
How then for example would a page like http://www.showdown.im/ (Online markdown converter) be done?
Two text areas and one button
<textarea id="inputPane" cols="80" rows="20" class="pane">...</textarea> <textarea id="syntaxPane" class="pane" cols="80" rows="20" readonly="readonly"> ... </textarea> <button id="convertTextButton" type="button" title="Convert text now"> Convert text </button>
--Hannes
On 9/10/12, Colin Putney colin@wiresong.com wrote:
On Mon, Sep 10, 2012 at 11:12 AM, Chris Cunnington smalltalktelevision@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