<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [Seaside] CSS dinamycally manipulated</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.3086" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007>Hi there,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007> 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. </SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007> 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.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007> 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.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007> 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.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=937045220-10062007> cheers,</SPAN></FONT></DIV>
<DIV align=left><SPAN class=250542422-20122006>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt" align=left><?xml:namespace prefix
= st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:PersonName
ProductID="Sebastian Sastre " w:st="on"><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'"></SPAN></st1:PersonName> </P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt" align=left><st1:PersonName
ProductID="Sebastian Sastre " w:st="on"><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'">Sebastian
Sastre</SPAN></st1:PersonName></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt" align=left><st1:PersonName
ProductID="Sebastian Sastre " w:st="on"><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'"><FONT color=#0000ff><SPAN
class=937045220-10062007>PD1: </SPAN>html is <SPAN
class=937045220-10062007>mere </SPAN>assembler <SPAN
class=937045220-10062007>in the </SPAN>browser<SPAN
class=937045220-10062007>/</SPAN>OS<SPAN class=937045220-10062007>
"hardware"</SPAN></FONT></SPAN></st1:PersonName></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt" align=left><st1:PersonName
ProductID="Sebastian Sastre " w:st="on"><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'"><FONT color=#0000ff><SPAN
class=937045220-10062007>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.</SPAN></FONT></SPAN></st1:PersonName></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'"><?xml:namespace prefix = o
ns = "urn:schemas-microsoft-com:office:office"
/><o:p></o:p></SPAN></SPAN></P></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=es dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>De:</B> seaside-bounces@lists.squeakfoundation.org
[mailto:seaside-bounces@lists.squeakfoundation.org] <B>En nombre de </B>Boris
Popov<BR><B>Enviado el:</B> Sábado, 09 de Junio de 2007 19:07<BR><B>Para:</B>
seaside@lists.squeakfoundation.org<BR><B>Asunto:</B> Re: [Seaside] CSS
dinamycally manipulated<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/plain format -->
<P><FONT size=2>+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.<BR><BR>Cheers!<BR><BR>-Boris<BR>(Sent from a
BlackBerry)<BR><BR>----- Original Message -----<BR>From:
seaside-bounces@lists.squeakfoundation.org
<seaside-bounces@lists.squeakfoundation.org><BR>To: 'Seaside - general
discussion' <seaside@lists.squeakfoundation.org><BR>Sent: Sat Jun 09
15:04:34 2007<BR>Subject: RE: [Seaside] CSS dinamycally
manipulated<BR><BR>> I believe that having a dynamic css doesn't urge
the<BR>> designers to program it.<BR><BR>Of course not, because designers
don't program.<BR><BR>> I don't like much this old way of<BR>> thinking:
code and coders at one side, design tools and<BR>> designers at the other
one. Data vs code.<BR><BR>It's not old thinking, it's reality!<BR><BR>>
Coders and designers should do there work orthogonnally<BR>> without
annoying each other and with their own point of view.<BR><BR>Agreed, hence
HTML for programmers, and CSS for designers.<BR><BR>> But why not doing
this on the same language core.<BR><BR>Because if designers understand the
language we work in, they aren't<BR>designers, they're
programmers.<BR><BR>> It would even be nice for designers to have a bit of
coding<BR>> possibilities like macros. This standard philosophy
results<BR><BR>Then they become programmers, not designers.<BR><BR>> to the
failure of Lisp. I hope the trendy solution like<BR>> XML/XSLT would give
us a future way of composing<BR>> page/wiki/application in a more DSL
fashion.<BR><BR>You have a design DSL already, it's called
CSS.<BR><BR><BR>_______________________________________________<BR>Seaside
mailing list<BR>Seaside@lists.squeakfoundation.org<BR><A
href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</A><BR></FONT></P></BLOCKQUOTE></BODY></HTML>