Template mechanisms...

Stephen Pair spair at acm.org
Thu Dec 12 03:35:11 UTC 2002


Actually, it would be interesting to adopt an approach very similar to
Morphic for constructing web widgets (I'm thinking mostly in terms of
the compositional patterns found in Morphic...specifically how morphs
have a list of submorphs that are iterated when drawing).  If you also
enable the web widgets to render themselves as morphs, then you could
use Morphic to assemple your web GUIs...I've also thought that you could
use some of the dynamic features of the web browsers and build a web UI
editor in the web browser itself (but I think it would be easier and
better to do it in Morphic). 

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Avi Bryant
> Sent: Wednesday, December 11, 2002 10:06 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Template mechanisms...
> 
> 
> 
> On Wed, 11 Dec 2002, Stephen Pair wrote:
> 
> > For example, I have a widget called RolloverButton (which 
> has a mouse 
> > rollover effect).  That rollover button can just as easily general 
> > html indirectly using a DOM approach, or more directly with an SSP 
> > approach. The important thing is that you have a RolloverButton and 
> > use it (and other widgets) instead of directly dealing with 
> HTML or an 
> > HTML DOM to construct your UIs.
> 
> Absolutely.  Unfortunately, this is not what people tend to 
> do with templating systems, because it's not how HTML 
> designers typically work - instead, they produce one 
> monolithic HTML template per "page".  Once you're composing 
> tiny widgets instead of using huge templates, how the HTML is 
> actually specified isn't terribly relevant - but for exactly 
> that reason, I'd lean towards a DOM approach, because I find 
> smalltalk code much more tractable than string literals.
> 
> The other side of this is that there's no reason not to have 
> a very rough template with holes for the widgets - if your 
> designer wants to give you something that's basically a 
> header and a footer, with a few slots saying "put foo form 
> here" and "put bar button there", I think that's fairly 
> appropiate.  For this reason, in recent (unreleased) versions 
> of Seaside I've added #header and #footer (and #style) 
> methods to WAComponent that are expected to just return 
> string literals - this allows simple integration of 
> designer-produced HTML (and CSS) while still encouraging a 
> heavily factored, widget-based style.
> 
> Avi
> 
> 
> 




More information about the Squeak-dev mailing list