I’m also giving mold a try. I loaded it in seaside 2.9. No loading problem. On pharo, only #trimBlanks is missing. I used #trimBoth wich is definied in seaside (trim left and right blanks).

Problem is that validation doesn’t occur. I changed #priority from 7 to 3 and now it seems to work.

Anyway thanks for sharing it.

I could also imagine situations where it’d be handy to have two molds within one form, though in practice I haven’t done that much.

The canvas: setting bugs me too but I haven’t found a better way around it yet. I considered using a WADynamicVariable, or passing the canvas around as an argument to every method along the way, but both of those just added annoying noise to the code.

One other thing I forgot to mention about #customize: — the other option for customization in Mold is to send messages to the tag returned by #widget: — it’s just a tag brush, so something like this is perfectly legit:

(mold widget: #email) size: 30.

You don’t have this option when you’re using the more broad-sweeping helper methods like #tableRows or #paragraphs, of course.

Again, thanks for the compliments. I have long admired your solid thinking and the clear explanations you write up on your blog, so it means a lot to me.

Your metadata is generally specified in the view while building the mold using plain old objects, not that dissimilar from Magritte except of course it’s in the model. However, unlike Magritte, your metadata and the views that render the fields are one and the same while Magritte has a separate hierarchy of metadata (descriptions) and view components (overly complex IMHO).

Your mold views however, unlike Magritte, are pluggable, allowing a #customize: block to be sent to give you access to the tag while it’s being generated, very nice as that sidesteps the need to have to subclass and customize the views (why I don’t like Magritte’s approach). I do the same thing but using #respondsTo: and method naming conventions. In either case, exactly what you need to Ajax’ify up a form.

The only thing that seems off to me is the setting of the canvas on the mold and mold itself just being a helper class who does most of the work of the view. Looking at it, I think I’d make mold a subclass of WAComponent and do this…

Mold>>renderContentOn: html
html := html.
self renderMoldOn: html.

Mold>>renderMoldOn: html
self subclassResponsibility

So the form itself is the mold and the view…

MyForm>>initialize
| email confirmEmail |
email := self emailField
key: #email;
label: ‘Email Address:’.
confirmEmail := self emailField
key: #confirmEmail;
label: ‘Confirm Email:’.
email
addCondition: [ :input | input = confirmEmail input ]
labeled: ‘Email addresses did not match.’.
confirmEmail
addCondition: [ :input | input = email input ]
labeled: ‘Email addresses did not match.’.

MyForm>>renderMoldOn: html
html form:
[ html table: [ self tableRows ] ].
html submitButton
value: ‘Submit Form’;
callback: [ self isValid ifTrue: [ self save ] ] ]

But I could be overlooking some benefit of it being just a helper rather than the view.

In any case, I like your approach much better than Magritte because I think pluggable views are much easier to customize. But keeping the metadata in the view does pose the problem of duplicating it across multiple views.

I do like your field hierarchy, it’s much more OO feeling. Mine is a single class with a copy of the domain object as a memento for holding possibly invalid state and extentions to all the #on:of: holders in Seaside adding #on:of:type: which runs any submitted values through a type converter class before writing to the model. This class looks sort of like a visitor but the type name is used with reflection to invoke the correct conversion method. So rather than creating my own hierarchy of tags, I just extended the tags in Seaside to be type aware and keep all the validations in the form class itself. In any case, nice code, always enjoy seeing how someone else tackles a problem.

BTW, one of the reasons I like pragmas so much is that it’s a cross platform approach, most languages support some form of pragma regardless of what they call them, so it allows me to work in a consistent style across C#, VB.Net, and Smalltalk by tagging metadata onto classes and using reflection to access it.

You said that yours is a very different approach, but I think the general approach is more similar than different. In both cases, there is a sort of specification declared (in pragmas, or in a buildMold method) and then there are helpers (your form builder class, or Mold’s “macros” on the html canvas) that build and hook up the form while letting you override aspects of the rendering. For wizards, I’m doing the same thing you are; and for custom validations, again it’s the same approach: just implement the validation code in the form component.

Granted, I haven’t looked at your code yet, so maybe I don’t know what I’m talking about. :) I guess the main underlying similarity I’m seeing is that the model doesn’t drive the process, it just assists in it.

The main difference here seems to be where you put the declaration. I’m still not sold on metadata in the models, but I can see where your framework makes it easier to build multiple forms on top of the same model. Most of my forms end up asking the user for the same types of data, which is why Mold is built around a concept like “now prompt them for a percentage” rather than “now prompt them for #completion, according to whatever its rules are”.