[Seaside] Seaside subsets

[Boris Popov]

Isn't CSS best left to people who do it for living anyway? They already
have the tools to get it right. For instance, there isn't a single
#style method in our application and all CSS is referenced externally.

Cheers!

-Boris

-- 
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

boris at deepcovelabs.com

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> bounces at lists.squeakfoundation.org] On Behalf Of Jason Johnson
> Sent: Wednesday, February 28, 2007 9:39 AM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] Seaside subsets
> 
> Well, for my web pages I use Pier.
> 
> But one thing I would change (and will if someone else doesn't before
I
> get there :) is how CSS rendering works.  I think instead of having a
> #style message that just spits out a string, CSS should have it's own
> renderer.  It more or less has it's own render phase anyway, we may as
> well make it official with a CSSCanvas class or something.  This could
> help with browser version differences and maybe help with some of the
> problems with CSS fighting with Halos (i.e. conflict
> detection/resolution).  I also have other ideas for such a renderer to
> make CSS building more accessible to non-programmers. ;)
> 
> Avi Bryant wrote:
> > As 2.7 gets closer to beta (right?) and people might be thinking
about
> > what 2.8 or even 3.0 might look like, I thought it might be
> > interesting to share a somewhat surprising experience I've had:
Dabble
> > DB, which is by far the most complex web application I've ever
worked
> > on, uses really a rather small subset of Seaside.  For example:
> >
> > - We never use the old WAHtmlRenderer code.  Ok, no surprise there,
> > but in case anyone was wondering, it's all Canvas all the way.
> > - We never use decorations, ever.  No new subclasses of
WADecoration,
> > no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.
> > - We never use any of the standard dialog or widget components.  For
> > us, anyway, the Canvas tags turn out to be the right level of detail
> > for reuse across apps.  We do plenty of reusing components within
the
> > app, but a generic YesOrNoDialog or WATree doesn't cut it except
when
> > prototyping.
> > - We do use halos, and I'd like to use them more, but they do badly
> > with heavily CSS-styled layouts.  Note that I only use them to see
> > page structure and for view source, I don't use the web-based system
> > browser (that's what the RFB Server is for).
> > - We do use the preferences system pretty heavily, with app-specific
> > subclasses of WASystemConfiguration that provide defaults we can
> > override from /config.  But we don't use the baroque multiple
> > inheritance system.
> > - We don't use libraries (CSS or Javascript) at all.  We use
> > #updateRoot: and #resourceUrl: heavily to bring in external .css and
> > .js files which the designer controls.
> > - We use WATask sparingly.  In fact, pretty much the only use is for
> > collecting payment info, which is of course the classic example I
> > always give.
> > - We certainly do use #call: and #answer:, but much less than you
> > might expect given how much talk there is about continuations.  And
> > the #call: stack rarely gets more than one component deep.  Instead,
> > we're much more likely to conditionally render a child component, or
> > to have a "currentChild" state variable which is constantly modified
> > during navigation.
> > - Except for a handful of those "currentChild" state variables, we
> > don't use WAStateHolder or #registerObjectForBacktracking: at all.
> > Well, that's not strictly true: we use it once, with a single
> > session-global NavigationContext object that holds all the
> > backtrackable state as instance variables.  The entire component
tree
> > at any given time can almost always be determined by examining the
> > NavigationContext.
> > - We do use Scriptaculous, but mostly only the Ajax bits rather than
> > the effects.
> >
> > So, I'm curious how typical my experience is.  If it's shared by
most
> > of you, we may want to do some major housecleaning...
> >
> > Avi
> > _______________________________________________
> > Seaside mailing list
> > Seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >
> 
> 
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside