Brandon Craig Rhodes wrote:
> But, I still think the proposal can be significantly improved. It's
> just ugly to have to pass "self" (or something inside of self) for
> every single command that you call.
An alternative suggestion (from the one you gave) for this problem could
be something like this:
from kss.base import core
from kss.zope import kssaction
class SomeKSSView(KSSView):
@kssaction
def update_something(self, commands):
core.replaceInnerHTML(commands, '#some-node', 'some content')
This avoids the access to self so the syntax is a bit more compact.
> Though I have never, in my
> career, suggested such a thing, I'm going to make a strong suggestion
> that we consider multiple inheritance:
>
> class SomeKSSView(KSSView, jQueryCommands):
> def update_something(self):
>
> # The KSSView itself comes with the "core" commands already
> self.replaceInnerHTML('#some-node', 'some content')
>
> # The jQueryCommands superclass provides some other functions
> self.animate('{scrollTop: targetOffset}', 1000)
>
> return self.render()
>
> I think this would make for far, far clearer code. Right at the top
> of a KSS class, you get to see what command sets it requires (instead
> of having to read the whole way through it). And, those commands can
> be used without having to pass "self" or something inside of "self".
> I think that this achieves all of the goals that I +1'd up above, and
> makes things even cleaner in addition.
Whilst I understand that your approach has merits it also has some
downsides. The first one which comes to mind is that sub-classing
usually implies an is-a relation. In this case SomeKSSView is a KSSView.
SomeKSS is *not* a command set, it just uses a command set.
Next to this conceptual issue you can also run into collisions. What do
you do if both YUI and the jQuery commands provide an `effect` method?
You could of course change the ordering but it would be less obvious at
a glance which one provides it. It can also introduce problems when the
YUI one starts to support the `effect` method where it did not do so before.
Another reason why this might not be practical is that `kss.base` has no
concept of views. This means that this would not work at that basic
plumbing level. We also want to support Django, Pylons, Turbo Gears etc.
which also have different ways of rendering data (instead of using class
based views).
_______________________________________________
Kss-devel mailing list
[email protected]
http://codespeak.net/mailman/listinfo/kss-devel
