Hi Martijn and All,
I was reconsidering all possibilities carefully in the
recent period, and I came to the conclusion that we
(or actually, mainly, I) ought to
give way to the needs of the python developers and allow the
access of commandsets in a "more pythonic" and "less
kss-like" way, even if this means we loose advantages of
centralized support.
So according to this, the answer to my original three
questions would be the following:
1. Yes, commandsets (and commands) remain a central concept
in kss.
2. But: No, we do not support any more the implementation of
commandsets in a centralized kss way. It's up to the
server/language implementations how they implement commands at all.
Python (kss.base) implements its own support, other systems
like Zope will need to extend this with additional support.
We attempt to give no guideline on implementing commandsets
in a server side environment (other than, for example Zope
will keep on needing view-like commandsets, so other systems
that also need this, can choose to copypaste this code to
support their own view-like commandsets.)
This is a serious decision for kss, and as I expressed my
opinion several times on this subject, it will result in a
diversity of methods for defining and using commandsets
across different server sides (even zope usage will be
a little different from python one, to start with),
which will make
commandset code less readable for people that do not know
that particular server side well, and it will be more
difficult to document all kss commandsets in a uniform way
(for example, we have to give up including commandsets into
the long planned autogenerated documentation as well). I
consider this a significant loss, but I cannot
figure out any way to satisfy both this requirement and
the raised pythonicity needs, at the same time.
However I have no doubt either that despite this perceived loss,
if we choose this way we will still be able to address
all upcoming problems appropriately.
3. The namespace access issue: The commandsets (and
commands) will be accessed from python exclusively by their
python namespace, which, in return, will not necessarily
correspond to the kss namespace (unless, the implementor
chooses to follow convention). What's more, the commandsets
won't be handled by the kss registry at all.
I believe that if this is the road we are following, then we
also need to settle about a few other actions (or non-actions):
- The kss plugin registry remains placeless as it is
currently (ie. a plugin is not forced to be in any specific module)
(this makes sense for the javascript files anyway).
- but the registry will not handle commandsets at all, so
they will be imported directly from python (old commandset registry
will be kept only for bbb)
- plugin implementors can decide if they keep the
commandsets (the plugin) in a subpackage under their
application package, or follow the convention and move it to
kss.plugin.mynamespace, only in the latter case will the
import path of commands correspond to the kss namespace.
So the definition of plugins remain the same as currently except
we press people to move stuff under kss.plugin.
- to lead the convention we suggest, we have to move the
core plugin out of kss.base, into kss.plugin.core. This
separation is, by the way, useful in
general as well, however results in an extra dependency.
- as a consequence the import paths in the original API proposal
will change like this::
from kss.plugin.core.XXXX import core
- as you see in the previous example (XXXX) we also have to
create a convention for _where_ to place the commandset(s)
inside the plugin module. This would ensure developers
find the commandsets in the same location in each plugin.
(Previously this problem did not exist because we used
registry.) I am not suggesting a particular value for XXXX,
just saying that we need a convention.
- kss.zope will keep its view-based commandsets and to
replace self.getCommandSet() to something similarly convenient
but more clear, it can introduce an ICommandSetGetter (?)
helper for instantiating the view-based
commandsets as well as handle the python-ones in the same
manner, so zope applications will keep on having a convenient
way to issue commands without importing and instantiating them
directly (unless they want) and without the need to
differentiate usage between python and zope commandsets
So basically: commands usage from Zope based systems won't
change significantly although it will also be possible to
use the python level API directly as well.
However this question can be discussed separately from
the main issue, because it will be an autonomous decision
of kss.zope.
As you see this solution almost entirely agrees the original
kss.base commandset API proposal (except in one point, that
the core plugin should move to kss.plugin.core) and satisfies several
points of Martijn's argument. This makes me hope that it can be
found acceptable by all of us.
Best wishes,
--
Balazs Ree
_______________________________________________
Kss-devel mailing list
Kss-devel@codespeak.net
http://codespeak.net/mailman/listinfo/kss-devel
