Hey,
I don't really have the time to go through all of this at this point in
time. I'll just responded to some bits.
[snip]
> There is two reasons why it is good if kss commands follow the kss
> namespace and not the python namespace.
>
> First, let's consider a command 'plone-followLink'. Now this should
> actually be in its own namespace and depend on python only but let's
> ignore this now.
>
> The 'plone-followLink' action is in the 'plone' kss plugin. The command
> that emits this action from the server is also called 'plone-followLink'.
> The command is bound to the action, it actually provides the access
> interface for it on the python side.
>
> Now in an advantagous solution, this would be accessable from python (from
> a view-like construct that Zope uses) like this:
>
> >>> # ...we are in a view or commandset
> >>> self.commandsets.plone.followLink(href)
>
> (for reference, currently this works like:
>
> >>> # ...we are in a view or commandset
> >>> self.getCommandset('plone').followLink(href)
> )
>
> Let me apply the same pattern you suggest to this case:
>
> >>> # ...we are in a view or commandset
>
> >>> # Import the commandset class directly from
> >>> plone.app.kss.plugins.plone import PloneCommandSet
>
> >>> # Instantiate the commandset
> >>> commandset = CommandSet(self, self.request, self.response)
> >>> self.commandsets.plone.followLink(href)
>
> Ignore the last two lines for a moment since that is the instantiation
> only, and look at the import path. Why is it intuitive to import the
> plugin from "plone.app.kss" (the module that provides the implementation),
> instead of accessing it with its kss plugin name? Especially since we
> _are_ already in a kss view's or another commandset's code.
> It is easy to understand that we also don't want to call the kss action
> itself "plone-app-kss-plugins-plone-followLink", because there is no point
> in following python namespaces from kss stylesheets.
I don't understand why there is no point. If you used the Python
namespace in the stylesheet, people could find their way to the
implementation really easily.
Another reason to make this the same namespace mechanism: you will have
only one of them, not two.
Of course, plone-app-kss-plugins-plone-followLink looks horrible. But
then, plone.app.kss.plugins.plone.followLink *also* looks horrible. I
think I understand some of the reasons:
* plone.app contains plone-the-app-stuff, so just
'plone.kss.plugins.plone.followlink' cannot be used
* you presumably need plone.app.kss for something that is not the
plugins, while plugins is a namespace package.
I have no idea what's the reason for .plugins.*plone*.followLink; what
else gets hooked into plugins here?
Anyway, you can easily flatten this unwieldly namespace into almost
nothing, by making plone.kss.plugins.plone something less lengthy, such
"kss.plone", or "plone.kss", or just 'plonekss'. Then people can type
'plonekss-followLink', or 'kss-plone-followLink'.
In Python, when confronted with long namespaces, besides just flattening
the long nested tree, we have ways to do relative imports. Could a KSS
stylesheet equivalent of relative imports be devised?
In summary, you can't argue against using Python's namespacing mechanism
just because you picked a pretty convoluted namespace in Python in the
first place.
Flat is better than nested.
[snip]
> Second thing that happens often is that I want to move a plugin definition
> from one module to the another. "plone-followLink" will be still
> plone.followLink, even if I move it from plone.app.kss.plugins.plone to
> somewhere else. So now you'd have to change all your python imports in
> every code that uses the plugin. But I agree that the current
> placeless-ness of commandsets, however handy, is not an absolute
> requirement in itself.
Yeah, you don't make this requirement of Python code either. You just
adjust your imports. If you want backwards compatibility for Python
namespaces, there are plenty of well-explored mechanisms to ensure this.
[snip]
> The basic reason why the discussion must be made now, is that kss.base
> will not only support commandsets from the core plugin. It will support
> all commandsets, coming from different plugins. And kss.base will replace
> kss.core, so all current kss application will be based on it. This will
> affect the development model of kss in a global way.
What does it mean to support all the commandsets?
I think the point here is that you can refer to a command in a
commandset from two places, from Python code, or from a KSS stylesheet.
From Python code, you need to import whatever you want to use, and then
pass it the right arguments or instantiate a class or whatever other
mechanism your framework wants.
From KSS code, the problem, I take it, is that the framework will now
need to know what to do. That is, it'll need to know to import, and then
pass 'view' as a parameter, or perhaps instantiate a class and pass
'view' as a parameter and then call a method, or something else. You can
explain this to a Python programmer but to explain it to KSS you'll have
to write some code.
So, the KSS framework needs to be aware of Python framework-specific
ways to call a command. The programmer will need to encode, not just
document, how to call a command, if this command is to be used from the
stylesheet.
So, we are looking at a Python web framework specific policy, which may
want to interfere with the following bits of KSS operation:
* look up a command given a KSS stylesheet command identifier. I am
arguing the default policy in KSS should be that this is done by using
Python namespaces. I can well imagine a framework may want to plug in
there and deviate from this, however.
* actually call the command. We've found the command, but we need to
pass some extra information to it. I think the default of KSS should be
to simply call a function, but a framework could plug into this and
deviate from this.
* determine which framework specific extra arguments get passed to an
actual command
You could allow this some per-module registration machinery. If you
write a framework specific module that wanted to change the parameters
that need to be passed in, I'd write something like:
kss.registerExtraParameters('my.module', getParameters)
and then define a framework specific getParameters that returns a
dictionary with the parameters in question.
By doing it this way, you'd leave it up to the framework to deviate from
the default behavior (thereby encouraging the default behavior), and you
don't need to abstract out over frameworks.
[snip]
> As a result, commandset code and code that uses them will not only be
> significantly different between say plain python, zope and django, but
> even within a specific server implementation there will occur to be
> differences between two plugins.
I'm extremely skeptical about an abstraction over multiple frameworks.
Better give the framework the hook points to interfere with operations,
so they can do what they need, with sensible default out of the box
behavior. The framework authors will try to make the default behavior
work for them first. If that fails, they will look for mechanisms to
inject framework specific behavior without breaking KSS.
Regards,
Martijn
_______________________________________________
Kss-devel mailing list
Kss-devel@codespeak.net
http://codespeak.net/mailman/listinfo/kss-devel
