From mymir.org at googlemail.com  Thu May  1 15:36:49 2008
From: mymir.org at googlemail.com (Vladislav Vorobiev)
Date: Thu, 1 May 2008 17:36:49 +0400
Subject: [Kss-devel] form and kssattr in request
Message-ID: <604c02230805010636w297265d8sb2ed3a6a79a9ace1@mail.gmail.com>

Hi,

I hope this list is right for my concern.

I try to send parameter from "form" *and* kssattr.

Something like this:

<form>
<input name="bla' value="bla" />
<div class="inlineEdit kssattr-inputId-email">blabla</div>
</form>

My kss:

.inlineEdit:click {
action-server: inlineEdit;
inlineEdit-value: currentFormVar(value);
inlineEdit-inputId: kssAttr(inputId);
}

It does not work. inlineEdit script get only inputId in the request.
It need form variables too.

Any Ideas? How I can do this?

-- 
Best Regards
Vlad Vorobiev

From gotcha at bubblenet.be  Fri May  2 10:19:50 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Fri, 02 May 2008 10:19:50 +0200
Subject: [Kss-devel] form and kssattr in request
In-Reply-To: <604c02230805010636w297265d8sb2ed3a6a79a9ace1@mail.gmail.com>
References: <604c02230805010636w297265d8sb2ed3a6a79a9ace1@mail.gmail.com>
Message-ID: <481ACEA6.3020506@bubblenet.be>

Vladislav Vorobiev wrote:
> Hi,
> 
> I hope this list is right for my concern.
> 
> I try to send parameter from "form" *and* kssattr.
> 
> Something like this:
> 
> <form>
> <input name="bla' value="bla" />
> <div class="inlineEdit kssattr-inputId-email">blabla</div>
> </form>
> 
> My kss:
> 
> .inlineEdit:click {
> action-server: inlineEdit;
> inlineEdit-value: currentFormVar(value);
> inlineEdit-inputId: kssAttr(inputId);
> }
> 
> It does not work. inlineEdit script get only inputId in the request.
> It need form variables too.
> 
> Any Ideas? How I can do this?
> 

This should be :

.inlineEdit:click {
     action-server: inlineEdit;
     inlineEdit-value: currentFormVar(bla);
     inlineEdit-inputId: kssAttr(inputId);
}

because the argument to currentFormVar value provider is the input "name"

HTH
-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

From jeroen.vloothuis at pareto.nl  Fri May  2 12:44:51 2008
From: jeroen.vloothuis at pareto.nl (Jeroen Vloothuis)
Date: Fri, 02 May 2008 12:44:51 +0200
Subject: [Kss-devel] API proposal
Message-ID: <481AF0A3.3070302@pareto.nl>

At the Grokkerdam sprint Godefroid, Martijn Faassen and I had a 
discussion about the current KSS API. The example below shows how we 
currently use it (in `kss.core`):

class SomeKSSView(KSSView):
    def update_something(self):
        core = self.getCommandSet('core')
        core.replaceInnerHTML('#some-node', 'some content')
        return self.render()

Behind the scenes this uses a named adapter lookup to get a command set. 
Martijn does not like this since it is not clear where the code is 
implemented (because of the lookup based on a string). To make this 
better Martijn and I came to this proposal:

from kss.base import core

class SomeKSSView(KSSView):
    def update_something(self):
        core.replaceInnerHTML(self.commands, '#some-node', 'some content')
        return self.render()

This makes it explicit where the code is implemented (see the import). 
Advantages of this proposal are that it would both work with a pure 
Python implementation (for kss.base) and makes the system a bit simpler 
(conceptually). The `core` name would be implemented in `kss.base` as a 
module where `replaceInnerHTML` is a function, something like this:

def replaceInnerHTML(commands, selector, value):
    """Replace the contents of a node (selector) with the new `value`"""
        commands.add('replaceInnerHTML', selector, html=htmldata(value))


This change will only affect the clients of `kss.base`.

From christophe.bosse at ingeniweb.com  Fri May  2 13:19:57 2008
From: christophe.bosse at ingeniweb.com (Christophe Bosse)
Date: Fri, 2 May 2008 13:19:57 +0200
Subject: [Kss-devel] Bug in kukit.dom.parseHTMLNodes
Message-ID: <f435c32e0805020419sb8eb70di84c82e39f785fd2a@mail.gmail.com>

I've found a bug while using replaceHTML kss command.
The deal here is to create a DIV element to let the browser engine to parse
HTML code. The problem is that in gecko browser (maybe others too) when
adding a node requiring a special parent node (LI, TR, TD, DT, DD etc...) it
will skip those nodes because the DIV  element does not fit in this case.

Here's my dirty quick patch:

var restrictedParentNodes = {
    'th': 'thead',
    'td': 'tr',
    'tr': 'table',
    'thead': 'table',
    'tbody': 'table',
    'tfoot': 'table',
    'li': 'ul',
    'dt': 'dl',
    'dd': 'dl',
    'option': 'select',
    'optgroup': 'select',
};
kukit.dom.parseHTMLNodes = function(txt){
    var firstNode = /<([^> ]*)[> ]/.exec(txt);
    firstNode = firstNode ? firstNode[1] : null;
    var node = document.createElement(restrictedParentNodes[firstNode] ||
'div');
    node.innerHTML = txt;
     console.log(node.firstChild);
    // gecko engine automatically adds a TBODY node
    if (node.firstChild) {
        if (node.firstChild.nodeType == 3)
            node.removeChild(node.firstChild);
        if (node.firstChild.nodeName == 'TBODY')
            node = node.firstChild;
    }
    var resultNodes = [];
    for (var i=0; i<node.childNodes.length; i++) {
        resultNodes.push(node.childNodes.item(i));
    }
    return resultNodes;
};
-- 
Christophe BOSSE - D?veloppeur
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royal - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01 78 15 24 02 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/kss-devel/attachments/20080502/b7818521/attachment-0001.htm 

From brandon at rhodesmill.org  Fri May  2 15:07:11 2008
From: brandon at rhodesmill.org (Brandon Craig Rhodes)
Date: Fri, 02 May 2008 09:07:11 -0400
Subject: [Kss-devel] API proposal
References: <481AF0A3.3070302@pareto.nl>
Message-ID: <87myn8svls.fsf@ten22.rhodesmill.org>

Jeroen Vloothuis <jeroen.vloothuis at pareto.nl> writes:

> To make this better Martijn and I came to this proposal:
>
> from kss.base import core
>
> class SomeKSSView(KSSView):
>     def update_something(self):
>         core.replaceInnerHTML(self.commands, '#some-node', 'some content')
>         return self.render()
>
> This makes it explicit where the code is implemented (see the import).

+1

> it would both work with a pure Python implementation (for kss.base)

+1

> and makes the system a bit simpler (conceptually).

+1

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

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon


From jeroen.vloothuis at xs4all.nl  Fri May  2 16:52:07 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Fri, 02 May 2008 16:52:07 +0200
Subject: [Kss-devel] API proposal
In-Reply-To: <87myn8svls.fsf@ten22.rhodesmill.org>
References: <481AF0A3.3070302@pareto.nl> <87myn8svls.fsf@ten22.rhodesmill.org>
Message-ID: <481B2A97.1000007@xs4all.nl>

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




From ree at ree.hu  Sat May  3 10:40:38 2008
From: ree at ree.hu (Balazs Ree)
Date: Sat, 3 May 2008 10:40:38 +0200
Subject: [Kss-devel] API proposal
References: <481AF0A3.3070302@pareto.nl>
Message-ID: <pan.2008.05.03.08.41.01@ree.hu>


On Fri, 02 May 2008 12:44:51 +0200, Jeroen Vloothuis wrote:

> At the Grokkerdam sprint Godefroid, Martijn Faassen and I had a
> discussion about the current KSS API. The example below shows how we
> currently use it (in `kss.core`):
> 
> class SomeKSSView(KSSView):
>     def update_something(self):
>         core = self.getCommandSet('core')
>         core.replaceInnerHTML('#some-node', 'some content') return
>         self.render()
> 
> Behind the scenes this uses a named adapter lookup to get a command set.
> Martijn does not like this since it is not clear where the code is
> implemented (because of the lookup based on a string). To make this
> better Martijn and I came to this proposal:
> 
> from kss.base import core
> 
> class SomeKSSView(KSSView):
>     def update_something(self):
>         core.replaceInnerHTML(self.commands, '#some-node', 'some
>         content') return self.render()
> 
> This makes it explicit where the code is implemented (see the import).
> Advantages of this proposal are that it would both work with a pure
> Python implementation (for kss.base) and makes the system a bit simpler
> (conceptually). 

First, I would like to understand why the change is proposed to the 
original proposal we followed with Jeroen in the working code
of kss.base and kss.zope. Since I am not present on the sprint, for me
the most important would be to understand the motivation.

To bring the discussion into context with the current solution (not the 
one in kss.core but the one we worked out in kss.zope / kss.base), I would
summarize it briefly and tell a bit of history too. Most of this was
discussed and implemented by me and Jeroen in last November in kss.zope 
code.

To state the general problem
-----------------------------

One general problem we realized when creating the kss.base / kss.zope
implementation is that the commandsets on Zope need to access to the
"commands" which are stored on the view. They also need to access
request and context. So in Zope the commandset adapts on the view or on 
the commandset it is called from. However in plain python all this is not
needed, there is hard to speak about the view or request even,
except the commandset still needs to access commands, but we
cannot use the "view" pattern we had till know, without the change.

The way Jeroen implemented the commandsets in kss.base first,
mainly considers the actual commandsets that are in the core, and
simplify these cases. However we have more complex usage needs in zope
and plone that the previous version supported. With the way the
kss.base handles the commandsets, 
- we cannot support our current needs with Zope and Plone, 
- but we also don't want different type of commandsets in python, Zope, 
and server X, 
so we were trying to find a way to fulfill both simplicity in the
plain python implementation, and support sophiscticated needs of
server frameworks, while having a unified commandset model. In addition 
we need to stay open for other, including non-pythonic implementations: 
we have these needs in Zope but we have no reason to assume that another 
server side framework will now raise its own specific needs which will 
even be different from that of Zope.

My proposal (also discussed and agreed with Jeroen previously) to attack 
this problem is "Implementation dependent adaptation of commandset". Let' 
make a rule: commandsets are identical in every server side 
implementation except that we allow the commandset (which
is always an adapter then) to adapt to different objects in different
implementations. For example in Zope the commandset as currently adapts
on  [context, request, view]. In python, the core commandset could
just adapt on [commands]. Besides this no differences are allowed.

To implement this every implementation must provide the actual way of
instantiation (adaptation) of the commandset, using whatever objects
it needs to adapt it on for the constructor. This is possible to
implement (needs to be implemented once per server framework), and if 
every view and commandset has the commodity view.getCommandSet() then in 
the end the usage is totally independent from the commandset's 
implementation and what it's adapting to.

This was on plain python the commandset would look like:

>>> class CommandSet(object):
...    def __init__(self, commands)
...        self.commands = commands)
  
>>> class someCommandSet(object):    
...     def replaceInnerHTML(self, selector, value):
...         """Replace the contents of a node (selector) with the new 
`value`"""
...            self.commands.add('replaceInnerHTML', selector, 
html=htmldata(value))

and it can be called like

>>>  commandset.getCommandSet('core').replaceInnerHTML(selector, html)

or directly:

...  getCommandSet('core')(commands).replaceInnerHTML(selector, html)

Zope commandsets would be different from python, and same as now (only
this example only adapts on the view since it's actually enough, no
need to differentiate on context or request):

>>>  class ZopeCommandSet(object):
...     def __init__(self, view)
...        self.view = view
...        self.request = view.request
...        self.response = view.response
...        self.commands = view.commands
...
...    def refreshPortlet(self, ...)
...        something = accessed_from(self.request, self.response)
...        self.issue_the_commands()    # can call directly from the
...                                     # same commandset

And they would be called like:

>>>  view.getCommandSet('core').replaceInnerHTML(selector, html)
>>>  commandset.getCommandSet('core').replaceInnerHTML(selector, html)

The implementation of the getCommandSets would be easy because for
example the python commandset need not know to instantiate a zope
commandset, only the other way around (ie. you cannot use zope
commandsets if you are not in zope, or call a zope commandset from a
plain python commandset). 

Iw would be important for me to understand what problems you identify
with this proposal? If it is only the inconvenience of getCommandSet() 
with the string in it, then we need to address this and I will return to 
this a few lines below.

Following I would like to emphasize two important issues:


1. KSS plugins have no global import, is Good
---------------------------------------------

In other words, since no code imports from the plugins directly, the 
plugins are agnostic of where they are included from. (In kss.core we use 
zcml for this, in kss.base we use setuptools and entry_points to locate 
the plugins, but the principle of registration is similar.)
This makes it easy to change the location of plugins, redistribute
them with one component or another to build a website. As often a plugin 
comes with a specific widget implementation, this is a big advantage. The 
already have a registry andso its location is known. The proposal in 
discussion basically suggests: let's strip this registry code for 
commandsets and access the commandsets as ordinary python code.

It is of course arguable: should not commandsets be accessed more 
pythonically as proposed in the thread? So let's argue about this, 
because in general I don't mind to be more pythonic, but in this case I 
am against loosing the import independance, and allow to decouple the 
commandsets from the kss registry, thus loosing all advantage of 
registration (like portability and platform independence).

I would like to add that (unlike Martijn said) the commandset's name
is not "just a string". It is a fully dashed global identifier of the
commandset (Example plone-issuePortalMessage, but we will support
multilevel namespaces my-fancy-app-command any moment): 
this is as much of an identifier for kss as the imports in python.
And thus identifies the module from point of view of kss (the concept), 
and not from point of view of python (the implementation). Imo this 
is good, because commandsets belong much more to the plugin itself,
then to the python server side and they can be used uniformly
everywhere where kss is. The slight separation from python land also
helps to understand to the reader of the code that executes is a
registered part of a kss plugin - much more important then to see
which python module it's importing from.

Also, the server side is python in our case but it could be anything
else and we would like to provide something that is manageable in
every implementation environment (while being very pythonic here
would mean giving no guideline for a generic implementation.)

Which means a view.getCommandSet(name) is not a large price for this.

We may think, however, other ways to make the syntax usage sweeter, if 
the view.getCommandSet() is the biggest annoyance in the
story. The view.getCommandSet can be removed and instead we can provide a 
kss import namespace like

>>> from kss.commandsets import Core
>>> from kss.commandsets import Zope

>>> Core(commands).replaceHTML

where the actual modules could be anywhere physically, and loaded to
this location from their original place initially. But even then: these 
are classes so you would need to instantiate the commandsets, which is 
why the view.getCommandSet comes handy. But instead of the getCommandSet 
method, it would also be possible to also provide the namespace on the 
view:

>>> view.commandsets.core.replaceHTML
>>> commandset.commandsets.core.replaceHTML

where view.commandsets.core would actually give an instantiated
commandset already. Note that disturbingly "Core" above was the 
commandset class, and "core" is already the instance in the last two 
lines, this is why I changed the first letter to uppercase.

Of course this would not work with "my-fancy-app-command", but then
nothing keeps us away to do view.commandsets.my.fancy.app.command instead.

2. Zope commandsets do need to access the view
----------------------------------------------

A commandset does not only execute a simple data dump with no other
sources then the parameters it receives, as it is in the case
of the core commandset. In complex kss applications in Zope we use
commandsets that access the request and response, call up and execute
other command sets. This allows the decomposition of bigger task into
elementary kss operation, iow, no need to build everything in the
client.

For example, the plone-issuePortalMessage command needs to access not
only to commands, but also to the content and the request. This could
not be handled sanely in the plain-python way, unless an arbitrary
number of parameters were passed to the actual command implementations
which would be insane. However with the "commandset as adapter"
pattern, this is easy since the implementation-dependent parameters
are all hidden. (In addition every other system may also want to
implement its own
issuePortalMessage.)

Another example is saveField that is used for inline editing and needs
to access the context object as well as the request.


To summarize
------------

If the proposal in the thread becomes the supported way of API for 
commandsets, first we loose import location independence, then we also 
won't be able to support existing commandsets code this way. As a result 
all the code that cannot be supported and inevitably will be implemented 
out of scope from kss (= differently from the supported way), which means 
loosing the advantage of platform independence and portability.

At the same time I feel that the "commandset adaptation" pattern would 
allow to keep best of all worlds, and it would not limit the
implementations. It may not be the most perfect option either so it's
essential to understand for me to get your reactions on the issue.





-- 
Balazs Ree


From faassen at startifact.com  Sat May  3 13:51:15 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Sat, 03 May 2008 13:51:15 +0200
Subject: [Kss-devel] API proposal
In-Reply-To: <pan.2008.05.03.08.41.01@ree.hu>
References: <481AF0A3.3070302@pareto.nl> <pan.2008.05.03.08.41.01@ree.hu>
Message-ID: <fvhjjj$5p8$1@ger.gmane.org>

Balazs Ree wrote:
[snip]
> The way Jeroen implemented the commandsets in kss.base first,
> mainly considers the actual commandsets that are in the core, and
> simplify these cases. However we have more complex usage needs in zope
> and plone that the previous version supported. With the way the
> kss.base handles the commandsets, 
> - we cannot support our current needs with Zope and Plone, 
> - but we also don't want different type of commandsets in python, Zope, 
> and server X, 

I disagree with the second requirement. Why *do* you want the same type 
of commandset for all these servers? What's the point? I can't reuse the 
commandset that I write for a Zope app in server X anyway, right? Any 
resuable bits that do exist I can factor out into independent libraries.

I think that anything that relies on kss.base only should only have to 
deal with commandsets that are as close to straightforward Python 
possible, which means a module with functions in it. Or a module with an 
instance of a class in it (where the methods are the commands), if you 
need to be able to parameterize commandsets for some reason (in specific 
cases). The great advantage of this is that when people follow the 
import trail (something all Python programmers can do), they can find 
the implementation. Any registry-based approach breaks this.

Some commandsets may implement the same abstract interface. You can then 
look up the one relevant in your particular application. I'm somewhat 
skeptical of this requirement myself, as I've only heard the 'different 
effects libraries' examples so far, which doesn't convince me. How many 
of these protocols are there right now in the real world? Do they 
actually have multiple implementations?

Anyway, putting aside this skepticism, let's imagine we have an effects 
commandset and there's a reimplementation of this (the example I keep 
hearing about). I want to use this other implementation in my 
application. So I change the import. This is straightforward and 
something that Python programmers understand. It's not like I don't need 
to test my application with this new effects library anyway.

The word 'commandset' may be able to go away. Instead people can use the 
familiar concept of a "python module".

Now you could envisage a general framework that helps you get an 
implementation of a commandset interface dynamically, based on some 
configuration setting and pulling it from a registry. Zope 3 has such a 
story for registration (the component architecture). So when *I* need 
this, I'll use zope.component. kss.zope could offer some approach that 
uses this. Other systems have different stories for this, or will grow 
ad-hoc stories for this.

I want the Zope 3 story to look like the Zope 3 story, and the other 
frameworks will have to be on their own. Perhaps eventually something 
like kss.registry might grow if some of these frameworks want to reuse 
the same registry after they gain some experience with this and it turns 
out to be an important requirement. I doubt a Zope 3 application will 
want to use this, as one of Zope 3's strongest points is its powerful 
configuration story.

> 1. KSS plugins have no global import, is Good

This is not good in the lowest layer. The lowest layer should be simple 
to understand for a Python programmer. If you want this kind of stuff, 
please use the Zope 3 component architecture, which was born to do this 
kind of thing and is at least something you don't need to reinvent.

 > but in this case I
> am against loosing the import independance, and allow to decouple the 
> commandsets from the kss registry, thus loosing all advantage of 
> registration (like portability and platform independence).

If a developer wants import independence for a particular command set, 
please tell the developers to write a Python module that does this:

def get_right_module():
     if some_configuration():
          import foo
          return foo
     else:
          import bar
          return bar

and use 'get_right_module'.

An arbitrary Python developer will be able to come up with this 
themselves. I won't come up with this but will use the component 
architecture when I need this, and this offers more pluggability. Many 
python developers don't want to know about such things as they don't 
*need* it. Don't bother them with this. Point them to zope.component if 
they do need it, or let them invent their own approach. They do this anyway.

> I would like to add that (unlike Martijn said) the commandset's name
> is not "just a string". It is a fully dashed global identifier of the
> commandset (Example plone-issuePortalMessage, but we will support
> multilevel namespaces my-fancy-app-command any moment):

(I'm not sure why I am said to have said this)

Why invent your own namespace construct when Python already has one?

>  The slight separation from python land also
> helps to understand to the reader of the code that executes is a
> registered part of a kss plugin - much more important then to see
> which python module it's importing from.

I assume that if you import KSS commands from a module, you already know 
you're dealing with KSS here. Use a global 'kssplugin' namespace that 
peopple can use their KSS plugins under if you're concerned with this, 
just like Zope uses 'zope'. Don't enforce that (Zope doesn't).

[snip]
> We may think, however, other ways to make the syntax usage sweeter, if 
> the view.getCommandSet() is the biggest annoyance in the
> story. The view.getCommandSet can be removed and instead we can provide a 
> kss import namespace like

To me, it's not just the syntax. It's mostly the semantics. It that it's 
an unnecessary abstraction at this level, that hinders the ability of a 
Python programmer to find things. If you used modules, a developer can 
find a module and then have an immediate idea of how you can use it (you 
don't need to know how it's registered, you can import it). If you see a 
module in use, you can go and find the module as you know its dotted name.

[snip]
> 2. Zope commandsets do need to access the view

I'll rephrase this: a Zope specific command will need access to the Zope 
view.

You can pass in the view as a parameter, or you could implement your 
Zope-specific set of commands as a class that takes the view as the 
argument. That's up to the developer. I disagree with tying this to the 
kss.base discussion, as I don't agree with the basic requirement that 
requires this.

Commands are much like functions or methods. I think you shouldn't 
require people to have to make a choice between implementing their own 
commands as functions, or methods, in the core of your framework.

[snip]
> For example, the plone-issuePortalMessage command needs to access not
> only to commands, but also to the content and the request. This could
> not be handled sanely in the plain-python way, unless an arbitrary
> number of parameters were passed to the actual command implementations
> which would be insane. 

I probably don't understand something here, but why can't the *Zope 
specific commands* get these extra parameters, while the underlying core 
commands on top of which you're building them don't? Is this again a 
result of the requirement that commandsets look the same for all Python 
frameworks?

> However with the "commandset as adapter"
> pattern, this is easy since the implementation-dependent parameters
> are all hidden. (In addition every other system may also want to
> implement its own
> issuePortalMessage.)

If you want to use adapters, please use zope.component. I don't want to 
use a reimplementation of zope.component. I also don't think Python 
programmers in general are looking for this.

[snip]
> If the proposal in the thread becomes the supported way of API for 
> commandsets, first we loose import location independence, 

Location independence doesn't belong in the core. Python has location 
dependence, so there's no requirement to get rid of this dependence in a 
general Python library.

> then we also 
> won't be able to support existing commandsets code this way. 

That's only because of the requirement you want commands to look like 
each other in different frameworks, while still supporting the different 
requirements of each framework. You're essentially looking to abstract 
over different frameworks, and that's a very risky business. Commands 
already look like each other as they look like Python functions, and 
sets of commands are like modules or classes. The universal way to plug 
into any framework is by writing an actual library.

> As a result 
> all the code that cannot be supported and inevitably will be implemented 
> out of scope from kss (= differently from the supported way), which means 
> loosing the advantage of platform independence and portability.

Platform independence for Zope specific code dealing with Zope views, 
contexts and requests?

> At the same time I feel that the "commandset adaptation" pattern would 
> allow to keep best of all worlds, and it would not limit the
> implementations. It may not be the most perfect option either so it's
> essential to understand for me to get your reactions on the issue.

I think it is limiting implementations and makes KSS harder to 
understand for Python programmers. I myself am familiar with adaptation 
but I already am committed to the use of zope.component.

Regards,

Martijn


From gotcha at bubblenet.be  Sat May  3 18:09:20 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Sat, 03 May 2008 18:09:20 +0200
Subject: [Kss-devel] form and kssattr in request
In-Reply-To: <604c02230805020328m1a124d74nb7ac8e7ed5470abb@mail.gmail.com>
References: <604c02230805010636w297265d8sb2ed3a6a79a9ace1@mail.gmail.com>	<481ACEA6.3020506@bubblenet.be>
	<604c02230805020328m1a124d74nb7ac8e7ed5470abb@mail.gmail.com>
Message-ID: <481C8E30.3000602@bubblenet.be>

Vladislav Vorobiev wrote:
> 2008/5/2 Godefroid Chapelle <gotcha at bubblenet.be>:
>> Vladislav Vorobiev wrote:
>>
>>> Hi,
>>>
>>> I hope this list is right for my concern.
>>>
>>> I try to send parameter from "form" *and* kssattr.
>>>
>>> Something like this:
>>>
>>> <form>
>>> <input name="bla' value="bla" />
>>> <div class="inlineEdit kssattr-inputId-email">blabla</div>
>>> </form>
>>>
>>> My kss:
>>>
>>> .inlineEdit:click {
>>> action-server: inlineEdit;
>>> inlineEdit-value: currentFormVar(value);
>>> inlineEdit-inputId: kssAttr(inputId);
>>> }
>>>
>>> It does not work. inlineEdit script get only inputId in the request.
>>> It need form variables too.
>>>
>>> Any Ideas? How I can do this?
>>>
>>>
>>  This should be :
>>
>>
>>  .inlineEdit:click {
>>     action-server: inlineEdit;
>>     inlineEdit-value: currentFormVar(bla);
>>     inlineEdit-inputId: kssAttr(inputId);
>>  }
>>
>>  because the argument to currentFormVar value provider is the input "name"
>>
> 
> Hi,
> Thanks but it is not quite the thing.
> I need to stick to to form-variables my variable inputId.

I do not understand what you mean here...

I suspect there is a language issue.

Can you try to explain better ?

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

From mymir.org at googlemail.com  Fri May  2 12:29:31 2008
From: mymir.org at googlemail.com (Vladislav Vorobiev)
Date: Fri, 2 May 2008 14:29:31 +0400
Subject: [Kss-devel] form and kssattr in request
In-Reply-To: <481ACEA6.3020506@bubblenet.be>
References: <604c02230805010636w297265d8sb2ed3a6a79a9ace1@mail.gmail.com>
	<481ACEA6.3020506@bubblenet.be>
Message-ID: <604c02230805020329x43cb0055h78b205143155da82@mail.gmail.com>

2008/5/2 Godefroid Chapelle <gotcha at bubblenet.be>:
>
> Vladislav Vorobiev wrote:
>
> > Hi,
> >
> > I hope this list is right for my concern.
> >
> > I try to send parameter from "form" *and* kssattr.
> >
> > Something like this:
> >
> > <form>
> > <input name="bla' value="bla" />
> > <div class="inlineEdit kssattr-inputId-email">blabla</div>
> > </form>
> >
> > My kss:
> >
> > .inlineEdit:click {
> > action-server: inlineEdit;
> > inlineEdit-value: currentFormVar(value);
> > inlineEdit-inputId: kssAttr(inputId);
> > }
> >
> > It does not work. inlineEdit script get only inputId in the request.
> > It need form variables too.
> >
> > Any Ideas? How I can do this?
> >
> >
>
>  This should be :
>
>
>  .inlineEdit:click {
>     action-server: inlineEdit;
>     inlineEdit-value: currentFormVar(bla);
>     inlineEdit-inputId: kssAttr(inputId);
>  }
>
>  because the argument to currentFormVar value provider is the input "name"
>

Hi,
Thanks but it is not quite the thing.
I need to stick to to form-variables my variable inputId.
--
Best Regards
Vlad Vorobiev

From jeroen.vloothuis at xs4all.nl  Fri May  2 16:52:07 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Fri, 02 May 2008 16:52:07 +0200
Subject: [Kss-devel] API proposal
In-Reply-To: <87myn8svls.fsf@ten22.rhodesmill.org>
References: <481AF0A3.3070302@pareto.nl> <87myn8svls.fsf@ten22.rhodesmill.org>
Message-ID: <481B2A97.1000007@xs4all.nl>



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





From gotcha at bubblenet.be  Mon May  5 17:41:33 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Mon, 05 May 2008 17:41:33 +0200
Subject: [Kss-devel] form and kssattr in request
In-Reply-To: <604c02230805050805r4ff8cecbudd6fd2acce7a43d2@mail.gmail.com>
References: <604c02230805010636w297265d8sb2ed3a6a79a9ace1@mail.gmail.com>	<481ACEA6.3020506@bubblenet.be>	<604c02230805020328m1a124d74nb7ac8e7ed5470abb@mail.gmail.com>	<481C8E30.3000602@bubblenet.be>
	<604c02230805050805r4ff8cecbudd6fd2acce7a43d2@mail.gmail.com>
Message-ID: <481F2AAD.3060509@bubblenet.be>

Vladislav Vorobiev wrote:

> 
> Hi,
> try to explain it better...
> 
> I have to send a form to my ServerScript

Could you show an example of your server side method ?
like :

def inlineEdit(s....):

that might help to uderstand...

> Something like this:
> 
>  <form>
>  <input name="bla' value="bla" /> <input name="bla2' value="bla"
> /><input name="bla3' value="bla" /> ect?
> <div class="inlineEdit kssattr-inputId-email">blabla</div>
> <div class="inlineEdit kssattr-inputId-tel">blabla</div>
> <div class="inlineEdit kssattr-inputId-post">blabla</div>
> </form>
> 
> My kss for this statement looks like this.
> 
> .inlineEdit:click {
> action-server: inlineEdit;
>  inlineEdit-value: currentFormVar(value);
>  inlineEdit-inputId: kssAttr(inputId);
> }
> 
> This is all I can send  :currentFormVar(value) or kssAttr(inputId).

There are other value providers :

look at

http://codespeak.net/svn/kukit/docs/introducing_kss/trunk/3-shipped-kss-plugins.txt

and search for parameter providers (they have been renamed value 
providers since then).
> 
> I want add more variables to my form respectively REQUEST.
> 
> The nominee construction is probably works, but it's not realy what I
> want. The thing is I have to make kss statement for every different
> forms on my site. It would be more dynamically if I'm able to attach
> kssattr on my form.
> 
> Hope you got it.)
> 
> Exuse me for my English
> 

We all do our best...

> Vlad

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

From gotcha at bubblenet.be  Mon May  5 20:05:28 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Mon, 05 May 2008 20:05:28 +0200
Subject: [Kss-devel] Bug in kukit.dom.parseHTMLNodes
In-Reply-To: <f435c32e0805020419sb8eb70di84c82e39f785fd2a@mail.gmail.com>
References: <f435c32e0805020419sb8eb70di84c82e39f785fd2a@mail.gmail.com>
Message-ID: <fvni98$4vb$1@ger.gmane.org>

Christophe Bosse wrote:
> I've found a bug while using replaceHTML kss command.
> The deal here is to create a DIV element to let the browser engine to 
> parse HTML code. The problem is that in gecko browser (maybe others too) 
> when adding a node requiring a special parent node (LI, TR, TD, DT, DD 
> etc...) it will skip those nodes because the DIV  element does not fit 
> in this case.
> 
> Here's my dirty quick patch:
> 
> var restrictedParentNodes = {
>     'th': 'thead',
>     'td': 'tr',
>     'tr': 'table',
>     'thead': 'table',
>     'tbody': 'table',
>     'tfoot': 'table',
>     'li': 'ul',
>     'dt': 'dl',
>     'dd': 'dl',
>     'option': 'select',
>     'optgroup': 'select',
> };
> kukit.dom.parseHTMLNodes = function(txt){
>     var firstNode = /<([^> ]*)[> ]/.exec(txt);
>     firstNode = firstNode ? firstNode[1] : null;
>     var node = document.createElement(restrictedParentNodes[firstNode] 
> || 'div');
>     node.innerHTML = txt;
>      console.log(node.firstChild);
>     // gecko engine automatically adds a TBODY node
>     if (node.firstChild) {
>         if (node.firstChild.nodeType == 3)
>             node.removeChild(node.firstChild);
>         if (node.firstChild.nodeName == 'TBODY')
>             node = node.firstChild;
>     }
>     var resultNodes = [];
>     for (var i=0; i<node.childNodes.length; i++) {
>         resultNodes.push(node.childNodes.item(i));
>     }
>     return resultNodes;
> };
> -- 
> Christophe BOSSE - D?veloppeur

Thanks for the report !

I think your fix looks nice !

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be


From ree at ree.hu  Tue May  6 08:24:43 2008
From: ree at ree.hu (Balazs Ree)
Date: Tue, 6 May 2008 08:24:43 +0200
Subject: [Kss-devel] Bug in kukit.dom.parseHTMLNodes
References: <f435c32e0805020419sb8eb70di84c82e39f785fd2a@mail.gmail.com>
	<fvni98$4vb$1@ger.gmane.org>
Message-ID: <pan.2008.05.06.06.25.06@ree.hu>

On Mon, 05 May 2008 20:05:28 +0200, Godefroid Chapelle wrote:

> Christophe Bosse wrote:
>> I've found a bug while using replaceHTML kss command. The deal here is
>> to create a DIV element to let the browser engine to parse HTML code.
>> The problem is that in gecko browser (maybe others too) when adding a
>> node requiring a special parent node (LI, TR, TD, DT, DD etc...) it
>> will skip those nodes because the DIV  element does not fit in this
>> case.
>> 
>> Here's my dirty quick patch:
>> 
>> var restrictedParentNodes = {
>>     'th': 'thead',
>>     'td': 'tr',
>>     'tr': 'table',
>>     'thead': 'table',
>>     'tbody': 'table',
>>     'tfoot': 'table',
>>     'li': 'ul',
>>     'dt': 'dl',
>>     'dd': 'dl',
>>     'option': 'select',
>>     'optgroup': 'select',
>> };
>> kukit.dom.parseHTMLNodes = function(txt){
>>     var firstNode = /<([^> ]*)[> ]/.exec(txt); firstNode = firstNode ?
>>     firstNode[1] : null; var node =
>>     document.createElement(restrictedParentNodes[firstNode]
>> || 'div');
>>     node.innerHTML = txt;
>>      console.log(node.firstChild);
>>     // gecko engine automatically adds a TBODY node if
>>     (node.firstChild) {
>>         if (node.firstChild.nodeType == 3)
>>             node.removeChild(node.firstChild);
>>         if (node.firstChild.nodeName == 'TBODY')
>>             node = node.firstChild;
>>     }
>>     var resultNodes = [];
>>     for (var i=0; i<node.childNodes.length; i++) {
>>         resultNodes.push(node.childNodes.item(i));
>>     }
>>     return resultNodes;
>> };
>> --
>> Christophe BOSSE - D?veloppeur
> 
> Thanks for the report !
> 
> I think your fix looks nice !

I find one particular issue: maybe the first text node should not be 
removed unconditionally. Can you explain in more details, why this becomes
necessary?

In certain cases we do want the first text node to appear, it is allowed
to add something like this to an ordinary tag like <P>: 

   "Text <b>bold</b> and <b>more bold</b> is accepted."

I have the feeling that your patch would remove "Text" from the beginning.

But maybe this is not allowed anyway from where you do want to remove 
them, so the removal can be used conditionally.

(Jeroen: I think we have to add tests for these cases to the list in the 
blueprint.)


-- 
Balazs Ree


From jeroen.vloothuis at xs4all.nl  Tue May  6 08:43:22 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Tue, 06 May 2008 08:43:22 +0200
Subject: [Kss-devel] Bug in kukit.dom.parseHTMLNodes
In-Reply-To: <pan.2008.05.06.06.25.06@ree.hu>
References: <f435c32e0805020419sb8eb70di84c82e39f785fd2a@mail.gmail.com>	<fvni98$4vb$1@ger.gmane.org>
	<pan.2008.05.06.06.25.06@ree.hu>
Message-ID: <481FFE0A.3020108@xs4all.nl>

Balazs Ree wrote:
> On Mon, 05 May 2008 20:05:28 +0200, Godefroid Chapelle wrote:
>
>   
>> Christophe Bosse wrote:
>>     
>>> var restrictedParentNodes = {
>>>     'th': 'thead',
>>>     'td': 'tr',
>>>     'tr': 'table',
>>>     'thead': 'table',
>>>     'tbody': 'table',
>>>     'tfoot': 'table',
>>>     'li': 'ul',
>>>     'dt': 'dl',
>>>     'dd': 'dl',
>>>     'option': 'select',
>>>     'optgroup': 'select',
>>> };
> (Jeroen: I think we have to add tests for these cases to the list in the 
> blueprint.)
>   
Yes, do note that some of these will (probably) never work in IE 
(replacing part of the table, options etc.).


From christophe.bosse at ingeniweb.com  Tue May  6 09:52:33 2008
From: christophe.bosse at ingeniweb.com (Christophe Bosse)
Date: Tue, 6 May 2008 09:52:33 +0200
Subject: [Kss-devel] Bug in kukit.dom.parseHTMLNodes
In-Reply-To: <481FFE0A.3020108@xs4all.nl>
References: <f435c32e0805020419sb8eb70di84c82e39f785fd2a@mail.gmail.com>
	<fvni98$4vb$1@ger.gmane.org> <pan.2008.05.06.06.25.06@ree.hu>
	<481FFE0A.3020108@xs4all.nl>
Message-ID: <f435c32e0805060052s64f9c772w427cde9594d09414@mail.gmail.com>

>
> > I find one particular issue: maybe the first text node should not be
> > removed unconditionally.
>

Yes you're right I have just quickly suggested to correct it that way and
thare are bugs in what I have sent you.

> Yes, do note that some of these will (probably) never work in IE
> (replacing part of the table, options etc.).

What's is not supposed to work ?  Those nodes work like in other browsers
excepted it does not restrict contained nodes.

My last suggestion would be:
var restrictedContainerNodes = {
    'TD': 'TABLE',
    'TH': 'TABLE',
    'TR': 'TABLE',
    'THEAD': 'TABLE',
    'TBODY': 'TABLE',
    'TFOOT': 'TABLE',
    'LI': 'UL',
    'DT': 'DL',
    'DD': 'DL',
    'OPTION': 'SELECT',
    'OPTGROUP': 'SELECT',
};
kukit.dom.parseHTMLNodes = function(txt){
    var firstNode = /<([^> ]*)[> ]/.exec(txt);
    firstNode = firstNode ? firstNode[1].toUpperCase() : null;
    var node = document.createElement(restrictedContainerNodes[firstNode] ||
'DIV');
    node.innerHTML = txt;
    // gecko engine automatically adds a TBODY node for table elements
    if (node.firstChild) {
        var elementNode = node.firstChild.nodeType != 3 ? node.childNodes[0]
:

node.childNodes[1];
        if (restrictedContainerNodes[firstNode] == 'TABLE' &&
            restrictedContainerNodes[elementNode.nodeName] == 'TABLE')
            node = elementNode;
    }
    var resultNodes = [];
    for (var i=0; i<node.childNodes.length; i++) {
        resultNodes.push(node.childNodes.item(i));
    }
    return resultNodes;
};



-- 
Christophe BOSSE - D?veloppeur
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royal - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01 78 15 24 02 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/kss-devel/attachments/20080506/86bc2f7c/attachment-0001.htm 

From ree at ree.hu  Tue May  6 10:00:45 2008
From: ree at ree.hu (Balazs Ree)
Date: Tue, 6 May 2008 10:00:45 +0200
Subject: [Kss-devel] Bug in kukit.dom.parseHTMLNodes
References: <f435c32e0805020419sb8eb70di84c82e39f785fd2a@mail.gmail.com>
	<fvni98$4vb$1@ger.gmane.org> <pan.2008.05.06.06.25.06@ree.hu>
	<481FFE0A.3020108@xs4all.nl>
	<f435c32e0805060052s64f9c772w427cde9594d09414@mail.gmail.com>
Message-ID: <pan.2008.05.06.08.01.10@ree.hu>

On Tue, 06 May 2008 09:52:33 +0200, Christophe Bosse wrote:

Jeroen wrote:
>> Yes, do note that some of these will (probably) never work in IE
>> (replacing part of the table, options etc.).
> 
> What's is not supposed to work ?  Those nodes work like in other
> browsers excepted it does not restrict contained nodes.

Inserting an OPTION into SELECT won't work with IE, but this is a bit 
separate issue. It will be inserted all right but IE won't notice it, it 
won't appear. This is a bug in IE and the current workaround is to 
replace the whole SELECT instead.

On the other hand, inserting TR into TABLE, may work cross browser 
including IE, in my opinion (but we can only be sure if we have tested it 
of course), if the current issue is solved.


Best wishes
 
-- 
Balazs Ree


From christophe.bosse at ingeniweb.com  Tue May  6 10:19:31 2008
From: christophe.bosse at ingeniweb.com (Christophe Bosse)
Date: Tue, 6 May 2008 10:19:31 +0200
Subject: [Kss-devel] Bug in kukit.dom.parseHTMLNodes
In-Reply-To: <pan.2008.05.06.08.01.10@ree.hu>
References: <f435c32e0805020419sb8eb70di84c82e39f785fd2a@mail.gmail.com>
	<fvni98$4vb$1@ger.gmane.org> <pan.2008.05.06.06.25.06@ree.hu>
	<481FFE0A.3020108@xs4all.nl>
	<f435c32e0805060052s64f9c772w427cde9594d09414@mail.gmail.com>
	<pan.2008.05.06.08.01.10@ree.hu>
Message-ID: <f435c32e0805060119t5534d1deieeb965d96c98c9e2@mail.gmail.com>

> Inserting an OPTION into SELECT won't work with IE
I was totally not aware about that ! Don't know what 's so annoying about
inserting an OPTION in a SELECT node !!

The workaround for IE would be to pass my fix.

Anyway I'll try take time to test all those things on IE.

2008/5/6 Balazs Ree <ree at ree.hu>:

> On Tue, 06 May 2008 09:52:33 +0200, Christophe Bosse wrote:
>
> Jeroen wrote:
> >> Yes, do note that some of these will (probably) never work in IE
> >> (replacing part of the table, options etc.).
> >
> > What's is not supposed to work ?  Those nodes work like in other
> > browsers excepted it does not restrict contained nodes.
>
> Inserting an OPTION into SELECT won't work with IE, but this is a bit
> separate issue. It will be inserted all right but IE won't notice it, it
> won't appear. This is a bug in IE and the current workaround is to
> replace the whole SELECT instead.
>
> On the other hand, inserting TR into TABLE, may work cross browser
> including IE, in my opinion (but we can only be sure if we have tested it
> of course), if the current issue is solved.
>
>
> Best wishes
>
> --
> Balazs Ree
>
> _______________________________________________
> Kss-devel mailing list
> Kss-devel at codespeak.net
> http://codespeak.net/mailman/listinfo/kss-devel
>



-- 
Christophe BOSSE - D?veloppeur
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royal - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01 78 15 24 02 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/kss-devel/attachments/20080506/c0bc9a21/attachment.htm 

From mymir.org at googlemail.com  Mon May  5 17:05:36 2008
From: mymir.org at googlemail.com (Vladislav Vorobiev)
Date: Mon, 5 May 2008 19:05:36 +0400
Subject: [Kss-devel] form and kssattr in request
In-Reply-To: <481C8E30.3000602@bubblenet.be>
References: <604c02230805010636w297265d8sb2ed3a6a79a9ace1@mail.gmail.com>
	<481ACEA6.3020506@bubblenet.be>
	<604c02230805020328m1a124d74nb7ac8e7ed5470abb@mail.gmail.com>
	<481C8E30.3000602@bubblenet.be>
Message-ID: <604c02230805050805r4ff8cecbudd6fd2acce7a43d2@mail.gmail.com>

2008/5/3 Godefroid Chapelle <gotcha at bubblenet.be>:
>
> Vladislav Vorobiev wrote:
>  > 2008/5/2 Godefroid Chapelle <gotcha at bubblenet.be>:
>  >> Vladislav Vorobiev wrote:
>  >>
>  >>> Hi,
>  >>>
>  >>> I hope this list is right for my concern.
>  >>>
>  >>> I try to send parameter from "form" *and* kssattr.
>  >>>
>  >>> Something like this:
>  >>>
>  >>> <form>
>  >>> <input name="bla' value="bla" />
>  >>> <div class="inlineEdit kssattr-inputId-email">blabla</div>
>  >>> </form>
>  >>>
>  >>> My kss:
>  >>>
>  >>> .inlineEdit:click {
>  >>> action-server: inlineEdit;
>  >>> inlineEdit-value: currentFormVar(value);
>  >>> inlineEdit-inputId: kssAttr(inputId);
>  >>> }
>  >>>
>  >>> It does not work. inlineEdit script get only inputId in the request.
>  >>> It need form variables too.
>  >>>
>  >>> Any Ideas? How I can do this?
>  >>>
>  >>>
>  >>  This should be :
>  >>
>  >>
>  >>  .inlineEdit:click {
>  >>     action-server: inlineEdit;
>  >>     inlineEdit-value: currentFormVar(bla);
>  >>     inlineEdit-inputId: kssAttr(inputId);
>  >>  }
>  >>
>  >>  because the argument to currentFormVar value provider is the input "name"
>  >>
>  >
>  > Hi,
>  > Thanks but it is not quite the thing.
>  > I need to stick to to form-variables my variable inputId.
>
>  I do not understand what you mean here...
>
>  I suspect there is a language issue.
>
>  Can you try to explain better ?

Hi,
try to explain it better...

I have to send a form to my ServerScript
Something like this:

 <form>
 <input name="bla' value="bla" /> <input name="bla2' value="bla"
/><input name="bla3' value="bla" /> ect?
<div class="inlineEdit kssattr-inputId-email">blabla</div>
<div class="inlineEdit kssattr-inputId-tel">blabla</div>
<div class="inlineEdit kssattr-inputId-post">blabla</div>
</form>

My kss for this statement looks like this.

.inlineEdit:click {
action-server: inlineEdit;
 inlineEdit-value: currentFormVar(value);
 inlineEdit-inputId: kssAttr(inputId);
}

This is all I can send  :currentFormVar(value) or kssAttr(inputId).

I want add more variables to my form respectively REQUEST.

The nominee construction is probably works, but it's not realy what I
want. The thing is I have to make kss statement for every different
forms on my site. It would be more dynamically if I'm able to attach
kssattr on my form.

Hope you got it.)

Exuse me for my English

Vlad

From mymir.org at googlemail.com  Mon May  5 18:26:14 2008
From: mymir.org at googlemail.com (Vladislav Vorobiev)
Date: Mon, 5 May 2008 20:26:14 +0400
Subject: [Kss-devel] form and kssattr in request
In-Reply-To: <481F2AAD.3060509@bubblenet.be>
References: <604c02230805010636w297265d8sb2ed3a6a79a9ace1@mail.gmail.com>
	<481ACEA6.3020506@bubblenet.be>
	<604c02230805020328m1a124d74nb7ac8e7ed5470abb@mail.gmail.com>
	<481C8E30.3000602@bubblenet.be>
	<604c02230805050805r4ff8cecbudd6fd2acce7a43d2@mail.gmail.com>
	<481F2AAD.3060509@bubblenet.be>
Message-ID: <604c02230805050926g19f13c48l67d97f14b421a963@mail.gmail.com>

>  Could you show an example of your server side method ?
>  like :

http://mymir.ru//test/testKSS
ttp://mymir.ru//test/testKSS/a.kss

Vlad

From gotcha at bubblenet.be  Tue May  6 19:00:04 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Tue, 06 May 2008 19:00:04 +0200
Subject: [Kss-devel] Bug in kukit.dom.parseHTMLNodes
In-Reply-To: <f435c32e0805060119t5534d1deieeb965d96c98c9e2@mail.gmail.com>
References: <f435c32e0805020419sb8eb70di84c82e39f785fd2a@mail.gmail.com>	<fvni98$4vb$1@ger.gmane.org>
	<pan.2008.05.06.06.25.06@ree.hu>	<481FFE0A.3020108@xs4all.nl>	<f435c32e0805060052s64f9c772w427cde9594d09414@mail.gmail.com>	<pan.2008.05.06.08.01.10@ree.hu>
	<f435c32e0805060119t5534d1deieeb965d96c98c9e2@mail.gmail.com>
Message-ID: <48208E94.1010809@bubblenet.be>

Christophe Bosse wrote:
>  > Inserting an OPTION into SELECT won't work with IE
> I was totally not aware about that ! Don't know what 's so annoying 
> about inserting an OPTION in a SELECT node !!
> 
> The workaround for IE would be to pass my fix.
> 
> Anyway I'll try take time to test all those things on IE.
> 

The bug might not exist in IE7. But we know for sure it is in IE6.
-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

From mymir.org at googlemail.com  Wed May  7 00:40:51 2008
From: mymir.org at googlemail.com (Vladislav Vorobiev)
Date: Wed, 7 May 2008 02:40:51 +0400
Subject: [Kss-devel] form and kssattr in request
In-Reply-To: <481F4CF2.8080306@bubblenet.be>
References: <604c02230805010636w297265d8sb2ed3a6a79a9ace1@mail.gmail.com>
	<481ACEA6.3020506@bubblenet.be>
	<604c02230805020328m1a124d74nb7ac8e7ed5470abb@mail.gmail.com>
	<481C8E30.3000602@bubblenet.be>
	<604c02230805050805r4ff8cecbudd6fd2acce7a43d2@mail.gmail.com>
	<481F2AAD.3060509@bubblenet.be>
	<604c02230805050926g19f13c48l67d97f14b421a963@mail.gmail.com>
	<481F4CF2.8080306@bubblenet.be>
Message-ID: <604c02230805061540t4483eab2taa63c31f3b73ab5a@mail.gmail.com>

Hello Godefroid,

i need the follow result:
http://mymir.ru//test/testKSS/withJavaScript
You can see that a have inputId in the request too.

Also I need the same result with kss:
http://mymir.ru//test/testKSS/theSamewithKSS/
You can see that a have ONLY inputId in the request and this is my problem

Very difficult for me to describe my user case in english. I need to
tell sombody for help.
Sorry.

Vlad

2008/5/5 Godefroid Chapelle <gotcha at bubblenet.be>:
>
> Vladislav Vorobiev wrote:
>
> >
> > >  Could you show an example of your server side method ?
> > >  like :
> > >
> >
> > http://mymir.ru//test/testKSS
> > ttp://mymir.ru//test/testKSS/a.kss
> >
> > Vlad
> >
>
>  I have looked at your code. I have the feeling you try to misuse KSS.
>
>  Instead of asking about technical details, could you first describe your
> use case ?
>
>  I'll try to help.
>
>
>
>  --
>  Godefroid Chapelle (aka __gotcha) http://bubblenet.be
>



-- 
Best Regards
Vlad Vorobiev
http://www.mymir.org

From ree at ree.hu  Mon May 12 13:56:25 2008
From: ree at ree.hu (Balazs Ree)
Date: Mon, 12 May 2008 13:56:25 +0200
Subject: [Kss-devel] API proposal
References: <481AF0A3.3070302@pareto.nl> <pan.2008.05.03.08.41.01@ree.hu>
	<fvhjjj$5p8$1@ger.gmane.org>
Message-ID: <pan.2008.05.12.11.56.52@ree.hu>

On Sat, 03 May 2008 13:51:15 +0200, Martijn Faassen wrote:

Besides giving the detailed reply below, I also try to summarize in the
beginning how I see the situation and what principal questions I can
identify. I hope this makes my point of view more clear. I suggest to
continue along these summary points, by extending them if needed. The
reason for this is that the posts are getting too long and have
overlapping issues.

I believe I now understand the arguments of both sides. My main motivation
to extend the original kss.base commandset API proposal is that while I
agree upon the need to use commandsets more pythonically, there is also a
need from the kss side to provide clean concepts and be mostly server
agnostic. These seem to be contradicting requirements at first, but still
I believe there is a way that satisfies both the kss and the python
perspectives.

But I agree with your intentions, that the actual python implementation
should be easy to use, and the usage should be natural and intuitive for
the programmers - apparently this is not the case now so this needs to be
changed. It should be also beyond argument that no such implementation
will be chosen that python programmers find non-fitting.

Based on the discussion so far, I believe the following corner questions
need to be decided:

1. Do we want to keep the "commandset" concept in kss,
   or drop it completely?

2. In the python-based server implementations, does kss want to support
   "commandsets" in a unified and server independent way?

3. Are commandsets accessed from python by their kss, or python
   namespace?

I propose to examine the answer to these points, and only after this we
should decide about the implementation issues, like the actual import and
calling of commandsets from python or from a zope view.


Let me explain the relevance of these points in details:

-------------------------------------------------------------
1. Do we want to
keep the "commandset" concept in kss, or drop it completely?
-------------------------------------------------------------

I believe the answer to the question should be yes. Commandsets turned out
to be a useful concept for two reasons:

- by making an equivalent "command" for each client action, server
  side can emit these commands easily and in a pythonic way.

- complex commands that have no client action, can break down a
  complex page manipulation task into smaller parts without the need to
  program on the client. This code is distributed together with the kss
  plugin, and is usable everywhere in the same way, where the plugin is
  installed. - Occasionally these commands have the need to access the
  server side content and utilities.

  The advantage of this last point may not be obvious if we only think of
  the usage of the "core" commandset but it's somewhat understood if we
  look at the commandsets in the "plone" plugin.

If we answer "no" to this question, then there is no need to think about
the following questions. If the answer is "yes" then it is worth thinking
on how make the commandsets more accessible, so that programmers can find
the best and most balanced way of using them.


----------------------------------------------------------------------- 
2. In the python-based server implementations, does kss want to support
"commandsets" in a unified and server independent way?
-----------------------------------------------------------------------

By "unified" I mean that although commandsets are provided by plugins, the

- usage and definition of commandsets is independent from
  the plugin they are defined from: the commandsets from the core plugin
  and from other plugins should not be different to define or use. We do
  not give the freedom to plugins to come up with their own format.

By "server independent way" I mean that while servers will need different
commandset implementations, for example Zope needs to use them from a
view, other environments will come up with their individual needs, but:

- usage of the commandsets (and the readibility of code that calls them)
  should be the same in the different server implementations (python,
  zope, django) and their

- definition should also be "as similar as possible".

I'd find it very undesirable, if for example, a Zope view needs to call up
a core command and a command from a Zope commandset (that accesses the
view) in two consequtive lines, and it needs to do these two calls with a
different syntax.

In my definition, if we leave to decide the way of implementation
completely up to the plugins and/or server side implementations, that
means the answer "no" to this question. This means leave to python to
decide its own "best way", let Zope add its own type of commandsets, and
django, etc. do the same, then actually kss is not specifying the API, but
python, Zope, django does.

Which is also a possible direction, and this means that the answer to this
question needs to be considered seriously. In case of "no", there is also
no need to think about point 3.

While I agree that this unified support must not impose restriction on the
server side code (ie. should be very pythonic) kss should do (in my
opinion) more then just giving suggestions and guidelines for server side
implementations: it should provide a pythonic API but also provide a
generic scheme that can be implemented by all server sides. We should also
demonstrate how this works in python, zope and django. We can never be
sure if a new server side brings additonal requirements, but we can
already draw conclusions from the cases we have already at hand.


------------------------------------------------------------------- 
3. Are commandsets accessed from python by 
their kss, or python namespace?
-------------------------------------------------------------------

I could also ask it in this way: Are kss _commands_ accessed from python
by their kss, or python namespace?

Fact is that in kss we have a namespace where all events, actions, etc.,
including commands, are named with a dashed namespaced name, like
"pluginname-commandname". We will soon allow multi-level namespaces as
well: ie. you could soon use a "jquery-dnd-drag" action or
"plone-forms-submit' action and command. Note: the kss namespace is not a
python namespace and it's unhandy to think of it as such.

There are two basic issues, which namespace the commandsets are accessed
by, and how do we aid calling the commandsets from view-like constructs
(in Zope, from kss views or from other commandsets).

The namespace issue is principal and I see the following possible
directions (there could be more):


A. Access commandsets by the kss namespace
..........................................

This is how currently, in Zope, the commandsets are looked up by the
getCommandSet call that accepts the kss name of the commandset as a
parameter: this would be the namespaced name, but since we have no
multilevel, now it's just the "name" of the commandset.

The disadvantage is that the actual python code of the commandset is
difficult to find: there is no direct import, so similarly how you need to
look up the CA to find the actual import location of a Zope browser view,
you also need to call the kss plugin registry to look up the commandset.

I understand why this is a serious con as well.


B. Access commandsets by the python namespace
.............................................

This is the suggested way if we follow the original proposal and extend it
to other plugins. However intuitive it may be that in this case the
commandset's code is exactly where you import it from, but it is
contraintuitive from the point of view that for example the
"plone-issuePortalMessage' command would be needed to import from
"plone.app.kss.plugin.commandsets.PloneCommandSet", however specifying the
command by its kss namespace seems to be more important here then knowing
its python namespace.

I also understand that the direct import is handy in case of the
python-only commandsets (that use no context view), and why it's important
to have it, but I don't imagine easily how this direct import would be
applied benefitially to the current Zope usage, where I guess we will need
some helper method on the view to lookup the commandset anyway.


C. Unify the two namespaces
---------------------------

One feasible solution that would allow direct import from python would be
to _force_ the implementation of kss plugin "X" to be in the python module
kss.plugin.X. In this case plugins would loose import location
independence, which is however not the only consequence.

In this case all code that adds a kss plugin, will need to create a
separate egg in kss.plugin. For example plone.app.kss will need to come
with a kss.plugin.plone and if we are consequent kss.base should have a
kss.plugin.core. Similarly, megrok.kss would need to add a
kss.plugin.megrok egg if it has plugins, and so on. Since we have
setuptools, this may be easy to satisfy in some cases but can also be a
burden in other cases.

There is another specific use case when I create a kss plugin for a
specific application, or application component, in this case my code is in
for example z3c.mylib.mywidget but I would immediately need to make a
kss.plugin.mywidget egg, while I would rather just put the plugin in a
subdirectory of my component itself (as possible currently, as well).

Altogether, while I see the apparent merit of forcing all plugins to
kss.plugin, I believe it adds too much constraint to developers to require
this in each case. I would find it better to allow the current placeless
definition and registration of plugins, with a _convention_ to say that
they should be eggified to kss.plugin. This way all general purpose
plugins would move there while application components lile kss.base,
plone.app.kss, or megrok.kss, as well as custom application code, could
choose to keep their plugin code embedded.

This would make code easily enough locatable but indeed not in every case,
additional information is needed like to know that the plone plugin is in
plone.app.kss.

But indeed if we strictly enforce this placement rule, then we can import
the commandset (class?) in python always from its real location, and
without a registry, since it will have a 1-to-1 mapping to the kss plugin
namespace.

Even in this case we have to work out where the commandsets themselves are
in the kss.plugin.X module, so probably more convention or rule is needed.




In the following, I attempt to react to Martijn's original letter, which
will be a repetition or elaboration of the above summary.

On Sat, 03 May 2008 13:51:15 +0200, Martijn Faassen wrote:

> Balazs Ree wrote:
> [snip]
>> The way Jeroen implemented the commandsets in kss.base first, mainly
>> considers the actual commandsets that are in the core, and simplify
>> these cases. However we have more complex usage needs in zope and plone
>> that the previous version supported. With the way the kss.base handles
>> the commandsets,
>> - we cannot support our current needs with Zope and Plone, - but we
>> also don't want different type of commandsets in python, Zope, and
>> server X,
> 
> I disagree with the second requirement. Why *do* you want the same type
> of commandset for all these servers? What's the point? I can't reuse the
> commandset that I write for a Zope app in server X anyway, right? Any
> resuable bits that do exist I can factor out into independent libraries.

This is party true. I believe however that the followings are targetable
(and feasible) goals, as outlined in the point 2.:

1. Commandsets should be acquired in always the same way, independently
from the application type.

2. The commandset code written for any server can be read and understand
by anyone who is familiar with kss, even if he does not know that
particular server side well. This includes our tutorials become more
useful as well (we cannot expect every tutorial ported to every single
server side implementation).

I note that I also believe that in the present application code we are not
using commandsets efficiently enough. Lot of the things we are doing in
the browser view in a server action method, could be factored to
commandsets and let the view call them (examples are in plone.app.kss and
archetypes.kss). But again this is my personal impression and I am sure
that some programmers will think in a different flavour, therefore this
(what you factor out into a commandset) should be a personal decision of
the programmer, but to enable this decision, we have to give good and
coherent support from kss.

> I think that anything that relies on kss.base only should only have to
> deal with commandsets that are as close to straightforward Python
> possible, which means a module with functions in it. Or a module with an
> instance of a class in it (where the methods are the commands), if you
> need to be able to parameterize commandsets for some reason (in specific
> cases). The great advantage of this is that when people follow the
> import trail (something all Python programmers can do), they can find
> the implementation. Any registry-based approach breaks this.
> 
> Some commandsets may implement the same abstract interface. You can then
> look up the one relevant in your particular application. I'm somewhat
> skeptical of this requirement myself, as I've only heard the 'different
> effects libraries' examples so far, which doesn't convince me. How many
> of these protocols are there right now in the real world? Do they
> actually have multiple implementations?
> 
> Anyway, putting aside this skepticism, let's imagine we have an effects
> commandset and there's a reimplementation of this (the example I keep
> hearing about). I want to use this other implementation in my
> application. So I change the import. This is straightforward and
> something that Python programmers understand. It's not like I don't need
> to test my application with this new effects library anyway.
> 
> The word 'commandset' may be able to go away. Instead people can use the
> familiar concept of a "python module".
> 
> Now you could envisage a general framework that helps you get an
> implementation of a commandset interface dynamically, based on some
> configuration setting and pulling it from a registry. Zope 3 has such a
> story for registration (the component architecture). So when *I* need
> this, I'll use zope.component. kss.zope could offer some approach that
> uses this. Other systems have different stories for this, or will grow
> ad-hoc stories for this.

> I want the Zope 3 story to look like the Zope 3 story, and the other
> frameworks will have to be on their own. Perhaps eventually something
> like kss.registry might grow if some of these frameworks want to reuse
> the same registry after they gain some experience with this and it turns
> out to be an important requirement. I doubt a Zope 3 application will
> want to use this, as one of Zope 3's strongest points is its powerful
> configuration story.

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. But note, the "name
of the commandset" still does not match the python import path of the
code.

Now, you can argue "but what about the commands that call up other
commands and have no corresponding action on the client." For example,
plone-issuePortalMessage is like this. However I still prefer to call it
plone-issuePortalMessage and not
plone.app.kss.plugins.plone.issuePortalMessage. It belongs to the "plone" 
kss plugin, its availability depends if the plugin is enabled. (although 
it's true that the commandset can only be used if plone.app.kss is 
present.)


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.


>> 1. KSS plugins have no global import, is Good
> 
> This is not good in the lowest layer. The lowest layer should be simple
> to understand for a Python programmer. If you want this kind of stuff,
> please use the Zope 3 component architecture, which was born to do this
> kind of thing and is at least something you don't need to reinvent.

We cannot use the CA for implementation. We had that and we have decided
to move away from it, precisely because we want to support plain python.
The implementation of the kss plugin registry in kss.zope uses the CA, but
the definition and usage of commandsets must be zope-independent.

This does not mean the programmer cannot use the CA for the implementation
of its own code. Only the code that is specific to KSS, should go to
commandsets, and this code does not need the CA for its definition.

But otherwise this is turning to touch my initial point 3.
 
>> I would like to add that (unlike Martijn said) the commandset's name is
>> not "just a string". It is a fully dashed global identifier of the
>> commandset (Example plone-issuePortalMessage, but we will support
>> multilevel namespaces my-fancy-app-command any moment):
> 
> (I'm not sure why I am said to have said this)
> 
> Why invent your own namespace construct when Python already has one?

KSS has a namespace that is based on KSS's conceptial model and not that
of python. Following the python namespace from kss was never raised as a
requirement: this is ultimately a client library and the closest language
it depends on is actually javascript. I also believe it would be
inconvenient and pointless to require python import paths to appear in the
plugin namespaces and kss files.

But I also think that this is not what is being argued. The maximum thing
that can be considered is saying that the commandsets (and command names)
should not follow the namespace of the kss plugin they belong to, or find
another solution (as described in point 3.)


>>  The slight separation from python land also
>> helps to understand to the reader of the code that executes is a
>> registered part of a kss plugin - much more important then to see which
>> python module it's importing from.
> 
> I assume that if you import KSS commands from a module, you already know
> you're dealing with KSS here. Use a global 'kssplugin' namespace that
> peopple can use their KSS plugins under if you're concerned with this,
> just like Zope uses 'zope'. Don't enforce that (Zope doesn't).

You are suggesting to enforce plugins into the kss.plugin python namespace
to solve the "kss name != python import" problem, I elaborated on this in
my initial summary.
 
 
> [snip]
>> We may think, however, other ways to make the syntax usage sweeter, if
>> the view.getCommandSet() is the biggest annoyance in the story. The
>> view.getCommandSet can be removed and instead we can provide a kss
>> import namespace like
> 
> To me, it's not just the syntax. It's mostly the semantics. It that it's
> an unnecessary abstraction at this level, that hinders the ability of a
> Python programmer to find things. If you used modules, a developer can
> find a module and then have an immediate idea of how you can use it (you
> don't need to know how it's registered, you can import it). If you see a
> module in use, you can go and find the module as you know its dotted
> name.

In python, if you see a method called on an object, you don't necessarily
find the module the method is defined in at once. As a programmer you
always need to learn to find things, such is the case for zope where you
need to search zcml files, or kss where you currently need to find the
plugin's define location to read its code. So "it needs an effort to find
a code" is not a disaster in itself, if it's easy enough.

But it is indeed important that beginners should not need to learn
everything before they can use a commandset. (To write a commandset: well,
for that we can already assume some more knowledge, but it should be easy
as well.) It's also an important concept not to invent something if there
is a straightforward solution.


> [snip]
>> 2. Zope commandsets do need to access the view
> 
> I'll rephrase this: a Zope specific command will need access to the Zope
> view.
> 
> You can pass in the view as a parameter, or you could implement your
> Zope-specific set of commands as a class that takes the view as the
> argument. That's up to the developer. I disagree with tying this to the
> kss.base discussion, as I don't agree with the basic requirement that
> requires this.

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.

It is also the first time that we support a plain python stack, which
means carefully reconsidering the kss model and adjusting it as needed, so
it stays generic and does not only fit one or the other server side
implementation.

Naturally if the final decision concerning  my initial point 2. in turns
out to be negative, then this reason becomes invalidated, but still the
basic requirement to discuss point 2. stays.


> Commands are much like functions or methods. I think you shouldn't
> require people to have to make a choice between implementing their own
> commands as functions, or methods, in the core of your framework.

Not forcing them to implement in a specific way means that instead of the
support we give, we basically say "no support, do it your own way". (Re:
Point 2 in my initial summary.) So the message is: forget about
commandsets ant their registry, and try to implement it with the full
power of python.

The scenario that this will lead to, is, in my opinion:

Besides that everyone will implement commandsets a bit differently,
everyone will also use commandsets in different ways. Zope will apperantly
stick to its current implementation or similar, to be able to support
transparent changes triggered by events, for which views are inevitable.

Occasinally people will build their own libraries and convenience methods,
for calling up a commandset from a view or from another command set. Both
the definition and the way of calling of a commandset will be different
everywhere. And indeed as you mention, commandsets will cease to exist
because it will not be a central concept in kss any more.

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.

Instead of this, I suggest the keep the current notion of "commandsets" as
it has an important role in the kss model. And try to finalize a python
level implementation and access for it that is both pythonic, easy to use,
and that supports the needs of different server side environments. This
would not force programmers to move all code to commandsets though: we
should let them find the balance between "code that is in the app" that
uses free python, or "code in the commandset" that complies some rules and
is closely attached to client page manipulation and reusable on the level
of kss.


> [snip]
>> For example, the plone-issuePortalMessage command needs to access not
>> only to commands, but also to the content and the request. This could
>> not be handled sanely in the plain-python way, unless an arbitrary
>> number of parameters were passed to the actual command implementations
>> which would be insane.
> 
> I probably don't understand something here, but why can't the *Zope
> specific commands* get these extra parameters, while the underlying core
> commands on top of which you're building them don't? Is this again a
> result of the requirement that commandsets look the same for all Python
> frameworks?
> 
>> However with the "commandset as adapter" pattern, this is easy since
>> the implementation-dependent parameters are all hidden. (In addition
>> every other system may also want to implement its own
>> issuePortalMessage.)
> 
> If you want to use adapters, please use zope.component. I don't want to
> use a reimplementation of zope.component. I also don't think Python
> programmers in general are looking for this.

When I said "adaptation" I was not talking about the registration or
lookup of adapters in the Component Architecture, I was trying to explain
my point by using the adaptation pattern as a generic OOP principle. This
characterized a possible way how the commandsets could be defined, but
this knowledge would not be needed for just using commandsets. (Very
roughly speaking, the views that use commandsets would "inherit by
adaptation" from all plugged in commandsets, similarly to the currently
applied pattern.) This is however just one possibility for implementation
to consider, and could be revisited after the ponts 1., 2., 3. will have
been answered.

We can and we do use the CA within the implementation of kss.zope itself,
but we cannot require programmers to use the CA from code where they want
to define or access a commandset: this way it would be entirely zope
specific - we are moving away from this.

Apart from this, there is no intention of reimplementing any CA in kss:
kss.base has a simple registry for kss plugins that works in plain python
with setuptools, and it has no similarity whatsoever to the CA.


> [snip]
>> If the proposal in the thread becomes the supported way of API for
>> commandsets, first we loose import location independence,
> 
> Location independence doesn't belong in the core. Python has location
> dependence, so there's no requirement to get rid of this dependence in a
> general Python library.
> 
>> then we also
>> won't be able to support existing commandsets code this way.
> 
> That's only because of the requirement you want commands to look like
> each other in different frameworks, while still supporting the different
> requirements of each framework. You're essentially looking to abstract
> over different frameworks, and that's a very risky business. Commands
> already look like each other as they look like Python functions, and
> sets of commands are like modules or classes. The universal way to plug
> into any framework is by writing an actual library.

This is true, and this does not differ principally from the goals I
outlined.  However we do want to support zope commandset similarly to
python, django, etc. commandsets, if the answer to point "2" in the
beginning is Yes.


>> As a result
>> all the code that cannot be supported and inevitably will be
>> implemented out of scope from kss (= differently from the supported
>> way), which means loosing the advantage of platform independence and
>> portability.
> 
> Platform independence for Zope specific code dealing with Zope views,
> contexts and requests?

The breaking down the commandset to smaller commandsets will be different,
but the pattern will be the same on each platform. As a result, if I read
the code of a "django" commandset, I may find it easy to port it to zope,
because I will just need to replace the parts that access the (view)
context, but the code part that calls up other commandsets, will not need
to be changed.

Obviously we need the "writing an actual library" as you refer above, ie.
implement the zope needs to add support to instantiate its own type of
commandsets, and so does django, but the usage will be the same and
definition will be also very similar.


>> At the same time I feel that the "commandset adaptation" pattern would
>> allow to keep best of all worlds, and it would not limit the
>> implementations. It may not be the most perfect option either so it's
>> essential to understand for me to get your reactions on the issue.
> 
> 
> I think it is limiting implementations and makes KSS harder to
> understand for Python programmers. I myself am familiar with adaptation
> but I already am committed to the use of zope.component.

Finally, I come to the conclusion that we are arguing here about "should
commandsets go from kss" as referred in point 1. of my initial summary.

I just would like to add that writing code like

   >>> self.commandsets.core.replaceHTML

in a commandset, does not require the deep understanding of the adaptation
pattern, in case it is used. Neither does inheriting from "KSSCommandSet".
For all the rest, kss users need not we aware of the adaptation, it only
concerns the implementation of the base commandsets and there will be only
two of these implementations at the moment (python, zope). Again, the
implementation question needs to be revisited after answering the initial
points.



So these were my detailed reactions but I think that my initial summary
offers an easier way for the issue to be discussed further.



-- 
Balazs Ree


From faassen at startifact.com  Fri May 16 20:05:50 2008
From: faassen at startifact.com (Martijn Faassen)
Date: Fri, 16 May 2008 20:05:50 +0200
Subject: [Kss-devel] API proposal
In-Reply-To: <pan.2008.05.12.11.56.52@ree.hu>
References: <481AF0A3.3070302@pareto.nl>
	<pan.2008.05.03.08.41.01@ree.hu>	<fvhjjj$5p8$1@ger.gmane.org>
	<pan.2008.05.12.11.56.52@ree.hu>
Message-ID: <g0kie5$crn$1@ger.gmane.org>

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


From mymir.org at googlemail.com  Tue May 20 14:19:08 2008
From: mymir.org at googlemail.com (Vladislav Vorobiev)
Date: Tue, 20 May 2008 16:19:08 +0400
Subject: [Kss-devel] Kss BUG? Text and Image in a-tag
Message-ID: <604c02230805200519t7150dbe8pc3e3dc6806b135@mail.gmail.com>

Hello,

I think that I have found a bug in KSS.


<a href="/xxx" class="nb">
<img src="http://myimage" alt="edit" />
</a>

If I click on the image firebug logs follow information
"Ignored bubbling event for event [click], target [IMG], EventRule #1
mergeId [@@0@@click]"
and reloading the page.

Follow constriction works:
<a href="/xxx" class="nb">
edit
</a>

My kss:
.nb:click {
evt-click-preventdefault: true;
action-server: nb;
nb-editMode: 8;
}

The KSS seems to be different. It depends on image or text in the <a> tag.

Any Ideas?

From gotcha at bubblenet.be  Tue May 20 14:30:31 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Tue, 20 May 2008 14:30:31 +0200
Subject: [Kss-devel] Kss BUG? Text and Image in a-tag
In-Reply-To: <604c02230805200519t7150dbe8pc3e3dc6806b135@mail.gmail.com>
References: <604c02230805200519t7150dbe8pc3e3dc6806b135@mail.gmail.com>
Message-ID: <4832C467.5030305@bubblenet.be>

Vladislav Vorobiev wrote:
> Hello,
> 
> I think that I have found a bug in KSS.
> 
> 
> <a href="/xxx" class="nb">
> <img src="http://myimage" alt="edit" />
> </a>
> 
> If I click on the image firebug logs follow information
> "Ignored bubbling event for event [click], target [IMG], EventRule #1
> mergeId [@@0@@click]"
> and reloading the page.
> 
> Follow constriction works:
> <a href="/xxx" class="nb">
> edit
> </a>
> 
> My kss:
> .nb:click {
> evt-click-preventdefault: true;
> action-server: nb;
> nb-editMode: 8;
> }
> 
> The KSS seems to be different. It depends on image or text in the <a> tag.
> 
> Any Ideas?

I think you miss

evt-click-allowbubbling: true;

HTH
-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

From mymir.org at googlemail.com  Tue May 20 14:40:41 2008
From: mymir.org at googlemail.com (Vladislav Vorobiev)
Date: Tue, 20 May 2008 16:40:41 +0400
Subject: [Kss-devel] Kss BUG? Text and Image in a-tag
In-Reply-To: <4832C467.5030305@bubblenet.be>
References: <604c02230805200519t7150dbe8pc3e3dc6806b135@mail.gmail.com>
	<4832C467.5030305@bubblenet.be>
Message-ID: <604c02230805200540w385b0bf1mf493f06255d360a4@mail.gmail.com>

> evt-click-allowbubbling: true;

Thanks!

From massimo.azzolini at gmail.com  Tue May 27 16:23:16 2008
From: massimo.azzolini at gmail.com (Massimo Azzolini)
Date: Tue, 27 May 2008 16:23:16 +0200
Subject: [Kss-devel] simulate mouse click
Message-ID: <ef1d3f8e0805270723j13f0d3a4h6e7cf52ab6177f3c@mail.gmail.com>

Hi all,

I need to simulate a click on a kss-ed element on my page's DOM.

I have a button element:

<button id="my_id" class="selected">...</button>

on which there is a KSS selector:

button.selected:click{
... do stuff
}

I open a popup window and, clicking on a anchor/button/whatever on it,
I need to simulate a click on that "button.selected". In this way kss
stuff should run etc.

I did something like:
<script>
function f(){
    document.getElementById(my_id).click()
}
</script>

but it works if applied on a standard button (e.g. <button
tal:attributes="name string:theSubmitButton-$fieldName; id
string:theSubmitButton-$fieldName;" onClick="alert('The button was
clicked.');">...</button>), but not on kss-ed one...

any hint?

thanks, bye

massimo

From lmb at eurotux.com  Tue May 27 16:48:56 2008
From: lmb at eurotux.com (Luis Miguel Braga)
Date: Tue, 27 May 2008 15:48:56 +0100
Subject: [Kss-devel] simulate mouse click
In-Reply-To: <ef1d3f8e0805270723j13f0d3a4h6e7cf52ab6177f3c@mail.gmail.com>
References: <ef1d3f8e0805270723j13f0d3a4h6e7cf52ab6177f3c@mail.gmail.com>
Message-ID: <483C1F58.70704@eurotux.com>

Hi,

Off the top of my head.... did you try triggering the kss click event?
I mean triggering the event from inside kss. I know there are examples 
of this on the site.


Best regards,
Lu?s Miguel Braga

Massimo Azzolini wrote:
> Hi all,
>
> I need to simulate a click on a kss-ed element on my page's DOM.
>
> I have a button element:
>
> <button id="my_id" class="selected">...</button>
>
> on which there is a KSS selector:
>
> button.selected:click{
> ... do stuff
> }
>
> I open a popup window and, clicking on a anchor/button/whatever on it,
> I need to simulate a click on that "button.selected". In this way kss
> stuff should run etc.
>
> I did something like:
> <script>
> function f(){
>     document.getElementById(my_id).click()
> }
> </script>
>
> but it works if applied on a standard button (e.g. <button
> tal:attributes="name string:theSubmitButton-$fieldName; id
> string:theSubmitButton-$fieldName;" onClick="alert('The button was
> clicked.');">...</button>), but not on kss-ed one...
>
> any hint?
>
> thanks, bye
>
> massimo
> _______________________________________________
> Kss-devel mailing list
> Kss-devel at codespeak.net
> http://codespeak.net/mailman/listinfo/kss-devel
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://codespeak.net/pipermail/kss-devel/attachments/20080527/265075c8/attachment.pgp 

From massimo.azzolini at gmail.com  Tue May 27 18:56:45 2008
From: massimo.azzolini at gmail.com (Massimo Azzolini)
Date: Tue, 27 May 2008 18:56:45 +0200
Subject: [Kss-devel] simulate mouse click
In-Reply-To: <483C1F58.70704@eurotux.com>
References: <ef1d3f8e0805270723j13f0d3a4h6e7cf52ab6177f3c@mail.gmail.com>
	<483C1F58.70704@eurotux.com>
Message-ID: <ef1d3f8e0805270956m6cd9c392x24914d87b836c254@mail.gmail.com>

On Tue, May 27, 2008 at 4:48 PM, Luis Miguel Braga <lmb at eurotux.com> wrote:
> Hi,
>
> Off the top of my head.... did you try triggering the kss click event?
> I mean triggering the event from inside kss. I know there are examples of
> this on the site.
>
ops, I didn't remember there were those examples.. I read them, thanks

max