Martin Aspeli wrote:
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 the example of inline validation we needed to embed the fieldname in
the html tags, so that we can use one KSS rule to rule them all:
.kssValidateInput:blur {
action-server: kssValidateField;
kssValidateField-fieldname: kssAttr('atfieldname', true);
kssValidateField-value: currentFormVar();
}
Note that this rule applies to both immediate validation of the edit
form *and* that of the inline editing in the view.
For this to work, you need to embed the 'atfieldname' (which is -- you
guessed it -- the Archetypes fieldname). But that has been taken care
of for most of the stock AT widgets already.
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
