[Seaside] CSS dinamycally manipulated

Sun Jun 10 21:47:21 UTC 2007

Hi there,

    I've asked for this subject so is fear that I tell what I think. As I
see things, this is just another style to discuss an old thing again: the
convenience of coupling a model domain and a view domain. 

    Let's understood this one step ahead: for Seaside developers, browsers
should be considered mere hardware. The application is the Model and
WAComponents are some sort of "proto views" that serializes (aka render) in
html and should be the preamble of the generation of the views (view
objects). In this framework, internet will be just a convenient bus of the
system.

    All outside Seaside, you will find (now in 2007) the View part of the
framework full of holes, this is, with lack of the completenes that one is
used to enjoy in smalltalk (and it should have no matter tech is about). The
CSS solves, yet incompletely, only the satic layout part of the View. If you
need dynamic layout you will feel CSS small or incomplete (not to mention
incompatible for some browsers). Here the javascript Prototype framework can
help.

    I'm working this days on a little framework of my own, made (one part)
in javascript based on Prototype, to have in the browser js objects that are
homologous instances to the Seaside components (match 1:1). This way I hope
to be able to manage elegantly and masively but with minimal st inteligible
code 99,9% from smalltalk 1) the event wiring of the seaside components and
the matching elements in browser, 2) the actions (defining defaults for
everything and specializing just what is needed) of those events
specifically in a "non hakish" style, 3) factorization of all this in one
rich convenient hierarchy, 4) A step forward in the fullfill of those holes
outside smalltalk to reach reasonably the objetive of completeness of Views
objects for web applications.

    cheers,

Sebastian Sastre

PD1: html is mere assembler in the browser/OS "hardware"

PD2: one should not blame the tables for layouting. They are intuitive and
compatible. They just work and not only for the web development industry.
The problem is that they usually are used in a way that couple layout and
code (so it became troublegenic for designers and coders). I do use tables
for layout (it's very new and several browsers dont work well but CSS will
do suport tables real soon) decoupling at render time the layout policy of
the components from the content of the components. Designers and coders will
have it's lives a lot happier when proper tools allow the flexibility
designers need without compromising the coders engeneering. Two important
thing for the benefit of the consumers (accesibility and functionality).
This is only archivable trough decoupling the View displaying policies
(accesibility definition factor) from the Model (functionality definition
factor) by giving proper tools to define and adjust those policies. A couple
of years ago I told in this list that will become the time in which we
should have an online kind of resource editor for Seaside where resource
mean the definition of how do should look like every Seaside Component in a
WYSIWYG fashion. That piece of software will bring happier experiences for
designers, seasiders, it's employers and it's clients. That is not small.

  _____  

De: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] En nombre de Boris Popov
Enviado el: Sábado, 09 de Junio de 2007 19:07
Para: seaside at lists.squeakfoundation.org
Asunto: Re: [Seaside] CSS dinamycally manipulated

+1, the whole reason behind css is to separate it from content, why mash
them back together? Instead we should remove #style: and go the other way.

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: seaside-bounces at lists.squeakfoundation.org
<seaside-bounces at lists.squeakfoundation.org>
To: 'Seaside - general discussion' <seaside at lists.squeakfoundation.org>
Sent: Sat Jun 09 15:04:34 2007
Subject: RE: [Seaside] CSS dinamycally manipulated

> I believe that having a dynamic css doesn't urge the
> designers to program it.

Of course not, because designers don't program.

> I don't like much this old way of
> thinking: code and coders at one side, design tools and
> designers at the other one. Data vs code.

It's not old thinking, it's reality!

> Coders and designers should do there work orthogonnally
> without annoying each other and with their own point of view.

Agreed, hence HTML for programmers, and CSS for designers.

> But why not doing this on the same language core.

Because if designers understand the language we work in, they aren't
designers, they're programmers.

> It would even be nice for designers to have a bit of coding
> possibilities like macros. This standard philosophy results

Then they become programmers, not designers.

> to the failure of Lisp. I hope the trendy solution like
> XML/XSLT would give us a future way of composing
> page/wiki/application in a more DSL fashion.

You have a design DSL already, it's called CSS.

_______________________________________________
Seaside mailing list
Seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20070610/3419ed4a/attachment.htm