Hi Daniel
From Saturday to Tuesday, I attended 4 days of presentation, discussion
and hands-on experience with KSS. First of all, thanks to Godefroid for
hosting a very nice sprint and to the whole team for the good time I had!
I want to share some experiences with the framework team and bring in
some new perspectives for this discussion.
This is very, very useful! :)
A couple of responses to some finer points.
My feeling is that kukit is quite flexible, even if it might have a
rough spot here and there. Maybe registering of plugins can become a
bit easier still. I also dislike the class value hacks, i.e.
"kukit-key-value" as a class versus kukit:key="value" as an attribute.
But as Martin points out in this thread, you can just use the second
approach if you're not paranoid about (transitional?) HTML compliance.
I believe Balazs said IE (surprise) has problems with the XML attribute
version, too. :-(
- Azax is a Zope 2 and/or 3 library that can talk to kukit. It
provides a view base class (AzaxView, which extends BrowserView) that
makes it easier to construct kukit commands for sending back to the
client, as well as handling things like the registration of
appropriate browser resources.
Handling registration of browser resources? I haven't seen that in a
view.
This is a ZCML directive for aggregating multiple stylesheets into a
single Z3 browser resource, so ++resource++kukit.js is actually pulling
in all kinds of smaller files, kinda like what RR does but at a lower
level (and more general).
The view code is generally very close to Ben's PJS.
That's not expressly true, since PJS is about proxies, so if your client
side JS can handle (or is extended to handle) method foo() you can use
foo() on a PJS proxy straight away. In KSS, you'd probably write a
server side named command adapter with new custom behaviour. But it's
true that the resultant syntax in most cases is quite easy to read and
natural.
The output
is not JavaScript however, but commands for the client to process. The
idea being that an abstraction of JavaScript is easier to test than
actual JavaScript code (which will require hacks here and there).
Probably. Do we have any tests that test the actual results in the wild?
Note that defining your own client actions is seldomly needed. There
are a few powerful primitives available, like "set attribute of node
element", or "replace childnodes". This is most of what you'll need for
your everyday work.
That was my feeling too. If people have use cases they think cannot be
handled this way, it'd be good to hear about them. Most of the ones I
can think of would be solved quite well with this basic functionality
plus some abstractions of effects (esp. common Plone-standard effects
with different semantic meanings, like a 'highlight' that always looks
the same).
What about refreshing the breadcrumbs when you change title? Or the
navigation portlet? What about changing the state of an object
without reload, or copy? Is there a list of what Bling does (when it's
fixed)?
I'm unsure but I don't think so.
As much as I agree that inline editing of the WYSIWYG editor is really
nice to have I don't see why it's particularly difficult to implement.
Probably because kupu is complicated. The BlingEditor, based on TinyMCE
*ought* to be reusable, and I know Ben spent a fair amount of time on it.
I realize the rich-text editor seems to be a real priority for you.
I'm pretty sure though that the KSS people can implement this.
It's a priority mostly because I think it's complex and thus not
something to leave to the last minute. I have a gut feeling that if
anything is going to uncover major problems, this is it. :)
I suggest that we ship KSS with Plone 3.0, but not install it per
default. Why? Because the step is too big. There's still lots of work
to be done (on the Plone front), to make the templates really ajaxyfiable.
Interesting position. I have a feeling we may drift in a direction where
that's not a viable option, although I really agree that Plone must work
with Azax uninstalled/disabled.
What I would say is that we shouldn't rely on template customisations in
PloneAzax and ATAzax. This will quickly become a maintenance nightmare.
If changes truly are about ids and CSS classes only and are
non-intrusive, then that should be fine.
- We need a general way of saying which UI components (e.g. portlets)
need a refresh after a certain change. I imagine that these
components (=viewlets in the future) will register for events (e.g.
ObjectModified) and request that they are redrawn.
Azax could certainly fire event or have generic handlers, like a
IRefreshPortletEvent or some such. Some of that kind of generic-ness may
wait till later, though.
- Much of Plone's JavaScript needs to be refactored so that it can
operate on a single node, instead of on the whole document on load.
Why? Can you elaborate?
Thanks again - this kind of experience is exactly what we need! :)
Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
