headers
Martin Aspeli | 8 Apr 2006 00:53
Picon
Gravatar

Viewlets

Hi guys,

I'm thinking about several things I'd like to enable in Plone 3.0, and the  
concept of using viewlets is really attractive. For example, the  
contentmenu (the green one, with actions and state and add item): It's  
impossible to add a new drop-down without overriding the entire thing. In  
general, this could be solved by having the whole menu be rendered as a  
viewlet manager, with each menu provided by a viewlet. You could then  
register new viewlets to get new menus.

I've only read through the READMEs of zope.contentprovider 

(http://svn.zope.org/Zope3/trunk/src/zope/contentprovider/README.txt?rev=66018&view=markup)

and zope.viewlet  
(http://svn.zope.org/Zope3/trunk/src/zope/viewlet/README.txt?rev=41173&view=auto),  
and probably should do so again.

I wanted to ask, though, if any of you have got some experience with  
viewlets and would like to discuss it further? In particular, we need to  
work out whether we could:

  - use them in 3.0  directly (unlikely, since it requires a provides: TAL  
namespace, which probably requires the Zope 3.x TAL implementation that  
may or may not land in Zope 2.10)

  - use them via some additional magic (e.g. a global python object that  
could act as the provides: expression in a regular tal:content)

  - use its interfaces and implement our own rendering cycle via views (the
(Continue reading)

Permalink | Reply | 6 comments |
headers
whit | 8 Apr 2006 05:54
Picon

Re: Viewlets

Martin Aspeli wrote:
> Hi guys,
>
> I'm thinking about several things I'd like to enable in Plone 3.0, and 
> the concept of using viewlets is really attractive. For example, the 
> contentmenu (the green one, with actions and state and add item): It's 
> impossible to add a new drop-down without overriding the entire thing. 
> In general, this could be solved by having the whole menu be rendered 
> as a viewlet manager, with each menu provided by a viewlet. You could 
> then register new viewlets to get new menus.
>
> I've only read through the READMEs of zope.contentprovider 
>
(http://svn.zope.org/Zope3/trunk/src/zope/contentprovider/README.txt?rev=66018&view=markup) 
> and zope.viewlet 
> (http://svn.zope.org/Zope3/trunk/src/zope/viewlet/README.txt?rev=41173&view=auto), 
> and probably should do so again.
>
> I wanted to ask, though, if any of you have got some experience with 
> viewlets and would like to discuss it further? In particular, we need 
> to work out whether we could:
>
>  - use them in 3.0  directly (unlikely, since it requires a provides: 
> TAL namespace, which probably requires the Zope 3.x TAL implementation 
> that may or may not land in Zope 2.10)
+1. this is the right thing to do.  it might require more work but until 
it's been tried and tracer bullets have been fired, everything else is a 
premature hack.  I realize this isn't much of a way to start discussion, 
but personally I think investigation is more important at this point.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rob Miller | 8 Apr 2006 06:17
Favicon

Re: Viewlets

On Apr 7, 2006, at 8:54 PM, whit wrote:
> Martin Aspeli wrote:
>> Hi guys,
>>
>> I'm thinking about several things I'd like to enable in Plone 3.0,  
>> and the concept of using viewlets is really attractive. For  
>> example, the contentmenu (the green one, with actions and state  
>> and add item): It's impossible to add a new drop-down without  
>> overriding the entire thing. In general, this could be solved by  
>> having the whole menu be rendered as a viewlet manager, with each  
>> menu provided by a viewlet. You could then register new viewlets  
>> to get new menus.
>>
>> I've only read through the READMEs of zope.contentprovider (http:// 
>> svn.zope.org/Zope3/trunk/src/zope/contentprovider/README.txt? 
>> rev=66018&view=markup) and zope.viewlet (http://svn.zope.org/Zope3/ 
>> trunk/src/zope/viewlet/README.txt?rev=41173&view=auto), and  
>> probably should do so again.
>>
>> I wanted to ask, though, if any of you have got some experience  
>> with viewlets and would like to discuss it further? In particular,  
>> we need to work out whether we could:
>>
>>  - use them in 3.0  directly (unlikely, since it requires a  
>> provides: TAL namespace, which probably requires the Zope 3.x TAL  
>> implementation that may or may not land in Zope 2.10)
> +1. this is the right thing to do.  it might require more work but  
> until it's been tried and tracer bullets have been fired,  
> everything else is a premature hack.  I realize this isn't much of  
> a way to start discussion, but personally I think investigation is
(Continue reading)

Permalink | Reply | 4 comments |
headers
whit | 8 Apr 2006 06:40
Picon

Re: Viewlets

Rob Miller wrote:
> On Apr 7, 2006, at 8:54 PM, whit wrote:
>> Martin Aspeli wrote:
>>> Hi guys,
>>>
>>> I'm thinking about several things I'd like to enable in Plone 3.0, 
>>> and the concept of using viewlets is really attractive. For example, 
>>> the contentmenu (the green one, with actions and state and add 
>>> item): It's impossible to add a new drop-down without overriding the 
>>> entire thing. In general, this could be solved by having the whole 
>>> menu be rendered as a viewlet manager, with each menu provided by a 
>>> viewlet. You could then register new viewlets to get new menus.
>>>
>>> I've only read through the READMEs of zope.contentprovider 
>>>
(http://svn.zope.org/Zope3/trunk/src/zope/contentprovider/README.txt?rev=66018&view=markup) 
>>> and zope.viewlet 
>>> (http://svn.zope.org/Zope3/trunk/src/zope/viewlet/README.txt?rev=41173&view=auto), 
>>> and probably should do so again.
>>>
>>> I wanted to ask, though, if any of you have got some experience with 
>>> viewlets and would like to discuss it further? In particular, we 
>>> need to work out whether we could:
>>>
>>>  - use them in 3.0  directly (unlikely, since it requires a 
>>> provides: TAL namespace, which probably requires the Zope 3.x TAL 
>>> implementation that may or may not land in Zope 2.10)
>> +1. this is the right thing to do.  it might require more work but 
>> until it's been tried and tracer bullets have been fired, everything 
>> else is a premature hack.  I realize this isn't much of a way to
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Aspeli | 8 Apr 2006 13:56
Picon
Gravatar

Re: Viewlets

On Sat, 08 Apr 2006 05:40:48 +0100, whit  
<d.w.morriss@...> wrote:

> considering we are jumping from 2.5 -> 3.0, we have some play.
>
> there is no reason that there can't be releases in between 2.5 and 3.0.
> Let's use those numbers to get ourselves back in sync with the rest of
> our stack.  depending on when thing fall, 2.6, 2.7, 2.8, and 2.9 could
> serve as a way to ease onto CMF2.0, zope 2.10, AT1.4 & 1.5, Five 1.5,
> etc.

I'm not sure where this came from... 3.0 has a release date and a plan  
that doesn't allow for a four more releases to be completed and tested in  
time. I think it's extemely unlikely we'll see a Plone 2.6 or a Plone 2.7  
unless someone seriously commits to doing the needed integration work and  
manages that release. Each release cycle brings with it serious overheads  
of betas, rcs, bug days, migration work etc.

Which brings us back to the original point. If Plone 3.0 is supposed to be  
an end-user experience focused release, part of that is to make sure that  
third party products can integrate well into the Plone UI without having  
to override major templates like global_contentmenu or, worse,  
main_template. I *want* to see  
classification/taxonomy/ontology/tagging/whatever in a way that's generic  
and usable, and I want to make it possible for products like LinguaPlone  
and CMFEditions to inject things into the Plone UI without that having to  
be un ugly hack.

I'm happy to support Zope 2.10 only in 3.0 if that's stable and out the  
door, though (not that it's my call).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rocky Burt | 8 Apr 2006 16:22

Re: Viewlets

On Sat, 2006-08-04 at 12:56 +0100, Martin Aspeli wrote:
> I'm happy to support Zope 2.10 only in 3.0 if that's stable and out the  
> door, though (not that it's my call).

Just a quick comment from me ... part of the reason we didn't want to
target zope 2.9 only with plone 2.5 was because we were always so scared
about early major releases of zope.  Well, by the time plone 2.5 is
released (even the first beta has been released now) we already have a
fairly solid zope 2.9.2 release.

I would *love* for us to finally catch up with zope and not require to
support the last major version with plone 3.0.

I'm +10 on Plone 3.0 only supporting the current lastest major version
of Zope.

- Rocky

--

-- 
Rocky Burt
AdaptiveWave - Content Management as a Service
http://www.adaptivewave.com
Content Management Made Simple
Permalink | Reply | 0 comments |
headers
whit | 8 Apr 2006 20:09
Picon

Re: Re: Viewlets

Martin Aspeli wrote:
> On Sat, 08 Apr 2006 05:40:48 +0100, whit <d.w.morriss@...> wrote:
>
>> considering we are jumping from 2.5 -> 3.0, we have some play.
>>
>> there is no reason that there can't be releases in between 2.5 and 3.0.
>> Let's use those numbers to get ourselves back in sync with the rest of
>> our stack.  depending on when thing fall, 2.6, 2.7, 2.8, and 2.9 could
>> serve as a way to ease onto CMF2.0, zope 2.10, AT1.4 & 1.5, Five 1.5,
>> etc.
>
> I'm not sure where this came from... 3.0 has a release date and a plan 
> that doesn't allow for a four more releases to be completed and tested 
> in time. I think it's extemely unlikely we'll see a Plone 2.6 or a 
> Plone 2.7 unless someone seriously commits to doing the needed 
> integration work and manages that release. Each release cycle brings 
> with it serious overheads of betas, rcs, bug days, migration work etc.
>
I'm not an expert at release management, but it seems that how serious 
the overhead would depend on how serious the changes to plone need to be 
to make them run on the new stack layers. at some point, someone will 
have to commit to doing this work, and it would be better to be before 
said stack layer is approaching unsupported obsolescence.  I'm not 
saying that it will necessarily be expedient between now and the release 
of 3.0, I'm just saying the numbers are there, and we can use them to 
pad the way to things that might suit the 3.0 release best.

free unspoken for numbers if we happen to need them.   but this is a 
divergent topic.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Aspeli | 9 Apr 2006 22:54
Picon
Gravatar

Zope versions

... continuing the one-word-subject tradition;

I had another think about viewlets and Plone. Please see post to z3-user,  
five and Plone lists (yes, I cross posted, so sue me). The short of it is,  
if we can get them in Zope 2.10 then I'd +1 dropping Zope 2.9 support for  
Plone 3.0.

If the argument is stability, then the time-since-release and  
number-of-bug-reports are probably better indicators than the raw version  
number. Now - Zope 3 movies pretty fast. I think getView() and  
getMultiAdapter() are pretty good examples - we've had to introduce a bbb  
alias because getView() was the only way in 2.8 and the deprecated way in  
2.9. I think we're going to have a lot more of those if we keep straddling  
two Zope versions.

Obviously, this will be a case-by-case decision. The risk may be too  
great, the migration path may be too hard. But it seems to me we're  
supporting two versions just because that's what we've always done, and  
because of some general suspiciousness about .0 releases of Zope 2. Well,  
suck it up. :) Already, people are in pain because they installed the  
Windows installer of Plone and then wanted to use listen or Poi or some  
other product that required 2.8. We're creating migration problems as well  
as easing them.

What version will Zope be at when the 3.0 release date is hit?

Martin

--

-- 
(muted)
(Continue reading)

Permalink | Reply | 9 comments |
headers
Martin Aspeli | 9 Apr 2006 23:08
Picon
Gravatar

Menus

Hi guys,

The viewlet craze started because I wanted to investigate pluggable UIs,  
but was actually mostly driven by the fact that I hate the monolithic  
ugliness that is global_contentmenu.pt. Now, a viewlet is basically just a  
free-form HTML snippet (the examples all return them as strings in Python,  
ouch). A viewlet sits in a viewlet manager, which another html-producing  
thing that knows how to aggregate viewlets (do you put each inside a div  
or a span, basically).

The contentmenu wouldn't benefit from any such thing. We want to have  
menus, with common markup. We don't want people to shove an h1 in there.  
:) However, menus are by definition context dependent, and are (via  
actions for the content tabs) in the rest of Plone.

I'd like to PLIP before the Archipelago sprint something like this:

  - global_contentmenu.pt uses a view  <at>  <at> content_menu that builds all that  
nastiness and does all the conditionals.

  - the main part of that will be something that just loops over a tuple of  
IContentMenu objects that list IContentMenuItem objects:

class IContentMenu(Interface):
   id = Attribute('The id of the menu')
   before = Attribute('The id this menu should be rendered before, or None')
   title = Attribute('The title displayed')
   i18n_key = Attribute('The i18n key of the menu')
   children = Attribute('An ordered list of children of this menu, all  
should be IContentMenuItem')
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hanno Schlichting | 10 Apr 2006 00:30
Gravatar

Re: Zope versions

Martin Aspeli wrote:
> I had another think about viewlets and Plone. Please see post to
> z3-user, five and Plone lists (yes, I cross posted, so sue me). The
> short of it is, if we can get them in Zope 2.10 then I'd +1 dropping
> Zope 2.9 support for Plone 3.0.
> 
> If the argument is stability, then the time-since-release and
> number-of-bug-reports are probably better indicators than the raw
> version number. Now - Zope 3 movies pretty fast. I think getView() and
> getMultiAdapter() are pretty good examples - we've had to introduce a
> bbb alias because getView() was the only way in 2.8 and the deprecated
> way in 2.9. I think we're going to have a lot more of those if we keep
> straddling two Zope versions.

Well, Zope 2.8 vs. 2.9 is a special case, as it is really Zope X3.0 vs.
3.2, which is a 0.2 step and at least one year of extra development.

> Obviously, this will be a case-by-case decision. The risk may be too
> great, the migration path may be too hard. But it seems to me we're
> supporting two versions just because that's what we've always done, and
> because of some general suspiciousness about .0 releases of Zope 2.
> Well, suck it up. :) Already, people are in pain because they installed
> the Windows installer of Plone and then wanted to use listen or Poi or
> some other product that required 2.8. We're creating migration problems
> as well as easing them.

Right now I'm actually +1 on changing the recommend platform for Plone
2.5 to Zope 2.9 and including this in the installers. My main argument
here is that we want to advertise using new development strategies based
on Zope3. But if we get people to start with Zope X3.0 lots of what they
(Continue reading)

Permalink | Reply | 7 comments |

Gmane