Fastest way to mock up web UI?

Giovanni Corriga giovanni at corriga.net
Wed Mar 28 13:54:21 UTC 2007


Il giorno mer, 28/03/2007 alle 12.50 +0200, Göran Krampe ha scritto:
> Hi!
> 
> > Hi Goran -
> >
> > As someone who had exposure to both HV2 and Seaside I am particularly
> > interested in your opinion. Looking at HV2 and Seaside it seems clear
> > that HV2 is a much more straightforward approach that is actually very
> > nice and understandable (I like it a lot).
> 
> Glad to hear! And feel free to improve it too, right now Giovanni is the
> one maintaining it - I haven't had the time to look at his snapshots yet.

Right now I'm in the process of building a Canvas/Painter similar to
Seaside's Canvas. I'm using a slightly different metaphor where the
Canvas is responsible for the low-level structure generation (that is,
XHTML generation) while the Painter does the high-level structure
generation (the Painter can work in terms of navigationalBars,
mainContentAreas, errorMessages etc).
Unfortunately it will take a little while for it to be on par,
feature-wise, with HV2's current HtmlBuilder system.

> Now - the simplicity in usability of Seaside and HV2 are pretty similar.
> Both lets you build a small app by simply creating a subclass of a given
> base class and then implement methods for rendering. In Seaside you always
> implement #renderOn: and in HV2 you implement methods matching the first
> "directory" in the URL by name.
> 
> In Seaside you get a builder sent into renderOn: - in HV2 you create it
> yourself. Then both build its respective HTML. HV2 builds a full page, in
> Seaside the component only builds its own HTML since it can be embedded.

I'm thinking about having partial painters for that. Basically, those
painters wouldn't produce any XHTML code for tags like title, head etc.
This would allow you to nest View classes withouth changing the XHTML
generation code.

> Also, building/handling forms in HV2 is a little bit more "hands on" - HV2
> uses a trivial trick to know which field in the POST matched the field in
> the GET. It is based on the assumption that the POST will build the same
> fields in the same order as the GET will. As long as you follow this
> "rule" it works - *or* as long as you are aware of breaking it and instead
> use explicit ids.

I have a couple of half-baked ideas on how to make this easier.

	Giovanni




More information about the Squeak-dev mailing list