Forms in Seaside and Iliad: helpers to make life easier

Seaside has come up with a very nice way of building html in code. Coding a component in the renderContentOn: method is different than what other frameworks did before, but it also is powerful and makes many things easy.

But it also can be difficult: You can hook a Smalltalk Block onto the submit event of a form (this is a very short and inprecise way of describing it), but once the Block gets evaluated, you are on your own.

What do I mean by that?

Let’s say you have code like this in your render method:

html textInput
callback: [:input| self modelObject name: input]
with: self modelObject name.

Then you already hooked the rendered text input field to your model object full round trip, meaning the field will display the contents of a variable when the component gets rendered, and when the form gets submitted (or, if you use AJAX, when the field gets serialized), the model object will be updated with the contents of the field.
Cool. Isn’t it?
Well, sometimes it isn’t.
Because sometimes the data you want to work on needs to be validated, converted, checked for plausbility and so on. Not all possible inputs in an html text field are probably valid values for your model object.
So there needs to be something in between the html tags and the value callbacks and your object model.
Some naive approach for this could be to code a lot of stuff in the callback blocks or in a special subclass of WAComponent that can be used from within the callback blocks. This will probably be a feasible solution for smaller apps, but especially in projects where an existing application is about to be ported to the web, there possibly is much of the functionality for validation and conversion. If you know VA Smalltalk, you surely know what I mean if I say “AbtConverter”.
In Java, there once was an idea that was called Java Server Faces in which every html tag on a form had its server side counterpart to handle vaidation and conversion and promotion between model and servlet. (Well, the idea had been born about ten years earlier at IBM and there it had ironically been implemented in VisualAge Smalltalk – remember Web Connection? – but that’s another story).
In Seaside, there’s nothing like this out of the box.
In our first, non-trivial Seaside Application, we tried implementing a set of GUI components as subclasses of WAComponent that offered all these functionalities and also handled collection and display of errors in validation and conversion and did not answer: before all errors were gone.
But the approach ended in a mess. Decorations and delegations everywhere, and in the end our components could only be embedded in components of our own framework.
When Scriptaculous and JQuery became popular, we saw that this approach is leading nowhere else than a seaside-shadow-framework with very complicated rules and dependencies, and much of the stuff needed for Ajax would be extremely hard to do, since at creation time of our components we didn’t have the html-ids and there were more complicated problems.
Later I read a post by Ken Treis about Form Validation with a Micro-Framework called Mold, that he had been using. I liked the idea and saw some clear strengths in it. As far as it is published today, there’s a lt missing, but it’s a great starting point.
We are currently using our own micro Framework based on the ideas of Mold for another project, and we are able to integrate with jQuery quite nicely. It uses existing AbtConverter classes, since our goal is to provide help to VA Smalltalk customers who want to port their fat clients to Seaside.
Just today I read Nicolas Petton‘s announcement of Formula, a similar framwork for Iliad (a Web Framework inspired by both Seaside and AIDA) on GNU Smalltalk, and the code examples somewhat remind me of Mold and our own framework.
It seems today it’s not so much about templating nice pages any more, but about handling form data in an easy and elegant way…

One thought on “Forms in Seaside and Iliad: helpers to make life easier

Comments are closed.