Hi!

Giovanni Corriga giovanni@corriga.net wrote:

Il giorno lun, 26/03/2007 alle 20.15 -0700, Andreas Raab ha scritto:

...

Folks -

I have the need for mocking up a bit of a web UI as an administrative interface to some domain objects living inside Squeak. What is the easiest[*][**] framework to use for that purpose?

I'm sure one of the options is Seaside but I'm not sure it is the only game in town, neither am I sure if it's the right thing for the task at hand. Since I remember that various people had used a number of frameworks I'm curious about alternatives and tradeoffs. Any opinions or recommendations?

Well, I initially wrote HV2 and now I have been working with Seaside in Gjallar quite a bit. I have written a bunch of apps using HV2 (World Cup Betting site, SqueakMap server, some other odds and ends)and HV2 has a few things going for it IMHO:

-Trivial to learn and debug, it is very small. No continuations or "magic stuff" going on.

-Nifty URL "directory" to selector mapping. You just add a method in a View class and tada - you can instantly "call it" by typing it in as a URL. (HV2 uses a special method category for such selectors)

-Uses the same HTML generation model as Seaside did before Seaside changed to the canvas model. Not sure if Giovanni has had time to move HV2 in the same direction yet (he was working on it).

-Uses "real" URLs instead of Seasidish "weird" URLs.

Seaside of course offers a true component model where each WAComponent can "live" on its own and removes all the need for state management using url args, hidden fields and so on. And then there are tons of other useful things in Seaside like Scriptaculous integration etc.

...

[*] easiest = least painful install, reasonably quickly to learn, fast intermediate results, open to future extensions (in case that UI needs to become "not-so-mockup" anymore ;-)

I guess HV2 fulfils this, but on the other hand so does Seaside IMHO.

...

[**] One strict requirement though: It must work under 3.8/Croquet.

Can't see any problem with either Seaside or HV2 - I use 3.8 in Gjallar and I can't imagine HV2 to not work in 3.8. And I can't imagine Croquet has any effect.

I'm currently using (and extending) Goran's HV2, the web framework used for the SqueakMap server. It's not as advanced and innovative as Seaside, but I think it's a nifty little framework.

Giovanni

Right, the SqueakMap server code might serve as a useful "larger" example to look at. HV2 also has some small examples in it.

HV2 invites you to write each "page" in a single method - sure, they can get pretty large, but it works pretty nicely in practice. This is because of the trick commonly used in HV2 by letting the same method handle the GET and the Form POST giving automatic mapping of fields etc.

regards, Göran

Since no one else has, I will plug for Seaside here. Seaside does *do* complicated stuff, but you generally don't see it (unless you are doing something that in other systems would be much more complicated if it was even possible at all).

Basically what you have to do in Seaside is derive your class from a specific Seaside class, then you do the class as a normal domain class not thinking about html at all. To get it to show up on the web site, all you have to do is add a #renderOn: method that displays it in HTML and tell Seaside where to insert you class (which is done with a simple configuration on a web page).

For me the "painless" part of Seaside is that you write it like normal code, you don't really think about any of the normal web things except your html.

And if you are really brave, you don't even have to do that. You could use Magritte that lets you add a class side method #description that specifies how the object should look, and Magritte will display it in Seaside or Morphic for you. It just depends on what kind of site you are mocking up I guess.

From: goran@krampe.se Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Fastest way to mock up web UI? Date: Tue, 27 Mar 2007 10:12:28 +0200

Hi!

Giovanni Corriga giovanni@corriga.net wrote:

...

Il giorno lun, 26/03/2007 alle 20.15 -0700, Andreas Raab ha scritto:

...

Folks -

I have the need for mocking up a bit of a web UI as an administrative interface to some domain objects living inside Squeak. What is the easiest[*][**] framework to use for that purpose?

I'm sure one of the options is Seaside but I'm not sure it is the only game in town, neither am I sure if it's the right thing for the task

at

...

...

hand. Since I remember that various people had used a number of frameworks I'm curious about alternatives and tradeoffs. Any opinions

or

...

...

recommendations?

Well, I initially wrote HV2 and now I have been working with Seaside in Gjallar quite a bit. I have written a bunch of apps using HV2 (World Cup Betting site, SqueakMap server, some other odds and ends)and HV2 has a few things going for it IMHO:

-Trivial to learn and debug, it is very small. No continuations or "magic stuff" going on.

-Nifty URL "directory" to selector mapping. You just add a method in a View class and tada - you can instantly "call it" by typing it in as a URL. (HV2 uses a special method category for such selectors)

-Uses the same HTML generation model as Seaside did before Seaside changed to the canvas model. Not sure if Giovanni has had time to move HV2 in the same direction yet (he was working on it).

-Uses "real" URLs instead of Seasidish "weird" URLs.

Seaside of course offers a true component model where each WAComponent can "live" on its own and removes all the need for state management using url args, hidden fields and so on. And then there are tons of other useful things in Seaside like Scriptaculous integration etc.

...

...

[*] easiest = least painful install, reasonably quickly to learn, fast intermediate results, open to future extensions (in case that UI needs to become "not-so-mockup" anymore ;-)

I guess HV2 fulfils this, but on the other hand so does Seaside IMHO.

...

...

[**] One strict requirement though: It must work under 3.8/Croquet.

Can't see any problem with either Seaside or HV2 - I use 3.8 in Gjallar and I can't imagine HV2 to not work in 3.8. And I can't imagine Croquet has any effect.

...

I'm currently using (and extending) Goran's HV2, the web framework used for the SqueakMap server. It's not as advanced and innovative as Seaside, but I think it's a nifty little framework.

Giovanni

Right, the SqueakMap server code might serve as a useful "larger" example to look at. HV2 also has some small examples in it.

HV2 invites you to write each "page" in a single method - sure, they can get pretty large, but it works pretty nicely in practice. This is because of the trick commonly used in HV2 by letting the same method handle the GET and the Form POST giving automatic mapping of fields etc.

regards, Göran

_________________________________________________________________ Exercise your brain! Try Flexicon. http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglinemar...

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.

Seaside on the other hand, seems much more complex in its control flow (even trying to follow the store example quickly gets you into call/cc and at that point all bets are off).

I actually haven't looked at the store example. ;)

Given that, what made you use Seaside for Gjallar? What are the characteristics for applications that would be better off with Seaside compared to HV2? I'm more interested in technical areas here btw; clearly there is community and all that where Seaside is strong but I'm just curious how someone like who has used both would characterize when to use which framework.

Oh, and what are the prospects for RESTful urls in Seaside these days? Last time I asked about it there wasn't really a good answer - is there one these days? I'm not really into the whole auto-magic URLs myself; I'd rather have it say http://foo.bar.com/users/andreas if I want to refer to a user page.

Cheers,

• Andreas

Ok, let's see if I can sum this up. My decision for using Seaside in Gjallar was mainly based on the fact that I anticipated rather complex user interfaces in Gjallar. The fact that it also has a Scriptaculous integration was also a factor IIRC - we do want to use a teeny bit of Ajax here and there. I am satisfied with that decision btw.

In retrospect the main benefit, as I see it, of Seaside in Gjallar is the component model. The fact that I can construct the UI using separate components that can be used embedded inside each other and still render themselves totally oblivious of the environment and the request/response cycle.

The reason for this is of course the fact that a WAComponent is "persistent" in the user session and can hold all its state simply in instvars. So it erases the need for "inter request client side state management" using say URL params or hidden fields and so on.

Sidenote: Btw, I haven't thought much about it but in the beginning I visualized the HttpView instances to also be "persistent" in the user session - but then in practice it turned out (at the time) I didn't need them to be - and the rest is history. Perhaps it would be of use to reconsider that and at least make it *optional* to have "persistent" HttpView chains (as you may know a typical HV2 technique that at least I have used is to mirror the hierarchy of the domain model with view instances that get chained together matching the hierarchical structure of the URLs) that can then maintain state between requests as simple instvars.

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.

In HV2 it is trivial to follow what happens next - the builder simply gets returned up the view chain and then gets told to produce its HTML that gets sent back in the response. What Seaside does I am not quite sure, haven't bothered to dwelve into it. ;)

Personally I would pick Seaside if I can suspect the UI to grow complex OR if I want to use Scriptaculous or any of the other Seaside based components like say Magritte or Pier. HV2 has no such components that I am aware of. :) You can also use HV2 alongside with Seaside, no problem.

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.

HV2 is a neat pick if you want to get up running in 2 minutes *and* actually understand how it works - you can use the debugger to follow each request all the way from KomHttpServer into HV2, through the view chain and all the way back. This of course also makes HV2 simple to "hack" - if you want to meddle around with using some "common web techniques" there is nothing in HV2 stopping you since it is so "bare metal". The builder approach is also not so tightly coupled with the rest so I imagine you could easily instead use a templat engine if that suits.

Seaside is also quick to get running with IMHO, but it is definitely not easy to understand (under the hood) - BUT... if you can ignore that then you can build apps and still get away with it. I definitely don't understand the inner workings of Seaside BUT I have managed to build Gjallar nevertheless. :)

And finally, RESTful URLs. In HV2 they are the rule and IMHO the simple idea of dispatching on each "directory" in turn creating a chain of view instances is pretty darn neat. For example, all URLs beginning with "/account/" in SqueakMap will run through a single method called #account in the root view and that point is the single place where we check that the user is logged in and then create an AccountView and let it take over to dispatch on the rest of the URL. Quite nice.

In Seaside I am actually not sure what the "state of the art" is regarding explicit URLs. We do have a mechanism in Gjallar (haven't looked closely at it, Magnus wrote it) where we deal with a URL having a case number in it, so evidently you can rather easily hack it. But this is "on the side" so to speak - it doesn't play along with the Seaside AFAIK. There is something called Bicephale (http://map.squeak.org/packagebyname/biceph) that is more integrated in Seaside - have no idea about it. I guess Lukas or Avi will have to answer this one.

Finally - in Gjallar we almost never use #call: btw. And we haven't bothered maintaining backtracking state either (which we really should look into because right now Gjallar is not "back button" safe). Again, the component model is what rocks IMHO.

Hope this sheds some light on it all. Feel free to ask more.

regards, Göran

PS. Cees once built a thingy using HV2 and had some nice words to say on his blog: http://www.cdegroot.com/blog/2005/12/06/kilauea-magma-server-manager/

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

Hi -

This is an interesting point. But I'm not sure I understand Magritte enough to be able to make a good decision. First, I think Magritte isn't being used to define application control flow, is this correct? If not, how does one define control flow in Magritte (data flow I can see by having editors on editors on editors but control flow seems different). Second, Magritte is effectively an extension to Seaside, no? Therefore, any decision about Magritte would imply to go with Seaside too (incl. the good and the bad of it).

Thanks for any insight you can provide.

Cheers, - Andreas

Keith Hodges wrote:

I think it might be worth pointing out that Pier may be an option and is used by many, such as lukas for their personal websites.

Looking at the components of a web site.

Content: text, files, images can all be entered and uploaded using the website itself. Style: At present the stylesheet is stored in a class, served as a set of files, and can be edited directly. (I have done an 'edit style via website' experiment too.) Layout: The layout is defined as an assembly of other embedded components or pages and can be edited via the website at: /seaside/pier/environment. For example I replaced the header component with my own picture, this is trivially easy to do. Nice urls: Pier supports sensible bookmarking

This is just the starting point, for any more complex stuff, seaside components can be embedded, magritte is part of the base package, and there are many other plugins such as rss, blog, two security models etc.

best regards

Keith

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Wednesday, March 28, 2007 9:51 AM To: The general-purpose Squeak developers list Subject: Re: Fastest way to mock up web UI?

Hi -

This is an interesting point. But I'm not sure I understand Magritte enough to be able to make a good decision. First, I think Magritte isn't being used to define application control flow, is this correct? If not, how does one define control flow in Magritte (data flow I can see by having editors on editors on editors but control flow seems different).

Workflow can be accomplished by subclassing WATask instead of WAComponent. Tasks are components with no UI, that mediate child components. They are one of the most unique things about seaside and use continuations to allow you to model the entire workflow as a single clear method.

Second, Magritte is effectively an extension to Seaside, no? Therefore, any decision about Magritte would imply to go with Seaside too (incl. the good and the bad of it). Thanks for any insight you can provide.

Cheers,

• Andreas

No, Magritte is a meta model on top of classes. It's a stand alone package that can be used from Seaside, Morphic, or just plain Smalltalk. The package for Magritte enabled Seaside views is separate.

In practice, Magritte is mostly used in Seaside, but the model is useful by itself. For example, I've used Magritte's meta model to generate Glorp descriptions dynamically. It contains everything I need, types, required fields, relationships to other classes, etc.

Ramon Leon http://onsmalltalk.com

From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Fastest way to mock up web UI? Date: Wed, 28 Mar 2007 09:50:37 -0700

Hi -

This is an interesting point. But I'm not sure I understand Magritte enough to be able to make a good decision. First, I think Magritte isn't being used to define application control flow, is this correct? If not, how does one define control flow in Magritte (data flow I can see by having editors on editors on editors but control flow seems different).

Magritte is, for the most part, about abstracting the view of an object.

Second, Magritte is effectively an extension to Seaside, no? Therefore, any decision about Magritte would imply to go with Seaside too (incl. the good and the bad of it).

No. Magritte is an abstraction of making a view of an object. It does happen to have generators defined for Seaside. It also has them defined for Morphic. It would be possible to define them for anything you wanted.

_________________________________________________________________ Live Search Maps – find all the local information you need, right when you need it. http://maps.live.com/?icid=hmtag2&FORM=MGAC01

Hi Goran -

Thanks for the information. This is incredibly helpful.

In retrospect the main benefit, as I see it, of Seaside in Gjallar is the component model. The fact that I can construct the UI using separate components that can be used embedded inside each other and still render themselves totally oblivious of the environment and the request/response cycle.

The reason for this is of course the fact that a WAComponent is "persistent" in the user session and can hold all its state simply in instvars. So it erases the need for "inter request client side state management" using say URL params or hidden fields and so on.

Right. This is what I understood to be "special" about Seaside.

Sidenote: Btw, I haven't thought much about it but in the beginning I visualized the HttpView instances to also be "persistent" in the user session - but then in practice it turned out (at the time) I didn't need them to be - and the rest is history. Perhaps it would be of use to reconsider that and at least make it *optional* to have "persistent" HttpView chains (as you may know a typical HV2 technique that at least I have used is to mirror the hierarchy of the domain model with view instances that get chained together matching the hierarchical structure of the URLs) that can then maintain state between requests as simple instvars.

Yes, and I actually had been wondering about this. It seemed you have basically everything in place to match an incoming request with some session identifier and be able to simply use the view chain corresponding to the request. I don't have a need for this right now but it doesn't seem overly hard to me.

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.

Right. The small conceptual distance to the HTTP request / response protocol make it very simple to follow the control flow in HV2. And of course, it's trivial to add your own custom dispatch if you have any kind of dynamic content.

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.

Thanks, that is good to know. I noticed some automatic variable generation in the HTML builder which I suspect is at the root of this technique ;-)

HV2 is a neat pick if you want to get up running in 2 minutes *and* actually understand how it works - you can use the debugger to follow each request all the way from KomHttpServer into HV2, through the view chain and all the way back. This of course also makes HV2 simple to "hack" - if you want to meddle around with using some "common web techniques" there is nothing in HV2 stopping you since it is so "bare metal". The builder approach is also not so tightly coupled with the rest so I imagine you could easily instead use a template engine if that suits.

Indeed. I have a few "custom needs" in this area so the ability to back out a few special URLs to completely other places is really important. Again, this is trivial with HV2.

Seaside is also quick to get running with IMHO, but it is definitely not easy to understand (under the hood) - BUT... if you can ignore that then you can build apps and still get away with it. I definitely don't understand the inner workings of Seaside BUT I have managed to build Gjallar nevertheless. :)

That's good to know too. But since I won't be able to understand it, I'll need some examples to learn from - what did you use? Given that WAStore doesn't seem to be the example of choice, any alternatives would be greatly appreciated.

And finally, RESTful URLs. In HV2 they are the rule and IMHO the simple idea of dispatching on each "directory" in turn creating a chain of view instances is pretty darn neat. For example, all URLs beginning with "/account/" in SqueakMap will run through a single method called #account in the root view and that point is the single place where we check that the user is logged in and then create an AccountView and let it take over to dispatch on the rest of the URL. Quite nice.

Indeed. To me, the simplicity and straightforwardness of this approach is _the_ core strength of HV2 since it allows a very elegant overall structuring of the application. It is trivial to map out areas of interest (/users /products /support) and have HV2 pick it up and do the right thing. And I also suspect that some of this will come in handy for Apache integration.

In Seaside I am actually not sure what the "state of the art" is regarding explicit URLs. We do have a mechanism in Gjallar (haven't looked closely at it, Magnus wrote it) where we deal with a URL having a case number in it, so evidently you can rather easily hack it. But this is "on the side" so to speak - it doesn't play along with the Seaside AFAIK. There is something called Bicephale (http://map.squeak.org/packagebyname/biceph) that is more integrated in Seaside - have no idea about it. I guess Lukas or Avi will have to answer this one.

That's a bummer. The ability to define accessible entry points into sites is one of the core strengths of the web in my understanding.

Finally - in Gjallar we almost never use #call: btw. And we haven't bothered maintaining backtracking state either (which we really should look into because right now Gjallar is not "back button" safe). Again, the component model is what rocks IMHO.

So how do you build an application if you don't use #call:? The WAStore example seems to use #call: exclusively and it is not clear to me how exactly one would actually build an application in Seaside without using call:.

Hope this sheds some light on it all. Feel free to ask more.

Yes, this is all very, very helpful. I think I'll stick with HV2 for the time being, simply because it's such a nice vehicle for experimentation. I'm not quite sure how some of the stuff that I'm doing actually integrates with HTTP (this is one of the reasons why custom request handling is relevant) and maybe I'll give Seaside another try later.

Ain't it nice to have some alternatives? ;-)

Cheers, - Andreas

So how do you build an application if you don't use #call:? The WAStore example seems to use #call: exclusively and it is not clear to me how exactly one would actually build an application in Seaside without using call:.

You write it using callbacks to change state that drives the rendering.

e.g. for want of a better example look at WAMultiCounter. Change these methods:

initialize counters := OrderedCollection new

renderContentOn: html html anchor callback: [counters add: WACounter new]; with: 'Add counter'. counters do: [:ea | html render: ea] separatedBy: [html horizontalRule]

If you compare to the original you can see I make the counter's collection empty and just add the callback at the top of the render method. The callback changes the state of the component and this dictates what is rendered. #children is already valid but important for this to work.

#call: is useful when you want to be able to switch a component in the page layout, in place, with zero effort. In the example above, we are in direct control of the component's composition. #call: is a lower-level framework feature. For example, add this callback:

html anchor callback: [counters atRandom call: WAMiniCalendar new]; with: 'Call component at random'.

we #call: one of the components. The effect of this is to show the mini calendar in place of one of the counters. We have not had to say anything else to achieve this, and get #answer support, back button support, etc.

Instead if we do this:

html anchor callback: [counters at: counters size atRandom put: WAMiniCalendar new]; with: 'Replace component at random'.

we get the same visual effect but the side-effect is quite different. You can see this if you turn the halos on. In the former example of #call: the framework completely handles the layering of the components (and any #answer that unwinds the layering and hands a result back).

In the later example, we just ditch the component and replace it. Hopefully you can see the difference. Deciding which to use is more difficult. This example is contrived but the principle is to show that call: is orthogonal to page layout / component composition.

There is REST support in Seaside as Philippe says, and whilst it is not as central as other features it is not difficult to create entry points into your application, or just have multiple applications. I think this approach scales well, you define any entry points that you want and stop thinking about URLs after that.

Also the subjects of complexity and "magic" have been raised in this thread. Whilst I understand where this is coming from, really you just need to look at WACounter. Seaside is not that complicated, after all WACounter is a fully dynamic web application. I think what we could do with is some better examples. I don't find WAStore the best starting point I have to say.

By all means ask any questions on the Seaside list. That is one of the other advantages to your framework selection.... Have fun.

Cheers,

Mike