From briang at webcollective.coop  Tue Mar  4 23:14:05 2008
From: briang at webcollective.coop (Brian Gershon)
Date: Tue, 4 Mar 2008 14:14:05 -0800
Subject: [Kss-devel] KSS: Inline editing on multiple rows of data
Message-ID: <AD513DFD-E4C5-45DC-AF50-BC6BBF306BFB@webcollective.coop>

Greetings!

I hope you can point me in the right direction.

What I want to do:

I have multiple rows of fields in a table.  One field is each row is  
"Due Date". I want to click on the Due Date, have a text box appear,  
change date and save.

Problem:

Everything is going well, except for the initial "click on Due Date to  
bring up a form".

When I click, the forms open up for ALL rows.  Each row has a field  
like this, and by default <div class="editform"> is hidden  
via .hiddenform style:

<div class="action-due-section">
    <span class="action-due label">2008/02/25</span>
    <div class="editform">
       <input class="dueDateField" value="2008/02/25"/>
       <input class="change" type="button" value="change"/>
       <input class="cancel" type="button" value="cancel"/>
    </div>
</div>

(my KSS is below)

I think the answer is "parentnode" so when they click on 2008/02/25 I  
can ultimately find div.editform and unhide it.

Problem: If I use css() selector I get all rows, though unfortunately  
the parentnode of "2008/02/05" is the <span> tag, and not the <div  
class="action-due-section">.

I don't want to use htmlid() because I'm not sure how to dynamically  
id each row in KSS -- so hoping to just work on the parent HTML (and  
children) (and not the whole DOM).

Is there a better way to restructure my HTML?  Or how do I get the  
parent of a parent?

Thanks,
-Brian

ps: My cancel button successfully hides the fields in just that row  
because the parentnode() correctly grabs the <iv class="editform">

pps: My KSS:

/* show edit form when label clicked */
div.action-due-section span.label:click {
     evt-click-preventdefault: true;

     action-client: toggleClass;
     toggleClass-kssSelector: css("div.editform");
     toggleClass-value: hiddenform;
}

/* hide form for one row */
input.cancel:click {
     action-client: toggleClass;
     toggleClass-kssSelector: parentnode("div.editform");
     toggleClass-value: hiddenform;
     }


From jeroen.vloothuis at xs4all.nl  Wed Mar  5 00:15:00 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Wed, 05 Mar 2008 00:15:00 +0100
Subject: [Kss-devel] KSS: Inline editing on multiple rows of data
In-Reply-To: <AD513DFD-E4C5-45DC-AF50-BC6BBF306BFB@webcollective.coop>
References: <AD513DFD-E4C5-45DC-AF50-BC6BBF306BFB@webcollective.coop>
Message-ID: <47CDD7F4.6@xs4all.nl>

Brian Gershon wrote:
> When I click, the forms open up for ALL rows.  Each row has a field  
> like this, and by default <div class="editform"> is hidden  
> via .hiddenform style:
>
> <div class="action-due-section">
>     <span class="action-due label">2008/02/25</span>
>     <div class="editform">
>        <input class="dueDateField" value="2008/02/25"/>
>        <input class="change" type="button" value="change"/>
>        <input class="cancel" type="button" value="cancel"/>
>     </div>
> </div>
>   
You could do something like:


/* show edit form when label clicked */
div.action-due-section span.label:click {
 evt-click-preventdefault: true;
 action-client: toggleClass;
 toggleClass-kssSelector: parentnode("div.editform");
 toggleClass-value: hiddenform;
}


Then you should make your CSS something like:

.hiddenform .editform {
  display: none;
}


The trick here is that you are actually toggling the class name on the 
outer div but you let the CSS rule apply through that. So after (and you 
probably want to have this a page load time as well) toggling the HTML 
would become:

<div class="action-due-section hiddenform">
    <span class="action-due label">2008/02/25</span>
    <div class="editform">
...  

Now if you look at the CSS snippet above you can see how it first 
selects .hiddenform and than any node below with the editform class name.

From ree at ree.hu  Thu Mar  6 08:15:58 2008
From: ree at ree.hu (Balazs Ree)
Date: Thu, 6 Mar 2008 08:15:58 +0100
Subject: [Kss-devel] kss and extjs (was: TR : 18 Things I Wish Were True
 About Plone)
References: <op.t5qo4sa8vhba00@ts42loaner>
	<8FAF06163E22434EACB677AD054EF89102A3BAE6@sm-exchange.groupesm.com>
	<15211310.post@talk.nabble.com> <15853490.post@talk.nabble.com>
	<FD42410A498C56418806170D067392E403D53331@DAEMSG03.eur.ad.sag>
Message-ID: <pan.2008.03.06.07.15.32@ree.hu>

On Wed, 05 Mar 2008 16:58:37 +0100, Mignon, Laurent wrote:

> On our current project, Gotcha has experienced the intergration of the
> extjs grid control with plone and kss to display the content of a
> folder.

> All this work is not finalized and was done for a POC,..

> For me, it's sure that the future for Plone UI is extjs + kss + ...

Sounds interesting. Is there going to be a kss plugin as a result?

When can we expect the code to be public?

p.s. I'm also cc-ing this to kss-devel, since it may interest other 
people,

-- 
Balazs Ree


From gotcha at bubblenet.be  Thu Mar  6 09:21:59 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Thu, 06 Mar 2008 09:21:59 +0100
Subject: [Kss-devel] kss and extjs
In-Reply-To: <pan.2008.03.06.07.15.32@ree.hu>
References: <op.t5qo4sa8vhba00@ts42loaner>	<8FAF06163E22434EACB677AD054EF89102A3BAE6@sm-exchange.groupesm.com>	<15211310.post@talk.nabble.com>
	<15853490.post@talk.nabble.com>	<FD42410A498C56418806170D067392E403D53331@DAEMSG03.eur.ad.sag>
	<pan.2008.03.06.07.15.32@ree.hu>
Message-ID: <47CFA9A7.1040706@bubblenet.be>

Balazs Ree wrote:
> On Wed, 05 Mar 2008 16:58:37 +0100, Mignon, Laurent wrote:
> 
>> On our current project, Gotcha has experienced the intergration of the
>> extjs grid control with plone and kss to display the content of a
>> folder.
> 
>> All this work is not finalized and was done for a POC,..
> 
>> For me, it's sure that the future for Plone UI is extjs + kss + ...
> 
> Sounds interesting. Is there going to be a kss plugin as a result?

The customer needs to make a decision. If it is positive, there will be 
a plugin in a public repository.

Until now, it has only been hacking a proof of concept...

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

From kev at coolcavemen.com  Thu Mar  6 18:48:13 2008
From: kev at coolcavemen.com (kev at coolcavemen.com)
Date: Thu, 06 Mar 2008 18:48:13 +0100
Subject: [Kss-devel] Default compression method fail (patch included)
Message-ID: <1204825693.47d02e5d318ca@imp.ovh.net>

Hi !

Under some circumstances, the compression method of KSS fallback to the
default method. This mecanism is implemented in
kss.core.pluginregistry._concatresource.compression.

I've spotted an error in this file when the content_type is not
application/x-javascript or text/css.

Here is the error I get:

  Module kss.core.pluginregistry._concatresource.compression, line 20, in
compress
  018 |    'Returns compressed text for a given content type'
  019 |    method = compress_methods.get(content_type, default_compress_method)
  020>|    return method(data, compress_level)
  TypeError: <lambda>() takes exactly 1 argument (2 given)

Please find as an attachment my patch to fix this problem (file:
default-compress-method-argument-number.diff).

Do you think it's a good idea to commit it in the trunk ? If you don't have
time, I can commit it for you if you give me an access to the repository.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default-compress-method-argument-number.diff
Type: application/octet-stream
Size: 513 bytes
Desc: not available
Url : http://codespeak.net/pipermail/kss-devel/attachments/20080306/18983b43/attachment.obj 

From ree at ree.hu  Fri Mar  7 09:34:12 2008
From: ree at ree.hu (Balazs Ree)
Date: Fri, 7 Mar 2008 09:34:12 +0100
Subject: [Kss-devel] Default compression method fail (patch included)
References: <1204825693.47d02e5d318ca@imp.ovh.net>
Message-ID: <pan.2008.03.07.08.33.47@ree.hu>

Hi,

thanks for your report!

However: I am sorry but the way I am reading this list (via the news 
interface), make me ask these questions:

- Who are you? I see no signature at the end of yout letter, and you are 
probably aware that in some systems (like gmane) the sender email is 
deprecated for security, so I don't see who you are from your email 
either.

- I also don't see your patch attached, but it's not a big problem at the 
moment, see my remark below.


On Thu, 06 Mar 2008 18:48:13 +0100, kev-yavNWJ2Ar3iEqOdQ7c3UMQ wrote:!
> Under some circumstances, the compression method of KSS fallback to the
> default method. This mecanism is implemented in
> kss.core.pluginregistry._concatresource.compression.

> I've spotted an error in this file when the content_type is not
> application/x-javascript or text/css.

Can you please provide some more details, on why this is needed? In what 
circumstances can it happen that the javascript file's mimetype is not 
application/x-javascript?


> Do you think it's a good idea to commit it in the trunk ? If you don't
> have time, I can commit it for you if you give me an access to the
> repository.

Before thinking of a fix, please provide more details to convince us that 
we really need this change. We absolutely need to understand and 
reproduce the problem before taking any more action about the issue.

Best wishes,

-- 
Balazs Ree


From jeroen.vloothuis at xs4all.nl  Fri Mar  7 22:56:53 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Fri, 07 Mar 2008 22:56:53 +0100
Subject: [Kss-devel] Default compression method fail (patch included)
In-Reply-To: <pan.2008.03.07.08.33.47@ree.hu>
References: <1204825693.47d02e5d318ca@imp.ovh.net>
	<pan.2008.03.07.08.33.47@ree.hu>
Message-ID: <47D1BA25.2030809@xs4all.nl>

Balazs Ree wrote:
>> Do you think it's a good idea to commit it in the trunk ? If you don't
>> have time, I can commit it for you if you give me an access to the
>> repository.
>>     
>
> Before thinking of a fix, please provide more details to convince us that 
> we really need this change. We absolutely need to understand and 
> reproduce the problem before taking any more action about the issue.
>   
The change just seems to fix the number of parameters of a lambda which 
is used as a callback. Afaik we should just create a test to make sure 
it does not break again (and is supposed to have two arguments). 
Discussing the need for this behavior seems irrelevant since the code is 
already there, its just broken.

From gotcha at bubblenet.be  Sat Mar  8 08:56:36 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Sat, 08 Mar 2008 08:56:36 +0100
Subject: [Kss-devel] Default compression method fail (patch included)
In-Reply-To: <47D1BA25.2030809@xs4all.nl>
References: <1204825693.47d02e5d318ca@imp.ovh.net>	<pan.2008.03.07.08.33.47@ree.hu>
	<47D1BA25.2030809@xs4all.nl>
Message-ID: <47D246B4.5040304@bubblenet.be>

Jeroen Vloothuis wrote:
> Balazs Ree wrote:
>>> Do you think it's a good idea to commit it in the trunk ? If you don't
>>> have time, I can commit it for you if you give me an access to the
>>> repository.
>>>     
>> Before thinking of a fix, please provide more details to convince us that 
>> we really need this change. We absolutely need to understand and 
>> reproduce the problem before taking any more action about the issue.
>>   
> The change just seems to fix the number of parameters of a lambda which 
> is used as a callback. Afaik we should just create a test to make sure 
> it does not break again (and is supposed to have two arguments). 
> Discussing the need for this behavior seems irrelevant since the code is 
> already there, its just broken.

I think you are right.

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


From ree at ree.hu  Sat Mar  8 09:10:08 2008
From: ree at ree.hu (Balazs Ree)
Date: Sat, 8 Mar 2008 09:10:08 +0100
Subject: [Kss-devel] Default compression method fail (patch included)
References: <1204825693.47d02e5d318ca@imp.ovh.net>
	<pan.2008.03.07.08.33.47@ree.hu> <47D1BA25.2030809@xs4all.nl>
Message-ID: <pan.2008.03.08.08.10.17@ree.hu>

On Fri, 07 Mar 2008 22:56:53 +0100, Jeroen Vloothuis wrote:

> Balazs Ree wrote:
>>> Do you think it's a good idea to commit it in the trunk ? If you don't
>>> have time, I can commit it for you if you give me an access to the
>>> repository.
>>>     
>>>     
>> Before thinking of a fix, please provide more details to convince us
>> that we really need this change. We absolutely need to understand and
>> reproduce the problem before taking any more action about the issue.
>>   
> The change just seems to fix the number of parameters of a lambda which
> is used as a callback. Afaik we should just create a test to make sure
> it does not break again (and is supposed to have two arguments).
> Discussing the need for this behavior seems irrelevant since the code is
> already there, its just broken.

I'm still interested in why we need the fix. The selection of compression 
type is there in the code, because originally I thought it would be a 
general purpose utility. However this did not happen we (from kss) don't 
use it for anything else then compressing javascript. Note that in the 
next version of kss this piece of code even goes away. Maybe the solution 
is to backport this from the new kss.base code and let the compression 
type selection go away completely, maybe we should apply the fix 
suggested, or maybe just leave it like it is. We have more options and it 
all depends on _why_ this problem occured.

So what I'd like to see is a bugreport with

- a full traceback producing the problem
- description of steps that lead to the problem
- a test that reproduces the problem

We use this code in kss for years without any problems. If someone 
suddenly experiences problems, it is most certainly because of changed 
use conditions. I want to know about these changed conditions, before 
touching the code that actually has been stable for a while.

If the current code causes problems, we definitely want to change it so 
the problem goes away, and we want the best solution to fix it. But 
applying a fix without understanding the problem that we want to fix, 
seems the wrong way for me.

So without any further explanation, I demand more information from the 
original reporter of this bug.

-- 
Balazs Ree


From victor.fernandez at upcnet.es  Sat Mar  8 10:53:43 2008
From: victor.fernandez at upcnet.es (Victor Fernandez de Alba)
Date: Sat, 8 Mar 2008 10:53:43 +0100
Subject: [Kss-devel] KSS enabled SiteUser Autocomplete widget
Message-ID: <00fe01c88102$4ef49a70$ecddcf50$@fernandez@upcnet.es>

Hi,

 

I?ve been trying to develop an AT widget that would search the PAS for all
the available users in the site. It would be great if that widget will have
the autocomplete feature. The idea came from a widget I liked very much that
the dojo library have and I wanted to create an AT widget that emule its
behavior. 

 

It would be of a great use for those who have a large user databases such as
LDAP based ones, as is my case.

 

I borrowed the code from the ?sharing? tab which already use KSS to search
the PAS, and I managed to integrate it in a widget. Then, created a new KSS
file and register it to the portal_kss with a set of modified definitions
from the one uses the ?sharing? tab. It works perfectly. Now I?m stuck on
adding the autocomplete behavior. I?ve tried the KSS events keypress, keyup,
keydown with no effect
 However, I?ve tried with another type of event, and
worked, like timeout or change
 Any ideas?

 

 

----------------------------------------------

V?ctor Fern?ndez de Alba Encinas

Projectes Tecnol?gics

UPCnet

Edifici M?ster's - Pedro i Pons, 9, 9?

08034 BARCELONA

Tel. centraleta: 93 401 16 00

----------------------------------------------

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/kss-devel/attachments/20080308/ba10f3a7/attachment.htm 

From gotcha at bubblenet.be  Sat Mar  8 11:29:39 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Sat, 08 Mar 2008 11:29:39 +0100
Subject: [Kss-devel] KSS enabled SiteUser Autocomplete widget
In-Reply-To: <35722.4824409515$1204970628@news.gmane.org>
References: <35722.4824409515$1204970628@news.gmane.org>
Message-ID: <47D26A93.5080002@bubblenet.be>

Victor Fernandez de Alba wrote:
> Hi,
> 
>  
> 
> I?ve been trying to develop an AT widget that would search the PAS for 
> all the available users in the site. It would be great if that widget 
> will have the autocomplete feature. The idea came from a widget I liked 
> very much that the dojo library have and I wanted to create an AT widget 
> that emule its behavior.
> 
>  
> 
> It would be of a great use for those who have a large user databases 
> such as LDAP based ones, as is my case.
> 
>  
> 
> I borrowed the code from the ?sharing? tab which already use KSS to 
> search the PAS, and I managed to integrate it in a widget. Then, created 
> a new KSS file and register it to the portal_kss with a set of modified 
> definitions from the one uses the ?sharing? tab. It works perfectly. 

Great !

> Now I?m stuck on adding the autocomplete behavior. I?ve tried the KSS events 
> keypress, keyup, keydown with no effect? However, I?ve tried with 
> another type of event, and worked, like timeout or change? Any ideas?
>
> V?ctor Fern?ndez de Alba Encinas

I am afraid the autocomplete part needs to happen in JS code.

Balazs has worked on code that autocomples/live searches content :

http://svn.plone.org/svn/collective/Products.CMFBibliographyAT/branches/ree-martior-kss/

I have no idea how easy it would be to make it work with PAS as well.


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


From gotcha at bubblenet.be  Sat Mar  8 11:29:39 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Sat, 08 Mar 2008 11:29:39 +0100
Subject: [Kss-devel] KSS enabled SiteUser Autocomplete widget
In-Reply-To: <35722.4824409515$1204970628@news.gmane.org>
References: <35722.4824409515$1204970628@news.gmane.org>
Message-ID: <47D26A93.5080002@bubblenet.be>



Victor Fernandez de Alba wrote:
> Hi,
> 
>  
> 
> I?ve been trying to develop an AT widget that would search the PAS for 
> all the available users in the site. It would be great if that widget 
> will have the autocomplete feature. The idea came from a widget I liked 
> very much that the dojo library have and I wanted to create an AT widget 
> that emule its behavior.
> 
>  
> 
> It would be of a great use for those who have a large user databases 
> such as LDAP based ones, as is my case.
> 
>  
> 
> I borrowed the code from the ?sharing? tab which already use KSS to 
> search the PAS, and I managed to integrate it in a widget. Then, created 
> a new KSS file and register it to the portal_kss with a set of modified 
> definitions from the one uses the ?sharing? tab. It works perfectly. 

Great !

> Now I?m stuck on adding the autocomplete behavior. I?ve tried the KSS events 
> keypress, keyup, keydown with no effect? However, I?ve tried with 
> another type of event, and worked, like timeout or change? Any ideas?
>
> V?ctor Fern?ndez de Alba Encinas

I am afraid the autocomplete part needs to happen in JS code.

Balazs has worked on code that autocomples/live searches content :

http://svn.plone.org/svn/collective/Products.CMFBibliographyAT/branches/ree-martior-kss/

I have no idea how easy it would be to make it work with PAS as well.


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


From optilude at gmx.net  Sat Mar  8 15:30:47 2008
From: optilude at gmx.net (Martin Aspeli)
Date: Sat, 08 Mar 2008 14:30:47 +0000
Subject: [Kss-devel] KSS enabled SiteUser Autocomplete widget
In-Reply-To: <35722.4824409515$1204970628@news.gmane.org>
References: <35722.4824409515$1204970628@news.gmane.org>
Message-ID: <fqu7uo$hhu$1@ger.gmane.org>

Victor Fernandez de Alba wrote:
> Hi,
> 
>  
> 
> I?ve been trying to develop an AT widget that would search the PAS for 
> all the available users in the site. It would be great if that widget 
> will have the autocomplete feature. The idea came from a widget I liked 
> very much that the dojo library have and I wanted to create an AT widget 
> that emule its behavior.
> 
>  
> 
> It would be of a great use for those who have a large user databases 
> such as LDAP based ones, as is my case.
> 
>  
> 
> I borrowed the code from the ?sharing? tab which already use KSS to 
> search the PAS, and I managed to integrate it in a widget. Then, created 
> a new KSS file and register it to the portal_kss with a set of modified 
> definitions from the one uses the ?sharing? tab. It works perfectly. Now 
> I?m stuck on adding the autocomplete behavior. I?ve tried the KSS events 
> keypress, keyup, keydown with no effect? However, I?ve tried with 
> another type of event, and worked, like timeout or change? Any ideas?

This isn't an Archetypes widget (yet) and it doesn't yet use AJAX in the 
released version, but the UberSelectionWidget aims to give you a 
search-based interface to this kind of thing. We already have a (Zope 3 
style) vocabulary (which you can use in Archetypes as of Plone 3, just 
give its name in the vocabulary_factory option) that enables you to find 
users by searching.

If you look at borg.project or oi.plum (both in the collective) you'll 
see this in action for selecting users that are members of a project.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


From gotcha at bubblenet.be  Sun Mar  9 07:38:40 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Sun, 09 Mar 2008 07:38:40 +0100
Subject: [Kss-devel] KSS, Firefox 3 and selective-click
In-Reply-To: <c66fb64e0803081450q7c553bccw3be3bcc201ac92d4@mail.gmail.com>
References: <c66fb64e0803081450q7c553bccw3be3bcc201ac92d4@mail.gmail.com>
Message-ID: <47D385F0.1030409@bubblenet.be>

Malthe Borch wrote:
> Godefroid, ??
> 
> First, I've tried out KSS in Firefox 3, and it complains with a syntax
> error in base2-dom-fp.js. Are you aware of this?

Nope, can you report the problem on

http://code.google.com/p/base2/issues/list

and let us know ? This way, we can follow up...

> 
> Secondly, I can't seem to get my head around the KSS rules required to
> have the following flow:
> 
> A delete-button where the user first clicks once, then a class
> 'clicked' is appended to the class-attribute, then he clicks again,
> and a server-action is carried out.
> 
> ``selected-click`` seems to be the way here, but it complains about
> some namespace error or plugin error.

I have no idea what you mean by selected-click

However, there are currently no way in KSS to only change a class and 
have new comportment bound.

You need to replace the HTML in order for KSS events to be bound.

I'd try sthing like this :

button:click {
     action-client:replaceHTML;
     replaceHTML-html:"<button value="Ok" class="clicked" />"
}

button.clicked:click {
     action-server:blabla;
}

> 
> Suggestions?
> 
> \malthe
> 
> --=====================--
>   mail: mborch at gmail.com
>   homepage: zeitmaschine.dk
> --=====================--


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

From mborch at gmail.com  Sun Mar  9 14:39:10 2008
From: mborch at gmail.com (Malthe Borch)
Date: Sun, 09 Mar 2008 14:39:10 +0100
Subject: [Kss-devel] API change in base2
Message-ID: <fr0p9r$pc3$1@ger.gmane.org>

It seems in base2 1.0 beta, the matchAll-method has been renamed to 
querySelectorAll. I changed this locally in dom.js:96 and it seems to work.

Note that this version of base2 is larger in size, but gzipped it's only 
1.5 kb more.

\malthe


From mborch at gmail.com  Sun Mar  9 10:04:32 2008
From: mborch at gmail.com (Malthe Borch)
Date: Sun, 9 Mar 2008 10:04:32 +0100
Subject: [Kss-devel] KSS, Firefox 3 and selective-click
In-Reply-To: <47D385F0.1030409@bubblenet.be>
References: <c66fb64e0803081450q7c553bccw3be3bcc201ac92d4@mail.gmail.com>
	<47D385F0.1030409@bubblenet.be>
Message-ID: <c66fb64e0803090104g2dd1e109u3672d74598bf0bbe@mail.gmail.com>

On 09/03/2008, Godefroid Chapelle <gotcha at bubblenet.be> wrote:
>  > First, I've tried out KSS in Firefox 3, and it complains with a syntax
>  > error in base2-dom-fp.js. Are you aware of this?
>
>
> Nope, can you report the problem on
>
>  http://code.google.com/p/base2/issues/list

Now reported as issue 77. I think the issue might already have been
resolved in a newer version of the library, but it seems not
compatible with the KSS-libraries.

\malthe

From mborch at gmail.com  Sun Mar  9 11:20:50 2008
From: mborch at gmail.com (Malthe Borch)
Date: Sun, 9 Mar 2008 11:20:50 +0100
Subject: [Kss-devel] continueEvent issue
Message-ID: <c66fb64e0803090320q59e8af4fx8768ee336f2e53d2@mail.gmail.com>

I'm trying to get the annoyClicker-example to work. This is my plugin source:

  http://paste.plone.org/20033

I'm using it with these rules:

#region-inspector .inspectorActions a.deleteButton:selective-click(delete) {
    evt-selective-click-count: 2;
}

behavior:selective-doit(delete) {
    action-server: deletePage;
}

But I get this error message:

[Exception... "'Error: Could not trigger event name [doit] on
namespace [selective], because there is neither an explicit KSS rule,
nor a default method' when calling method:
[nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001c
(NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "<unknown>"  data: no]
http://localhost:8080/voodoo1/@@/kss.core.kukit/3rd_party/base2-dom-fp.js
Line 1

Any clues?

From ree at ree.hu  Sun Mar  9 19:08:50 2008
From: ree at ree.hu (Balazs Ree)
Date: Sun, 9 Mar 2008 19:08:50 +0100
Subject: [Kss-devel] API change in base2
References: <fr0p9r$pc3$1@ger.gmane.org>
Message-ID: <pan.2008.03.09.18.08.59@ree.hu>

On Sun, 09 Mar 2008 14:39:10 +0100, Malthe Borch wrote:

> It seems in base2 1.0 beta, the matchAll-method has been renamed to
> querySelectorAll. I changed this locally in dom.js:96 and it seems to
> work.
> 
> Note that this version of base2 is larger in size, but gzipped it's only
> 1.5 kb more.

Thanks Malthe for spotting this! If there are no objections I would make
the kss code test for both versions, this would allow it to operate with
both api versions.

I will also start to test the new version and in case no problems occur,
we could upgrade the version shipped with kss as well. This is not
risky, because we will always be able to downgrade just the resource,
without touching the kss code.

-- 
Balazs Ree


From ree at ree.hu  Sun Mar  9 19:26:44 2008
From: ree at ree.hu (Balazs Ree)
Date: Sun, 9 Mar 2008 19:26:44 +0100
Subject: [Kss-devel] continueEvent issue
References: <c66fb64e0803090320q59e8af4fx8768ee336f2e53d2@mail.gmail.com>
Message-ID: <pan.2008.03.09.18.26.53@ree.hu>

On Sun, 09 Mar 2008 11:20:50 +0100, Malthe Borch wrote:

> I'm trying to get the annoyClicker-example to work. This is my plugin
> source:
> 
>   http://paste.plone.org/20033
> 
> I'm using it with these rules:
> 
> #region-inspector .inspectorActions
> a.deleteButton:selective-click(delete) {
>     evt-selective-click-count: 2;
> }
> 
> behavior:selective-doit(delete) {
>     action-server: deletePage;
> }
> 
> But I get this error message:
> 
> [Exception... "'Error: Could not trigger event name [doit] on namespace
> [selective], because there is neither an explicit KSS rule, nor a
> default method' when calling method: [nsIDOMEventListener::handleEvent]"
>  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location:
> "<unknown>"  data: no]



The full, dashed namespace name must be used in the continueEvent call.


this.continueEvent('selective-doit', oper.node, {});

and

this.continueEvent('selective-annoy', oper.node, {});


As a main rule, kss names (events, actions and all) always require their 
fully namespaced (dashed) form. (This was not a strict policy earlier, 
and I believe that the current way of handling is more logical and also 
simplified the kss core code.) 

For example:

"doit"               would be a name in the default namespace, which is 
                     not defined
"selective-doit"     is the doit event in the "selective" namespace

In the future we may also support namespaces with more levels (it is just 
a question of decision, because the code can already support this).

(As a little annoyance, no BBB could be provided in this case, but this 
part of the api was also not officially stable and documented either.)

It may be a good idea to add a hint about the namespace issue at the end 
of this error message though.


-- 
Balazs Ree


From jeroen.vloothuis at xs4all.nl  Sun Mar  9 21:35:45 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Sun, 09 Mar 2008 21:35:45 +0100
Subject: [Kss-devel] API change in base2
In-Reply-To: <pan.2008.03.09.18.08.59@ree.hu>
References: <fr0p9r$pc3$1@ger.gmane.org> <pan.2008.03.09.18.08.59@ree.hu>
Message-ID: <47D44A21.4040202@xs4all.nl>

Balazs Ree wrote:
> On Sun, 09 Mar 2008 14:39:10 +0100, Malthe Borch wrote:
>
>   
>> It seems in base2 1.0 beta, the matchAll-method has been renamed to
>> querySelectorAll. I changed this locally in dom.js:96 and it seems to
>> work.
>>
>> Note that this version of base2 is larger in size, but gzipped it's only
>> 1.5 kb more.
>>     
>
> Thanks Malthe for spotting this! If there are no objections I would make
> the kss code test for both versions, this would allow it to operate with
> both api versions.
>   
I was thinking about a way of making it possible to be less depended on 
specific checks. The reason for this is that although jquery may seem a 
bit slower it might be good enough for some (non Plone) applications. If 
these applications already use jquery for something else they should not 
have to drag in base2 just to use KSS.

The way I propose to handle this is to make a namespace for utility 
functions like CSS selectors. We could also put handy functions like 
forEach etc. in there (which in most cases would just be aliases to the 
functions from base2 / jquery etc.).

If we implement it like this you would just need to toggle which 
javascript file is loaded (using the plugin system).

From ree at ree.hu  Mon Mar 10 07:44:52 2008
From: ree at ree.hu (Balazs Ree)
Date: Mon, 10 Mar 2008 07:44:52 +0100
Subject: [Kss-devel] API change in base2
References: <fr0p9r$pc3$1@ger.gmane.org> <pan.2008.03.09.18.08.59@ree.hu>
	<47D44A21.4040202@xs4all.nl>
Message-ID: <pan.2008.03.10.06.45.01@ree.hu>

On Sun, 09 Mar 2008 21:35:45 +0100, Jeroen Vloothuis wrote:

> Balazs Ree wrote:
>> On Sun, 09 Mar 2008 14:39:10 +0100, Malthe Borch wrote:
>>
>>
>>> It seems in base2 1.0 beta, the matchAll-method has been renamed to
>>> querySelectorAll. I changed this locally in dom.js:96 and it seems to
>>> work.
>>>
>>> Note that this version of base2 is larger in size, but gzipped it's
>>> only 1.5 kb more.
>>>     
>>>     
>> Thanks Malthe for spotting this! If there are no objections I would
>> make the kss code test for both versions, this would allow it to
>> operate with both api versions.
>>   
> I was thinking about a way of making it possible to be less depended on
> specific checks. The reason for this is that although jquery may seem a
> bit slower it might be good enough for some (non Plone) applications. If
> these applications already use jquery for something else they should not
> have to drag in base2 just to use KSS.
> 
> The way I propose to handle this is to make a namespace for utility
> functions like CSS selectors. We could also put handy functions like
> forEach etc. in there (which in most cases would just be aliases to the
> functions from base2 / jquery etc.).
> 
> If we implement it like this you would just need to toggle which
> javascript file is loaded (using the plugin system).


You are banging on open doors! The proposal for this is on launchpad 
since quite some time:

http://paste.plone.org/20033

I really remember having discussed this with you personally on more 
occasions, but from your reaction it seems that I may be wrong. 
In any case, I tried to communicate the importance of this work on 
several occasion before to both the kss and the Plone developers, so I am 
glad to receive a positive reaction from you now.

The implementation for this has been finished in the first week of 
January, and is waiting for merge since then. I targeted this to be 
merged for version of kss 1.4, but in the end another decision has been 
made.

I will rebase this on the newest kukit trunk (will be quite some work sue 
to other merges since then), change the 
variable names as discussed with Godefroid on the snowsprint, and submit 
it for a second review. You can expect this within a few days

Besides the implementation of the service layer, the branch contains a 
generic refactored implementation of the entire kukit plugin system, as 
well as several very important code cleanup and a few algorithmic 
speedups as well.

I count on your positive vote for merge.

-- 
Balazs Ree


From jfroche at pyxel.be  Mon Mar 10 11:28:37 2008
From: jfroche at pyxel.be (=?ISO-8859-1?Q?Jean-Fran=E7ois_Roche?=)
Date: Mon, 10 Mar 2008 11:28:37 +0100
Subject: [Kss-devel] demo
Message-ID: <47D50D55.4010005@pyxel.be>

Hello,

  I was wondering if kss would help me to implement something, went to
the website and found out that the demonstration part is still empty so
I had to setup kss.demo

  I would be pleased to help you fill in some demo to
http://kssproject.org/demonstration/demonstration/ . I think it's really
important to really show what kss can do. Adding plone skin to kss.demo
would be enough ? And moving KssTheme to plone 3.0 ?

  Regards,

			Jeff

From gotcha at bubblenet.be  Mon Mar 10 11:33:07 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Mon, 10 Mar 2008 11:33:07 +0100
Subject: [Kss-devel] demo
In-Reply-To: <47D50D55.4010005@pyxel.be>
References: <47D50D55.4010005@pyxel.be>
Message-ID: <47D50E63.7050704@bubblenet.be>

Jean-Fran?ois Roche wrote:
> Hello,
> 
>   I was wondering if kss would help me to implement something, went to
> the website and found out that the demonstration part is still empty so
> I had to setup kss.demo
> 
>   I would be pleased to help you fill in some demo to
> http://kssproject.org/demonstration/demonstration/ . I think it's really
> important to really show what kss can do. Adding plone skin to kss.demo
> would be enough ? And moving KssTheme to plone 3.0 ?
> 
>   Regards,
> 
> 			Jeff

There is an improve-demos branch that needs to be merged.

Then we can setup a separate Zope instance that holds kss.core 1.4 and 
link the demo.

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

From jeroen.vloothuis at xs4all.nl  Mon Mar 10 18:57:02 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Mon, 10 Mar 2008 18:57:02 +0100
Subject: [Kss-devel] API change in base2
In-Reply-To: <pan.2008.03.10.06.45.01@ree.hu>
References: <fr0p9r$pc3$1@ger.gmane.org>
	<pan.2008.03.09.18.08.59@ree.hu>	<47D44A21.4040202@xs4all.nl>
	<pan.2008.03.10.06.45.01@ree.hu>
Message-ID: <47D5766E.8050306@xs4all.nl>

Balazs Ree wrote:
> You are banging on open doors! The proposal for this is on launchpad
> since quite some time:
>   

> I really remember having discussed this with you personally on more 
> occasions, but from your reaction it seems that I may be wrong.
I am sorry if I came across as being the inventor of the idea. We indeed 
discussed this at some time. My memory is not the most reliable in the 
world so please blame it on that  :-)
> The implementation for this has been finished in the first week of 
> January, and is waiting for merge since then. I targeted this to be 
> merged for version of kss 1.4, but in the end another decision has been 
> made.
>
> I will rebase this on the newest kukit trunk (will be quite some work sue 
> to other merges since then), change the 
> variable names as discussed with Godefroid on the snowsprint, and submit 
> it for a second review. You can expect this within a few days
>
> Besides the implementation of the service layer, the branch contains a 
> generic refactored implementation of the entire kukit plugin system, as 
> well as several very important code cleanup and a few algorithmic 
> speedups as well.
>   
Is it possible to split these changes from the kukit.service (as the 
blueprint seems to call it) part? I am not saying that these changes are 
not good. It just seems (from your description) that the branch changes 
several things at once which could be done in smaller chunks. Am I 
correct, or is there a reason for doing everything together?

The reason I bring this up is that I think it would be easier to merge a 
small patch which only touches a few lines vs something which would 
changes the plugin api. The Firefox 3 support for Plone 3.1 would be a 
great reason imho to make a small change to add the kukit.service. 
Especially since this can be considered a bug fix with relatively minor 
impact.

From ree at ree.hu  Tue Mar 11 08:16:42 2008
From: ree at ree.hu (Balazs Ree)
Date: Tue, 11 Mar 2008 08:16:42 +0100
Subject: [Kss-devel] API change in base2 vs. service layer
References: <fr0p9r$pc3$1@ger.gmane.org> <pan.2008.03.09.18.08.59@ree.hu>
	<47D44A21.4040202@xs4all.nl> <pan.2008.03.10.06.45.01@ree.hu>
	<47D5766E.8050306@xs4all.nl>
Message-ID: <pan.2008.03.11.07.16.51@ree.hu>

On Mon, 10 Mar 2008 18:57:02 +0100, Jeroen Vloothuis wrote:

> Balazs Ree wrote:
>> You are banging on open doors! The proposal for this is on launchpad
>> since quite some time:
>>   
>>   
>> I really remember having discussed this with you personally on more
>> occasions, but from your reaction it seems that I may be wrong.
> I am sorry if I came across as being the inventor of the idea. We indeed
> discussed this at some time. My memory is not the most reliable in the
> world so please blame it on that  :-)

I don't claim to be the originator of the idea about the "service layer", 
on the contrary, I believe we came to it together during previous 
verbal discussions with several developers.

I am rather thinking about a way that could assure that our blueprints 
become more visible for ourselves.

>> Besides the implementation of the service layer, the branch contains a
>> generic refactored implementation of the entire kukit plugin system, as
>> well as several very important code cleanup and a few algorithmic
>> speedups as well.

The service-layer branch is now targeted to 1.5 (current trunk), since 
there is no way to get it to 1.4 that is closed now.

About a partial backport, sure it would be possible but I am not sure if 
this would be good, for the following reasons:

- The main improvement of the service-layer branch is that it implements 
a single registry that handles all registration that depends on 
javascript source code. Then it bases the service interface (that we 
currently discuss) and all the other kss plugin registry as well, on top 
of a single implementation. If we only port back the service interfaces 
(that is, interfaces.js and service.js) we end up with more code without 
most of the expected benefits.

- Indeed the branch also brings a lot of small cleanups and fixes in the 
code. These became necessary one by one, during I implemented the main 
goals. In this sense this can be thought of a minimal set of refactoring 
that became necessary. I am afraid if we bring in a few things from the 
branch, we will end up needing the whole set of changes.

So I would suggest, that instead of backporting the whole service layer 
implementation to 1.4, we simply hardcode the swithching between the old 
and new base2 api, in the very same way as we do the swith between the 
old cssQuery and base2 (the way we imnplemented it together in our mini 
sprint in Amsterdam). This is just a few lines can happen on both 1.2 and 
1.4 branches. I would volunteer to do this asap, and I would be very glad 
if you could elaborate on the code after this.


Best wishes,


-- 
Balazs Ree


From gotcha at bubblenet.be  Tue Mar 11 09:31:48 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Tue, 11 Mar 2008 09:31:48 +0100
Subject: [Kss-devel] API change in base2 vs. service layer
In-Reply-To: <pan.2008.03.11.07.16.51@ree.hu>
References: <fr0p9r$pc3$1@ger.gmane.org>
	<pan.2008.03.09.18.08.59@ree.hu>	<47D44A21.4040202@xs4all.nl>
	<pan.2008.03.10.06.45.01@ree.hu>	<47D5766E.8050306@xs4all.nl>
	<pan.2008.03.11.07.16.51@ree.hu>
Message-ID: <47D64374.3010209@bubblenet.be>

Balazs Ree wrote:
> So I would suggest, that instead of backporting the whole service layer 
> implementation to 1.4, we simply hardcode the swithching between the old 
> and new base2 api, in the very same way as we do the swith between the 
> old cssQuery and base2 (the way we imnplemented it together in our mini 
> sprint in Amsterdam). This is just a few lines can happen on both 1.2 and 
> 1.4 branches. I would volunteer to do this asap, and I would be very glad 
> if you could elaborate on the code after this. 

+1

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


From jeroen.vloothuis at xs4all.nl  Tue Mar 11 23:37:42 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Tue, 11 Mar 2008 23:37:42 +0100
Subject: [Kss-devel] Superfluous view registration?
Message-ID: <47D709B6.8010700@xs4all.nl>

In kss.core's configure.zcml there is this small snippet:

    <!-- (non-kss) browser view -->
    <browser:page
          for="*"
          name="kss_view"
        permission="zope.Public"
        class=".browserview.KSSBrowserView"
        allowed_attributes="attach_error"
    </browser:page>

This seems to be used only by a single test (test_browserview.py). 
Should this be something which is only registered for the tests or does 
it have some actual use ?

From ree at ree.hu  Wed Mar 12 07:41:14 2008
From: ree at ree.hu (Balazs Ree)
Date: Wed, 12 Mar 2008 07:41:14 +0100
Subject: [Kss-devel] Superfluous view registration?
References: <47D709B6.8010700@xs4all.nl>
Message-ID: <pan.2008.03.12.06.41.24@ree.hu>

On Tue, 11 Mar 2008 23:37:42 +0100, Jeroen Vloothuis wrote:

> In kss.core's configure.zcml there is this small snippet:
> 
>     <!-- (non-kss) browser view -->
>     <browser:page
>           for="*"
>           name="kss_view"
>         permission="zope.Public"
>         class=".browserview.KSSBrowserView"
>         allowed_attributes="attach_error"
>     </browser:page>
> 
> This seems to be used only by a single test (test_browserview.py).
> Should this be something which is only registered for the tests or does
> it have some actual use ?

This is indeed not used by kss.core itself, but is implemented by 
kss.core and is used by applications, for the following:

If a server action gives an uncaught server side exception (including 
NotFound or Unauthorized), Zope renders a default error page. This view 
makes it possible that the default error page makes the server side 
exception information available for the client side, by "annotating" it 
into the page.

This is done in such a way that a kss command payload is produced that 
contains the error information. However unlike normal kss responses, the 
payload in this case is embedded into a html header (X-KSSCOMMANDS) in 
the response.

If the default error page is calling this up (like it happens in case of 
PLone), then the client side logger can actually log the server side 
error message into the (FireBug) log, instead of some meaningless error 
message "there was an error on the server".

This is, besides the unittest you mentioned, also completely tested in 
all variations in the "error" demo and selenium test. There is also a 
different zpt that is involved into the rendering of these type of 
payloads.  This kind of rendering (attaching the payload to a normal page 
response) is not used by kss for anything else then this error rendering, 
but it likely will be in the future, because it has some important 
although yet unexplored use cases (like sending some kss initially with 
the page, that can be useful in different caching scenario and for 
eventPush, etc.).

Sincerely,


-- 
Balazs Ree


From jeroen.vloothuis at xs4all.nl  Wed Mar 12 18:11:04 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Wed, 12 Mar 2008 18:11:04 +0100
Subject: [Kss-devel] Superfluous view registration?
In-Reply-To: <pan.2008.03.12.06.41.24@ree.hu>
References: <47D709B6.8010700@xs4all.nl> <pan.2008.03.12.06.41.24@ree.hu>
Message-ID: <47D80EA8.5040309@xs4all.nl>

Balazs Ree wrote:
> This is, besides the unittest you mentioned, also completely tested in 
> all variations in the "error" demo and selenium test.
No it is not tested in the Selenium tests. That is what made me think 
this was a useless view (since kss.zope does not load it and all 
Selenium tests ran fine). The Selenium test in question has this code:

    @kssaction
    def errTest(self, id, act):

What happens is that the `kssaction` decorator itself catches exceptions 
and returns an entirely different body (normal KSS style). Here is a 
small snippet of that code (from actionwrapper.py).

        try:
            result = self.f(obj, *arg, **kw)
        except KSSExplicitError, exc:
            # Clear all the commands, and emit an error command
            obj.commands.clear()
            obj.commands.add('error', None, message=str(exc))

So it seems that at the very least we have lack in our tests. What I 
would like to know is when would this view be used if `kssaction` seems 
to do it's own thing?

From ree at ree.hu  Wed Mar 12 19:05:16 2008
From: ree at ree.hu (Balazs Ree)
Date: Wed, 12 Mar 2008 19:05:16 +0100
Subject: [Kss-devel] Superfluous view registration?
References: <47D709B6.8010700@xs4all.nl> <pan.2008.03.12.06.41.24@ree.hu>
	<47D80EA8.5040309@xs4all.nl>
Message-ID: <pan.2008.03.12.18.05.26@ree.hu>

On Wed, 12 Mar 2008 18:11:04 +0100, Jeroen Vloothuis wrote:

> Balazs Ree wrote:
>> This is, besides the unittest you mentioned, also completely tested in
>> all variations in the "error" demo and selenium test.
> No it is not tested in the Selenium tests. That is what made me think
> this was a useless view (since kss.zope does not load it and all
> Selenium tests ran fine).

True, I would add that this also proves we need more work before we can 
release kss.zope - and there will be still other missing bits to 
discover. And even in kss.core, Selenium coverage is not yet 100% 
although it is closing. But indeed we miss something here.

> The Selenium test in question has this code:
> 
>     @kssaction
>     def errTest(self, id, act):
> 
> What happens is that the `kssaction` decorator itself catches exceptions
> and returns an entirely different body (normal KSS style). Here is a
> small snippet of that code (from actionwrapper.py).

There are more different cases that can happen, you refer one of them 
here and what you are looking for is in another case. We can have errors 
raised explicitely (KSSExplicitError, this is what you refer here), we 
have normal exceptions (that have a default zope error response, that's 
where the payload gets added in the headers), and we have timeouts. All 
these cases are handled differently (look at the buttons in the row in 
the selenium test). But you are right when you say that the Selenium 
tests are not complete, see my remark below.

 
>         try:
>             result = self.f(obj, *arg, **kw)
>         except KSSExplicitError, exc:
>             # Clear all the commands, and emit an error command
>             obj.commands.clear()
>             obj.commands.add('error', None, message=str(exc))
> 
> So it seems that at the very least we have lack in our tests.

Indeed. Let me count the things that we _do_ test though: on the server 
side we test that the method puts the kss payload correctly in the 
headers. On the client side, we test that the error message that is sent 
in the payload appears in the log correctly, in all the 3 different error 
scenarios (eplicit error, normal error, timeout, the latter is commented 
out though).

> What I
> would like to know is when would this view be used if `kssaction` seems
> to do it's own thing?

It's when there is a normal exception, and the default error template 
annotates the error information by using this method. Please have a look 
at how it is used in Plone with the default error template. (At least I 
hope it's not currently broken: another place where we will be safer once 
the psps proposal will have been implemented.)

If you could figure out how to substitute zope's default error template 
only for the context of this single test (or for all our tests) and not 
replace it globally, that would be a great thing and it would allow us to 
test the missing bit from Selenium but I could not figure out how to 
achieve it, at the time when I wrote this code and its tests.


-- 
Balazs Ree


From jeroen.vloothuis at xs4all.nl  Thu Mar 13 21:58:07 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Thu, 13 Mar 2008 21:58:07 +0100
Subject: [Kss-devel] Cleanup of kss.core (new kss.zope based branch)
Message-ID: <47D9955F.2070402@xs4all.nl>

The kss.core branch which builds on kss.zope has been cleaned of all the 
unneeded code. What is left is either tests (or related documents) or 
bbb imports or code.

While cleaning out kss.core I came across a few module which seem to 
have some use but that I am uncertain of how to handle these.

The first one is BeautifulSoup.py, this is imported from a plone.app.kss 
directly. Next is the unicode_quirks.py file. It is used from 
plone.app.kss as well (plonekssview.py).

My suggestion is to just to leave them in kss.core so that we can 
deprecate them at some later time.

The buildout for the kss.zope related work has been updated to match the 
trunk of Plone. All tests in de demo's pass and a Grok demo works.

To get the Plone trunk on kss.zope, this also includes the kss.demo 
package for the Selenium demos/tests:

svn co https://codespeak.net/svn/kukit/buildout/kss.zope

For the Grok demo:

bzr branch http://bazaar.launchpad.net/~jvloothuis/kssgrokdemo/trunk



From ree at ree.hu  Fri Mar 14 09:00:54 2008
From: ree at ree.hu (Balazs Ree)
Date: Fri, 14 Mar 2008 09:00:54 +0100
Subject: [Kss-devel] Cleanup of kss.core - sanitization of string and
	html params
References: <47D9955F.2070402@xs4all.nl>
Message-ID: <pan.2008.03.14.08.01.04@ree.hu>

On Thu, 13 Mar 2008 21:58:07 +0100, Jeroen Vloothuis wrote:

> The kss.core branch which builds on kss.zope has been cleaned of all the
> unneeded code. What is left is either tests (or related documents) or
> bbb imports or code.
> 
> While cleaning out kss.core I came across a few module which seem to
> have some use but that I am uncertain of how to handle these.
> 
> The first one is BeautifulSoup.py, this is imported from a plone.app.kss
> directly. Next is the unicode_quirks.py file. It is used from
> plone.app.kss as well (plonekssview.py).

I'll try to explain first, how these currently work in kss.core, and what 
is their functionality.

BeautifulSoup.py is an html parser that is used for sanitizing the html 
output, and its usage is enforced each time html is sent to the client. 
This is done each time an HTML parameter is added, by the addHtmlParam 
method, ie any time when the semantics of a parameter is "HTML".

The force_unicode method works similarly for adding parameters with a 
"string" semantics, ie. when addString is used. This makes sure that 
either plain ascii, or proper unicode is added (with an additional 
parameter that makes it possible to _explicitely_ enforce conversion from 
a given codepage other then utf8.) In case of faulty input an exception 
is raised on the server side.

> My suggestion is to just to leave them in kss.core so that we can
> deprecate them at some later time.

Before getting to the bbb policy at all, there is a more important 
question that raises.

The AddHtmlParam and AddStringParam, besides implementation reason that 
may occur differently in the case of kss.base, have a very important 
function. We do not only handle these parameter types disctintly from 
each other because we marshal them disctinctly on the kss command payload 
(which we may change in the next implementation), but precisely because 
we want to check and sanitize the parameter content on the server side. 
This altogether improves the quality of applications based on top of kss, 
and enables earlier caching of certain application errors.

I would like to refer to some of our earlier discussions when I tried to 
emphasize the importance of keeping the different addXXXParam methods 
based on the parameter's semantics, versus having a single addBlobParam 
method. (As in the IKSSCommand interface.) One of my reasons for doing so 
is that I am strongly on the point of view, that these sanitizations are 
very important. I keep standing on this point still at the moment. Apart 
from this importance, the other reason is that I believe that the switch 
to kss.zope should not cause any observable difference to the 
applications that are running on top of kss. It is important to nail down 
that he goal of kss.base - although it was a complete rewrite - is not 
redesigning the kss server side behaviour but to enable exactly the same 
behaviour that we currently have, on the level of plain python 
applications. We may want to do refactorizazion in the future but it must 
occur in a consecutive step, separated from the current porting effort.

Now, if implemented properly, this functionality belongs to the level of 
kss.base. I am not sure if this checking is implemented in kss.base and 
on what extent, but it seems not or not identically implemented to the 
way they currently are in kss.core. However I may be wrong at this point.

So the question that is raised: I offered some reasons above why I find 
this functionality important and to be kept. Do we have any reason to 
drop this functionality in the next release (based on kss.base)?

And what problems may possibly arise for existing applications and Plone, 
in particular, if we do so?

I believe we must discuss and answer these questions first, and decide 
the implementation and deprecation policy based on the decision we make.
 

> The buildout for the kss.zope related work has been updated to match the
> trunk of Plone. All tests in de demo's pass and a Grok demo works.

Obviously, tests were (again) missing in this case, otherwise they would 
not pass.

After deciding on the above mentioned question, what would follow?

If we decide to keep this checks, we must add additional tests to 
kss.core that check for the existence of the string and html checking and 
sanitization. Following this the tests must be moved or implemented in 
kss.base as well (together with the actual implementation of the 
sanitization, if missing.)

In case we decide to drop these checks, we must carefully check in real 
life scenarios, what errors or changed behaviour we get in case broken 
html or sting content is inserted to a kss command. If this is the case 
we may still consider if we redistribute BeautifulSoup in kss.zope 
because it is a very handy html parser that we used several times in 
applications that produce html content for kss, but in this case it will 
be just provided as a utility and not be used by kss.base/kss.core itself.


Best wishes

-- 
Balazs Ree


From gotcha at bubblenet.be  Fri Mar 14 10:23:56 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Fri, 14 Mar 2008 10:23:56 +0100
Subject: [Kss-devel] Cleanup of kss.core - sanitization of string and
 html params
In-Reply-To: <pan.2008.03.14.08.01.04@ree.hu>
References: <47D9955F.2070402@xs4all.nl> <pan.2008.03.14.08.01.04@ree.hu>
Message-ID: <47DA442C.5020102@bubblenet.be>

Balazs Ree wrote:
> On Thu, 13 Mar 2008 21:58:07 +0100, Jeroen Vloothuis wrote:
> 
>> The kss.core branch which builds on kss.zope has been cleaned of all the
>> unneeded code. What is left is either tests (or related documents) or
>> bbb imports or code.
>>
>> While cleaning out kss.core I came across a few module which seem to
>> have some use but that I am uncertain of how to handle these.
>>
>> The first one is BeautifulSoup.py, this is imported from a plone.app.kss
>> directly. Next is the unicode_quirks.py file. It is used from
>> plone.app.kss as well (plonekssview.py).
> 
> I'll try to explain first, how these currently work in kss.core, and what 
> is their functionality.
> 
> BeautifulSoup.py is an html parser that is used for sanitizing the html 
> output, and its usage is enforced each time html is sent to the client. 
> This is done each time an HTML parameter is added, by the addHtmlParam 
> method, ie any time when the semantics of a parameter is "HTML".
> 
> The force_unicode method works similarly for adding parameters with a 
> "string" semantics, ie. when addString is used. This makes sure that 
> either plain ascii, or proper unicode is added (with an additional 
> parameter that makes it possible to _explicitely_ enforce conversion from 
> a given codepage other then utf8.) In case of faulty input an exception 
> is raised on the server side.
> 
>> My suggestion is to just to leave them in kss.core so that we can
>> deprecate them at some later time.
> 
> Before getting to the bbb policy at all, there is a more important 
> question that raises.
> 
> The AddHtmlParam and AddStringParam, besides implementation reason that 
> may occur differently in the case of kss.base, have a very important 
> function. We do not only handle these parameter types disctintly from 
> each other because we marshal them disctinctly on the kss command payload 
> (which we may change in the next implementation), but precisely because 
> we want to check and sanitize the parameter content on the server side. 
> This altogether improves the quality of applications based on top of kss, 
> and enables earlier caching of certain application errors.
> 
> I would like to refer to some of our earlier discussions when I tried to 
> emphasize the importance of keeping the different addXXXParam methods 
> based on the parameter's semantics, versus having a single addBlobParam 
> method. (As in the IKSSCommand interface.) One of my reasons for doing so 
> is that I am strongly on the point of view, that these sanitizations are 
> very important. I keep standing on this point still at the moment. Apart 
> from this importance, the other reason is that I believe that the switch 
> to kss.zope should not cause any observable difference to the 
> applications that are running on top of kss. It is important to nail down 
> that he goal of kss.base - although it was a complete rewrite - is not 
> redesigning the kss server side behaviour but to enable exactly the same 
> behaviour that we currently have, on the level of plain python 
> applications. We may want to do refactorizazion in the future but it must 
> occur in a consecutive step, separated from the current porting effort.
> 
> Now, if implemented properly, this functionality belongs to the level of 
> kss.base. I am not sure if this checking is implemented in kss.base and 
> on what extent, but it seems not or not identically implemented to the 
> way they currently are in kss.core. However I may be wrong at this point.
> 
> So the question that is raised: I offered some reasons above why I find 
> this functionality important and to be kept. Do we have any reason to 
> drop this functionality in the next release (based on kss.base)?

Definitely no reason. I agree that html sanitizing and unicode nicety 
need to be kept.

And that they should go to kss.base.


> And what problems may possibly arise for existing applications and Plone, 
> in particular, if we do so?
> 
> I believe we must discuss and answer these questions first, and decide 
> the implementation and deprecation policy based on the decision we make.
>  
> 
>> The buildout for the kss.zope related work has been updated to match the
>> trunk of Plone. All tests in de demo's pass and a Grok demo works.
> 
> Obviously, tests were (again) missing in this case, otherwise they would 
> not pass.
> 
> After deciding on the above mentioned question, what would follow?
> 
> If we decide to keep this checks, we must add additional tests to 
> kss.core that check for the existence of the string and html checking and 
> sanitization. Following this the tests must be moved or implemented in 
> kss.base as well (together with the actual implementation of the 
> sanitization, if missing.)
> 
> In case we decide to drop these checks, we must carefully check in real 
> life scenarios, what errors or changed behaviour we get in case broken 
> html or sting content is inserted to a kss command. If this is the case 
> we may still consider if we redistribute BeautifulSoup in kss.zope 
> because it is a very handy html parser that we used several times in 
> applications that produce html content for kss, but in this case it will 
> be just provided as a utility and not be used by kss.base/kss.core itself.

FYI, BeautifulSoup is now available as an egg.

> 
> Best wishes
> 


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

From mborch at gmail.com  Fri Mar 14 13:08:37 2008
From: mborch at gmail.com (Malthe Borch)
Date: Fri, 14 Mar 2008 13:08:37 +0100
Subject: [Kss-devel] Cleanup of kss.core - sanitization of string and
	html params
In-Reply-To: <47DA442C.5020102@bubblenet.be>
References: <47D9955F.2070402@xs4all.nl> <pan.2008.03.14.08.01.04@ree.hu>
	<47DA442C.5020102@bubblenet.be>
Message-ID: <frdps3$g9a$1@ger.gmane.org>

Godefroid Chapelle wrote:
> FYI, BeautifulSoup is now available as an egg.

We might look into using lxml instead of BeautifulSoup to minimize 
dependencies. Many zope packages already depend on lxml.

\malthe


From jeroen.vloothuis at xs4all.nl  Fri Mar 14 21:30:27 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Fri, 14 Mar 2008 21:30:27 +0100
Subject: [Kss-devel] Cleanup of kss.core - sanitization of string and
 html params
In-Reply-To: <47DA442C.5020102@bubblenet.be>
References: <47D9955F.2070402@xs4all.nl> <pan.2008.03.14.08.01.04@ree.hu>
	<47DA442C.5020102@bubblenet.be>
Message-ID: <47DAE063.80909@xs4all.nl>

Godefroid Chapelle wrote:
> Balazs Ree wrote:
>   
>>> My suggestion is to just to leave them in kss.core so that we can
>>> deprecate them at some later time.
>>>       
>> The AddHtmlParam and AddStringParam, besides implementation reason that 
>> may occur differently in the case of kss.base, have a very important 
>> function. We do not only handle these parameter types disctintly from 
>> each other because we marshal them disctinctly on the kss command payload 
>> (which we may change in the next implementation), but precisely because 
>> we want to check and sanitize the parameter content on the server side. 
>> This altogether improves the quality of applications based on top of kss, 
>> and enables earlier caching of certain application errors.
>>     
>> So the question that is raised: I offered some reasons above why I find 
>> this functionality important and to be kept. Do we have any reason to 
>> drop this functionality in the next release (based on kss.base)?
>>     
According to you two things are handled by BeautifulSoup. One is 
validation and the other is automagically "fixing" data. I am against 
anything which tries to fix my HTML without my intervention, ss you 
might have guessed from me calling it automagic. This could lead to all 
sorts of weird problems which would take an app developer some serious 
time to figure out. I guess if they where anything like me they would be 
very displeased to find out that KSS was doing more than just sending 
the data over the wire.

The other thing you mentioned is checking. Checking implies that we know 
what is correct. It does seem a bit pretentious though to know what is 
valid. If I send some partial paragraph (<p> without an end) because a 
wysiwyg editor stored it like that should KSS explode on me? Even though 
for the application I am developing it would be fine? How do we handle 
new / upcomming tags or entities? Do we know in advance how a tag for a 
new HTML 6 (speculation) tag must be closed?

This also brings me to question the actual necessity of this validation. 
Plone and most other web tools / frameworks seem to be perfectly fine 
with not sanitizing or checking the generated HTML. Why would KSS be 
different?

> Definitely no reason. I agree that html sanitizing and unicode nicety 
> need to be kept.
>
> And that they should go to kss.base.
>   
The unicode is something different again. I think it would be o.k. to 
check for this in kss.base (in case it is not done ex- or implicitly 
already).

From mborch at gmail.com  Mon Mar 17 14:35:47 2008
From: mborch at gmail.com (Malthe Borch)
Date: Mon, 17 Mar 2008 14:35:47 +0100
Subject: [Kss-devel] Dev-egg link
Message-ID: <frls3f$tp$1@ger.gmane.org>

Would be nice if the KSS-packages had a link to trunk, e.g.

    http://codespeak.net/svn/lxml/trunk#egg=lxml-dev

This way, people can simply depend on lxml==dev (in this example).

For a package like megrok.kss which isn't really released, this is a 
nice way to not have to make a dev-tarball.

\malthe


From ree at ree.hu  Mon Mar 17 14:52:20 2008
From: ree at ree.hu (Balazs Ree)
Date: Mon, 17 Mar 2008 14:52:20 +0100
Subject: [Kss-devel] Dev-egg link
References: <frls3f$tp$1@ger.gmane.org>
Message-ID: <pan.2008.03.17.13.52.30@ree.hu>

On Mon, 17 Mar 2008 14:35:47 +0100, Malthe Borch wrote:

> Would be nice if the KSS-packages had a link to trunk, e.g.
> 
>     http://codespeak.net/svn/lxml/trunk#egg=lxml-dev
> 
> This way, people can simply depend on lxml==dev (in this example).
> 
> For a package like megrok.kss which isn't really released, this is a
> nice way to not have to make a dev-tarball.

Thanks for pointing tis out, and definitely. We attempt to do the same 
thing in relationship of the kss.demo and kss.core on the trunk and 
branches, too.

(Note kss.core itself does not depend on lxml or to any other package 
right now, but with megrok.kss this should be the right policy.)

The only thing I could not figure out, is that we also have to put the 
dependent package into version dependencies. However in this case 
kss.core==dev did not work well, I had to use kss.core>=dev as a 
"workaround". I hope you can figure this out correctly with the 
dependency between megrok.kss and lxml - or maybe between megrok.kss and 
kss.core as well, then I'd correct this in kss.demo as well. 

-- 
Balazs Ree


From mborch at gmail.com  Mon Mar 17 16:13:45 2008
From: mborch at gmail.com (Malthe Borch)
Date: Mon, 17 Mar 2008 16:13:45 +0100
Subject: [Kss-devel] Dev-egg link
In-Reply-To: <pan.2008.03.17.13.52.30@ree.hu>
References: <frls3f$tp$1@ger.gmane.org> <pan.2008.03.17.13.52.30@ree.hu>
Message-ID: <47DE8AA9.80403@gmail.com>

Balazs Ree wrote:
> (Note kss.core itself does not depend on lxml or to any other package 
> right now, but with megrok.kss this should be the right policy.)

I just referred to lxml as an example (completely unrelated) actully :-)

> The only thing I could not figure out, is that we also have to put the 
> dependent package into version dependencies. However in this case 
> kss.core==dev did not work well, I had to use kss.core>=dev as a 
> "workaround". I hope you can figure this out correctly with the 
> dependency between megrok.kss and lxml - or maybe between megrok.kss and 
> kss.core as well, then I'd correct this in kss.demo as well. 

Right I think I also could only get it to work by saying >=dev.


From ree at ree.hu  Mon Mar 17 16:48:13 2008
From: ree at ree.hu (Balazs Ree)
Date: Mon, 17 Mar 2008 16:48:13 +0100
Subject: [Kss-devel] Dev-egg link
References: <frls3f$tp$1@ger.gmane.org> <pan.2008.03.17.13.52.30@ree.hu>
	<47DE8AA9.80403@gmail.com>
Message-ID: <pan.2008.03.17.15.48.23@ree.hu>

On Mon, 17 Mar 2008 16:13:45 +0100, Malthe Borch wrote:

> Balazs Ree wrote:

>> The only thing I could not figure out, is that we also have to put the
>> dependent package into version dependencies. However in this case
>> kss.core==dev did not work well, I had to use kss.core>=dev as a
>> "workaround". I hope you can figure this out correctly with the
>> dependency between megrok.kss and lxml - or maybe between megrok.kss
>> and kss.core as well, then I'd correct this in kss.demo as well.
> 
> Right I think I also could only get it to work by saying >=dev.

The question now becomes a bit more important, since we also have an 1.4 
branch so I am using kss.core>=1.4 there as dependency to the head of the 
svn branch. Somehow I don't like this.

I wonder what would be the absolutely correct way of handling these 
egg versions / dependencies to svn branches.

-- 
Balazs Ree


From mborch at gmail.com  Mon Mar 17 16:13:45 2008
From: mborch at gmail.com (Malthe Borch)
Date: Mon, 17 Mar 2008 16:13:45 +0100
Subject: [Kss-devel] Dev-egg link
In-Reply-To: <pan.2008.03.17.13.52.30@ree.hu>
References: <frls3f$tp$1@ger.gmane.org> <pan.2008.03.17.13.52.30@ree.hu>
Message-ID: <47DE8AA9.80403@gmail.com>



Balazs Ree wrote:
> (Note kss.core itself does not depend on lxml or to any other package 
> right now, but with megrok.kss this should be the right policy.)

I just referred to lxml as an example (completely unrelated) actully :-)

> The only thing I could not figure out, is that we also have to put the 
> dependent package into version dependencies. However in this case 
> kss.core==dev did not work well, I had to use kss.core>=dev as a 
> "workaround". I hope you can figure this out correctly with the 
> dependency between megrok.kss and lxml - or maybe between megrok.kss and 
> kss.core as well, then I'd correct this in kss.demo as well. 

Right I think I also could only get it to work by saying >=dev.


From gotcha at bubblenet.be  Wed Mar 19 09:07:33 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Wed, 19 Mar 2008 09:07:33 +0100
Subject: [Kss-devel] Safari 3.1 released
Message-ID: <47E0C9C5.2080408@bubblenet.be>

Hi all,

Some parts of KSS do not work on freshly released Safari 3.1

I'll look at it ASAP.

Any help appreciated though.
-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

From sgillies at frii.com  Wed Mar 19 22:07:06 2008
From: sgillies at frii.com (Sean Gillies)
Date: Wed, 19 Mar 2008 15:07:06 -0600
Subject: [Kss-devel] zope.View permission from zope.app.security
Message-ID: <frrv9l$p38$1@ger.gmane.org>

Could kss.core include zope.app.security instead of separately defining
a zope.View permission? If so, I have the patch ready to go, all
kss.core tests pass.

Sean


From gotcha at bubblenet.be  Thu Mar 20 07:33:04 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Thu, 20 Mar 2008 07:33:04 +0100
Subject: [Kss-devel] zope.View permission from zope.app.security
In-Reply-To: <frrv9l$p38$1@ger.gmane.org>
References: <frrv9l$p38$1@ger.gmane.org>
Message-ID: <47E20520.9000208@bubblenet.be>

Sean Gillies wrote:
> Could kss.core include zope.app.security instead of separately defining
> a zope.View permission? If so, I have the patch ready to go, all
> kss.core tests pass.
> 
> Sean

kss.core is supposed to work both with Z2 and Z3.

What is your setup ?

Can you send the patch ?


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

From ree at ree.hu  Thu Mar 20 09:29:58 2008
From: ree at ree.hu (Balazs Ree)
Date: Thu, 20 Mar 2008 09:29:58 +0100
Subject: [Kss-devel] Cleanup of kss.core - sanitization of string and
	html params
References: <47D9955F.2070402@xs4all.nl> <pan.2008.03.14.08.01.04@ree.hu>
	<47DA442C.5020102@bubblenet.be> <47DAE063.80909@xs4all.nl>
Message-ID: <pan.2008.03.20.08.30.10@ree.hu>

On Fri, 14 Mar 2008 21:30:27 +0100, Jeroen Vloothuis wrote:


>> Balazs Ree wrote:
>>   
 
>>> So the question that is raised: I offered some reasons above why I
>>> find this functionality important and to be kept. Do we have any
>>> reason to drop this functionality in the next release (based on
>>> kss.base)?
>>>     
> According to you two things are handled by BeautifulSoup. One is
> validation and the other is automagically "fixing" data. I am against
> anything which tries to fix my HTML without my intervention, ss you
> might have guessed from me calling it automagic. This could lead to all
> sorts of weird problems which would take an app developer some serious
> time to figure out. I guess if they where anything like me they would be
> very displeased to find out that KSS was doing more than just sending
> the data over the wire.
> 
> The other thing you mentioned is checking. Checking implies that we know
> what is correct. It does seem a bit pretentious though to know what is
> valid. If I send some partial paragraph (<p> without an end) because a
> wysiwyg editor stored it like that should KSS explode on me? Even though
> for the application I am developing it would be fine? How do we handle
> new / upcomming tags or entities? Do we know in advance how a tag for a
> new HTML 6 (speculation) tag must be closed?


I hear your opinion, but the reasons you offer above do not convince me.

Note that in the end this html content will be inserted into DOM by the 
browser. All browsers will do checking and sanitization of this content 
anyway, in a way uncontrollable for us. So in my view the "exact control" 
of html you pursue above, is difficult to interpret.

By doing the server side checking and sanitization, as currently, we have 
the advantage that

- we have a (possibly more detailed) server side error message in case of 
syntactically wrong content, instead of having a client side error,

- and that we can do the sanitization of html in a well defined, 
controlled way instead of letting all the browser versions do it 
differently, in undefined and uncontrollable ways.

I am not saying we are currently doing the best possible way, but this is 
the way it happens now.

 
> This also brings me to question the actual necessity of this validation.
> Plone and most other web tools / frameworks seem to be perfectly fine
> with not sanitizing or checking the generated HTML. Why would KSS be
> different?

In my opinion, Zope page templates (zpt) do validity checking and some 
sanitization. Also KSS is doing this currently. If they _could_ be fine 
without this is a different question. This brings me to the other issue 
that is related to the procedural question of porting kss.core to 
kss.base.

We are always open to fixes and improvements on the code, however noone - 
including you - has suggested to change the current way of html 
sanitization, unchanged from the initial version of kss. This indicates 
that the current way of handling works correctly. Changing it may still 
be a valid question in the future even it will open other issues.

But this should not happen _together_ with the current porting effort, 
instead it should follow later in a separate step. It is an important 
principle that the porting (that means changing the entire server side 
stack of kss) should be unobservable for all applications that use kss. 


> Godefroid Chapelle wrote:

>> Definitely no reason. I agree that html sanitizing and unicode nicety
>> need to be kept.
>>
>> And that they should go to kss.base.

However as I think the current argument will not lead to a resolution, I 
propose that the following should happen:

1. The current way of sanitization done by BeautifulSoup should be 
implemented identically to the current way.

2. It should go the kss.base as it belongs there.

3. We should implement a switch in kss.base that can be used to disable 
this server side checking. The default value should be the current 
behaviour.

4. If developers like Jeroen indeed feel the importance of not having the 
sanitization, they can make the effort to change the switch manually 
after installing kss. They also become aware that they need to deal with 
all possible problems caused by this.

The advantage of this strategy that instead of arguing about it, we give 
the freedom to the developers to choose. We can also see that if the 
majority of developers is actually toggling the switch, and can base our 
future dealing with the issue based on their gained experience.  

I would not like here to go into the details on _how_ we should implement 
this switch. We need to think about this in a further thread, in case of 
the proposal is acceptable.


-- 
Balazs Ree


From ree at ree.hu  Thu Mar 20 09:58:30 2008
From: ree at ree.hu (Balazs Ree)
Date: Thu, 20 Mar 2008 09:58:30 +0100
Subject: [Kss-devel] BeautifulSoup usage in kss.core
References: <47E218BF.9060807@wiggy.net>
Message-ID: <pan.2008.03.20.08.58.42@ree.hu>

On Thu, 20 Mar 2008 08:56:47 +0100, Wichert Akkerman wrote:

> I became aware that kss.core uses BeautifulSoup. Looking at the code it
> is used to transform any HTML and XML parameters added to a KSS command.
> I'm not sure I like that behaviour: if I pass in XML I would expect that
> to be outputed as-is without any changes. I'm fine with an exception
> being raised if my XML is invalid, but it should never be transformed.
> Likewise for HTML: BeautifulSoup may make changes to my html that I do
> not want. I feel that KSS should trust people using its API to pass in
> valid data. If people put garbage in you will always get garbage going
> out as well, even if you use BeautifulSoup in an attempt to clean things
> up.

It seems you are in the same opinion with Jeroen. He raised this question 
in connection with the kss.base rewrite. As I just responded to his post, 
let me quote my full reply on this list as well.

Besides what is in my reply, there were also several reasons why we ended 
up applying the current solution, it is a result of a long work, and it 
seems to work reasonably well in practice, with no complains so far.

As you can see below I am not opposing the improvement of the currently 
applied method but I insist on dealing with it in a separate step from 
the kss.base porting.

To further explore the details of the problem, it would also be nice if 
you could provide some concrete examples to show where the current 
approach fails for you, possibly in the form of working code so we can 
test it with different browsers with and without the sanitization.



Best wishes,


-----------------------------------------------------

On Fri, 14 Mar 2008 21:30:27 +0100, Jeroen Vloothuis wrote:


>> Balazs Ree wrote:
>>   
 
>>> So the question that is raised: I offered some reasons above why I
>>> find this functionality important and to be kept. Do we have any
>>> reason to drop this functionality in the next release (based on
>>> kss.base)?
>>>     
> According to you two things are handled by BeautifulSoup. One is
> validation and the other is automagically "fixing" data. I am against
> anything which tries to fix my HTML without my intervention, ss you
> might have guessed from me calling it automagic. This could lead to all
> sorts of weird problems which would take an app developer some serious
> time to figure out. I guess if they where anything like me they would be
> very displeased to find out that KSS was doing more than just sending
> the data over the wire.
> 
> The other thing you mentioned is checking. Checking implies that we know
> what is correct. It does seem a bit pretentious though to know what is
> valid. If I send some partial paragraph (<p> without an end) because a
> wysiwyg editor stored it like that should KSS explode on me? Even though
> for the application I am developing it would be fine? How do we handle
> new / upcomming tags or entities? Do we know in advance how a tag for a
> new HTML 6 (speculation) tag must be closed?


I hear your opinion, but the reasons you offer above do not convince me.

Note that in the end this html content will be inserted into DOM by the 
browser. All browsers will do checking and sanitization of this content 
anyway, in a way uncontrollable for us. So in my view the "exact control" 
of html you pursue above, is difficult to interpret.

By doing the server side checking and sanitization, as currently, we have 
the advantage that

- we have a (possibly more detailed) server side error message in case of 
syntactically wrong content, instead of having a client side error,

- and that we can do the sanitization of html in a well defined, 
controlled way instead of letting all the browser versions do it 
differently, in undefined and uncontrollable ways.

I am not saying we are currently doing the best possible way, but this is 
the way it happens now.

 
> This also brings me to question the actual necessity of this validation.
> Plone and most other web tools / frameworks seem to be perfectly fine
> with not sanitizing or checking the generated HTML. Why would KSS be
> different?

In my opinion, Zope page templates (zpt) do validity checking and some 
sanitization. Also KSS is doing this currently. If they _could_ be fine 
without this is a different question. This brings me to the other issue 
that is related to the procedural question of porting kss.core to 
kss.base.

We are always open to fixes and improvements on the code, however noone - 
including you - has suggested to change the current way of html 
sanitization, unchanged from the initial version of kss. This indicates 
that the current way of handling works correctly. Changing it may still 
be a valid question in the future even it will open other issues.

But this should not happen _together_ with the current porting effort, 
instead it should follow later in a separate step. It is an important 
principle that the porting (that means changing the entire server side 
stack of kss) should be unobservable for all applications that use kss. 


> Godefroid Chapelle wrote:

>> Definitely no reason. I agree that html sanitizing and unicode nicety
>> need to be kept.
>>
>> And that they should go to kss.base.

However as I think the current argument will not lead to a resolution, I 
propose that the following should happen:

1. The current way of sanitization done by BeautifulSoup should be 
implemented identically to the current way.

2. It should go the kss.base as it belongs there.

3. We should implement a switch in kss.base that can be used to disable 
this server side checking. The default value should be the current 
behaviour.

4. If developers like Jeroen indeed feel the importance of not having the 
sanitization, they can make the effort to change the switch manually 
after installing kss. They also become aware that they need to deal with 
all possible problems caused by this.

The advantage of this strategy that instead of arguing about it, we give 
the freedom to the developers to choose. We can also see that if the 
majority of developers is actually toggling the switch, and can base our 
future dealing with the issue based on their gained experience.  

I would not like here to go into the details on _how_ we should implement 
this switch. We need to think about this in a further thread, in case of 
the proposal is acceptable.


-- 
Balazs Ree


From waltercruz at threepointsweb.com  Thu Mar 20 14:31:55 2008
From: waltercruz at threepointsweb.com (Walter Cruz)
Date: Thu, 20 Mar 2008 10:31:55 -0300
Subject: [Kss-devel] kss with pylons
Message-ID: <b4fc30530803200631m4fc11560h9fc6df685afbfe2c@mail.gmail.com>

Hi all.
I've found the kss project, and liked it a lot :)

Browsing the repositories, I found that is possible to use it with Pylons.

I tried the wiki sample from kss svn, but is outdated.

So, I begin with a clean QuickWiki and added kss support.

You can see a running example here: http://kss.waltercruz.com/.

I can donate the code, if you wish.

-- 
Atenciosamente

Walter Rodrigo de S? Cruz
waltercruz at threepointsweb.com
http://www.threepointsweb.com
+55 61 3468-1604

Python, Zope e Plone com quem entende do assunto

From gotcha at bubblenet.be  Thu Mar 20 14:41:46 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Thu, 20 Mar 2008 14:41:46 +0100
Subject: [Kss-devel] kss with pylons
In-Reply-To: <b4fc30530803200631m4fc11560h9fc6df685afbfe2c@mail.gmail.com>
References: <b4fc30530803200631m4fc11560h9fc6df685afbfe2c@mail.gmail.com>
Message-ID: <47E2699A.7010109@bubblenet.be>

Walter Cruz wrote:
> Hi all.
> I've found the kss project, and liked it a lot :)

I am very happy !

How did you find the project ?

Would you mind to explain what you liked in a few lines (this way we 
could update our testimonial section)

> Browsing the repositories, I found that is possible to use it with Pylons.
> 
> I tried the wiki sample from kss svn, but is outdated.
> 
> So, I begin with a clean QuickWiki and added kss support.

I am sure that Jeroen (who ported kss to pure python and made first 
implementations with Pylons) will comment.

> You can see a running example here: http://kss.waltercruz.com/.

Cool.

Question : why did you prefix all your kss server actions with 'kss/' ?

> I can donate the code, if you wish.

It would be nice to see your code, definitely !

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

From sgillies at frii.com  Thu Mar 20 14:56:02 2008
From: sgillies at frii.com (Sean Gillies)
Date: Thu, 20 Mar 2008 07:56:02 -0600
Subject: [Kss-devel] zope.View permission from zope.app.security
In-Reply-To: <47E20520.9000208@bubblenet.be>
References: <frrv9l$p38$1@ger.gmane.org> <47E20520.9000208@bubblenet.be>
Message-ID: <frtqde$8fi$1@ger.gmane.org>

Godefroid Chapelle wrote:
> Sean Gillies wrote:
>> Could kss.core include zope.app.security instead of separately defining
>> a zope.View permission? If so, I have the patch ready to go, all
>> kss.core tests pass.
>>
>> Sean
> 
> kss.core is supposed to work both with Z2 and Z3.
> 
> What is your setup ?
> 
> Can you send the patch ?
> 
> 

I'm using Plone 3.1 beta and Zope 2.10.5. Patch for kss.core is attached.

I'm developing a Plone 3 product around a working Zope (3.4) package
that includes zope.app.security and have found that the zope.View
permission defined in kss.core conflicts.

Sean



-------------- next part --------------
A non-text attachment was scrubbed...
Name: zope-app-security.patch
Type: text/x-patch
Size: 577 bytes
Desc: not available
Url : http://codespeak.net/pipermail/kss-devel/attachments/20080320/dda557cc/attachment-0001.bin 

From gotcha at bubblenet.be  Thu Mar 20 15:11:46 2008
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Thu, 20 Mar 2008 15:11:46 +0100
Subject: [Kss-devel] zope.View permission from zope.app.security
In-Reply-To: <frtqde$8fi$1@ger.gmane.org>
References: <frrv9l$p38$1@ger.gmane.org> <47E20520.9000208@bubblenet.be>
	<frtqde$8fi$1@ger.gmane.org>
Message-ID: <47E270A2.7030800@bubblenet.be>

Sean Gillies wrote:
> Godefroid Chapelle wrote:
>> Sean Gillies wrote:
>>> Could kss.core include zope.app.security instead of separately defining
>>> a zope.View permission? If so, I have the patch ready to go, all
>>> kss.core tests pass.
>>>
>>> Sean
>> kss.core is supposed to work both with Z2 and Z3.
>>
>> What is your setup ?
>>
>> Can you send the patch ?
>>
>>
> 
> I'm using Plone 3.1 beta and Zope 2.10.5. Patch for kss.core is attached.
> 
> I'm developing a Plone 3 product around a working Zope (3.4) package
> that includes zope.app.security and have found that the zope.View
> permission defined in kss.core conflicts.
> 
> Sean

Thanks for the patch.

Balazs, could that permission.zcml file be a remainder of Zope 2.8 
compatibility ?

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

From jeroen.vloothuis at xs4all.nl  Thu Mar 20 21:25:15 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Thu, 20 Mar 2008 21:25:15 +0100
Subject: [Kss-devel] kss with pylons
In-Reply-To: <47E2699A.7010109@bubblenet.be>
References: <b4fc30530803200631m4fc11560h9fc6df685afbfe2c@mail.gmail.com>
	<47E2699A.7010109@bubblenet.be>
Message-ID: <47E2C82B.1010103@xs4all.nl>

Godefroid Chapelle wrote:
>> Browsing the repositories, I found that is possible to use it with Pylons.
>>
>> I tried the wiki sample from kss svn, but is outdated.
>>
>> So, I begin with a clean QuickWiki and added kss support.
If you have any patches I would be happy to apply them (and give you the 
proper credit).
>> You can see a running example here: http://kss.waltercruz.com/.
>>     
>
> Question : why did you prefix all your kss server actions with 'kss/' ?
>   
That might be because my original version had them. I think that 
Godefroid is trying to suggest that you could remove them if you have 
something like the following tag in the `head` section of your HTML:

<link rel="kss-base-url" href="http://kss.waltercruz.com/kss/" />

>> I can donate the code, if you wish.
>>     
>
> It would be nice to see your code, definitely !
>   
Like I said earlier, patches are appreciated.

From jeroen.vloothuis at xs4all.nl  Thu Mar 20 22:18:17 2008
From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis)
Date: Thu, 20 Mar 2008 22:18:17 +0100
Subject: [Kss-devel] BeautifulSoup usage in kss.core
In-Reply-To: <pan.2008.03.20.08.58.42@ree.hu>
References: <47E218BF.9060807@wiggy.net> <pan.2008.03.20.08.58.42@ree.hu>
Message-ID: <47E2D499.1020505@xs4all.nl>

Balazs Ree wrote:
> On Thu, 20 Mar 2008 08:56:47 +0100, Wichert Akkerman wrote: 
>   
>> This also brings me to question the actual necessity of this validation.
>> Plone and most other web tools / frameworks seem to be perfectly fine
>> with not sanitizing or checking the generated HTML. Why would KSS be
>> different?
> We are always open to fixes and improvements on the code, however noone - 
> including you - has suggested to change the current way of html 
> sanitization, unchanged from the initial version of kss. This indicates 
> that the current way of handling works correctly. 
Just because no one complained does not mean it is not broken. The next 
example demonstrates a problem with BeautifulSoup and HTML5 (please note 
that mail will probably split the lines, see 
http://paste.plone.org/20266 for a non broken version):

  >>> from BeautifulSoup import BeautifulSoup

  >>> html = '<p>To make George eat an apple, press 
<kbd><kbd>Shift</kbd>+<kbd>F3</kbd></kbd></p>'
  >>> print BeautifulSoup(html)
  <p>To make George eat an apple, press 
<kbd></kbd><kbd>Shift</kbd>+<kbd>F3</kbd></p>

The example is taken directly from the HTML5 spec:

http://www.w3.org/html/wg/html5/#the-kbd

From wichert at wiggy.net  Thu Mar 20 11:52:36 2008
From: wichert at wiggy.net (Wichert Akkerman)
Date: Thu, 20 Mar 2008 11:52:36 +0100
Subject: [Kss-devel] [Plone-developers] BeautifulSoup usage in kss.core
In-Reply-To: <pan.2008.03.20.08.58.42@ree.hu>
References: <47E218BF.9060807@wiggy.net> <pan.2008.03.20.08.58.42@ree.hu>
Message-ID: <20080320105235.GA25184@wiggy.net>

Previously Balazs Ree wrote:
> On Thu, 20 Mar 2008 08:56:47 +0100, Wichert Akkerman wrote:
> 
> > I became aware that kss.core uses BeautifulSoup. Looking at the code it
> > is used to transform any HTML and XML parameters added to a KSS command.
> > I'm not sure I like that behaviour: if I pass in XML I would expect that
> > to be outputed as-is without any changes. I'm fine with an exception
> > being raised if my XML is invalid, but it should never be transformed.
> > Likewise for HTML: BeautifulSoup may make changes to my html that I do
> > not want. I feel that KSS should trust people using its API to pass in
> > valid data. If people put garbage in you will always get garbage going
> > out as well, even if you use BeautifulSoup in an attempt to clean things
> > up.
> 
> It seems you are in the same opinion with Jeroen. He raised this question 
> in connection with the kss.base rewrite. As I just responded to his post, 
> let me quote my full reply on this list as well.
> 
> Besides what is in my reply, there were also several reasons why we ended 
> up applying the current solution, it is a result of a long work, and it 
> seems to work reasonably well in practice, with no complains so far.
> 
> As you can see below I am not opposing the improvement of the currently 
> applied method but I insist on dealing with it in a separate step from 
> the kss.base porting.

Sure. I want to approach this from the other direction: any
transformation such as this has (un)expected side effects. I have never
seen this behaviour documented anywhere, so this can lead to lots of
painful debugging. So I woud like to see real world examples that are
best solved by doing such a transform at the KSS level. Personally I do
suspect there are none.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

From waltercruz at threepointsweb.com  Sat Mar 22 14:31:08 2008
From: waltercruz at threepointsweb.com (Walter Cruz)
Date: Sat, 22 Mar 2008 10:31:08 -0300
Subject: [Kss-devel] kss with pylons
In-Reply-To: <47E2699A.7010109@bubblenet.be>
References: <b4fc30530803200631m4fc11560h9fc6df685afbfe2c@mail.gmail.com>
	<47E2699A.7010109@bubblenet.be>
Message-ID: <b4fc30530803220631p79bc22d6s3905241cb7f930c5@mail.gmail.com>

Hi Godefroid!

I develop plone apps, so I knew kss there. But find the kss.pylons was
hard, I found it listing the repositories.

I'm testing various things in the zope/plone3 world. Zope and Plone
are becoming closer to Python, and use some parts of it with another
projects is very fine! With KSS I can make my javascript less ugly,
and can integrate it with my framework pretty straighford.

My code is all prefixed with kss, cause it's a route map to my
controller. A note about the port: The Jeroen version had 2 versions
for the controllers, one to plain http requests, other for
xmlhttprequests. The controllers were prretty similar, except that one
returned a rendered page, and other returned a kss set of command.

I added a patch, described at http://kssproject.org/bugs/25 (just one
line:) ) and with this patch, I can do the something like the
following insise my Pylons controller:

def mycontroller():
    make_common_actions()
    if request.is_xhr:
        return ksscomands
    else
        return a_rendered_template

With this, I can eliminate one of the controllers and make my app more DRY :)


-- 
Atenciosamente

Walter Rodrigo de S? Cruz
waltercruz at threepointsweb.com
http://www.threepointsweb.com
+55 61 3468-1604

Python, Zope e Plone com quem entende do assunto

From shywolf9982 at gmail.com  Mon Mar 31 19:32:24 2008
From: shywolf9982 at gmail.com (Simone Deponti)
Date: Mon, 31 Mar 2008 19:32:24 +0200
Subject: [Kss-devel] Selenuim tests - some (general) considerations
Message-ID: <fsr782$frb$1@ger.gmane.org>

Hello list,

I was trying to make a good selenium test for Plone workflow changes, and I
discovered some interesting things that I would like to share.

Probably everyone of you knew these things already, but I think it is very
useful to write them somewhere (I will merge this into the tutorial Beppe
was making, too):

1. It is better to always revise the selectors that Selenium generates: this
is because sometimes it generates selectors that look like this:
//dl[@id'plone-contentmenu-workflow']/dt/a/span[2]
where something like
//dl[@id'plone-contentmenu-workflow']//a/span[@class='state-private']
would be much better as it doesn't break if someone changes the dt into a dd
or moves changes the span order.
Also, if you have an id, it is better to do something like
//$element_tag[@id=$element_id]/$all_the_rest
by keeping the id in the beginning of the xpath selector and then travel
down for things that don't have an id. Don't use two id selectors in the
same xpath, because it's stupid and will make the test break on UI changes.

2. Don't use clickAndWait if there is no page reloading, because Selenium
clearly states that that command will wait for a page reload. Use instead a
click and waitFor* command.

3. Don't just text just for element existence: assertVisible and
waitForVisible are necessary in a lot of cases.

4. If, for example, you have some code like this:
<a id="mylink"
   href="some/url">
  <span>My text</span>
</a>
Don't issue a click command on #mylink but issue it
on //a[@id="mylink"]/span. This is because the user will most likely link
on the text (so, the span) and not on the a element. Clicking on the a
element might masquerade bubbling issues as is the case for Plone workflow
changes.

I think that is all: if you want something to take as example you can take a
look at
https://svn.plone.org/svn/plone/plone.app.kss/branches/1.4-kss-test/plone/app/kss/demo/selenium_tests/run_as_testmanager/workflow_transition.html

Hope this information was useful :)

--
Simone Deponti (shywolf9982)