Fastest way to mock up web UI?

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?

[*] 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 ;-)

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

Thanks,
   - Andreas

Il giorno lun, 26/03/2007 alle 20.15 -0700, Andreas Raab ha scritto:
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

Hi Andreas,

I'm on the way to port AIDA/Web (http://www.aidaweb.si) to Squeak. See
tutorial at http://www.aidaweb.si/tutorial.html to see if Aida is easy
enough for you. It also contains full user/group and security
management. Installation (at least on VisualWorks) is one click install
and it contains all, from web server on. You just need to configure your
host:ip:port and you are online. Because it is based on top of Swazoo
web server, it can also do virtual hosting - host more than on website
at once.

Best regards
Janko

Andreas Raab wrote:
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Hi!

Giovanni Corriga <[hidden email]> wrote:
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

Andreas,

If you have a lot of domain classes each requiring simple editors and
viewers you may be able to produce something quickly with Magritte
(http://www.lukas-renggli.ch/smalltalk/magritte/). Can't say whether it
works with 3.8/Croquet, sorry.

Regards,
Zulq.

Andreas Raab wrote:

Il giorno mar, 27/03/2007 alle 10.12 +0200, [hidden email] ha scritto:

> 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.

They get pretty large is you use the standard HtmlBuilder. I'm following
this pattern where I use custom builder derived from tha base one that
allow me to create the html page using not only (x)html tags, but also
more high level structural elements.

        Giovanni

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.


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

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). 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).

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

[hidden email] wrote:

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. ;)

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/

2007/3/28, Göran Krampe <[hidden email]>: I'm sure you wanted to write #renderContentOn:, implementing
#renderOn: in components is almost always the wrong thing to do and
causes a lot of problems and bugs unless you frigging exactly know
what you are doing.
It can be done have a look at: http://www.lukas-renggli.ch/blog/
It's just that you have to create and consume them "by hand", there is
almost nothing to help you with this.
On a component you can implement #initialRequest: to parse the url and
set it up once a new session is created. It's still tricky though
because you can't do #call s in there so you might end up using tasks.
For anchors you can use #addToPath:.

Philippe

Il giorno mer, 28/03/2007 alle 12.50 +0200, Göran Krampe ha scritto:
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

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

Hi Goran -

Thanks for the information. This is incredibly helpful.

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

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:.
>
>    - Andreas

Basically, since Seaside is component based anyway, many people build a root
component to contain header, footer, menus, etc, and then a component for
body.  You can then set the body component to any component you like and
it'll render, no need for call.  As Goran said, the component model is what
makes Seaside rock so much, it's just like programming a desktop
application, no fussing with state.

Ramon Leon
http://onsmalltalk.com

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:

Andreas Raab wrote:
> Hi -
>
> This is an interesting point. But I'm not sure I understand Magritte
> enough to be able to make a good decision.
I am not sure that I understand magritte at all! As a pier user I have
never used magritte.
> 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
Magritte is orthogonal to seaside, it is not really related conceptually
apart from the fact that seaside can be used with Magritte.

 From what I understand, which is very little, Magritte enables you to
describe your data types in such a way that forms for editing those data
types can be built automatically. So Magritte is at a different more
fundamental level, it supports the data modelling.

As far as control flow goes, I havent got a clue.

Seaside components as editors onto the underlying model are only one
possible emitter/front-end from Magritte. Magritte can equally well be
used to emit a morphic ui for editing the same data. As web interfaces
are becoming richer with AJax and XUL front ends. Magritte seems equally
well positioned to keep up with the latest fads, to generate XUL
interfaces onto its model, rather than going through the inconvenience
of HTML.

Since Pier is built on Magritte, this has the practical benefit that the
data in Pier is fully accessible outside of html, via alternative
front-end frameworks. It is possible to use a morphic browser onto the
same model without any extra work.
> about Magritte would imply to go with Seaside too (incl. the good and
> the bad of it).
>
> Thanks for any insight you can provide.
>
best regards

Keith

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 

In case you're interested, I have a screencast where I build a simple blog
using Seaside and Magritte in about 15 minutes.  Something to look at if
you've never used either.

http://onsmalltalk.com/programming/smalltalk/screencast-how-to-build-a-blog-
in-15-minutes-with-seaside/

Ramon Leon
http://onsmalltalk.com 

>
> 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

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