Template mechanisms... ( why not a weblayout designer? )

Daniel Joyce daniel.a.joyce at worldnet.att.net
Fri Dec 13 05:57:15 UTC 2002


On Thursday 12 December 2002 03:53 pm, Adrian Lienhard wrote:
> I think this idea would be a really good approach. It's quite simple
> and will work in 90% of the (my) cases.
> So far I was used to develop web-apps as following: The designer
> created a simple prototype. Then I started coding the web-app -
> producing ugly, simple html (e.g. just forms without layout). The
> prototype was then used by the designer to create some nicer design.
> During the development process we had many iterations of "coding -
> designing".
> Most produced html code by the designer is a) tables (some very
> complex) and b) formatting (done with CSS).
> I think, an approach which enables an iterative workflow between
> programmer and designer would be what many people need.
>
> If Avi's idea could be implemented, it would really be nice. The
> reminding 10 or 20% of special cases ("every 9th row has an image")
> would not be a too big disadvantage or problem, I think.
>
> Adrian
>

Why not just use 'morphs' that represent controls, tables, etc, that 
have tags that developers can define that 'hook' into post-get 
messages, but can be decorated with CSS/HTML/etc attributes....

Then, just as you can ask a page to spit itself out as a postscript 
image, ask the morphs to spit themselves out as HTML and CSS files?

Since the nesting heirarchy of the HTML design morphs would match the 
nesting heirarchy of the CSS tags, then one can handle the nesting 
rules for CSS too  ( context sensitive CSS, "When <a> is inside a <td> 
then decorate it like so ).

So the designer can design the layout, and the programmer can say "Okay, 
this is a drop down box that contains this, and sends this back to the 
server.... "

IE, a UI layout widget that handles both....

The layout guy could shift them around, and the programmer could make 
sure the program hooks are all there for the form submits, etc....

-Daniel




More information about the Squeak-dev mailing list