Alec Mitchell wrote:
Great analysis. I'm looking forward to my beer.
Wow, someone made it. :)
For me the big difference between these approaches is that one
requires changing many of the templates in Plone so that the rendered
results includes a bunch of fancy inline js that does all sorts of
neat things to various bits of the page, while the other requires some
consistent application of classes and ids so that arbitrary behaviors
(both pure client-side and client/server) can be applied to arbitrary
elements as desired in the same way one would apply look and feel
There is a certain element of illusion here - if you change the CSS
nodes around, you are liable to break AJAX behaviour. In other words,
you still need to touch the template to embed information, which could
be more than just the id of the node depending on how much information
you need to pass through to the server-side. That amount is directly
proportional to how generic the server-side function needs to be, which
is why things like the inline validation and in-place editor are such
important use cases to demonstrate. In addition, you need to define the
server-side handler and the KSS stylesheet.
For things that are just effects, you can probably get away with a pure
style sheet and little else. There is obviously a complexity curve here,
which KSS may give the illusion of hiding. What I mean is, it would
probably make it easier for a programmer to keep a cleaner separation of
concerns between page, behaviour application and server-side logic. It
would still not make it trivial to do complex new Ajaxy things for page
template people - that kind of stuff will always require a certain
amount of thought. The theory though, is that if it's sufficiently
generalised, it may be more re-usable, so that e.g. we could re-use the
action-menu drop-down code in something like CompositePack as well as
the global content menu, if desired, if this is made bindable by KSS via
a generic plugin.
(though the 'kukit-secondary-id' type classes seem like css class
abuse to me, I wish we could add some namespaced attributes without
breaking validation, it is X(tensible)HTML after all).
Balazs also mentioned problems with - you guessed it - IE :-/
I believe it is transparent, so when you do a kssAttr() statement, you
can either use class="kukit-name-value" (in combination with a "real"
class if you wish) or kukit:name="value". It's just that the former is
more reliable.
In the former
approach when an integrator wants to add a new behavior, he finds the
template he wants to effect and adds some inline js generating tal
expression that does what he needs, provided a
tal-expression/prototype-primitive exists that handles what he needs.
In the latter an integrator crafts a css-like file where he describes
what effect he want to apply to which element (provided an appropriate
effect exists) and arranges for that css-like file to be loaded by the
page.
Assuming, of course, that appropriate ids and classes exist. For simple
effects, that's quite simple. For more complex behaviour, he may also
need to encode some information into the page (e.g. via the
kukit-name-value magic), which would need to be done with TAL, and then
declare that those get passed to the server-side in the KSS file.
For me, if it does what we need, the latter is a clear winner. And I
guess this is the big question. It seems that the answer at this
point is "mostly", which is a lot better than where we were at the
sprint. Additionally, being tied so closely to Prototype has some
benefits, but it makes us dependent on a huge swath of IMO not so fun
to use, poorly documented, and poorly tested js code. The MochiKit
implementation of scriptaculous (for example) seems to be nearing
completion, and the ability to seemlessly switch to a well documented,
well tested, more "pythonic" framework if and when it provides what we
need would be a big win.
I said "in theory". I won't count this is a real plus unless we've seen
it really doable, practically, but I see no real reason why it couldn't
be done.
For now, I'd still advocate the Prototype route, for the reasons
outlined in the original email.
Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
