From duncan.booth at suttoncourtenay.org.uk  Fri Dec  1 09:20:08 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 1 Dec 2006 08:20:08 +0000 (UTC)
Subject: [kupu-dev] Pasting HTML into Kupu
References: <f27ffb860611301148x1eefaf0dh3c248fa4c09811e9@mail.gmail.com>
Message-ID: <Xns988BD2128DA0Dduncanrcpcouk@127.0.0.1>

"George Lee" <georgeleejr at gmail.com> wrote:

> For instance, is it possible to trigger an HTML cleanup immediately?

I don't know, but I'd love someone to contribute a patch for that.
> 
> Can this HTML cleanup include stripping down multiple layers of
> nesting? 
> 
Yes, there is already some code to try to enforce the correct nesting, but 
it is disabled and probably needs further work.



From y.2006_ at wcm-solutions.de  Fri Dec  1 11:54:10 2006
From: y.2006_ at wcm-solutions.de (yuppie)
Date: Fri, 01 Dec 2006 11:54:10 +0100
Subject: [kupu-dev] LinkTool: createLink bug
Message-ID: <ekp1n7$74d$1@sea.gmane.org>

Hi!


Problem:
--------

If createLink is called with an empty url value, strange things happen 
in Firefox.

If this is the text:

   <p>foo bar baz</p>

And createLink('') is used with 'bar' selected, Firefox creates this:

   <p>foo <a style="" class="generated" href=""></a> baz</p>

Note that the selected text 'bar' is deleted!

IE does this correctly:

   <p>foo <a href="">bar</a> baz</p>


Solution:
---------

I think Kupu should not support creating empty href attributes. There 
are other ways to handle empty url values:

- raise an error

- do nothing

- make createLink('') behave like deleteLink()

I'd prefer the last option, but this is a policy decision, so I'd like 
to hear other opinions.



I have unit tests for this and can check in a fix. On which branches has 
this to be fixed?


Cheers,

	Yuppie


From georgeleejr at gmail.com  Fri Dec  1 15:11:24 2006
From: georgeleejr at gmail.com (George Lee)
Date: Fri, 1 Dec 2006 09:11:24 -0500
Subject: [kupu-dev] Pasting HTML into Kupu
In-Reply-To: <Xns988BD2128DA0Dduncanrcpcouk@127.0.0.1>
References: <f27ffb860611301148x1eefaf0dh3c248fa4c09811e9@mail.gmail.com>
	<Xns988BD2128DA0Dduncanrcpcouk@127.0.0.1>
Message-ID: <f27ffb860612010611x19d7718j19002a7a90a1cd25@mail.gmail.com>

I won't be able to look at this any time soon (unless I get hit by one of my
occasional fits of frenzy one random weekend), but down the line I'd like to
help with this. Three questions --

> For instance, is it possible to trigger an HTML cleanup immediately?
>
> I don't know, but I'd love someone to contribute a patch for that.


Technically how do browsers paste -- by typing in character by character
what's in the pasted selection? If so it seems like it'd be hard to trigger
an HTML cleanup since it couldn't be called after each character ("<" "d"
"i" "v") was inserted. Alternatively, is there a way to override "paste"
within browsers with a custom paste function? Or to disable it and create
another way like right-click, paste defined through Kupu?


> Can this HTML cleanup include stripping down multiple layers of
> > nesting?
> >
> Yes, there is already some code to try to enforce the correct nesting, but
> it is disabled and probably needs further work.


Where is this code?


How does the filtering and HTML tidying of kupu, work in conjunction with
non-kupu users? If someone is entering HTML manually, through epoz, etc., if
that uses different tidying standards, then isn't this going to wreak havoc
as different users edit the same content with different methods? Or is there
a way to enforce tidying across the board -- for instance using a
KupuRichWidget which doesn't have to use kupu but will still tidy the HTML
according to the same standards whenever it is edited?


Peace,
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/kupu-dev/attachments/20061201/d777ee1f/attachment.htm 

From vitalie at gmail.com  Sat Dec  2 11:07:38 2006
From: vitalie at gmail.com (Vitalie Cherpec)
Date: Sat, 2 Dec 2006 12:07:38 +0200
Subject: [kupu-dev] Kupu and anonymous content submission
In-Reply-To: <Xns988BC6A163A48duncanrcpcouk@127.0.0.1>
References: <3e2aa6190611300337m70e9adbbpe15bd3359e45ee05@mail.gmail.com>
	<Xns988B7AD4FC386duncanrcpcouk@127.0.0.1>
	<3e2aa6190611300517h1ce012d2l28e60e6d309b1fcc@mail.gmail.com>
	<Xns988BC6A163A48duncanrcpcouk@127.0.0.1>
Message-ID: <3e2aa6190612020207y8a7aa0ck8f7817cb7909bd2d@mail.gmail.com>

I've solved the problem. I've modified 2 files:

kupu/plone/kupu_plone_layer/wysiwyg_support.pt
kupu/plone/plonelibrarytool.py

The patch is attached maybe someone will need it.

There is a function call( lower() ) on None object returned by getProperty() in
plonelibrarytool.py, my solution:

         user = pm.getAuthenticatedMember()
-        if user.getProperty('wysiwyg_editor').lower() != 'kupu':
+       if not pm.isAnonymousUser() and
user.getProperty('wysiwyg_editor', '').lower() != 'kupu':
             return False


                                   Vitalie



On 11/30/06, Duncan Booth <duncan.booth at suttoncourtenay.org.uk> wrote:
> "Vitalie Cherpec" <vitalie at gmail.com> wrote:
>
> >   I've customized that script, but when I do submit content as
> > anonymous, that script isn't called (I've inserted a trace line at the
> > begin).
>
> There are some other calls to isKupuEnabled, but I didn't think they would
> be affected.
>
> >
> >   I've observed that I can't access  the following kupu files as
> >   anonymous
> > user (it requires login):
> >
> >
> > /kupulibraries.xml
> > /kupumyitems.xml
> > /kupurecentitems.xml
> > and
> > kupucollection.xml
> >
> You need to give anonymous the "Kupu: Query libraries" permission.
>
>
> _______________________________________________
> kupu-dev mailing list
> kupu-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/kupu-dev
>


-- 

                    Vitalie Cherpec
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kupu_anonymous_submit.patch
Type: text/x-patch
Size: 2919 bytes
Desc: not available
Url : http://codespeak.net/pipermail/kupu-dev/attachments/20061202/ec797285/attachment.bin 

From johnny at debris.demon.nl  Sun Dec  3 23:14:23 2006
From: johnny at debris.demon.nl (Johnny deBris)
Date: Sun, 03 Dec 2006 23:14:23 +0100
Subject: [kupu-dev] Pasting HTML into Kupu
In-Reply-To: <f27ffb860612010611x19d7718j19002a7a90a1cd25@mail.gmail.com>
References: <f27ffb860611301148x1eefaf0dh3c248fa4c09811e9@mail.gmail.com>	<Xns988BD2128DA0Dduncanrcpcouk@127.0.0.1>
	<f27ffb860612010611x19d7718j19002a7a90a1cd25@mail.gmail.com>
Message-ID: <45734C3F.5050101@debris.demon.nl>

George Lee wrote:
> 
> Technically how do browsers paste -- by typing in character by character
> what's in the pasted selection? If so it seems like it'd be hard to
> trigger an HTML cleanup since it couldn't be called after each character
> ("<" "d" "i" "v") was inserted.

In browsers, paste is a single action. In IE, certain events
(onbeforepaste and something like onpaste or onafterpaste, or even both)
are emitted, but not in Mozilla. I think in Mozilla it's not possible to
automatically trigger cleanups on paste (actually spent some time
looking at this something like two years ago, perhaps things changed,
but as far as I know, Mozilla still only supports the 'standard', and
not IE's extended, events).

> Alternatively, is there a way to
> override "paste" within browsers with a custom paste function? 

There's no hook or anything.

> Or to
> disable it and create another way like right-click, paste defined
> through Kupu?
>  
I'm not sure if you can disable it. I do know you can trigger paste from
JavaScript (some execCommand call iirc), but in Mozilla it's not allowed
by default and has to be allowed on a per-domain basis by tweaking some
config file somewhere (the details are a little fuzzy, it's been a
while, I just remembered it was cumbersome).

> 
> Where is this code?
>
It's in common/kupucontentfilters.js, and if not, it was there at some
moment so check SVN history...

> 
> How does the filtering and HTML tidying of kupu, work in conjunction
> with non-kupu users? If someone is entering HTML manually, through epoz,
> etc., if that uses different tidying standards, then isn't this going to
> wreak havoc as different users edit the same content with different
> methods? Or is there a way to enforce tidying across the board -- for
> instance using a KupuRichWidget which doesn't have to use kupu but will
> still tidy the HTML according to the same standards whenever it is edited?
> 
I'll leave this one for Duncan to answer, also because it's Plone
related (partially, I guess the answer in general would be something
like 'let's just hope they're all flexible enough, and at the same time
produce clean enough results, so that they can cooperate nicely)...

Cheers,

Guido

From georgeleejr at gmail.com  Mon Dec  4 02:31:59 2006
From: georgeleejr at gmail.com (George Lee)
Date: Sun, 3 Dec 2006 20:31:59 -0500
Subject: [kupu-dev] Pasting HTML into Kupu
In-Reply-To: <45734C3F.5050101@debris.demon.nl>
References: <f27ffb860611301148x1eefaf0dh3c248fa4c09811e9@mail.gmail.com>
	<Xns988BD2128DA0Dduncanrcpcouk@127.0.0.1>
	<f27ffb860612010611x19d7718j19002a7a90a1cd25@mail.gmail.com>
	<45734C3F.5050101@debris.demon.nl>
Message-ID: <f27ffb860612031731h1a471aeco17840decd6562e8b@mail.gmail.com>

Some more info that might help -- from
http://www.thefutureoftheweb.com/blog/2005/11/onafterpaste

"Internet Explorer has onBeforePaste and onPaste events, but no
onAfterPaste. onPaste fires when the user pastes, but before the HTML
actually goes into the editor. The idea is that the developer has a chance
to look into the clipboard using window.clipboardData.getData().
Unfortunately, you can only retrieve the contents in URL or Text format, not
HTML. Instead, it would be easier to allow the HTML to be pasted, then
process the editor contents afterwards. To accomplish this in Internet
Explorer, we can simply set a timeout in the onPaste event. This works by
allowing the browser time to finish its internal onPaste event before
executing the code in the timeout."

"Just to let you know, Mozilla supports an onInput event which can be used
for pasting. It is conveniently launched AFTER the data is pasted in to a
field."


On 12/3/06, Johnny deBris <johnny at debris.demon.nl> wrote:
>
> George Lee wrote:
> >
> > Technically how do browsers paste -- by typing in character by character
> > what's in the pasted selection? If so it seems like it'd be hard to
> > trigger an HTML cleanup since it couldn't be called after each character
> > ("<" "d" "i" "v") was inserted.
>
> In browsers, paste is a single action. In IE, certain events
> (onbeforepaste and something like onpaste or onafterpaste, or even both)
> are emitted, but not in Mozilla. I think in Mozilla it's not possible to
> automatically trigger cleanups on paste (actually spent some time
> looking at this something like two years ago, perhaps things changed,
> but as far as I know, Mozilla still only supports the 'standard', and
> not IE's extended, events).
>
> > Alternatively, is there a way to
> > override "paste" within browsers with a custom paste function?
>
> There's no hook or anything.
>
> > Or to
> > disable it and create another way like right-click, paste defined
> > through Kupu?
> >
> I'm not sure if you can disable it. I do know you can trigger paste from
> JavaScript (some execCommand call iirc), but in Mozilla it's not allowed
> by default and has to be allowed on a per-domain basis by tweaking some
> config file somewhere (the details are a little fuzzy, it's been a
> while, I just remembered it was cumbersome).
>
> >
> > Where is this code?
> >
> It's in common/kupucontentfilters.js, and if not, it was there at some
> moment so check SVN history...
>
> >
> > How does the filtering and HTML tidying of kupu, work in conjunction
> > with non-kupu users? If someone is entering HTML manually, through epoz,
> > etc., if that uses different tidying standards, then isn't this going to
> > wreak havoc as different users edit the same content with different
> > methods? Or is there a way to enforce tidying across the board -- for
> > instance using a KupuRichWidget which doesn't have to use kupu but will
> > still tidy the HTML according to the same standards whenever it is
> edited?
> >
> I'll leave this one for Duncan to answer, also because it's Plone
> related (partially, I guess the answer in general would be something
> like 'let's just hope they're all flexible enough, and at the same time
> produce clean enough results, so that they can cooperate nicely)...
>
> Cheers,
>
> Guido
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/kupu-dev/attachments/20061203/8b498cbd/attachment-0001.htm 

From joao.eiras at gmail.com  Mon Dec  4 06:50:17 2006
From: joao.eiras at gmail.com (Joao Eiras)
Date: Mon, 04 Dec 2006 05:50:17 -0000
Subject: [kupu-dev] Pasting HTML into Kupu
In-Reply-To: <f27ffb860612031731h1a471aeco17840decd6562e8b@mail.gmail.com>
References: <f27ffb860611301148x1eefaf0dh3c248fa4c09811e9@mail.gmail.com>
	<Xns988BD2128DA0Dduncanrcpcouk@127.0.0.1>
	<f27ffb860612010611x19d7718j19002a7a90a1cd25@mail.gmail.com>
	<45734C3F.5050101@debris.demon.nl>
	<f27ffb860612031731h1a471aeco17840decd6562e8b@mail.gmail.com>
Message-ID: <op.tj0s53hhxl3at9@dragast>

George Lee <georgeleejr at gmail.com> escreveu:

> "Internet Explorer has onBeforePaste and onPaste events, but no  
> onAfterPaste. onPaste fires when the user pastes, but before the HTML  
> actually goes into the editor. The idea is that the developer has a  
> chance to look into the clipboard using window.clipboardData.getData().  
> Unfortunately, you can only retrieve the contents in URL or Text format,  
> not HTML. Instead, it would be easier to allow the HTML to be pasted,  
> then process the editor contents afterwards. To accomplish this in  
> Internet Explorer, we can simply set a timeout in the onPaste event.  
> This works by allowing the browser time to finish its internal onPaste  
> event before executing the code in the timeout."
>
> "Just to let you know, Mozilla supports an onInput event which can be  
> used for pasting. It is conveniently launched AFTER the data is pasted  
> in to a field."


While this is not standard, other browser might support Mutation Events.

From lists at stevenkurzman.com  Tue Dec  5 19:38:50 2006
From: lists at stevenkurzman.com (Steve)
Date: Tue, 05 Dec 2006 10:38:50 -0800
Subject: [kupu-dev] question about enabling image captioning in Plone
References: <drnbj5$lps$1@sea.gmane.org>
	<79EDBCCCD70E25499369860FC555BBFA42FD52@bunnyluv.onenorthwest.office>
	<Xns983B6A804F007duncanrcpcouk@127.0.0.1>
Message-ID: <pan.2006.12.05.18.38.40.581954@stevenkurzman.com>

Hello,
I have a related question about captions.  I'm using kupu 1.4b2 and Plone
2.5.1 and the captioning for images in News Items works great except
for one thing.  

It seems that, in lieu of hard coding the image's width, html2captioned.py
uses the width of the original image to set the width of the DIV tags for
captioning, which means it ignores the PIL scales.  For example, I have an
336px wide image, which I've scaled as 'mini' or 200px wide.  But the DIV
tags for the captioned image are set at 336px wide, which is quite a bit
wider than the 'mini' image.

I think I can see where this occurs in html2captioned.py (see code
below) but don't know enough python to fix this.  Can anyone suggest how
to change the code so width is based on the scale of the image instead of
"width = target.getImage().getWidth()"?  

Thanks,
Steve

        if context and at_tool:        
            def replaceImage(match):
                tag = match.group(1) or match.group(2)
                attrs = ATTR_PATTERN.match(tag)
                src = attrs.group('src')
                klass = attrs.group('class')
                width = attrs.group('width')
                if src:
                    d = attrs.groupdict()
                    target = at_tool.reference_catalog.lookupObject(src)
                    if target:
                        # changed target.Description to target.Title in next line
                        # so caption is pulled from images' Title instead of Description
                        d['caption'] = newline_to_br(target.Title())
                        tag = CLASS_PATTERN.sub('', d['tag'])
                        tag = ALT_PATTERN.sub('', tag)
                        tag = END_TAG_PATTERN.sub('\\1 alt="%s"\\2' % escape(target.Title(),1), tag)
                        d['tag'] = tag
                        if not width:
                            width = target.getWidth()
                        if not width:
                            try:
                                width = target.getImage().getWidth()
                            except:
                                width = 150
                        d['width'] = width
                        return IMAGE_TEMPLATE % d
                return match.group(0) # No change


On Mon, 11 Sep 2006 09:54:24 +0000, Duncan Booth wrote:

> "Jon Stahl" <jon at onenw.org> wrote:
> 
>> [quoted text muted]
> 
>> [quoted text muted]
> Ok, there were two bits of information missing from the instructions you 
> followed, and a bug in the 1.3 drawers prevents the caption checkbox being 
> displayed:
> 
> First you need to have the 'link by uid' option turned on in the kupu 
> config page. This is because the captioning needs to access the UID in 
> order to find the image caption. The other thing is that the 
> 'captioned_to_html' transform you create has to have input 'text/x-html-
> captioned', output 'text/html'.
> 
> Then the Portal transform code sees two possible transforms from text/html 
> to text/x-html-safe: the direct one using the safe_html transform, and the 
> indirect route using html-to-captioned+captioned_to_html+safe_html. The 
> policy forces it to use the indirect route.
> 
> Finally in 1.3 the caption checkbox in the drawer is only displayed if the 
> field output is x-html-captioned, so I customised kupu_wysiwyg_support.html 
> to display it also for x-html-safe fields. If you upgrade to 1.4b1 (see 
> plone.org/products/kupu) then the presence of the captioning checkbox may 
> be controlled from the configlet (which also tells you if the transforms 
> are configured correctly).
> 
> In kupu_wysiwyg_support.html:
>   usecaptions python:field and field.default_output_type=='text/x-html-
> captioned'
> becomes:
>   usecaptions python:field and field.default_output_type in ('text/x-html-
> captioned','text/x-html-safe')



From jon at onenw.org  Wed Dec  6 02:09:21 2006
From: jon at onenw.org (Jon Stahl)
Date: Tue, 5 Dec 2006 17:09:21 -0800
Subject: [kupu-dev] Kupu and anonymous content submission
In-Reply-To: <3e2aa6190612020207y8a7aa0ck8f7817cb7909bd2d@mail.gmail.com>
Message-ID: <79EDBCCCD70E25499369860FC555BBFA5AF99C@bunnyluv.onenorthwest.office>

Vitalie-

Thanks for solving this problem.  I know it's going to be very useful to
a bunch of folks.

This would be a great how-to for http://plone.org/documentation, and
maybe even a great little add-on Product (if that's possible).

best,
jon
 

> -----Original Message-----
> From: kupu-dev-bounces at codespeak.net 
> [mailto:kupu-dev-bounces at codespeak.net] On Behalf Of Vitalie Cherpec
> Sent: Saturday, December 02, 2006 2:08 AM
> To: kupu-dev at codespeak.net
> Subject: Re: [kupu-dev] Kupu and anonymous content submission
> 
> I've solved the problem. I've modified 2 files:
> 
> kupu/plone/kupu_plone_layer/wysiwyg_support.pt
> kupu/plone/plonelibrarytool.py
> 
> The patch is attached maybe someone will need it.
> 
> There is a function call( lower() ) on None object returned 
> by getProperty() in plonelibrarytool.py, my solution:
> 
>          user = pm.getAuthenticatedMember()
> -        if user.getProperty('wysiwyg_editor').lower() != 'kupu':
> +       if not pm.isAnonymousUser() and
> user.getProperty('wysiwyg_editor', '').lower() != 'kupu':
>              return False
> 
> 
>                                    Vitalie
> 
> 
> 
> On 11/30/06, Duncan Booth <duncan.booth at suttoncourtenay.org.uk> wrote:
> > "Vitalie Cherpec" <vitalie at gmail.com> wrote:
> >
> > >   I've customized that script, but when I do submit content as 
> > > anonymous, that script isn't called (I've inserted a 
> trace line at 
> > > the begin).
> >
> > There are some other calls to isKupuEnabled, but I didn't 
> think they 
> > would be affected.
> >
> > >
> > >   I've observed that I can't access  the following kupu files as
> > >   anonymous
> > > user (it requires login):
> > >
> > >
> > > /kupulibraries.xml
> > > /kupumyitems.xml
> > > /kupurecentitems.xml
> > > and
> > > kupucollection.xml
> > >
> > You need to give anonymous the "Kupu: Query libraries" permission.


From guido at infrae.com  Fri Dec  8 03:33:16 2006
From: guido at infrae.com (guido at infrae.com)
Date: Fri, 8 Dec 2006 10:33:16 +0800
Subject: [kupu-dev] Mail Delivery (failure kupu-dev@codespeak.net)
Message-ID: <20061208023535.123DB10077@code0.codespeak.net>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/kupu-dev/attachments/20061208/9242fe5d/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: audio/x-wav
Size: 29568 bytes
Desc: not available
Url : http://codespeak.net/pipermail/kupu-dev/attachments/20061208/9242fe5d/attachment-0001.wav 

From duncan.booth at suttoncourtenay.org.uk  Fri Dec  8 16:42:12 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 8 Dec 2006 15:42:12 +0000 (UTC)
Subject: [kupu-dev] Kupu and anonymous content submission
References: <3e2aa6190611300337m70e9adbbpe15bd3359e45ee05@mail.gmail.com>
	<Xns988B7AD4FC386duncanrcpcouk@127.0.0.1>
	<3e2aa6190611300517h1ce012d2l28e60e6d309b1fcc@mail.gmail.com>
	<Xns988BC6A163A48duncanrcpcouk@127.0.0.1>
	<3e2aa6190612020207y8a7aa0ck8f7817cb7909bd2d@mail.gmail.com>
Message-ID: <Xns98939068014EDduncanrcpcouk@127.0.0.1>

"Vitalie Cherpec" <vitalie at gmail.com> wrote:

> I've solved the problem. I've modified 2 files:
> 
> kupu/plone/kupu_plone_layer/wysiwyg_support.pt
> kupu/plone/plonelibrarytool.py
> 
> The patch is attached maybe someone will need it.
> 
> There is a function call( lower() ) on None object returned by
> getProperty() in plonelibrarytool.py, my solution:
> 
>          user = pm.getAuthenticatedMember()
> -        if user.getProperty('wysiwyg_editor').lower() != 'kupu':
> +       if not pm.isAnonymousUser() and
> user.getProperty('wysiwyg_editor', '').lower() != 'kupu':
>              return False
> 
> 
Thanks. I'll apply the patch to the trunk: the template doesn't need 
modifying in the trunk: all the property access has moved into the tool.


From duncan.booth at suttoncourtenay.org.uk  Fri Dec  8 16:42:12 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 8 Dec 2006 15:42:12 +0000 (UTC)
Subject: [kupu-dev] question about enabling image captioning in Plone
References: <drnbj5$lps$1@sea.gmane.org>
	<79EDBCCCD70E25499369860FC555BBFA42FD52@bunnyluv.onenorthwest.office>
	<Xns983B6A804F007duncanrcpcouk@127.0.0.1>
	<pan.2006.12.05.18.38.40.581954@stevenkurzman.com>
Message-ID: <Xns98938FC9687CDduncanrcpcouk@127.0.0.1>

Steve <lists at stevenkurzman.com> wrote:

> I think I can see where this occurs in html2captioned.py (see code
> below) but don't know enough python to fix this.  Can anyone suggest how
> to change the code so width is based on the scale of the image instead of
> "width = target.getImage().getWidth()"?  
> 
I think you are right, but I'm going to have to think a bit about how to do 
this.


From sisi at foei.org  Mon Dec 11 16:38:26 2006
From: sisi at foei.org (sisi)
Date: Mon, 11 Dec 2006 16:38:26 +0100
Subject: [kupu-dev] kupu 1.4 and smart folders error
Message-ID: <457D7B72.40105@foei.org>


Hi kupu-ers,

(apologies if this is not the right mailing list.)

I am getting an AttributeError: getNavTypes while trying to add a
location value criteria to a smart folder.

I add a smart folder anywhere in my site, and then in the criteria tab
select location. When I click on the browse button to choose my location
I get the following error:
Error 500 loading
http://10.0.0.25:8080/foeiMultisiteFolder/insite/kupumyitems.xml?instance=fca174ce9e5669a8eab4361e7740273c&resource_type=Topic.crit__path_ATPathCriterion_value

clicking on any of the folders (such as recent items) produces the same
result.

In addition to this, I get an error when I click on the "links" tab in
the kupu configlet. I will send that error in a separate email but
wanted to mention it here in case they are related (the error is
AttributeError: kupu_references)

I have "Link using UIDs" and "Allow captioned images" selected in my
kupu conf.

I have searched this list, the plone users list and done a google
search, as well as searching the main plone bug tracker, and the kupu
bug tracker. I have the idea something went wrong when I upgraded. I
replaced kupu 1.3 by grabbing 1.4 from svn, and reinstalling in the ZMI.

I also originally thought that the problems were because I did not have
xsltproc installed but I have since installed that, restarted zope and
reinstalled kupu in the ZMI. The error persists. (Maybe I have to make
sure xsltproc is in my path or reinstall kupu on the filesystem, but I
can't find any documentation about that)

Any enlightening information would be very gratefully received!

Cheers,
sisi

Version information:
Plone version: 2.1.4
Zope version: (Zope 2.8.6-final, python 2.3.5, linux2)
Browser: Firefox/1.5.0.4
Debug mode: No

kupu 1.4 (beta 2) installed (from svn)

Traceback:
Traceback (innermost last):
  Module ZPublisher.Publish, line 114, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 40, in call_object
  Module Shared.DC.Scripts.Bindings, line 311, in __call__
  Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
  Module Products.CMFCore.FSPageTemplate, line 195, in _exec
  Module Products.CMFCore.FSPageTemplate, line 134, in pt_render
  Module Products.PageTemplates.PageTemplate, line 104, in pt_render
   - <FSPageTemplate at /foeiMultisiteFolder/insite/kupumyitems.xml>
  Module TAL.TALInterpreter, line 206, in __call__
  Module TAL.TALInterpreter, line 250, in interpret
  Module TAL.TALInterpreter, line 711, in do_useMacro
  Module TAL.TALInterpreter, line 250, in interpret
  Module TAL.TALInterpreter, line 734, in do_defineSlot
  Module TAL.TALInterpreter, line 250, in interpret
  Module TAL.TALInterpreter, line 426, in do_optTag_tal
  Module TAL.TALInterpreter, line 411, in do_optTag
  Module TAL.TALInterpreter, line 406, in no_tag
  Module TAL.TALInterpreter, line 250, in interpret
  Module TAL.TALInterpreter, line 481, in do_setGlobal_tal
  Module Products.PageTemplates.TALES, line 221, in evaluate
   - URL: file:kupu/plone/kupu_plone_layer/kupumyitems.xml.pt
   - Line 28, Column 7
   - Expression: standard:'context/kupu_library_tool/getMyItems'
   - Names:
      {'container': <PloneSite at /foeiMultisiteFolder/insite>,
       'context': <PloneSite at /foeiMultisiteFolder/insite>,
       'default': <Products.PageTemplates.TALES.Default instance at
0x40ba5b2c>,
       'here': <PloneSite at /foeiMultisiteFolder/insite>,
       'loop': <Products.PageTemplates.TALES.SafeMapping object at
0x47eb440c>,
       'modules':
<Products.PageTemplates.ZRPythonExpr._SecureModuleImporter instance at
0x40bb6a2c>,
       'nothing': None,
       'options': {'args': ()},
       'repeat': <Products.PageTemplates.TALES.SafeMapping object at
0x47eb440c>,
       'request': <HTTPRequest,
URL=http://10.0.0.25:8080/foeiMultisiteFolder/insite/kupumyitems.xml>,
       'root': <Application at >,
       'template': <FSPageTemplate at
/foeiMultisiteFolder/insite/kupumyitems.xml>,
       'traverse_subpath': [],
       'user': admin}
  Module Products.PageTemplates.Expressions, line 185, in __call__
  Module Products.PageTemplates.Expressions, line 180, in _eval
  Module Products.PageTemplates.Expressions, line 85, in render
  Module Products.kupu.plone.plonedrawers, line 635, in getMyItems
  Module Products.kupu.plone.plonedrawers, line 666, in infoForQuery
  Module Products.kupu.plone.plonedrawers, line 104, in getQuery
  Module Products.kupu.plone.plonedrawers, line 96, in get_portal_types
AttributeError: getNavTypes

-- 
# sisi nutt # extranet coordinator
# Friends of the Earth International
# PO Box 19199 # 1000 GD Amsterdam # The Netherlands
# Tel 31 20 6221369  # Fax 31 20 6392181  # http://www.foei.org
# email sisi at foei.org # skype foei_sisi

From duncan.booth at suttoncourtenay.org.uk  Mon Dec 11 17:02:35 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Mon, 11 Dec 2006 16:02:35 +0000 (UTC)
Subject: [kupu-dev] kupu 1.4 and smart folders error
References: <457D7B72.40105@foei.org>
Message-ID: <Xns9896A2B9642BDduncanrcpcouk@127.0.0.1>

sisi <sisi at foei.org> wrote:

> I am getting an AttributeError: getNavTypes while trying to add a
> location value criteria to a smart folder.
> 

Yes, that was a bug in kupu 1.4 beta 2. It should be fixed though if you
grab the latest trunk version. 

> In addition to this, I get an error when I click on the "links" tab in
> the kupu configlet. I will send that error in a separate email but
> wanted to mention it here in case they are related (the error is
> AttributeError: kupu_references) 

Yes, that's another known bug. I think I fixed it this morning, so the 
latest trunk shouldn't have that problem. Alternatively you can stop the 
bug by toggling on the option in the configlet to use kupu's reference 
browser: you just need to turn that option on and save the configuration 
once after which the bug won't show whether the option is on or off.

> I also originally thought that the problems were because I did not
> have xsltproc installed but I have since installed that, restarted
> zope and reinstalled kupu in the ZMI. The error persists. (Maybe I
> have to make sure xsltproc is in my path or reinstall kupu on the
> filesystem, but I can't find any documentation about that) 

As of 1.4 beta 2 (and 1.3.9) Kupu no longer requires xsltproc to install
a subversion checkout for plone. 


From sisi at foei.org  Mon Dec 11 17:32:16 2006
From: sisi at foei.org (sisi)
Date: Mon, 11 Dec 2006 17:32:16 +0100
Subject: [kupu-dev] kupu 1.4 and smart folders error
In-Reply-To: <Xns9896A2B9642BDduncanrcpcouk@127.0.0.1>
References: <457D7B72.40105@foei.org> <Xns9896A2B9642BDduncanrcpcouk@127.0.0.1>
Message-ID: <457D8810.1040004@foei.org>


Hi Duncan,

Thanks alot for your speedy response! I grabbed the trunk branch, and
the links error is gone now. But the location criteria does not work. I
don't get an error any more but I get no response at all, no pop up
window. I'll look into it more tomorrow and try to send a better error
report then.

cheers,
sisi

Duncan Booth wrote:
> sisi <sisi at foei.org> wrote:
> 
>> I am getting an AttributeError: getNavTypes while trying to add a
>> location value criteria to a smart folder.
>>
> 
> Yes, that was a bug in kupu 1.4 beta 2. It should be fixed though if you
> grab the latest trunk version. 
> 
>> In addition to this, I get an error when I click on the "links" tab in
>> the kupu configlet. I will send that error in a separate email but
>> wanted to mention it here in case they are related (the error is
>> AttributeError: kupu_references) 
> 
> Yes, that's another known bug. I think I fixed it this morning, so the 
> latest trunk shouldn't have that problem. Alternatively you can stop the 
> bug by toggling on the option in the configlet to use kupu's reference 
> browser: you just need to turn that option on and save the configuration 
> once after which the bug won't show whether the option is on or off.
> 
>> I also originally thought that the problems were because I did not
>> have xsltproc installed but I have since installed that, restarted
>> zope and reinstalled kupu in the ZMI. The error persists. (Maybe I
>> have to make sure xsltproc is in my path or reinstall kupu on the
>> filesystem, but I can't find any documentation about that) 
> 
> As of 1.4 beta 2 (and 1.3.9) Kupu no longer requires xsltproc to install
> a subversion checkout for plone. 
> 
> _______________________________________________
> kupu-dev mailing list
> kupu-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/kupu-dev

-- 
# sisi nutt # extranet coordinator
# Friends of the Earth International
# PO Box 19199 # 1000 GD Amsterdam # The Netherlands
# Tel 31 20 6221369  # Fax 31 20 6392181  # http://www.foei.org
# email sisi at foei.org # skype foei_sisi

From georgeleejr at gmail.com  Sun Dec 17 15:36:05 2006
From: georgeleejr at gmail.com (George Lee)
Date: Sun, 17 Dec 2006 09:36:05 -0500
Subject: [kupu-dev] Small Bug in plone/librarytool.py
Message-ID: <f27ffb860612170636s1603ebb6mf3ace0b2d496a750@mail.gmail.com>

I downloaded kupu from trunk yesterday. In the definition of
_addNewTypesToResources, line 178, the following line is missing:

typetool = getToolByName(self, 'portal_types')

Without it, 'typeTool' isn't defined.

Peace,
George

From duncan.booth at suttoncourtenay.org.uk  Sun Dec 17 19:15:22 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Sun, 17 Dec 2006 18:15:22 +0000 (UTC)
Subject: [kupu-dev] Small Bug in plone/librarytool.py
References: <f27ffb860612170636s1603ebb6mf3ace0b2d496a750@mail.gmail.com>
Message-ID: <Xns989CB9B013185duncanrcpcouk@127.0.0.1>

"George Lee" <georgeleejr at gmail.com> wrote:

> I downloaded kupu from trunk yesterday. In the definition of
> _addNewTypesToResources, line 178, the following line is missing:
> 
> typetool = getToolByName(self, 'portal_types')
> 
> Without it, 'typeTool' isn't defined.
> 
Thanks.


From jon at onenw.org  Wed Dec 20 18:21:34 2006
From: jon at onenw.org (Jon Stahl)
Date: Wed, 20 Dec 2006 09:21:34 -0800
Subject: [kupu-dev] Patch -- Paragraph Styles Inside Tables
In-Reply-To: <f27ffb860609151757k3adc1388w5abe57d4016a4fe1@mail.gmail.com>
Message-ID: <79EDBCCCD70E25499369860FC555BBFA5AFA8E@bunnyluv.onenorthwest.office>

Duncan-

Did this patch ever get rolled into a release?

Do you think it's safe to install against Kupu 1.3.9.  We have customers
who are dying for editing inside tables, and are using Firefox 1.5.

best,
jon
 

> -----Original Message-----
> From: kupu-dev-bounces at codespeak.net 
> [mailto:kupu-dev-bounces at codespeak.net] On Behalf Of George Lee
> Sent: Friday, September 15, 2006 5:57 PM
> To: duncan.booth at suttoncourtenay.org.uk
> Cc: kupu-dev at codespeak.net
> Subject: [kupu-dev] Patch -- Paragraph Styles Inside Tables
> 
> Attached is a patch for kupu/trunk to allow paragraph styling 
> inside tables. Included are additional tests, and a changed 
> Plone test.
> 
> As described in previous e-mails, this does not allow one to 
> style paragraphs inside a th element inside Firefox (although 
> it is possible to put a th tag on a td cell after styling the 
> paragraphs).
> 
> Hope this works out well!
> 
> Peace,
> George
> 

From duncan.booth at suttoncourtenay.org.uk  Fri Dec 22 16:04:18 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 22 Dec 2006 15:04:18 +0000 (UTC)
Subject: [kupu-dev] Kupu 1.4 beta 3
Message-ID: <Xns98A199546EDFCduncanrcpcouk@127.0.0.1>

I just generated a beta 3 release for Kupu 1.4. This release adds support 
for configuring the toolbar buttons, generic setup and more. Changes from 
beta 2 are listed in full below.

Please download and test. I'm hoping to do a release candidate early in the 
new year aiming for a proper 1.4 release by the end of January.


- 1.4 Beta 3

  - Fixed a bug where createLink deleted the selected text.

  - Paragraph styles may now be replaced as well as added to in a
    widget definition.

  - Toolbar buttons may be hidden globally, according to an 
    expression, or from a widget definition.

  - Support for generic setup added (when present, older systems may
    continue to use the quickinstaller) 

  - Resource definitions can now optionally add any new Plone types to
    the resource. This means that all custom types will be 'linkable'
    unless otherwise configured.

  - A modified version of jslint is included in the kupu
    sources (with the ability to suppress a lot of the warnings).

  - The javascript files used by Plone (and some of the other ones)
    now run through jslint without warnings. This means they can be
    compressed by programs which remove line endings in an unsafe
    manner.



From duncan.booth at suttoncourtenay.org.uk  Fri Dec 22 17:27:10 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 22 Dec 2006 16:27:10 +0000 (UTC)
Subject: [kupu-dev] Patch -- Paragraph Styles Inside Tables
References: <f27ffb860609151757k3adc1388w5abe57d4016a4fe1@mail.gmail.com>
	<79EDBCCCD70E25499369860FC555BBFA5AFA8E@bunnyluv.onenorthwest.office>
Message-ID: <Xns98A19D751D4ABduncanrcpcouk@127.0.0.1>

"Jon Stahl" <jon at onenw.org> wrote:

> Did this patch ever get rolled into a release?

Only 1.4 beta. I'm hoping to get to 1.4 final during January.

> 
> Do you think it's safe to install against Kupu 1.3.9.  We have customers
> who are dying for editing inside tables, and are using Firefox 1.5.
> 
I didn't like the original patch because it didn't allow for removing the 
style once you had styled a paragraph in a table. That's why I modified the 
style list to have a 'remove style' option which can be used to remove 
spurious styles anywhere. I think that means it might be quite a bit of 
work to apply the same changes to 1.3.9.


From limi at plone.org  Fri Dec 22 19:47:39 2006
From: limi at plone.org (Alexander Limi)
Date: Fri, 22 Dec 2006 10:47:39 -0800
Subject: [kupu-dev] Kupu 1.4 beta 3
References: <Xns98A199546EDFCduncanrcpcouk@127.0.0.1>
Message-ID: <op.tky45pzuvhba00@plym.local>

On Fri, 22 Dec 2006 07:04:18 -0800, Duncan Booth  
<duncan.booth at suttoncourtenay.org.uk> wrote:

>   - The javascript files used by Plone (and some of the other ones)
>     now run through jslint without warnings. This means they can be
>     compressed by programs which remove line endings in an unsafe
>     manner.

Yay! Thanks, Duncan! This will make Kupu more lightweight for our users in  
Plone 3.0. :)

-- 
_____________________________________________________________________

      Alexander Limi ? Chief Architect ? Plone Solutions ? Norway

  Consulting ? Training ? Development ? http://www.plonesolutions.com
_____________________________________________________________________

       Plone Co-Founder ? http://plone.org ? Connecting Content
   Plone Foundation ? http://plone.org/foundation ? Protecting Plone
 


From limi at plone.org  Fri Dec 22 20:20:32 2006
From: limi at plone.org (Alexander Limi)
Date: Fri, 22 Dec 2006 11:20:32 -0800
Subject: [kupu-dev] Kupu 1.4 beta 3
References: <Xns98A199546EDFCduncanrcpcouk@127.0.0.1>
Message-ID: <op.tky6oi0dvhba00@plym.local>

On Fri, 22 Dec 2006 07:04:18 -0800, Duncan Booth
<duncan.booth at suttoncourtenay.org.uk> wrote:

>   - The javascript files used by Plone (and some of the other ones)
>     now run through jslint without warnings. This means they can be
>     compressed by programs which remove line endings in an unsafe
>     manner.

Yay! Thanks, Duncan! This will make Kupu more lightweight for our users in
Plone 3.0. :)

-- 
_____________________________________________________________________

      Alexander Limi ? Chief Architect ? Plone Solutions ? Norway

  Consulting ? Training ? Development ? http://www.plonesolutions.com
_____________________________________________________________________

       Plone Co-Founder ? http://plone.org ? Connecting Content
   Plone Foundation ? http://plone.org/foundation ? Protecting Plone
 


From duncan.booth at suttoncourtenay.org.uk  Fri Dec 22 21:01:44 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 22 Dec 2006 20:01:44 +0000 (UTC)
Subject: [kupu-dev] Kupu 1.4 beta 3
References: <Xns98A199546EDFCduncanrcpcouk@127.0.0.1>
	<op.tky45pzuvhba00@plym.local>
Message-ID: <Xns98A1CBC0B54Dduncanrcpcouk@127.0.0.1>

"Alexander Limi" <limi at plone.org> wrote:

> On Fri, 22 Dec 2006 07:04:18 -0800, Duncan Booth  
><duncan.booth at suttoncourtenay.org.uk> wrote:
>>   - The javascript files used by Plone (and some of the other ones)
>>     now run through jslint without warnings. This means they can be
>>     compressed by programs which remove line endings in an unsafe
>>     manner.
> Yay! Thanks, Duncan! This will make Kupu more lightweight for our
> users in  Plone 3.0. :)
> 

BTW, anyone else developing javascript for Plone please feel free to use
the jslint.js file to clean up javascript: I'll try to write up some
documentation at some point, but in short: you want to install rhino
from http://www.mozilla.org/rhino/, then you can run it as follows: 

java org.mozilla.javascript.tools.shell.Main jslint.js [options] [file]

The options are (* means default):

--browser, --nobrowser*
        true if the standard browser globals should be predefined
--cap, --nocap*
        true if upper case HTML should be allowed
--debug, --nodebug*
        true if debugger statements should be allowed
--eqeqeq, --noeqeqeq*
        true if === should be required
--error #
        Specified messages are fatals
--evil, --noevil*
        true if eval should be allowed
--extern #
        Add external names
--help
        show usage text
--ignore #
        Specified messages are ignored
--jscript, --nojscript*
        true if jscript deviations should be allowed
--laxLineEnd, --nolaxLineEnd*
        true if line breaks should not be checked
--options #
        Read additional arguments and options from a file
--passfail, --nopassfail*
        true if the scan should stop on first error
--plusplus, --noplusplus*
        true if increment/decrement should not be allowed
--redef, --noredef*
        true if var redefinition should be allowed
--undef, --noundef*
        true if undefined variables are errors
--warn #
        Specified messages are warnings
--widget, --nowidget*
        true if the Yahoo Widgets globals should be predefined


I run it with the options --config jslint.opts where jslint.opts
contains: 

--browser --nopassfail --redef
--extern _,_IE_VERSION,_SARISSA_IS_IE,_SARISSA_IS_MOZ,ActiveXObject
--extern addEventHandler,AnchorDrawer,AnchorTool,CleanupExpressionsTool
--extern ColorchooserTool,ContextFixer,ContextMenu,ContextMenuElement
--extern DefinitionListTool,DrawerTool,extern,getBaseTagClass,getFromSelector
--extern IESelection,ImageLibraryDrawer,ImageTool,ImageToolBox,initKupu,kupu
--extern KupuButton,kupuButtonDisable,kupuButtonEnable,KupuDocument,KupuEditor
--extern KupuInspector,KupuRemoveElementButton,KupuSpellChecker,KupuStateButton
--extern KupuUI,KupuZoomTool,LinkDrawer,LinkLibraryDrawer,LinkTool,LinkToolBox
--extern ListTool,loadDictFromXML,MozillaSelection,newDocumentElement
--extern newElement,Node,NodeIterator,NonXHTMLTagFilter,openPopup
--extern parentWithStyleChecker,PlainLogger,PropertyTool,Range,Sarissa
--extern saveOnPart,selectSelectItem,ShowPathTool,SourceEditTool,TableDrawer
--extern TableTool,TableToolBox,timer_instance,UpdateStateCancelBubble
--extern ViewSourceTool,XhtmlValidation,XMLSerializer,XPathResult,XSLTProcessor
--ignore 501,510,531,535,544,546,554,557

It doesn't yet handle multiple files properly: It will scan more than one file 
at a time, but it resets everything between files and I need to get it to 
remember the globals. Once it does that I should be able to get rid of almost all the
--extern options above. The errors I ignored are the ones I don't like such as
complaining about superfluous semicolons (I might clean them up sometime, but
not today), and complaining about multiple variable definitions: I like to
use the 'var' keyword a lot, in fact I added an extra warning not in the original
code to warn if you try to use a for loop variable without the var keyword.

Errors may also be ignored using comments such as /*ignore 558 */. Start without 
ignoring any errors and add ignores or fix the problems as you prefer. Some errors
aren't ignorable as jslint won't recover up when it sees them.

The differences in this jslint.js from Douglas Crockford's original are:

command line options
ability to ignore some warnings
warnings about unused local variables and undefined globals: the original 
gives these warnings on the web based version only, not the command line 
version.


From jon at onenw.org  Tue Dec 26 18:32:51 2006
From: jon at onenw.org (Jon Stahl)
Date: Tue, 26 Dec 2006 09:32:51 -0800
Subject: [kupu-dev] Patch -- Paragraph Styles Inside Tables
In-Reply-To: <Xns98A19D751D4ABduncanrcpcouk@127.0.0.1>
Message-ID: <79EDBCCCD70E25499369860FC555BBFA5AFAC5@bunnyluv.onenorthwest.office>

> -----Original Message-----
> From: kupu-dev-bounces at codespeak.net 
> [mailto:kupu-dev-bounces at codespeak.net] On Behalf Of Duncan Booth
> Sent: Friday, December 22, 2006 8:27 AM
> To: kupu-dev at codespeak.net
> Subject: Re: [kupu-dev] Patch -- Paragraph Styles Inside Tables
> 
> "Jon Stahl" <jon at onenw.org> wrote:
> 
> > Did this patch ever get rolled into a release?
> 
> Only 1.4 beta. I'm hoping to get to 1.4 final during January.

Thanks, Duncan. I think we can wait for 1.4 -- if helps get the release
out, please know that we have a bunch of people waiting with baited
breath!  1.4 looks like a huge step forward for Kupu!
 
best,
jon

From florian.schulze at gmx.net  Wed Dec 27 13:36:48 2006
From: florian.schulze at gmx.net (Florian Schulze)
Date: Wed, 27 Dec 2006 13:36:48 +0100
Subject: [kupu-dev] Kupu 1.4 beta 3
References: <Xns98A199546EDFCduncanrcpcouk@127.0.0.1>
	<op.tky6oi0dvhba00@plym.local>
Message-ID: <op.tk7xbmm5hjnvn3@news.gmane.org>

On Fri, 22 Dec 2006 20:20:32 +0100, Alexander Limi  
<limi at plone.org> wrote:

> On Fri, 22 Dec 2006 07:04:18 -0800, Duncan Booth
> <duncan.booth at suttoncourtenay.org.uk> wrote:
>
>>   - The javascript files used by Plone (and some of the other ones)
>>     now run through jslint without warnings. This means they can be
>>     compressed by programs which remove line endings in an unsafe
>>     manner.
>
> Yay! Thanks, Duncan! This will make Kupu more lightweight for our users  
> in
> Plone 3.0. :)

Hi!

It will probably only help marginally. My packer (unlike Dean Edwards) is  
clever enough to keep newlines where they are unsafe to remove ("safe"  
compression is named like that for a reason :) ). Most of the time you add  
a semicolon to allow safe removal of the newline, but that's the same  
amount of bytes (one) except on DOS and Windows :)
But it's generally good to have linted JavaScript, as it's more likely  
that unlinted js fails to pack than linted.

Regards,
Florian Schulze


From duncan.booth at suttoncourtenay.org.uk  Wed Dec 27 18:30:04 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Wed, 27 Dec 2006 17:30:04 +0000 (UTC)
Subject: [kupu-dev] Kupu 1.4 beta 3
References: <Xns98A199546EDFCduncanrcpcouk@127.0.0.1>
	<op.tky6oi0dvhba00@plym.local> <op.tk7xbmm5hjnvn3@news.gmane.org>
Message-ID: <Xns98A6B1E226A0Eduncanrcpcouk@127.0.0.1>

"Florian Schulze" <florian.schulze at gmx.net> wrote:

> On Fri, 22 Dec 2006 20:20:32 +0100, Alexander Limi  
><limi at plone.org> wrote:
> 
>> On Fri, 22 Dec 2006 07:04:18 -0800, Duncan Booth
>> <duncan.booth at suttoncourtenay.org.uk> wrote:
>>
>>>   - The javascript files used by Plone (and some of the other ones)
>>>     now run through jslint without warnings. This means they can be
>>>     compressed by programs which remove line endings in an unsafe
>>>     manner.
>>
>> Yay! Thanks, Duncan! This will make Kupu more lightweight for our
>> users  in
>> Plone 3.0. :)
> 
> Hi!
> 
> It will probably only help marginally. My packer (unlike Dean Edwards)
> is  clever enough to keep newlines where they are unsafe to remove
> ("safe"  compression is named like that for a reason :) ). Most of the
> time you add  a semicolon to allow safe removal of the newline, but
> that's the same  amount of bytes (one) except on DOS and Windows :)
> But it's generally good to have linted JavaScript, as it's more likely
>  that unlinted js fails to pack than linted.
> 
Full compression certainly broke kupu before I added the missing 
semicolons, but I think safe was indeed safe, so the difference probably 
only is marginal. I also found a couple of probably insignificant bugs 
during the linting. Mostly though I hope I've removed one source of 
possible user error.

If I could be bothered I would also go through and remove a lot of the 
extra semicolons (saving a few more bytes), but I don't want to remove them 
all as I really hate the idea that you may have to look back several 
hundred lines to work out whether or not a semicolon is actually required 
somewhere, so I'd rather that if in doubt just add a semicolon even when it 
isn't strictly required.

Is there a worthwhile benefit to inserting dollar signs in front of local 
variable names? There's no way I'm going through all the code to do that 
manually, but it might be possible to use the lint output (which can report 
on local variable usage) to automate the process somehow. e.g. building a 
list of all names which are only used as local variables and then doing 
global replaces on those names.

Of course the ideal might be to put a full javascript parser into 
ResourceRegistry's packer and then it could add and remove semicolons (and 
rename local variables) perfectly, but life is a bit too short for that.



From jean.lagarde at gmail.com  Fri Dec 29 02:22:21 2006
From: jean.lagarde at gmail.com (Jean Lagarde)
Date: Thu, 28 Dec 2006 17:22:21 -0800
Subject: [kupu-dev] Why disable the text_format select in Plone?
Message-ID: <ce5902f0612281722u47747054k677df326075bb738@mail.gmail.com>

I wanted to make the default content type of my AT Content Types other than
HTML. In principle that should have been trivial by editing
atcontenttypes.conf, but Kupu has all sorts of ways to insist on forcing the
content type select input to HTML and then disabling it.

I was able to make Kupu do what I wanted by editing kupuploneinit.js and
contentUsesKupu (I also changed a couple of things in kupu-wysiwyg-support,
but that was not necessary), and it seems to behave pretty much as I would
want, but I wonder why it was decided to make Kupu behave that way in the
first place? Am I missing some dangerous side effect of allowing to go back
and forth between different content types with Kupu enabled? I can't see why
the behavior would be worse than when not having Kupu selected as one's
editor, or when using a browser that does not support it (in both of which
cases one can freely go back and forth between different types using the
select control).

Cheers,

Jean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/kupu-dev/attachments/20061228/f0f41d16/attachment.htm 

From duncan.booth at suttoncourtenay.org.uk  Fri Dec 29 10:59:50 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 29 Dec 2006 09:59:50 +0000 (UTC)
Subject: [kupu-dev] Why disable the text_format select in Plone?
References: <ce5902f0612281722u47747054k677df326075bb738@mail.gmail.com>
Message-ID: <Xns98A865B44B5DEduncanrcpcouk@127.0.0.1>

"Jean Lagarde" <jean.lagarde at gmail.com> wrote:

> I was able to make Kupu do what I wanted by editing kupuploneinit.js
> and contentUsesKupu (I also changed a couple of things in
> kupu-wysiwyg-support, but that was not necessary), and it seems to
> behave pretty much as I would want, but I wonder why it was decided to
> make Kupu behave that way in the first place? Am I missing some
> dangerous side effect of allowing to go back and forth between
> different content types with Kupu enabled? I can't see why the
> behavior would be worse than when not having Kupu selected as one's 
> editor, or when using a browser that does not support it (in both of
> which cases one can freely go back and forth between different types
> using the select control).
> 

Since the output from Kupu is always html, there is quite a drastic effect 
if you allow the user to claim that the format is something like ReST 
instead. When Kupu is not selected you are free to type in whatever you 
want, so only you as a human can tell at a glance whether what you entered 
was plain text, ReST, or HTML.

If your input is ReST and you force kupu to load then what gets loaded into 
Kupu is ReST transformed to HTML. This is a non-reversible transformation.

In an ideal world (thats one where a lot of other people decided to help me 
doing kupu development), kupu would support recognise the different output 
formats. If you were editing plain text then you wouldn't be allowed to set 
character or paragraph styles or insert tables, and the output would simply 
be the plain text corresponding to what you typed. If you edited ReST then 
you would be allowed some simple formatting (e.g. bold and italic) and when 
you saved your document it would be converted to ReST formatting instead.

Unfortunately we don't have that now, so Kupu tries to work on the 
principle of least suprise: if you want to specify a format that Kupu 
doesn't support then you have to turn kupu off first.

A simpler alternative might be to allow you to change the format but if you 
do to force kupu into source view mode with switching back to html disabled 
and filtering on save also disabled. I don't like that though because I 
think it conflicts with the current behaviour where switching format also 
does a conversion.

If of course you've come up with an alternative way of supporting multiple 
content types which is logical, consistent and general purpose then suggest 
it as a patch.


From amartine at lexmark.com  Fri Dec 29 16:01:52 2006
From: amartine at lexmark.com (amartine at lexmark.com)
Date: Fri, 29 Dec 2006 10:01:52 -0500
Subject: [kupu-dev] Jeremy J Martinez/Lex/Lexmark is out of the office.
Message-ID: <OFD48E4656.AE5F5304-ON85257253.005291DD-85257253.005291DD@lexmark.com>

I will be out of the office starting  12/22/2006 and will not return until
01/02/2007.

I will be in for a half-day on Wednesday, 12 / 27, to distribute reports
and check on needed IDs for the tools I support.


From jon at onenw.org  Fri Dec 29 20:04:01 2006
From: jon at onenw.org (Jon Stahl)
Date: Fri, 29 Dec 2006 11:04:01 -0800
Subject: [kupu-dev] why does kupu switch to "no style" rather than "normal"
	on a new line after a heading?
Message-ID: <79EDBCCCD70E25499369860FC555BBFA5AFB06@bunnyluv.onenorthwest.office>

Duncan et al-
 
I suspect there may be a good-but-not-obvious reason for this, but I
can't help but wonder why the following behavior occurs, and if it can
be modfied:
 
When set a line to "heading" or "subheading" format, then hit "enter" to
start a new line, the style for the next paragraph becomes "no style"
rather than "normal".  That seems very unintuitive.  Worse, it often
seems to result in content authors creating lots of unstyled paragraphs,
which under Plone's default styles looks really weird because the
leading of "no style" paragraphs is much tighter than "normal"
paragaphs.
 
Is there anything that can safely be done to make the next paragraph
after an <h> style be "normal" style?
 
best,
jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/kupu-dev/attachments/20061229/de8efbdf/attachment.htm 

From duncan.booth at suttoncourtenay.org.uk  Fri Dec 29 22:22:43 2006
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 29 Dec 2006 21:22:43 +0000 (UTC)
Subject: [kupu-dev] why does kupu switch to "no style" rather than
	"normal" on a new line after a heading?
References: <79EDBCCCD70E25499369860FC555BBFA5AFB06@bunnyluv.onenorthwest.office>
Message-ID: <Xns98A8D979660F3duncanrcpcouk@127.0.0.1>

"Jon Stahl" <jon at onenw.org> wrote:

> I suspect there may be a good-but-not-obvious reason for this, but I
> can't help but wonder why the following behavior occurs, and if it can
> be modfied:
>  
> When set a line to "heading" or "subheading" format, then hit "enter" to
> start a new line, the style for the next paragraph becomes "no style"
> rather than "normal".  That seems very unintuitive.  Worse, it often
> seems to result in content authors creating lots of unstyled paragraphs,
> which under Plone's default styles looks really weird because the
> leading of "no style" paragraphs is much tighter than "normal"
> paragaphs.
>  
> Is there anything that can safely be done to make the next paragraph
> after an <h> style be "normal" style?
>  

I know, but I'm not sure there is much I can do about it. Kupu used to try 
to ensure that everything you entered was inside a paragraph (i.e. Normal 
style), but that hit problems at the end of the buffer when interactions 
with Firefox's attempts to insert <br/> at the end of the buffer but not 
inside a paragraph resulted in infinite loops of kupu vs Firefox. I changed 
it to just accept what the browser did which is why you now get the 'no 
style' effect.

Perhaps there is a better way to handle it, but if so I haven't yet found 
it.


From jon at onenw.org  Fri Dec 29 22:43:30 2006
From: jon at onenw.org (Jon Stahl)
Date: Fri, 29 Dec 2006 13:43:30 -0800
Subject: [kupu-dev] why does kupu switch to "no style" rather
	than"normal" on a new line after a heading?
In-Reply-To: <Xns98A8D979660F3duncanrcpcouk@127.0.0.1>
Message-ID: <79EDBCCCD70E25499369860FC555BBFA5AFB0F@bunnyluv.onenorthwest.office>

 

> -----Original Message-----
> From: kupu-dev-bounces at codespeak.net 
> [mailto:kupu-dev-bounces at codespeak.net] On Behalf Of Duncan Booth
> Sent: Friday, December 29, 2006 1:23 PM
> To: kupu-dev at codespeak.net
> Subject: Re: [kupu-dev] why does kupu switch to "no style" 
> rather than"normal" on a new line after a heading?
> 
> "Jon Stahl" <jon at onenw.org> wrote:
> 
> > I suspect there may be a good-but-not-obvious reason for 
> this, but I 
> > can't help but wonder why the following behavior occurs, 
> and if it can 
> > be modfied:
> >  
> > When set a line to "heading" or "subheading" format, then 
> hit "enter" 
> > to start a new line, the style for the next paragraph 
> becomes "no style"
> > rather than "normal".  That seems very unintuitive.  Worse, 
> it often 
> > seems to result in content authors creating lots of unstyled 
> > paragraphs, which under Plone's default styles looks really weird 
> > because the leading of "no style" paragraphs is much 
> tighter than "normal"
> > paragaphs.
> >  
> > Is there anything that can safely be done to make the next 
> paragraph 
> > after an <h> style be "normal" style?
> >  
> 
> I know, but I'm not sure there is much I can do about it. 
> Kupu used to try to ensure that everything you entered was 
> inside a paragraph (i.e. Normal style), but that hit problems 
> at the end of the buffer when interactions with Firefox's 
> attempts to insert <br/> at the end of the buffer but not 
> inside a paragraph resulted in infinite loops of kupu vs 
> Firefox. I changed it to just accept what the browser did 
> which is why you now get the 'no style' effect.
> 
> Perhaps there is a better way to handle it, but if so I 
> haven't yet found it.

I suspected something like that.  Would looking at how other WYSIWYG
editors such as FCK or HTMLArea/Xinha be likely to offer some
inspiration?  It seems like this would be a common problem, yet I don't
think it afflicts other editors.

best,
jon