[Framework-Team] Re: [AJAX] - Bling vs. KSS round 1

Daniel Nouri daniel.nouri at gmail.com
Thu Sep 21 22:26:42 UTC 2006


Hi!

Martin Aspeli wrote:
> 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. :-(

Ugh.  Balasz, can you verify?

>>>> - 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).

Ah now I know what you mean.

>> 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?

An example is the testReplaceContentRegion function, which does the
switching of tabs (edit, view etc.).  The result of the call
view.replaceContentRegion is a dict, which you can conveniently test
for:
http://dev.plone.org/collective/browser/ploneazax/PloneAzax/trunk/tests/test_menus.py#L60

> 
>> 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 may be wrong, but I think this is well doable.  Using the
BlingEditor implementation would certainly be another nice proof of
concept of KSS's flexibility.

>> 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.

I totally agree.  The template customizations should go into Plone
proper (because they *are* small), but KSS shouldn't be installed per
default.  Too many glitches (albeit small ones) in the UI.

>> - 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.

Right.  I expect that until Plone 3.5, we'll have a more modular
approach for this.  plone.portlets is certainly a step into this
direction.

>> - 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?

F.e. the JavaScript that handles collapsible areas like the content
history needs to work in such a way that it operates on a subtree of
the document DOM, instead of looking at the whole tree.  When you
replace parts of the DOM (like KSS does), you want the JavaScript to
only work on the replaced part.  But maybe this is less work than I
imagine.

Daniel





More information about the Framework-Team mailing list