headers
Hanno Schlichting | 1 Nov 2008 10:02
Picon

Re: r23053 - in Plone/trunk

David Glick wrote:
> Author: davisagli
> Date: Sat Nov  1 07:26:33 2008
> New Revision: 23053
> 
> Since we ripped out the template globals we're missing this IViewView
> marker on the view, which is important b/c the content action menus
> are registered to it.  is there a better way to do this?  should we
> deprecate IViewView since it only matters for the content actions
> viewlet in OOTB Plone?

The way this interface is hacked into templates is definitely a no-go.

The only sane solution I can see, is to have the IViewView interface be
provided by the view, which is featuring the specific template.

This does require each template, that wants to use this particular
feature, to be a view-driven template. For Plone trunk that is a
perfectly fine requirement.

For Plone itself this means to move the templates from the plone_content
skins layer into ATContentTypes/browser and let them be
ViewPageTemplateFiles.

Moving those templates into ATCT is on my todo list for a while anyways.
But anyone feel free to do that before I have the time ;)

Hanno

-------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 19 comments |
headers
Plone Tests Summarizer | 1 Nov 2008 13:00
Picon

Plone Tests: 11 OK, 7 Failed

Summary of messages to the testbot list.
Period Fri Oct 31 12:00:00 2008 UTC to Sat Nov  1 12:00:00 2008 UTC.
There were 18 messages: 5 from ATContentTypes Tests, 5 from Archetypes Tests, 5 from CMFPlone Tests, 3 from
plone.* Tests.

Test failures
-------------

Subject: FAILED (failures=2) : Plone-3.0 Zope-2.10 Python-2.4.5
From: CMFPlone Tests
Date: Sat Nov  1 04:31:11 UTC 2008
URL: http://lists.plone.org/pipermail/testbot/2008-November/005949.html

Subject: FAILED (failures=2) : Plone-3.1 Zope-2.10 Python-2.4.5
From: CMFPlone Tests
Date: Sat Nov  1 04:32:41 UTC 2008
URL: http://lists.plone.org/pipermail/testbot/2008-November/005950.html

Subject: FAILED (failures=2) : Plone-3.1 Zope-2.11 Python-2.4.5
From: CMFPlone Tests
Date: Sat Nov  1 04:34:11 UTC 2008
URL: http://lists.plone.org/pipermail/testbot/2008-November/005951.html

Subject: FAILED (failures=1) : Plone-3.0 Zope-2.10 Python-2.4.5
From: plone.* Tests
Date: Sat Nov  1 04:44:41 UTC 2008
URL: http://lists.plone.org/pipermail/testbot/2008-November/005952.html

Subject: FAILED (failures=3) : Plone-3.1 Zope-2.10 Python-2.4.5
From: plone.* Tests
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Aspeli | 1 Nov 2008 13:42
Picon
Gravatar

Re: r23053 - in Plone/trunk

Hanno Schlichting wrote:
> David Glick wrote:
>> Author: davisagli
>> Date: Sat Nov  1 07:26:33 2008
>> New Revision: 23053
>>
>> Since we ripped out the template globals we're missing this IViewView
>> marker on the view, which is important b/c the content action menus
>> are registered to it.  is there a better way to do this?  should we
>> deprecate IViewView since it only matters for the content actions
>> viewlet in OOTB Plone?

No!

IViewView is really important. It's a pretty common use case to register 
something that you want on "the view" (e.g. comments, ratings) and not 
elsewhere.

> The way this interface is hacked into templates is definitely a no-go.

You mean in 3.x? It's not hacked into templates as such, but it's 
applied to the view during a request cycle. I think applying it 
declaratively during the request is OK - it's a transient marker after 
all, and Plone has a reasonably good idea about whether you're on "the 
view" or not, but relying on global_defines to do so is pretty lame.

> The only sane solution I can see, is to have the IViewView interface be
> provided by the view, which is featuring the specific template.

Right - it could work that way, except it's probably practically
(Continue reading)

Permalink | Reply | 18 comments |
headers
Hanno Schlichting | 1 Nov 2008 14:24
Picon

Re: r23053 - in Plone/trunk

Martin Aspeli wrote:
> Hanno Schlichting wrote:
> IViewView is really important. It's a pretty common use case to register 
> something that you want on "the view" (e.g. comments, ratings) and not 
> elsewhere.

I'll comment on the general problem in a separate mail.

>> The way this interface is hacked into templates is definitely a no-go.
> 
> You mean in 3.x? It's not hacked into templates as such, but it's 
> applied to the view during a request cycle. I think applying it 
> declaratively during the request is OK - it's a transient marker after 
> all, and Plone has a reasonably good idea about whether you're on "the 
> view" or not, but relying on global_defines to do so is pretty lame.

I don't care about the technical implementation in 3.x. It is insane,
but has been around long enough and proven to be stable. For 4.x it is a
no-go. Walking stack frames to apply marker interfaces to innocent
victims is simply not an acceptable way of doing anything.

Hanno

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Permalink | Reply | 0 comments |
headers
Hanno Schlichting | 1 Nov 2008 15:35
Picon

IViewView and beyond - am I editing content or not

Martin Aspeli wrote:
> IViewView is really important. It's a pretty common use case to register 
> something that you want on "the view" (e.g. comments, ratings) and not 
> elsewhere.

Let me share my current thinking about this. This is not final or
completely thought of, but might spur some discussion.

I think the IViewView interface has horrible name and a horrible
implementation. It was invented to cover a particular use-case and then
has been abused for more use-cases without looking at the big-picture.

How did it came to live? According to my memory, Alexander wanted to
hide certain functionality on the edit screens. Most importantly the
content menu that allowed to add new items into a folder. This was
important, as thanks to the way portal factory works, you could easily
click on links in the menu, that would refer to the not yet created content.

What we did was to invent a marker interface that would transport the
opposite meaning, though. We don't yet have an IEditView interface, but
only a IViewView interface.

It would have been enough to restrict the content menu by the same
isTemporary methods from portal factory we use in so many different
places. But we wanted to be more general and liked interfaces. Give me a
hammer and your problem is certainly a nail ... ;)

So what is the real problem?

One problem is portal factory. There is a real need to hide certain
(Continue reading)

Permalink | Reply | 16 comments |
headers
Alan Runyan | 1 Nov 2008 19:37

Re: IViewView and beyond - am I editing content or not

> One problem is portal factory. There is a real need to hide certain
> functionality while using it. We do have methods to figure out if we are
> using portal factory right now (just looking at the url is enough).

We need to get rid of portal_factory.

> What are the other problems we started using this interface for?
>
> I think this boils down to be able to show certain functionality based
> on the way a user currently uses the site. It is something like a
> working mode of the user. This is influenced by policy decisions for
> each site that restrict the available options, show or hide certain
> features based on the audience.
>
> Sometimes a user wants to just look at the site. Sometimes he wants to
> actually edit things in the site. Sometimes he wants to manage the site
> and get as much information out of it as possible.
>
> For us this is a particular problem, as we do not have a separation
> between an edit or admin interface and a public site. You don't go to a
> different URL and use a complete separate admin UI to manage the site.

Uhm.  I believe Plone should official support this use case.  Look at
the suite of "Skin Switching" products.  They are around this use-case.
Just want to make sure we continue to support this mode of use.

> So we are left with the same kind of users using the exact same site
> while sometimes trying to change it and sometimes just to view or engage
> with its public offerings.
>
(Continue reading)

Permalink | Reply | 12 comments |
headers
Duncan Booth | 1 Nov 2008 19:40
X-Face
Picon

Re: kupu reference browser: NS_ERROR_DOM_NOT_SUPPORTED_ERR

mustapha <mustapha@...> wrote:

> Hi all,
> 
> I'm using kupu's refrencebrowser on a site that has:
> 
> Plone 2.5.5,
> CMF-1.6.4,
> Zope (Zope 2.9.8-final, python 2.4.4, linux2),
> Five 1.4.4,
> Python 2.4.4 (#2, Apr 15 2008, 23:43:20) [GCC 4.1.2 20061115
> (prerelease) (Debian 4.1.1-21)],
> PIL 1.1.6
> kupu 1.4.11
> 
> I keep getting this error on FF3 and IE7:
> 
> Error: uncaught exception: [Exception... "Operation is not supported"
> code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)"
> location: "http://www.myserver.com/referencebrowser.js Line: 73"]
> 
> when I select an object and click OK.
> 
> When I try with Flock 0.7.14 it is working as it should be.
> 
Do you have any other javascript libraries installed in your copy of Plone?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hanno Schlichting | 1 Nov 2008 20:48
Picon

Re: IViewView and beyond - am I editing content or not

(Reposting to the list)

Alan Runyan wrote:
>> The mode might be one of the variables that needs to be taken into
>> account when determining whether to show a particular UI feature or not.
>>
>> The permissions the user has in the current context, the global policies
>> defined by the site and personal preferences are all and maybe more
>> important factors to take into account when approaching this.
>>
>> Currently we have a wild mix of seventeen different ways to manage
>> availability of a UI feature. This is a problem to tackle as well. But
>> it is only barely related to the working mode of the user.
> 
> The first step could be for us to enumerate these modes.  And deprecate
> the ones that 4.0 will unify.
> 
> So is the understanding that there needs to be a lead in unifing these
> modes and get rid of IVIewView?

I'd very much welcome if someone would step up to look into this in detail.

My feeling is, that we do not have a good concise story for when and
where to show administrative functions in the UI.

We have the content area and wrap it with content specific actions. But
at the same time we have a personal bar and mix-in 'site setup' into the
global actions, which makes it hard to design for. Then we sprinkle the
"Manage portlets" into a random place in the design and once we enter
the author page / personal dashboard we end up with a wild mix of View
(Continue reading)

Permalink | Reply | 11 comments |
headers
Hedley Roos | 1 Nov 2008 20:59
Picon

Re: IViewView and beyond - am I editing content or not

> a new way of "Inline Editing"

Can you elaborate please?

Hedley

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Permalink | Reply | 1 comment |
headers
Hanno Schlichting | 1 Nov 2008 21:16
Picon

Re: IViewView and beyond - am I editing content or not

Hedley Roos wrote:
>> a new way of "Inline Editing"
> 
> Can you elaborate please?

Look for http://limi.net/articles/simplify-plones-editing-experience and
Limi's recent talks and keynotes on conferences. I'm not sure if there
is a widely accessible source for the most recent state of this.

Hanno

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Permalink | Reply | 0 comments |

Gmane