[Framework-Team] A Few Good Plonistas Needed for the Plone Framework Team

[Alec Mitchell]

Hello Fellow Plone Developers,

The Plone 4.x Framework Team could use a few new members to fill out
our current stable of Plone experts.  The Framework Team is
responsible for making decisions about new features and code quality
for future Plone releases.  We have recently adopted some new
procedures (http://dev.plone.org/plone/wiki/PlipProcess) which will
allow us to benefit from a slightly larger team.  To that end, we are
hunting for people interested in helping guide the future and guard
the quality of Plone.

If you or someone you know is interested in joining the team, please
send a nomination email to the framework team list
(Framework-Team@lists.plone.org).  Please include the name and email
of the nominee as well as a note detailing experience with Plone and
some reasons for wanting to join the team. It would be a good idea to
read the  Framework Team overview
(http://dev.plone.org/plone/wiki/FrameworkTeam)  and the PLIP Process
documentation (http://dev.plone.org/plone/wiki/PlipProcess) to get an
idea of the responsibilities that come with FWT membership.  The team
generally has a biweekly conference call, and all active members are
expected to participate.

Framework team members are expected to have made significant (code or
non-code) contributions to Plone, to be familiar with current Plone
code and/or UI best practices, to have plenty of experience with
buildout and to possess a tolerance for awkward silence during
conference calls ;-)  People with strong UI, accessibility and/or
internationalization experience are especially encouraged to apply.

Regards,
Alec Mitchell
Plone Framework Team (2.5, 4.x)
___
Framework-Team mailing list
Framework-Team@lists.plone.org
https://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion

[Alec Mitchell]

On Thu, Feb 24, 2011 at 10:36 AM, Hanno Schlichting  wrote:
> On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddy  wrote:
>> Feel free to respond over email or just edit the
>> document: http://dev.plone.org/plone/wiki/PlipProcess
>
> Great work!

Agreed!  This has the potential to greatly improve our process and
provide the larger community of developers and users with a more
certainty about how and when things are happening in the shadowy world
of framework decisions and release management.

>> In general, I'd like to give the fixed release schedule a 6 month test
>> drive. If it sucks we can go back to status quo or move forward with the
>> latest and greatest.
>
> I cannot remember any Plone releases that only took 6 months - even
> when we tried hard. I'd usually expect a 50% overrun from any stated
> timeline, so while aiming for 6 months we can manage to do a release
> after 9 months. We'd have to aim for a 3-4 months cycle to actually be
> able to do two releases in a year.
>
> And I wouldn't really want to do more than two releases per year, or
> we risk getting too fragmented, diverging code bases and very short
> support lifecycles for each release (only the last 4.x release gets
> bugfixes at any given time according to our current policy).
>
> I think we could aim for a spring and an autumn release, expecting
> most people to be busy in summer vacations and around x-mas/new year.

I agree strongly with this.  A 3 month cycle seems really ambitious.
While ambition may be a good thing here, we need to think about the
consequences of such a short cycle.  This could drastically shorten
the support lifetime of any given release.  Is that something we
really want to do?  It could also put a huge burden on release
managers with respect to minor/bugfix releases (especially if we
decide to support more of these 3-month releases at a time).  We might
be better off with the more realistic and practical goal of trying to
achieve a true 6-month cycle.

It seems likely that this process will require a also larger "team"
for any given release (particularly given the historic attrition rate
of team members over the course the review process), along with a
reasonable mechanism for members to opt-out of a particular cycle if
needed.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
https://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion

[Alec Mitchell]

On Wed, Feb 9, 2011 at 8:00 PM, Eric Steele  wrote:
> On Feb 9, 2011, at 10:49 PM, Ross Patterson wrote:
>> Ross Patterson  writes:
>>
>>> Elizabeth Leddy  writes:
>>>
 Thanks for all the feedback guys! Curious what current team members 
 think
>>>
>>> +1, though I expected to gather more contradicting perspectives before
>>> weighing in in.
>>
>> Ok, so Eric I think we're a go.  Lets schedule another FWT meeting and
>> hammer out the details.
>>
>> Liz, get ready!  :-)
>>
>> Ross
>
>
> Yes, sorry I never managed to respond to this. I have 12 different theses 
> sitting in my drafts folder and never quite managed to accurately capture 
> what I wanted to say.
>
> Basically:
>
> 1) Consider me +1000 on this
> 2) Let's plan on faster/regular/smaller releases
> 3) Review process should be a process of continuous feedback, not the "stop 
> doing things so we can maybe look at it over the next 6 weeks"
> 4) We need to be able to adapt to ideas that happen in the run-up to a 
> release (see Geir's discovery of other places contentlistings could be used)
> 4) 4.2 should be focused on getting events, collections, content listings, 
> search results. These need to happen.
> 5) Let's chat about this on Tuesday

These all sound good to me, but I'd note that #4-2 is, in a sense,
antithetical to 2, 3, and 4-1.  If we want to have small fast releases
with continuous review, then it's probably not a good idea to define
in advance the new features that "need to happen" for a given release.
 To me, having small quick releases means that features only get into
a release if they're ready in time for a scheduled alpha or similar,
not because they are "important".

In this case the features are already nearly ready, so it's _probably_
a safe bet they'll be a part of 4.2, but if we start thinking of
releases as bundles of specific features then we're heading right back
to where we were.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
https://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion

[Alec Mitchell]

On Thu, Jan 20, 2011 at 3:34 PM, Elizabeth Leddy  wrote:
> Thanks for all the feedback guys! Curious what current team members
> think
> Liz

I agree that the deadline issue isn't a major one, since the release
itself would provide a natural set of deadlines and being pushed to a
later release in the series would no longer imply the level of
uncertainty it does now.  Overall, this looks like something
definitely worth trying for a cycle or two.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
https://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Final decision on PLIP 9327 (Unified interface for lists of content)

[Alec Mitchell]

On Fri, Jan 21, 2011 at 6:52 AM, Geir Bækholt  wrote:
> On 20-01-2011 16:57, Eric Steele wrote:
>>
>> I'd like to get a final consensus on whether or not PLIP 9327 will be
>> included in 4.1. From discussion last week, several of you wanted to hold
>> out until we knew whether collections and search results would be in. At
>> this point, it looks like those two will be pushed off for 4.2.
>>
>> With 5 of 8 votes in, it stands at a +4 for inclusion. Are there any
>> objections to my considering it approved?
>
>
> I was told to prioritise documentation, but i'll be happy to convert default
> listing templates or portlets to use it.
>
>
> One of the more important cases with contentlisting is to make it easier to
> start using it as an integrator and that addons can depend on it. For that
> is important that it is included, not an addon.

That sounds like framework proliferation to me.  If an addon wants to
use this API then they can add it as a dependency; that's not a huge
burden after all.  If either the search improvements or the
collections were ready, then we'd at least be providing some examples
of how to use the library in Plone and some indication that it was a
recommended API.  As it is, it just seems to add further confusion to
Plone's developer/integrator story.

The PLIP had explicitly removed conversion of the templates as a goal.
 Also, it's not entirely clear whether such a conversion would be
appropriate for a 4.x release, since such changes could break
customizations which rely on the macros, etc. from the current
implementation.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
https://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Final decision on PLIP 9327 (Unified interface for lists of content)

[Alec Mitchell]

On Thu, Jan 20, 2011 at 10:52 AM, Ross Patterson  wrote:
> Eric Steele  writes:
>
>> I'd like to get a final consensus on whether or not PLIP 9327 will be
>> included in 4.1. From discussion last week, several of you wanted to
>> hold out until we knew whether collections and search results would be
>> in. At this point, it looks like those two will be pushed off for 4.2.
>>
>> With 5 of 8 votes in, it stands at a +4 for inclusion. Are there any
>> objections to my considering it approved?
>
> I'm a strong +1 for someone releasing this package to pypi so we can use
> it out in the world, but I'm -1 on including it with core Plone without
> those PLIPs that depend on it being included.  I've updated my vote on
> the spreadsheet and that bring the total to +2.

I feel identically.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Today's Call (Oct 12, 2010)

[Alec Mitchell]

On Tue, Oct 12, 2010 at 6:22 AM, Craig A. Haynal  wrote:
> On 10/12/10 8:58 AM, Eric Steele wrote:
>> We have a call scheduled for today. Since we've had all of one new review in 
>> the past two weeks, is it still worthwhile for us to get together to talk? 
>> Do we have any updates to the PLIPs we've already cast votes for to discuss?
>
> I think we should postpone the call until we have more to discuss.

+1
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Fwd: For next time around - review processes

[Alec Mitchell]

On Wed, Sep 22, 2010 at 2:14 AM, Martin Aspeli  wrote:
> Hi Alec,
>
> On 21 September 2010 18:33, Alec Mitchell  wrote:
>
>> While I agree that it would be worthwhile to promote a canonical space
>> for discussion of the PLIPs and reviews, and that Trac is probably our
>> best option for that, I disagree that putting the reviews themselves
>> into Trac comments would be helpful or necessary in that cause.  The
>> text files provide a canonical review location along with a history of
>> revisions to that review (reviews are nearly always updated over time
>> in response to discussions and code changes).
>>
>> If we need to sift through a Trac or mailing list discussion to
>> understand a reviewer's conclusions, then the process will become
>> quite cumbersome for the Framework Team (and anyone else wishing to
>> understand the conclusions of the process).  Trac comments and emails
>> are not easily updated, so finding the conclusive version of a review
>> that exists only as part of an ongoing discussion will be difficult.
>
> Good point.
>
>>
>> I'd like to suggest instead that we continue using the text file
>> reviews, but that reviewers remember to write clear commit messages
>> including "Refs #", so that updates to the review are noted in the
>> Trac comments for the relevant PLIP (also, if you're a reviewer add
>> yourself to the PLIP CC list in Trac if you're not already in it).  I
>> don't think it's a tremendous burden for PLIP authors to click the
>> link in Trac/email to read the review from the code browser, and then
>> begin discussions in Trac.
>
> Thankfully, this already happens (at least, it is the only way in which I am
> made aware of reviews, as I get emails from Trac telling me about new
> comments).
>
> However, it's still difficult for me to (a) know what specifically I need to
> do and (b) provide my responses in a way that allows me to address the
> individual points and satisfy everyone that the points raised in the review
> have either been addressed or agreed to be irrelevant/unnecessary. In other
> words - I can't make a threaded reply to a comment in a text file in svn.
>
> Perhaps what we need is for the "official" FWT verdict to be summarised in
> the Trac ticket after the response, e.g.:
>
> "The FWT is +1 pending the following:
>
>  - fix the test in module X
>  - address the XXX comment in module Y
>  - add this information to the README
>  - ...
> "
>
> At least then the implementer can track (pun intended) their responses to
> each point and we don't risk losing things.

Agreed.  I'd suggest that this summary should result from the FWT
discussion of a PLIP.  We won't be having those discussions until we
have the desired number of reviews for a given PLIP though.  In the
meantime, it might be wise to look at the reviews and begin the
discussion from there.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] For next time around - review processes

[Alec Mitchell]

On Tue, Sep 21, 2010 at 1:49 AM, Martin Aspeli  wrote:
> Hi,
>
> I know we have a process that says reviewers should add their notes in text
> files in the review buildout. I think it'd be bad to change the process now,
> but for next time around, can I suggest that we use Trac for all comments,
> voting and "official" review notes?
>
> Right now, I have several PLIPs each with multiple txt files with comments.
> I don't necessarily agree with all the comments (or at least I'd like a
> chance to explain certain decisions). However, text files in svn are just
> about the worst way to keep track of a conversation. I'm not sure if anyone
> is going to consolidate the review notes and tell me what I should do to get
> my PLIPs accepted. If so, it'd help if that was in Trac, so I could actually
> respond and a threaded fashion.
>
> What do others think?

While I agree that it would be worthwhile to promote a canonical space
for discussion of the PLIPs and reviews, and that Trac is probably our
best option for that, I disagree that putting the reviews themselves
into Trac comments would be helpful or necessary in that cause.  The
text files provide a canonical review location along with a history of
revisions to that review (reviews are nearly always updated over time
in response to discussions and code changes).

If we need to sift through a Trac or mailing list discussion to
understand a reviewer's conclusions, then the process will become
quite cumbersome for the Framework Team (and anyone else wishing to
understand the conclusions of the process).  Trac comments and emails
are not easily updated, so finding the conclusive version of a review
that exists only as part of an ongoing discussion will be difficult.

I'd like to suggest instead that we continue using the text file
reviews, but that reviewers remember to write clear commit messages
including "Refs #", so that updates to the review are noted in the
Trac comments for the relevant PLIP (also, if you're a reviewer add
yourself to the PLIP CC list in Trac if you're not already in it).  I
don't think it's a tremendous burden for PLIP authors to click the
link in Trac/email to read the review from the code browser, and then
begin discussions in Trac.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010

[Alec Mitchell]

Hi Martin,

On Thu, Aug 19, 2010 at 9:24 AM, Martin Aspeli  wrote:
> Hi Alec,
>
> On 20 August 2010 00:56, Alec Mitchell  wrote:
>
>>> I'd like to experiment with making the AT UID() and reference/UID
>>> catalogs use plone.uuid as well. Certainly, that's where I'd like us
>>> to end up. I just didn't want to be too ambitious with the PLIP in the
>>> first instance, in case we end up with complicated migrations or BBB
>>> issues.
>>>
>>> Of course, plone.uuid on its own works perfectly well with Archetypes
>>> objects. The problem is that as it's written right now, it doesn't
>>> care about the AT UID() method and related catalogues.
>>>
>>> One thing we probably could do, is to make the Archetypes make_uuid()
>>> method use the same UUID algorithm as plone.uuid. I'm not sure if we'd
>>> want to migrate old content. They probably shouldn't clash, and making
>>> changes could be problematic in case of embedded link-by-uid
>>> references and similar.
>>>
>>> We could also/instead make an IUUID adapter implementation for
>>> Archetypes content that looked context.UID(), and let AT continue to
>>> manage its own UUIDs (but ideally using the same UUID generating
>>> algorithm) to bridge the two.
>>>
>>> We could make the UUID indexer use the "UID" catalogue index instead
>>> of creating a new one. This would be more consistent, at least if the
>>> UUIDs looked and worked the same.
>>>
>>> If there's appetite for this type of a change, I'd be happy to implement it.
>>
>> I think this is probably the way forward; though for 4.1 we should
>> probably do our best to preserve existing UIDs and avoid serious
>> content migration headaches.  One thing that concerns me on the
>> technical side is that a "universal" UUID mechanism isn't really all
>> that useful unless existing code (e.g. the AT reference browser)
>> provides support for it.  Without at least some minimal support within
>> the existing framework, it would appear to make the lives of people
>> who live on the bleeding edge (e.g. dexterity users) slightly easier
>> at the expense of inconveniencing the vast majority of users by
>> forcing a slow and largely unnecessary migration step.
>
> So, we must provide some new features so that we can justify the
> feature we want to have. :-)

In my opinion, there must be a feature that's meaningful for Plone the
application to justify adding features to the Plone the framework,
yes.

> Anyway, if the PLIP is accepted, I'd be happy to spend some time on
> selective AT surgery (including the widget), unless the FWT feels this
> is too risky. Ditto for link-by-uid in general.

Great, I don't think allowing the reference browser to support
referencing non-AT content sounds particularly risky, and it's a
pretty compelling feature (i.e Plone supports references between
heterogenous content types).

>> It's my impression that people who are doing things with non-AT
>> content are an extremely small and highly experienced minority of
>> Plone users.
>
> The Dexterity list subscription rate and issue tracker suggest this is
> at least starting to change. It's easy to choke off adoption with that
> attitude, though.
>
> Three of the biggest "holes" in the Dexterity story that makes life
> difficult right now are a lack of link-by-uid, no mature multilingual
> support, and an inability to use Dexterity objects as reference
> targets from AT content. The first we can solve for 4.1 with this
> PLIP. The second will become more feasible with proper UUIDs according
> to Hanno. And the latter is the ideal end goal of any AT refactoring
> as per above.

The first is unequivocally solved by simply having dexterity depend on
plone.app.uuid.  For the second, if LinguaPlone wants to support
dexterity, it can also depend on plone.app.uuid (even as a soft
dependency if that's less worrisome).  The third is the only part that
this PLIP would seem to be necessary for, but it's not actually a part
of this PLIP, as you know.

>> I suspect that the vast majority of those users are core
>> developers and subscribe to this list.  Those users are probably
>> already aware that plone(.app).uuid is "the future" and can depend on
>> it if they need it.  If not, those who wish to promote it as such can
>> do so, but I don't think that should be the job of the framework team
>> (or the framework itself).
>
> I think you're missing my point: Since a UUID is only useful if it's
&

Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010

[Alec Mitchell]

On Wed, Aug 18, 2010 at 7:08 PM, Martin Aspeli  wrote:
> Hi Alec,
>
> On 19 August 2010 09:52, Alec Mitchell  wrote:
>
>> Though I voted against the inclusion of the UUID PLIP on it's own, if
>> the link-by-uuid PLIP makes good use of it, then it certainly could be
>> worth including.
>
> I'd like to work with David to make sure that happens. It seems like
> an obvious win.
>
>> If there were a PLIP to make AT compatible with this
>> implementation and convert Plone to using it, that would be a highly
>> compelling argument for its inclusion.
>
> I think "Plone using it" should mean "the link by UID mechanism" in
> the first instance.
>
> I'd like to experiment with making the AT UID() and reference/UID
> catalogs use plone.uuid as well. Certainly, that's where I'd like us
> to end up. I just didn't want to be too ambitious with the PLIP in the
> first instance, in case we end up with complicated migrations or BBB
> issues.
>
> Of course, plone.uuid on its own works perfectly well with Archetypes
> objects. The problem is that as it's written right now, it doesn't
> care about the AT UID() method and related catalogues.
>
> One thing we probably could do, is to make the Archetypes make_uuid()
> method use the same UUID algorithm as plone.uuid. I'm not sure if we'd
> want to migrate old content. They probably shouldn't clash, and making
> changes could be problematic in case of embedded link-by-uid
> references and similar.
>
> We could also/instead make an IUUID adapter implementation for
> Archetypes content that looked context.UID(), and let AT continue to
> manage its own UUIDs (but ideally using the same UUID generating
> algorithm) to bridge the two.
>
> We could make the UUID indexer use the "UID" catalogue index instead
> of creating a new one. This would be more consistent, at least if the
> UUIDs looked and worked the same.
>
> If there's appetite for this type of a change, I'd be happy to implement it.

I think this is probably the way forward; though for 4.1 we should
probably do our best to preserve existing UIDs and avoid serious
content migration headaches.  One thing that concerns me on the
technical side is that a "universal" UUID mechanism isn't really all
that useful unless existing code (e.g. the AT reference browser)
provides support for it.  Without at least some minimal support within
the existing framework, it would appear to make the lives of people
who live on the bleeding edge (e.g. dexterity users) slightly easier
at the expense of inconveniencing the vast majority of users by
forcing a slow and largely unnecessary migration step.

>> Otherwise we end up with Plone
>> directly using one non-deprecated UID API while promoting another
>> (which happens to not be useful anywhere within Plone itself).  Don't
>> we already suffer from enough of this kind of framework-level
>> confusion?
>
> I guess it depends on your point of view.
>
> To me, we don't actually have proper UUID mechanism at present.
> Archetypes has a UID() method, which exposes an ID that's principally
> used as an implementation detail of its reference engine. That
> reference engine (and by extension the UID() method and the way in
> which it generates UUIDs) is tightly bound to AT's base classes and
> virtually impossible to use elsewhere. You can't have these kinds of
> UID's on comments, for example, or on portlets, or on the Plone site
> object, or on any non-AT content (e.g. using Dexterity).
>
> I wrote the PLIP because I'm uncomfortable with the status quo. People
> end up making their own half-solutions, e.g. using their own counters,
> physical paths (which are not stable), keeping their own BTrees of
> content, using zope.intid or faking up the UID() method in a way that
> isn't quite compatible with how AT uses it.

It's my impression that people who are doing things with non-AT
content are an extremely small and highly experienced minority of
Plone users.  I suspect that the vast majority of those users are core
developers and subscribe to this list.  Those users are probably
already aware that plone(.app).uuid is "the future" and can depend on
it if they need it.  If not, those who wish to promote it as such can
do so, but I don't think that should be the job of the framework team
(or the framework itself).

>> By including this wouldn't we essentially be saying, "Martin made
>> this, and we think it's a nice thing; so now it's part of the core?"
>> What other nice little libraries should we make part of Plone just
>> because they might be useful to some dev

Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010

[Alec Mitchell]

On Wed, Aug 18, 2010 at 5:21 PM, Martin Aspeli  wrote:
> On 19 August 2010 09:20, Martin Aspeli  wrote:
>> On 19 August 2010 06:47, Geir Bækholt  wrote:
>>> On 18-08-2010 08.07, Martin Aspeli wrote:
>         • 10778 (Stand-alone UUID)
>>>
 I think my reason for wanting it in the core, is twofold:

   - There's a proliferation of half-solutions to this problem right
 now. We need something blessed that people feel safe relying on. There
 is a cost associated with each half-solution in terms of catalogue
 bloat and in terms of confusion.
>>>
>>> We have repeatedly had frustration with the lack of a unified UID system
>>> that we can depend on when writing add-ons. To base something on it as a
>>> developer, you need to know you can depend on it being available always.
>>>
>>> I don't think it makes sense to postpone it "because nothing uses it yet".
>>
>> Right - I think it becomes a bit of a "chicken and egg" problem otherwise.
>
> Also: If we do the PLIP to separate out link-by-UID and similar
> transforms, that's a natural candidate to use these UUIDs. :)

Though I voted against the inclusion of the UUID PLIP on it's own, if
the link-by-uuid PLIP makes good use of it, then it certainly could be
worth including.  If there were a PLIP to make AT compatible with this
implementation and convert Plone to using it, that would be a highly
compelling argument for its inclusion.  Otherwise we end up with Plone
directly using one non-deprecated UID API while promoting another
(which happens to not be useful anywhere within Plone itself).  Don't
we already suffer from enough of this kind of framework-level
confusion?

By including this wouldn't we essentially be saying, "Martin made
this, and we think it's a nice thing; so now it's part of the core?"
What other nice little libraries should we make part of Plone just
because they might be useful to some developers or are used by a few
add-ons that we happen to like?  I'm sure we could think of quite a
few, but I also think there's a good reason we don't generally do
this.

Adopting a library that we don't actually use, promotes a vision of
Plone as a pure framework/toolkit that I'm not entirely comfortable
with.  Plone is an application (though a highly extensible one), and I
don't really think we should be in the business of providing APIs
beyond those consumed by it and those used to customize it.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Our next meeting – PLIP-a-tho n part 1

[Alec Mitchell]

On Fri, Aug 13, 2010 at 4:29 AM, Eric Steele  wrote:
> On Aug 13, 2010, at 5:30 AM, Ross Patterson wrote:
>> Eric Steele  writes:
>>
>>> We've got 30 PLIPs in for 4.1 already
>>> (http://dev.plone.org/plone/report/24), so it's time to get together
>>> and start talking. Can I assume that next Tuesday at 14:00 UTC will
>>> work, or should I set up another Doodle thing?
>>
>> If that's the same time as the last meeting, that works for me.  The
>> last meeting was at 10AM here on the pacific coast.  The web sites I'm
>> consulting to translate 14:00 UTC to my time, however, seem to indicate
>> that's *way* too early in the morning.  I apologize in advance for my
>> time zone ignorance, but can someone tell me what time that is on the
>> pacific coast?
>>
>> Ross
>
> Bah. You're right. I can't add properly. That'd be 18:00 UTC, the same time 
> as our last meeting.

Works for me as well in that case.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Plone 4.x Framework Team Nominations Open

[Alec Mitchell]

On Sat, May 22, 2010 at 6:24 PM, Steve McMahon  wrote:
> Plone 4.0 is on it's way, and the Plone development team is beginning
> planning for future releases in the 4.x series. Would you like to help
> choose what goes into Plone 4.1, 4.2 ...?
>
> The Plone Framework team is now receiving applications and nominations for
> membership in the Plone 4.x Framework Team.

I'd be happy to continue on to the post-4.0 releases.

Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] FWT, Let's meet up

[Alec Mitchell]

I'm in.  Any evening or sometime during Friday open space works for me.

Alec

On Wed, Oct 28, 2009 at 2:41 PM, Eric Steele  wrote:
> For those of you in Budapest, I'd like to try to get together for a bit to
> 1) just actually meet you face-to-face
> 2) talk about which sprints we want to promote/run this weekend
> 3) buy you each a beer
>
> Think we can make that work?
> Eric
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Conference Sprint Update

[Alec Mitchell]

Hello Plone Community,

The Plone Conference is almost here and I am looking forward to seeing
all my friends in the community and making new ones.  I'm even more
excited about working directly with the Plone community to make Plone
better at the post-conference sprint.  A number of topics have been
added to the Sprint Wiki (http://ploneconf2009.org/program/sprint/)
and there's certainly room for a few more if you're willing to take
the lead on a topic.  Some of these topics involve important work for
the exciting upcoming Plone 4.0 release.

For those of you who are interested in participating in a particular
topic, it would be very helpful if you could add your name in the
participants section of any topic(s) in which you are interested.  If
you're the leader of a topic, it would be helpful if you could add
your name as topic leader, if you haven't already.  I encourage
everyone to visit the wiki
(http://ploneconf2009.org/program/sprint/budapest-conference-sprint)
and take a look around.

I look forward to seeing everyone in Budapest.

Best Wishes,
Alec Mitchell

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] plone.registry and z3c.form

[Alec Mitchell]

On Fri, Sep 25, 2009 at 8:09 AM, Eric Steele  wrote:
> Following up on the discussion of including these in Plone 4...
>
> The Framework team opinion is that they like them both, and will include
> them in Plone 4, but with the reservation that they wished they'd gone
> through a full PLIP process.
>
> Personally, I'm in favor of including both. I've used plone.registry on a
> project and found it very well done and easy to use. I also like the
> ControlPanelFormWrapper that plone.app.registry provides and would be happy
> to see that make it in too. I'm less convinced about the plone.app.registry
> search form itself. I'd lean towards leaving the registry search as one of
> those undocumented views that people can get to if they really need it, a la
> @@manage-viewlets. I'd like to have that worked on some more in a 4.x
> release and go through full Framework and UI team reviews before making it
> publicly available.
>
> Adding plone.registry and plone.app.registry brings in the following new
> dependencies:
> collective.z3cform.datetimewidget = 0.1a9
> plone.autoform = 1.0b2
> plone.supermodel = 1.0b2
>
> #Required by:
> #plone.app.registry 1.0b1
> plone.app.z3cform = 0.4.6
>
> #Required by:
> #plone.autoform 1.0b2
> plone.z3cform = 0.5.5
>
> #Required by:
> #plone.z3cform 0.5.5
> z3c.batching = 1.1.0
>
> #Required by:
> #plone.app.z3cform 0.4.6
> z3c.formwidget.query = 0.5
>
> If there are no staunch objections to the above, I'll move forward with it.

Won't these requirements come in automatically as we merge those PLIPs
that depend on these packages (provided they are accepted).  I'd
rather we not add these dependencies to Plone until we're certain that
we have code that makes use of them.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: [Plone 4] Framework Team Mi nutes – Sept 16, 2009

[Alec Mitchell]

Owner was there in Plone < 3.0.  IIRC, it was removed because the name
is confusing, particularly since it is redundant with the object
ownership.  Granting the Manager role means giving local ZMI rights
and even the ability to e.g. add a local acl_users and create a little
fiefdom,  which may not be wise to allow through the sharing tab.  In
any case only Managers would be able to grant Manager, whereas Owner
could be granted more easily.  However, I'd suggest we add it back
only if we can find a suitable synonym for it.  Being able to say
"grant this person the same rights that I (the creator of this
content) have" is a very useful thing, even if the default
nomenclature is confusing.  Alternatively, we could adjust the
workflows to make e.g. 'Contributor' more powerful.

Alec

On Wed, Sep 23, 2009 at 7:33 AM, Jon Stahl  wrote:
> On Tue, Sep 22, 2009 at 6:14 PM, Martin Aspeli  
> wrote:
>> Eric Steele wrote:
>>
>>> #9263: Erik: Looks good. i18n:attributes="title" be made implicit.
>>>  Important to re-add "owner".
>>
>> I don't know what that last comment means. If you mean we want the "Owner"
>> role on the sharing tab by default then (a) I disagree (it shouldn't be
>> necessary to delegate the Owner role and this is a very confusing concept,
>> especially when we have a "change ownership" form as well) and (b) it's
>> outside the scope of the PLIP.
>
> I'm missing some context here, but it is possible that it's actually
> "Manager" we need to re-add (we never had owner on there) -- I've
> certainly missed the ability to easily assign manager rights through
> the tab, since manager is not just the sum of view/edit/add.
>
> :jon
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PLIP load test reports available

[Alec Mitchell]

On Sun, Sep 6, 2009 at 11:51 AM, Eric Steele wrote:
>
> On Sep 6, 2009, at 1:02 PM, Ross Patterson wrote:
>>
>> Eric Steele  writes:
>
> ...
>>>
>>> One thing we need to keep in mind with the PLIP comparisons is that
>>> many of them haven't merged in changes to CMFPlone and other packages
>>> since they did their initial branches so that may be one of the
>>> factors in their speed differences.
>>
>> Any chance we can get implementers to do this?
>
> ...
>
> Definitely. It'll make my life easier when merge time comes as well. I'll
> ask them to get their branches up to date during the next implementation
> run.

I think it may make your job more difficult, because you'll have to
separate the actual PLIP work from the merging of already committed
code when merging PLIPs into the branch.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Status of PLIP 9315 — New theme for Plone 4

[Alec Mitchell]

On Mon, Aug 24, 2009 at 7:17 AM, Francesco
Ciriaci wrote:
>
> Il giorno 24/ago/09, alle ore 08:56, Alexander Limi ha scritto:
>
> You're a bit late, seeing as the initial deadline was last week. ;)
>
> Well, I'm trying to follow the framework and developers lists but the only
> screenshot with a new visual design I found was on your mail dated 21
> August.
> I must have a problems with email, too: about 4 months ago I proposed to
> help with the new visual design of Plone 4, but did not get any real answer,
> proposition, or contact. Frankly I'm struggling in trying to help improving
> Plone, lately.
> Anyway: I'll check out the code and review what I see there. I don't want to
> bother the framework team so I'll then report directly to you and use the
> tracker.

I promise you won't bother us.  The more help we have, the better.
Reviewing 36 PLIPs this week will probably send a few of us to an
early grave :-)

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Status of PLIP 9315 — New theme for Plone 4

[Alec Mitchell]

Hi Francesco,

If you'd like to volunteer to do a UI review of this PLIP or any of
the other UI intensive PLIPs, it could be a big help to our review
process.  If so, let us know which PLIPs you'd be interested in
reviewing.  Of course if Alex needs your help with implementation,
then your time would probably be better spent there :-)

Best wishes,
Alec

On Fri, Aug 21, 2009 at 5:45 AM, Francesco
Ciriaci wrote:
> Hi Alex,
> you know I've always been interested in the default theme of Plone. I'm
> really curious about the new "refresh" of Plone.
> If you need some help for the visual design I'd glad to give some of my
> time. There is also a couple of people in Reflab/Mediatria that are willing
> to contribute: Antonio, who works mostly on UI and JS and Giulio who's a
> visual designer and skinner.
> Also consider that the work we did back in old days of Plone 3 (October
> 2007) with Capri and other themes were precisely aimed into "refreshing" the
> Plone default theme with:
> 1) updated logo (had been officially announced a couple of days before the
> sprint)
> 2) updated (and extended) icon theme
> 3) accessibility (contrasts/colors included)
> 4) have a base theme for skinning
> 5) "recongnizable" / keeping Plone visual identity
> 6) nice use of typography
> 7) new use of colors for user actions and portlets
> 8) grid (fixed width)
> I'm glad to see that many of these elements plus some new one "fluid",
> HTML5, etc. are in the PLIP: nice work!
> I'm not sure how the review/PLIP process works for the visual design but I'd
> also bring the new design to the attention of the Plone evangelism team,
> just for a feedback. Then, once the PLIP is approved, it would be
> interesting to *promote* the new visual design and especially it's
> implementation.
> Let us know what we can do.

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] PLIP 8814 ready for review

[Alec Mitchell]

Hi all,

The SecureMailHost removal PLIP is ready for review.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: MailHost Improvements

[Alec Mitchell]

On Thu, 13 Aug 2009 21:22:07 -0700, Alec Mitchell   
wrote:



On Wed, Aug 12, 2009 at 9:42 PM, Andreas Jung wrote:

On 13.08.09 01:03, Alec Mitchell wrote:

Hello,

I've been working on making Plone use the standard Zope MailHost  in
place of the custom Products.SecureMailHost we've been using since
Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814).  During this
process I've run into a couple bugs in the MailHost implementation and
I believe it is missing some essential functionality.

The most significant issue is that if you call send() with a
messageText containing just the message body, and that body has a ':'
in it (e.g. a url) the body will be treated as a header and you'll
send a nonsense message.  The current implementation of send() also
puts a fairly large burden on developers who want to generate simple,
correctly encoded messages.  Finally, send() relies heavily on the
long deprecated 'rfc822' and 'mimetools' modules which have been
removed from Python 3.0.

I've attached a patch that updates MailHost to use the 'email' module
for parsing and generating messages.  In addition to fixing the issues
that I ran across, and maintaining compatibility, it provides a number
of new features:

* send and sendTemplate accept an optional charset argument.  Using
this will set the content-type charset, as well as trigger appropriate
encoding if needed.

* send and sendTemplate accept an optional msg_type argument which
will set the content type header for the message.

* The messageText, mfrom, mto, and subject arguments may now be
unicode or encoded non-ascii strings, provided a charset is given.
Any unicode input will be automatically encoded to the provided
charset (or the default charset).  Headers will be further encoded in
compliance with rfc2822.  The message body will be further encoded
using a transfer encoding determined by the email.Charset registry
(e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859,
base64 for most other encodings).

* The messageText argument now accepts email.Message.Message objects
directly.

I'm attaching a patch that includes these changes as well as tests for
all new functionality.  I hope to integrate these changes into Zope
2.12 before final release, but would like to hear the opinions of Zope
developers before committing.  Though these are fairly significant
changes, I believe they provide very useful functionality as well as
at least one critical fix, while maintaining 100% compatibility.


This comes very, very late. We are pretty close to a release. Please put
the changes on the trunk only.
We will check after my vacation if we can move it into the 2.12 beta.


I've put my latest changes on Zope trunk.  All the existing tests pass
(with a couple essentially cosmetic modifications in the MailHost
tests), and there are 14 new tests which verify both existing and new
functionality, as well as the fixed bugs.  The new behavior should be
identical to the existing behavior when the new charset and msg_type
parameters aren't used, with the following exceptions:

1) Passing a message body containing a ':' no longer produces a nonsense  
email.

2) Providing unicode strings for the text or headers no longer results
in a garbage message (it may produce a UnicodeEncodeError though).
3) 8bit (encoded) strings provided as headers will be converted to
7bit, using encoding determined in messageText headers or the default
encoding.

It would be very helpful to have these changes in Zope 2.12;
otherwise, Plone 4.0 will be stuck with our unmaintained
SecureMailHost product for yet another release in order to provide
equivalent functionality.  Moving to a standard Zope MailHost would be
a big benefit for Plone, and all Zope users will benefit from the
ability to easily send properly formed non-ASCII messages.


There's one additional significant change to Zope behavior here that I  
forgot to mention.  The current implementation sets the python default  
email transfer and header encoding for 'utf-8' messages to  
'quoted-printable', it normally defaults to 'base64'.  This is essentially  
a cosmetic change and makes reading and debugging email messages much more  
straightforward.  It also makes encoded mail less likely to be caught by  
SPAM filters (some of which dislike base64 mail on principle).


At present this change causes one test in CMFDefault to fail, which I'm  
happy to fix.  But it's also not a problem to just remove the line that  
sets the new 'utf-8' encoding, though I think it dpes have some important  
advantages.


Alec


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: [Zope-dev] MailHost Improvements

[Alec Mitchell]

On Wed, Aug 12, 2009 at 9:42 PM, Andreas Jung wrote:
> On 13.08.09 01:03, Alec Mitchell wrote:
>> Hello,
>>
>> I've been working on making Plone use the standard Zope MailHost  in
>> place of the custom Products.SecureMailHost we've been using since
>> Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814).  During this
>> process I've run into a couple bugs in the MailHost implementation and
>> I believe it is missing some essential functionality.
>>
>> The most significant issue is that if you call send() with a
>> messageText containing just the message body, and that body has a ':'
>> in it (e.g. a url) the body will be treated as a header and you'll
>> send a nonsense message.  The current implementation of send() also
>> puts a fairly large burden on developers who want to generate simple,
>> correctly encoded messages.  Finally, send() relies heavily on the
>> long deprecated 'rfc822' and 'mimetools' modules which have been
>> removed from Python 3.0.
>>
>> I've attached a patch that updates MailHost to use the 'email' module
>> for parsing and generating messages.  In addition to fixing the issues
>> that I ran across, and maintaining compatibility, it provides a number
>> of new features:
>>
>> * send and sendTemplate accept an optional charset argument.  Using
>> this will set the content-type charset, as well as trigger appropriate
>> encoding if needed.
>>
>> * send and sendTemplate accept an optional msg_type argument which
>> will set the content type header for the message.
>>
>> * The messageText, mfrom, mto, and subject arguments may now be
>> unicode or encoded non-ascii strings, provided a charset is given.
>> Any unicode input will be automatically encoded to the provided
>> charset (or the default charset).  Headers will be further encoded in
>> compliance with rfc2822.  The message body will be further encoded
>> using a transfer encoding determined by the email.Charset registry
>> (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859,
>> base64 for most other encodings).
>>
>> * The messageText argument now accepts email.Message.Message objects
>> directly.
>>
>> I'm attaching a patch that includes these changes as well as tests for
>> all new functionality.  I hope to integrate these changes into Zope
>> 2.12 before final release, but would like to hear the opinions of Zope
>> developers before committing.  Though these are fairly significant
>> changes, I believe they provide very useful functionality as well as
>> at least one critical fix, while maintaining 100% compatibility.
>
> This comes very, very late. We are pretty close to a release. Please put
> the changes on the trunk only.
> We will check after my vacation if we can move it into the 2.12 beta.

I've put my latest changes on Zope trunk.  All the existing tests pass
(with a couple essentially cosmetic modifications in the MailHost
tests), and there are 14 new tests which verify both existing and new
functionality, as well as the fixed bugs.  The new behavior should be
identical to the existing behavior when the new charset and msg_type
parameters aren't used, with the following exceptions:

1) Passing a message body containing a ':' no longer produces a nonsense email.
2) Providing unicode strings for the text or headers no longer results
in a garbage message (it may produce a UnicodeEncodeError though).
3) 8bit (encoded) strings provided as headers will be converted to
7bit, using encoding determined in messageText headers or the default
encoding.

It would be very helpful to have these changes in Zope 2.12;
otherwise, Plone 4.0 will be stuck with our unmaintained
SecureMailHost product for yet another release in order to provide
equivalent functionality.  Moving to a standard Zope MailHost would be
a big benefit for Plone, and all Zope users will benefit from the
ability to easily send properly formed non-ASCII messages.

Alec

P.S. Andreas, if there's an address where I can send some nice wine to
help facilitate the merge into 2.12, let me know ;-)

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: [Collective-checkins] r93885 - in Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS: tests tools

[Alec Mitchell]

On Fri, Aug 7, 2009 at 3:28 AM, Wichert Akkerman wrote:
> On 8/7/09 12:20 , Ralph Jacobs wrote:
>>
>> Wichert Akkerman wrote:
>>>
>>> On 8/7/09 12:13 , Wichert Akkerman wrote:

 I'm afraid I also don't buy the lookup mechanism mentioned in the PDF:
 you are essentialy creating a persistent cache system, which means that
 suddenly page views can trigger ZODB writes, which is very bad for high
 performance sites. It also will miss all user changes created directly
 in external user sources such as LDAP, AD and SQL databases, leading to
 incorrect and possibly correct behaviour.
>>>
>>> That should be 'possibly confusing'
>>>
>>> Wichert.
>>>
>> Hi Wichert,
>>
>> This all has been discussed in the PLIP proposal, so please contact the
>> framework team for that.
>
> I just checked the history of the trac ticket since I was surprised the
> framework missed this. The framework team has only voted on the idea of
> using a users full name instead of the userid in the Plone user interface.
> The implementation proposal was added three weeks, and will be taken into
> account in the next review round when the PLIP implementations will be
> reviewed. So please consider this a very early (and very unofficial since I
> am not a framework team member) review comment: I do like the idea to use a
> users full name, but I do see some problems with the current implementation
> strategy that should be addressed.

Please listen to Wichert's advice here, a persistent cache of user
data will not be considered acceptable.  Make an uncached
implementation and benchmark some listings vs. stock Plone.  Include
those benchmarks as part of the PLIP documentation.  If there is a
performance issue, then it can be addressed during review or in
discussions with the framework team.

Using the existing cacheability of the PAS calls could be advantageous
(though it is likely to lead to out-of-sync ZEO client caches).
Alternatively, plone.memoize could be used to provide a single request
cache or a ramcache with a short, configrable expiration time.  In any
case, it's too early in the implementation to be adding caches without
benchmarks.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009)

[Alec Mitchell]

On Thu, Aug 6, 2009 at 8:47 AM, David Glick wrote:
> On Aug 6, 2009, at 5:42 AM, Andreas Zeidler wrote:
>>
>> i've just tested linkintegrity in a blob-enabled setup (in order to use
>> the traversal adapter from `plone.app.imaging` in a known to work
>> environment, i.e. plone 3.x) and it turns out that it still has 13 failures
>> — as opposed to the 25 currently seen in tests against plone 4.0.  the
>> remaining 12 failure are very likely due to the "default mime-type issue"
>> (which in turn seems to be caused by the patch in
>> https://bugs.launchpad.net/zope2/+bug/143948 — thanks to david for
>> investigating, btw).
>
> Were you using an svn checkout of linkintegrity?  I adjusted the tests last
> night to specify a 'text/html' mimetype where needed, so if you're using an
> svn checkout then the remaining failures are something else (unless I missed
> an occurrence or two).  Following my changes I was seeing 18 failures for
> linkintegrity with Plone 4.
>
> From the investigating I've done so far, I think there are two main causes
> for the remaining failures:
> - linkintegrity's getObjectsFromLinks method uses OFS traversal, which is
> not aware of IPublishTraverse adapters and therefore does not find image
> scales ... as I've been discussing here
> - The linkintegrity tests try to trick the testrunner into not handling the
> LinkIntegrityNotificationException ... this is no longer working properly in
> Zope 2.12 for some reason.
>
>>> Does anyone know the background or justification for
>>> http://dev.plone.org/old/archetypes/changeset/9318 where the switch to an
>>> IPublishTraverse adapter first happened?  Wichert?
>>
>> since `p.a.blob` currently depends on `p.a.imaging`, which has the same
>> traversal adapter as wichert introduced here, and "image support" will be
>> required for the respective 4.0 plip, this needs to be fixed for
>> linkintegrity to work again anyway.  iow, i'll try to look into it during
>> the sprint...
>
> Yep.  That would be great.
>
>>> Even if we use BaseObject's __getitem__, we probably ought to make the
>>> image scale lookup be adapter-based...I know that Andi has had plans to take
>>> advantage of the IPublishTraverse adapter in plone.app.imaging to override
>>> how scales are found (see
>>> http://svn.plone.org/svn/plone/plone.app.imaging/trunk/src/plone/app/imaging/traverse.py --
>>> but this ImageTraverser isn't actually registered anywhere yet).
>>
>> those plans have long been carried out and the adapter is registered, in
>> fact — see http://dev.plone.org/plone/changeset/27627 :)
>
>
> Ah, my bad...I didn't look carefully enough.
>
>> btw, are there any other reasons/breakages besides the linkintegrity
>> failures?  i suppose i could make the latter aware of the traversal adapter,
>> too.  do we know of any (important) 3rd-party products that rely on being
>> able to traverse to image scales the old way?
>
> I haven't tested, but I presume that anything which does something like
> 
> would break.

Though linkintegrity may be working now, I think the code above would
still fail.  I'd guess there's a lot of code in the wild that uses
path expressions to access image scales by name, and we're breaking
all that code unless we fix this for the general case.  OTOH, we could
simply declare that we're OK with breaking backwards compatibility
here if we have consensus that this is worthwhile.  Perhaps we should
vote on this or discuss on the next call.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Minutes: 8 August 2009

[Alec Mitchell]

I concur that the globalize stuff is a serious hack and should be
removed at some point.  However, I don't think 4.0 is the right time
to remove it considering the huge impact it will have on 3rd-party
products.  If removing it doesn't result in a significant performance
improvement (and apparently it does not), then I'd suggest we continue
to live with it until the "break-everything" 5.0 release.  We didn't
have a PLIP for this and it would be a major disruption for 3rd party
developers and integrators.

Perhaps we could find some clever way to deprecate access to the
globalized attributes (e.g. make them all lazy lookups and issue a
warning on first access)?

Alec

On Wed, Aug 5, 2009 at 2:15 PM, Hanno Schlichting wrote:
> On Wed, Aug 5, 2009 at 10:00 PM, Erik Rose wrote:
>>  * All the globalization in templates is gone now, and Plone's
>>   templates have been updated to not use it. This originated in the
>>   5.x branch as a speed optimization, but does it deliver? It's
>>   going to break a lot of products. MatthewWilkes will talk to
>>   Hanno about this and see if it really did help performance. The
>>   FWT is concerned about breaking every product if it turns our
>>   we're just replacing one very slow thing with many less-slow
>>   things.
>
> This change is not only and maybe not even primarily a speed optimization.
>
> When running performance tests against current Plone 4 for typical
> full-fledged pages like a document view, edit screens or folder
> contents views, there is hardly any performance difference between
> Plone 4.0 and 3.3. Thus there doesn't seem to be an immediate
> performance gain for those kind of pages, but neither is there any
> increased cost.
>
> One thing where you should be able to measure a significant difference
> is on classic portlets. These used to set up all the globalize stuff
> again for the separate expression context of the classic template,
> making them quite a bit slower. Executing the globalize hack twice or
> even many times was certainly quite a bit of a difference.
>
> The reasons why I'm very much in favor of removing the globalize hack
> are different ones:
>
> Obviously the way it is done is an utter hack. Walking up stack frames
> to inject things into a higher global scope is very evil.
>
> Second the "globalized" names are today a random set of shortcuts,
> which have little to do with the typical need inside templates. They
> started out a point where access to a set of tools was essentially the
> whole Plone API, but this isn't the case anymore.
>
> Now they just make it harder to understand template code as there is
> no way to find the actual code path from for example the "syntool"
> name inside a template to the actual implementation. They obscure
> templates for little to no benefit, as most often the real call is a
> one-liner itself and context/portal_syndication gives a much better
> searchable term.
>
> Another point is that they make templates rely on execution order of
> the whole macros system. They only work when called after the
> globalize hack has been executed but not in isolation. This also leads
> to problems when trying to move templates into more reusable packages
> as it becomes very hard to see the actual dependencies of the
> template. What looks like locally defined shortcuts turn out to be "oh
> and btw. I need those other ten packages"-type dependencies. It would
> have been much harder to understand and disentangle dependencies
> between packages on trunk, if those hacked in names still would have
> been in place. If we want to make things optional to get people a more
> speedy and less memory hungry Plone, having a central place that binds
> them all doesn't work.
>
> And last removing these calls from a centralized place makes both
> profiling of what actually contributes to the slowness of Plone much
> easier and allows for easier deprecation of some of the so far
> globalized names. For example many of the actual performance
> improvements on trunk result from changes to the way actions are
> looked up. To make these work, all of the "actions, keyed_actions,
> user_actions, workflow_actions, folder_actions, global_actions" names
> of todays globalize thing need to be deprecated and replaced. Instead
> of always having these defined everywhere, they need to be turned into
> a pattern where only the viewlet / macro that actually shows the
> particular action category also calls and evaluates those actions. For
> example hiding the personal bar in the UI today doesn't make a
> difference since all the actions in that category are still evaluated
> and their conditions checked. Even though nobody will ever show any of
> them.
>
> Maybe I forgot other reasons why this particular hack is considered one ;-)
>
> Hanno
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

Re: [Framework-Team] Minutes: 8 August 2009

[Alec Mitchell]

On Wed, Aug 5, 2009 at 1:18 PM, David Glick wrote:
> On Aug 5, 2009, at 1:00 PM, Erik Rose wrote:
>>
>> Python 2.6, Zope 2.12 (https://dev.plone.org/plone/ticket/8808):
>>
>> * David ported the migration procedure to GS and moved it into
>>  plone.app.upgrade. Ran a migration from a stock Plone 2.5 to 4.0,
>>  and it seemed to work, though he welcomes more thorough testing.
>
> Actually Hanno did the work here, and I just copied it :)
>
>> * IPublishTraverse is used where ITraverse should be; that's why some
>>  linkintegrity tests are failing.
>
> Actually they both need to be used.  And that's just a guess -- I haven't
> actually looked at this yet.

It doesn't look like there's any way to override OFS traversal using a
component (other than a view of course).  Perhaps we should just be
using the existing custom __getitem__ that's already in
BaseObject/BaseFolder instead of traversal magic.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor

[Alec Mitchell]

I don't see much upside to renaming the package.  On the other hand,
the more core Plone code that's owned by the foundation the better,
IMO.  If Rob is willing to do the work to get all contributors to sign
over their contributions, then it's probably worth pursuing.

Alec

On Mon, Jul 27, 2009 at 11:37 AM, Ross Patterson wrote:
> Wichert Akkerman 
> writes:
>
>> On 7/27/09 1:38 PM, Rob Gietema wrote:
>>> Hi,
>>>
>>> I'm currently working on TinyMCE for Plone 4 and would like some
>>> feedback on two issues:
>>>
>>> 1) The current code base is located in the Collective. Since TinyMCE
>>> will be the default editor in Plone 4 should I move (copy) the code base
>>> to Plone SVN?
>>
>> -0
>>
>> I see no reason to move it.
>>
>>> 2) I'm currently using the Products namespace for the package. Would it
>>> be better to switch to the plone(.app) namespace for Plone 4 (and keep
>>> the Products.TinyMCE for Plone 3)?
>>
>> -1
>>
>> There is no benefit to moving, and this will make it harder to
>> maintain Plone 3 and 4 trees in parallel.
>
> I'm -1 to both of these, potential disruption for no benefit I can see.
>
> Ross
>
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: Combining Search Results PLIPs

[Alec Mitchell]

On Thu, Jul 2, 2009 at 11:42 AM, Laurens ., wrote:
> Hey guys,
>
> My proposal included:
> - adding location.
> - cutting out relevance.
> - improving search in current section.
> - sorting.
> - unified listing as in PLIP 9327.
>
> Geir added:
> - real human names, which has become PLIP 9305.
> - easy to read dates.
> - Left alignment.
>
> If we sum it up and cut out all the points people were against we have:
>
> - adding location.
> - cutting out relevance.
> - improving search in current section.
> - easy to read dates.
> - left alignment.
>
>
> Do you want me to add this as a new PLIP?
> Enjoy your holiday geir :)

I think updating either of the existing PLIPs with this full scope and
closing the other one with status "invalid" or "duplicate" is probably
the easiest option.

Thanks,
Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: Combining Search Results PLIPs

[Alec Mitchell]

Would it be acceptable if we simply marked one of those PLIPs as
invalid then?  Which one would be preferable?  Enjoy your vacation
Geir.

Alec

On Thu, Jul 2, 2009 at 11:10 AM, Geir Bækholt · Jarn wrote:
> I am on my way to vacation with my family, and cannot do anything until
> Monday at the earliest.
> I have discussed the search results improvements with Laurens before he
> submitted his, and the two plips are accidental. They are 95% the same plip.
> I'll coordinate and make sure there will not be 2 implementations. - but if
> the plips have to be merged before Monday, someone else needs to do it.
> (feel free). Sorry abut the delay.
>
> --
> Geir Bækholt
> (iPhone)
>
> On 2. juli 2009, at 18.52, Alec Mitchell  wrote:
>
>> Hello Geir and Laurens:
>>
>> Both of your search results PLIPs (9271, 9282) were approved by the
>> Framework Team for inclusion in Plone 4.0.  However, all voters
>> expressed a strong preference that the two PLIPs and the effort to
>> implement them be merged.  It would not be acceptable to have two
>> competing implementations of the same feature(s) submitted for code
>> review.  It is essential that you open a discussion and work together
>> to merge your efforts.  Please keep the Framework Team apprised of the
>> results of your discussion by re-submitting a single combined PLIP
>> ASAP.
>>
>> Thank you,
>> Alec Mitchell
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Combining Search Results PLIPs

[Alec Mitchell]

Hello Geir and Laurens:

Both of your search results PLIPs (9271, 9282) were approved by the
Framework Team for inclusion in Plone 4.0.  However, all voters
expressed a strong preference that the two PLIPs and the effort to
implement them be merged.  It would not be acceptable to have two
competing implementations of the same feature(s) submitted for code
review.  It is essential that you open a discussion and work together
to merge your efforts.  Please keep the Framework Team apprised of the
results of your discussion by re-submitting a single combined PLIP
ASAP.

Thank you,
Alec Mitchell

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Plone 4 FWT meeting summary 2009-06-23

[Alec Mitchell]

On Wed, Jun 24, 2009 at 3:34 PM, Ross Patterson wrote:
> "Alexander Limi"  writes:
>
>> On Tue, 23 Jun 2009 20:02:02 -0700, Alec Mitchell
>>  wrote:
>>
>>> The idea is to ensure everyone on the team who wants can get threaded
>>> updates on PLIP comments delivered.  Does Trac's RSS allow this?
>>
>> RSS isn't threaded, of course. But is it needed? :)
>>
>> (if you already have the mailing list up and running, nevermind — just
>> wanted to point to a quick and working solution :)
>
> Trac emails make it much easier to know *what* was changed while I think
> the RSS doesn't.  Right?  If it can do the same "here's what happened"
> stuff that the emails do then I'm using the wrong feed.  :)

And even if it did give a way to know what has changed.  With
independent discussions on 50+ PLIPs, having that information all
mixed together would be something of a nightmare.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Plone 4 FWT meeting summary 2009-06-23

[Alec Mitchell]

On Tue, Jun 23, 2009 at 5:07 PM, Alexander Limi wrote:
> On Tue, 23 Jun 2009 13:17:57 -0700, Eric Steele  wrote:
>
>>  * We have 57 PLIPs to evaluate, more than any previous version of Plone
>> (we're told), with less time than any other major release. #$&@!
>
> I will just observe that:
>
> a) This is an awesome "problem" to have
> b) I think this validates somewhat that the Trac route vs. PSC proposals
> leads to more submissions. Even subtracting the garbage PLIPs, this is an
> impressive collection of features. :)
>
>>      * Would be helpful to be automatically CC'ed on all PLIP changes.
>> Would be too much noise for the FWT list, let's create a new one. Ross will
>> try to get that set up.
>
> Why not use the Trac RSS feed instead? Seems like a perfect fit for a
> short-term feed like this.

The idea is to ensure everyone on the team who wants can get threaded
updates on PLIP comments delivered.  Does Trac's RSS allow this?

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PLIP deadline overly aggressive?

[Alec Mitchell]

On Mon, Jun 22, 2009 at 5:47 PM, Martin Aspeli wrote:
> Alec Mitchell wrote:
>>
>> On Mon, Jun 22, 2009 at 5:12 PM, Alexander Limi wrote:
>>>
>>> On Sat, 20 Jun 2009 21:32:19 -0700, Martin Aspeli
>>> 
>>> wrote:
>>>
>>>>  - We use this PLIP review cycle to start assigning PLIPs to 4.1.
>>>> There's
>>>> no reason we can't and shouldn't start planning for that now. So, if a
>>>> PLIP
>>>> looks like it'll take longer to do, we can still vote +1 in principle,
>>>> but
>>>> target it for a 4.1 release that can come not too long after 4.0 is out.
>>>
>>> I agree strongly on this. A process note, I see we have created 4.1, 4.2
>>> milestones — would it be better to create a 4.x milestone like we did on
>>> 3.x, so we can say "it'll be in one of the 4.x releases" instead of tying
>>> it
>>> to a specific release until we actually know which release it'll make it
>>> into?
>>
>> I'd say this may be premature.  There are going to be PLIPs which
>> require a break with backwards compatibility, and which only make
>> sense for 4.0.  Those we have to assess on their desirability and
>> feasibility.  If they seem too radical they would be pushed to 5.0.
>>
>> Then there are the less ambitious PLIPs which don't require
>> significant changes to add-ons, customizations or documentation.  If
>> we determine that the change is desirable, it would potentially be
>> acceptable for any release in the 4.x series.
>>
>> In that case, what is the purpose in explicitly pushing it into a
>> later release in the cycle?  Making that decision could discourage the
>> development of the feature entirely.  If the PLIP developers feel that
>> they can have the feature ready in the specified timeline, and we feel
>> that it is a beneficial change for Plone, arbitrarily pushing it to a
>> later release seems inappropriate.
>>
>> If the PLIP developers themselves indicate that they may not have
>> enough time for development, such a decision may make sense.  This
>> could easily be the case for developers who have submitted multiple
>> high quality PLIPs.  Beyond that, I don't see how we can make an
>> objective determination of which features are not right for 4.0 but
>> are fine for 4.1.
>>
>> If we are going to be assigning PLIPs to future 4.x releases, I think
>> we need to have some clear guidelines on which to base such decisions.
>
> I agree that we should defer this decision if we can. But also consider that
> each PLIP takes a fair amount of effort to review at each stage. In the
> past, the framework team has become a bottleneck as they've had to review
> more-than-expected PLIPs. Then we have a merge bottleneck and the potential
> for more bugs introduced during the merge process, which drags the release
> out further. For example, will all those "almost ready" add-on products work
> flawlessly on Zope 2.12? We don't know yet.
>
> I'm not saying we should defer things by default, and the BBB argument is
> very important w.r.t. going into a .0 release. I'm just suggesting we keep
> the option on the table to say "yes please, but we need to wait a little bit
> longer".

I understand the purpose it would serve, but on what basis would we
make such a determination?

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PLIP deadline overly aggressive?

[Alec Mitchell]

On Mon, Jun 22, 2009 at 5:12 PM, Alexander Limi wrote:
> On Sat, 20 Jun 2009 21:32:19 -0700, Martin Aspeli 
> wrote:
>
>>  - We use this PLIP review cycle to start assigning PLIPs to 4.1. There's
>> no reason we can't and shouldn't start planning for that now. So, if a PLIP
>> looks like it'll take longer to do, we can still vote +1 in principle, but
>> target it for a 4.1 release that can come not too long after 4.0 is out.
>
> I agree strongly on this. A process note, I see we have created 4.1, 4.2
> milestones — would it be better to create a 4.x milestone like we did on
> 3.x, so we can say "it'll be in one of the 4.x releases" instead of tying it
> to a specific release until we actually know which release it'll make it
> into?

I'd say this may be premature.  There are going to be PLIPs which
require a break with backwards compatibility, and which only make
sense for 4.0.  Those we have to assess on their desirability and
feasibility.  If they seem too radical they would be pushed to 5.0.

Then there are the less ambitious PLIPs which don't require
significant changes to add-ons, customizations or documentation.  If
we determine that the change is desirable, it would potentially be
acceptable for any release in the 4.x series.

In that case, what is the purpose in explicitly pushing it into a
later release in the cycle?  Making that decision could discourage the
development of the feature entirely.  If the PLIP developers feel that
they can have the feature ready in the specified timeline, and we feel
that it is a beneficial change for Plone, arbitrarily pushing it to a
later release seems inappropriate.

If the PLIP developers themselves indicate that they may not have
enough time for development, such a decision may make sense.  This
could easily be the case for developers who have submitted multiple
high quality PLIPs.  Beyond that, I don't see how we can make an
objective determination of which features are not right for 4.0 but
are fine for 4.1.

If we are going to be assigning PLIPs to future 4.x releases, I think
we need to have some clear guidelines on which to base such decisions.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP deadline overly aggressive?

[Alec Mitchell]

Joel,

I for one would really appreciate if you could provide some of your
insight on some of the current 4.0 PLIPs.  You have incomparable
breadth of knowledge and insight regarding what aspects of Plone are
heavily, popular or even despised (particularly among people who are
not necessarily active in the community).  I also know you probably
have a little free time this weekend :-)

https://dev.plone.org/plone/roadmap

Would it be a good idea to send a mail to the lists to determine if
there are a significant number of people who would have submitted
PLIPs given a slightly longer timeline?  We could then take that
knowledge into account during our next meeting.  We don't want to
disenfranchise anyone, but concerns about the timeline don't really
matter unless they are coming from people who would be involved in the
process.

We had discussed having an additional week after the deadline for
providing feedback to help improve any subpar PLIPs.  This was deemed
unnecessary, partly because it was agreed that FT members would be
giving feedback on PLIPs as they came in, as well as during the review
period.  We may want to reconsider that option, especially if we get
problematic feedback.

Alec

On Sat, Jun 20, 2009 at 10:46 AM, Joel Burton wrote:
> Hello, Framework Team!
>
> I, myself, don't have any questions or issues about the PLIP deadline
> for 4.0. I'm not planning on submitting any PLIPs.
>
> Over the past two weeks, though, while chatting in IRC with various
> framework team members and other core Plone people, at least 5 have
> mentioned, without my prompting, that the deadline for 4.0 PLIPs seemed
> awfully fast in coming, and they wondered whether it may have been too
> aggressive.
>
> I don't know what the discussion was like in deciding on this date. It
> may still be the right decision to have it end now. I'm just suggesting
> that, if it seems that quite a few people may think that this is a
> slightly-too-soon date, that you may benefit from having that
> conversation (sometimes, groupthink kicks in and everyone might be
> assuming "this is too soon, but I'm the only person who probably thinks
> that, so no point bringing it up.")
>
> Just want to make sure that's not what happens.
>
> In any event, have a wonderful PLIP season! I look forward to teaching
> what you invent. ;)
>
> Your biggest fan,
>
> - j.
>
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PLIP deadline overly aggressive?

[Alec Mitchell]

On Sat, Jun 20, 2009 at 12:15 PM, Ross Patterson wrote:
> Matthew Wilkes
>  writes:
>
>> On 20 Jun 2009, at 19:38, Tres Seaver wrote:
>>
>>> Isn't 4.0 deliberately a "short-hop" release, with minimal new
>>> feautres,
>>> mostly intended to move the platform forward (to modern versions of
>>> Zope, Python, CMF)?  Keeping the window short emphasizes that fact, at
>>> least to my outsider's eyes.
>>
>> Hmm, the way I see it is that the timeline is deliberately short as
>> 4.0 is an intermediate release.  Trunk is the innovative, new thing,
>> 4.0 is incremental upgrades that go beyond a 3.x release.  In fact,
>> the release was almost called 3.5 or similar.
>>
>> I don't know how I feel about this, the period is awfully short, but
>> I'm probably leaning towards short keeps things from getting too
>> ambitious.
>
> To clarify, I'm definitely on board with the spirit of moving quickly.
> My concern is that in moving quickly we'll end up missing discussion
> that needed to happen and that without that discussion we'll end up with
> a release that is technically short-sighted, demonstrates poor
> consideration of impacts to the wider community, or any other negative
> that can result from moving too quickly.
>
> So maybe we should re-phrase the question.  How fast is *too* fast?
> What *are* the minimum requirements for discussion of a backwards
> incompatible major release?

I think it's impossible to know in advance how fast too fast is.
However, the current deadline was based on a reasonably well attended
framework team meeting and was an essentially unanimous decision.  The
rationale was that a PLIP does not require a completed product or even
thorough design, and therefore does not require a long time to create.
 Allowing a little under two weeks including two weekends, seemed
reasonable at the time.  A longer timeframe would have led to
procrastination as likely as to productivity.  People who aren't
capable of putting together a one page summary of desired
functionality with realistic risk assessments in a two week period,
probably aren't likely candidates to implement such functionality in a
similarly compressed period (which is an implicit goal of this
release).

The results, I think, have born that theory out.  We have a large
number of submitted PLIPs, and though they are of varying quality,
framework team members (and others) have been providing feedback.  As
a result, many of the sub-par PLIPs are improving rapidly.  I doubt
that more time would have resulted in more PLIPs (and I'm not sure we
really need more PLIPs).  It may have allowed some extra time for
discussion and brought forward a better proportion of high-quality
PLIPs, but judging by what's currently in Trac and how quickly it's
improving, I don't believe that's a major issue either.  My guess is
that with a longer timeframe, most PLIPs would start coming in around
the time we started sending reminder emails and the results would have
been nearly identical.

We will be having a meeting early this coming week to discuss the
submissions and the review process.  If we determine that we have not
received enough quality PLIPs or that there are obvious gaps in what
we have, I don't see why the submission deadline couldn't be extended.
 I don't believe that will be the case, judging by the current
submissions, but I speak only for myself.  Further, I hope and expect
that framework team members (and others) will be commenting on those
PLIPs to further discussion and help clarify PLIP goals and
feasibility.  That process is likely to continue until the final
review deadline next weekend; hopefully with continuous feedback from
the PLIP authors and participants.

None of the deadlines are currently set in stone, and they can be
extended as needed.  However, the goal is to have a limited, mostly
backwards compatible, release with significant infrastructure
improvements and enough user facing improvements to merit the "4.0"
name.  We also aim is to make the release in a fairly short timeframe,
and that will be taken into account when making decisions on PLIPs.
We currently have a diverse set of PLIPs with many different authors
and varying levels of ambition.  This is undoubtedly a good thing.

No decisions have been made at this point, and the process seems to be
working well.  I suggest we see it through for the next week before
deciding whether or not there are major problems.  However, active
involvement by framework team members and PLIP authors is going to be
critical for this compressed timeframe to work.  I dedicated a full
day this week to providing feedback on submissions, and I plan to do
the same for the next week.  I hope other Framework Team members are
willing to put in similar effort, and if they do,  I think this
process will be successful.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIPs in Trac

[Alec Mitchell]

On Thu, Jun 18, 2009 at 4:47 PM, Hanno Schlichting wrote:
> Hi.
>
> Where and how to manage PLIP's is both a matter of a defined process
> and some software supporting this process.
>
> One of the main driving reasons to move all Plone Core development
> related information into Trac, was to have one place to manage and get
> an overview of all relevant information. If we need to get an overview
> of where Plone 3.3 currently is, we can only answer this based on the
> status of certain tasks and bugs in Trac plus the information shown on
> the plone.org/products/plone page. If you need to later find out what
> small feature / plip or bug has been part of which release, it is
> easier if all this information is in one place.

One of the main reasons that I'm in agreement with Matthew on this is
that I don't think major roadmap type decisions on which PLIPs
ostensibly focus belong mixed in with bugs and random feature
requests.  Having the potential roadmap and its progress outlined
within the software release system makes more sense than having it
available exclusively  in an issue tracker that no one besides
developers bothers with (especially when it's cluttered with noise).

> Now when it comes down to the exact software features of Trac vs. a
> Plone content type, they are pretty much the same from what I can see:
>
> - Notion of ownership of the plip by a user
> - Assignment to a milestone / release
> - Unique ID
> - Short title
> - Full text description
> - Workflow state
> - Comments
>
> What is different about these two:
>
> - PSC has multiple text fields for various sub-headings, whereas Trac
> only has one text field and the structure needs to be defined by a
> template. The structure given by PSC has often been ignored, as
> there's too many fields with unclear separation.

I consider this a large advantage for PSC, and I think the results so
far speak to that advantage.  In PSC, it is painfully obvious to the
creator/editor of a PLIP when their work is incomplete, because the
ostensible requirements are a prominent part of the editing process.
We don't have that with Trac.  The structure provided by PSC may have
been ignored (or left incomplete) at times, but never to the extent
that we're seeing with Trac.

> - PLIP's in PSC can only be edited by members of the plone core
> development team, whereas tickets in Trac can be worked on by anyone
> with collective write access.

This is not a requirement, just a choice made in our deployment of
PSC.  It may in fact be a good choice, but it could easily be changed
to allow collective committers or an even broader selection of users.

> - There's a more sophisticated specialized workflow in PSC for PLIP's
> that doesn't match the reality. Usually I used to move things into the
> appropriate stages all the time, but the workflow was largely unused
> in practice. Since we upgraded to Trac 0.11, we can define a
> specialized workflow in Trac as well, that could actually match our
> process.

We have customizable workflows in Plone as well, I believe ;-)  If the
workflow is not correct, we can change it easily.  It's certainly more
correct than the complete lack of PLIP workflow in Trac currently.

> - Trac has the ability to let users subscribe to tickets via the CC,
> so you can get updates about the progress of a particular ticket.

This is certainly a big advantage for Trac and it may even outweigh
many of the above disadvantages.  Having to go back to the PLIP pages
constantly to look for updates would be a major pain.

> Following this I don't see a clear win on the technical side for PSC,
> but see Trac as more feature-rich and tailored to this particular
> need. Another reason to move things out of Plone, has been the
> particular slowness of plone.org. Commenting on PLIP's to cast votes
> has been an utter pain in the past.

I don't think you can reasonably say that Trac is more tailored to
this particular need than the system developed specifically for this
particular need.  I gather that commenting was a pain mainly because
of slowness in the system?  That wasn't always the case, I wonder what
has changed since the Plone 2.1 days of Plone.org to make it so much
more painful.  Beyond performance issues and automatic emails, is
there any real difference in the commenting/voting process between the
two?

> Now I do agree that what we have seen in terms of submitted "plip's"
> in the last days is for the most part nothing that deserves this name.
> however I don't see a software problem, but a problem in an undefined
> or not-followed process here. What we have seen is for the most part
> feature wishes, which at some points have been raised for the first
> time in any community discussion.
>
> The PLIP process used to be:
>
> - If you have an idea, you discuss it on the plone-dev mailing list

This has only rarely been the case.  Often, PLIPs were written before
feedback was solicited.

> - After the community has provided feedback and you got som

Re: [Framework-Team] PLIPs in Trac

[Alec Mitchell]

I'm in agreement that the plone.org system is preferable; however I
think it's probably a little late to change this.  It does seem like
the "PLIPs" submitted so far are mostly unstructured feature requests.
 Even the better ones are pretty minimal.

Alec

On Thu, Jun 18, 2009 at 3:48 PM, Matthew
Wilkes wrote:
> Hi all,
>
> I'd like to open a public discussion on where tracs should be.  As some of
> you may know, I'm very much against the PLIPs-in-trac system that has been
> implemented following out-of-band discussions last year.
>
> I think we need to make a proper decision, I'm not sure how that will
> happen, but if it'll stop me whinging either way.
>
> For Plone <4.0 we've put PLIPs on plone.org, this has the following
> advatanges:
> - Unique, relatively low number for each PLIP
> - Custom content type enforces PLIP structure
> - Workflow matches our process
>
> The disadvantage of it being on a different site has been raised, but I
> don't buy this.  How often do you want to look at the bugs and PLIPs for a
> release at the same time?  They have a completely different process.
>
> The current crop of PLIPs for 4.0 are very unstructured, only the ones
> copied verbatim from plone.org have seconders.  We're having to bodge
> workflow by assigning different milestones.  It's really suboptimal.
>
> Do others agree with me, or do you prefer trac?
>
> Despairingly yours,
>
> Matt
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] [Plone 4] Framework team, let's talk...

[Alec Mitchell]

On Mon, Jun 8, 2009 at 5:30 AM, Eric Steele wrote:
> On Jun 8, 2009, at 8:15 AM, Matthew Wilkes wrote:
>
>>
>> On 5 Jun 2009, at 03:56, Calvin Hendryx-Parker wrote:
>>
>>> Based on the responses, generally folks are available Monday and Tuesday
>>> at 2:00PM US/Eastern time.  This works for me, how about the rest?
>>
>> Sure, shall we set a proper date then?
>>
>> Matt
>
> Sure. Can we make it this Tuesday at 2pm Eastern?
>
> I'll get myself set up with a stable connection and we'll try to do this
> over iChat or Skype. Hopefully it goes smoother than the one we attempted
> over the weekend.

That works for me.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] [Plone 4] Framework team, let's talk...

[Alec Mitchell]

On Thu, Jun 4, 2009 at 7:56 PM, Calvin
Hendryx-Parker wrote:
> Here is the link we used to start this process:
>
> http://www.doodle.com/ucb3w2fcqieken28
>
> Based on the responses, generally folks are available Monday and Tuesday at
> 2:00PM US/Eastern time.  This works for me, how about the rest?

These times should generally be OK for me as well.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Plone 2009: Going from here

[Alec Mitchell]

On Sun, May 10, 2009 at 8:25 AM, Eric Steele  wrote:
> Folks,
>
> A gentle prod since Steve wants to have something to vote on by Friday
>
> There seems to be general agreement on the hybrid team idea. Can we pare
> this down to a list of 7 people?
>
> We currently have responses of:
> available: Raphael (3), Ross (4), Matt (4)
> unavailable: Andi (3)

I'd be happy to be a part of this new framework team, though obviously
people from the existing teams should have priority (as should any
people deeply involved in Plone trunk development like Martin and
Hanno).

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Plone-developers] [Framework-Team] Plone 3.5

[Alec Mitchell]

I agree with what appears to be majority opinion here – that this
release should be called Plone 4.0.  Whatever expectations people
might already have regarding Plone 4.0 can be easily managed.

I'd like to stand up for "my" release a little, since people seem to
be implying it was some sort of expectations/compatibility disaster.
Plone 2.5 introduced some new infrastructure and officially deprecated
a number of old APIs, scripts and templates, but it maintained
compatibility for all of those.  The only exception that I'm aware of
is the introduction of PlonePAS, which theoretically offered API
compatibility but failed in that regard with some 3rd-party add-ons.
The scope of 2.5 was well defined, and highly constrained (in fact,
Plone's official deprecation/compatibility policy was established as a
part of the 2.5 release). The numbering jump may not have been ideal,
but calling that release 3.0, when there were almost no outwardly
visible changes (aside from deprecation warnings in your logs), would
have also been a blunder, IMO.

If you want to pinpoint a release that broke expectations with regard
to compatibility, Plone 2.1 is a far better example.  There were a
huge number of incompatibilities and migration issues between 2.0 and
2.1.  The transition to ATCT alone was worth a major revision, never
mind the numerous API and UI changes and configuration options
removed/disabled (some of which were thankfully put back in place in
2.5).  If anything, Plone 2.5 began to establish a contract of major
release compatibility that had been entirely destroyed with the 2.0 ->
2.1 transition.  Plone 2.5 wasn't perfect, but I find it hard to
imagine it as the expectations nightmare people are portraying here.

Alec

On Tue, May 5, 2009 at 5:23 AM, Matthew Wilkes  wrote:
> On 5 May 2009, at 12:44, Hanno Schlichting wrote:
>
>> The general idea that seems to have met some consensus is to go for a
>> Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
>> that is similar in spirit to the Plone 2.5 release. It tries to both
>> refresh some of our technical underpinnings in addition to some more
>> intrusive feature changes we didn't allow ourselves in the 3.x
>> series so
>> far.
>
> Why skip 3.4?  That Plone 2.5 was a special-case major release was
> quite nasty, it confused people about what was a major release and
> what isn't.  Also, we've made a commitment to 3.x being stable, I
> think we should keep to it.  However, it would be good to open the new
> features to a wider audience ASAP.
>
> I'd be -1 if it hurts our users by discontinuing a stable platform in
> favour of a half-way house.  If we keep Plone 3.x as fully supported
> and this being something for early adopters and dare-devils, then I'd
> be +0.  I'd be +1 if this was distinction was made explicit in the name.
>
> Matt
>
>
> --
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> ___
> Plone-developers mailing list
> plone-develop...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Supported Plone Releases

[Alec Mitchell]

I just want to note that I'm willing to make releases of Plone 2.5 to
fix truly critical bugs and security issues, provided those fixes
aren't too invasive (e.g. the most recent round of CSRF fixes are not
really feasible for incorporation into 2.5).  If that is "supported",
then consider it supported.  It may really be the foundation/board's
call though.

Alec

On Wed, Dec 10, 2008 at 8:28 AM, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> On 12/10/08 5:24 PM, Calvin Hendryx-Parker wrote:
>>
>>
>> On Dec 10, 2008, at 11:22 AM, Wichert Akkerman wrote:
>>
>>> Previously Calvin Hendryx-Parker wrote:

 I just noticed that on the PSC the Plone 2.5.5 release is listed as
 not supported.  I'd suggest that unless we have sent an email to the
 announce list that the latest 2.5.x relases still be "supported".  I
 also noticed that some of the older 3.1 releases are still listed as
 supported.  Is there a reason that those aren't listed as unsupported
 since there is a 3.1 that would supersede them?
>>>
>>> Why bring this up on the framework team list? The framework team is not
>>> a governing body.
>>
>>
>> I was pointed this direction by Steve,  where should this go?
>
> Likely candidates would be: the foundation board, the 2.5 release manager
> and the developers list.
>
> Wichert.
>
>
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP 238: Disable inline editing by default

[Alec Mitchell]

Is it really that much work to fix the ui for starting an edit?  I
think there are a lot of people who like this feature, but are
frustrated by the UI.  Disabling it does nothing to fix that though,
it's just another regression to work around what many consider a real
UI bug.

Alec

On Tue, Oct 28, 2008 at 8:08 AM, Raphael Ritz <[EMAIL PROTECTED]> wrote:
> Wichert Akkerman wrote:
>>
>> I want to propose PLIP 238: Disable inline editing by default
>>
>> Motivation
>> --
>> I suspect that by now most of us have realized that the current inline
>> editing
>> behaviour in Plone 3 is not very practical. It has two main problems:
>>
>> * it is very easily triggered by default, which causes unwanted edit
>> fields to
>>  be opened which have to be manually closed. This happens because many,
>>  if not most, people click accidentily, select text to keep track of
>>  the reading position, try to select text to copy&paste it or for other
>>  reasons. Since every single click activates inline edit this happens
>>  all too often and becomes very frustrating over time.
>>
>> * as Alexander mentioned in his new UI proposal what you really want is
>>  a quick option to go to a full edit-mode. Editing a single field is a
>>  much less common operation than we were expecting.
>>
>> I can't think of a single Plone deployment I have been involved in for
>> the last 6 months where we have not disabled inline editing, which
>> strengthens my believe that the current default is wrong.
>>
>> Proposal
>> -
>>
>> Current Plone releases have a simple toggle to enable or disable inline
>> editing. I propose that we change the default for newly created sites to
>> disabled.
>>
>> Please note that I do not propose to disable inline field validation in
>> edit screens: that is a very useful and desirable feature.
>>
>> Wichert.
>>
>>
>
> +1 on just changing the default.
>
> Raphael
>
> PS: And while we are at this: personally I do like inline editing
> for simple fields like title, description, a date and such.
> But where I really HATE it is when it comes to text fields as
> they often contain a large body of text that you want to scroll
> through, that has links embedded that you want to click etc.
>
> But that's not the matter of this PLIP and it seems like we are
> going to see more on this soon anyway.
>
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP 246: View for rendering events as an iCalendar file

[Alec Mitchell]

On Mon, Oct 20, 2008 at 9:51 AM, David Glick <[EMAIL PROTECTED]> wrote:
>
> On Oct 19, 2008, at 10:55 PM, Alexander Limi wrote:
>
>> Hi Framework Team,
>>
>> On behalf of Andreas Zeidler, I'd like to offer up the following PLIP for
>> your consideration for Plone 3.3:
>>
>> http://plone.org/products/plone/roadmap/246
>>
>> It's a pretty trivial PLIP that adds a new view that is capable of
>> rendering events as an iCalendar file, so people can subscribe to Plone
>> events in various calendaring software like iCal, Google Calendar, Outlook,
>> Sunbird, etc.
>>
>> The view is added to ATContentTypes, and is currently implemented on a
>> branch (and includes tests).
>>
>> PS: Andreas is fully responsible for the implementation here, I'm only
>> helping out by writing a short PLIP for him.
>
> An unofficial +0.5 from me, which will increment to +1 if the following
> question is addressed:
>
> Why is a calendar support mixin used, instead of adapting to
> ICalendarSupport?  The latter would make it easier to also implement
> calendar support for non-AT content.

No mixins please.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PLIP 244: Portlet management improvements

[Alec Mitchell]

On Thu, Oct 16, 2008 at 3:39 PM, Martin Aspeli <[EMAIL PROTECTED]> wrote:
> Wichert Akkerman wrote:
>>
>> Previously Martin Aspeli wrote:
>>>
>>>  - Create a "site wide" portlet category for portlets that should show on
>>> all pages (unless blocked). Currently, people have to use contextual
>>> portlets at the root of the site for this, which gets cumbersome since if
>>> you block them in one folder, you need to re-add all portlets in subfolders.
>>
>> This feels like a workaround for the fact that you can not selectively
>> block portlets.
>
> I used to think that way, I'm not so sure anymore. Speaking to people about
> this over the past few months, I've come to realise that our model of
> thinking that the site root is the "parent" of all content from which things
> like portlets can inherit if they need to be site-wide is not how people
> tend to think about it.
>
> I think to most people, the root is the front page and is just a page. You
> may want some portlets on the front page, or you may want some portlets that
> are global and show up (almost) everywhere. In our current model, the
> "workaround" is that you have to be careful to assign portlets to the root
> and then not block them unduly. This gets unnatural, especially if you have
> deep or complex content hierarchies.
>
>> I would prefer a method where you can both block
>> individual portlets and block only for the current object is, similar
>> to how you propose a flag to only show a portlet in the current object.
>
> Right, we need that too. :)

But since we need it and it effectively solves the same problem, why
concentrate effort on the less general solution.  Having both will
likely give us a few too many ways to do the same thing.

Also, +1 on Jon's suggestion for making portlet order independent of
portlet assignment type.  This is a pretty major shortcoming of the
portlet system.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Framework Team Meeting in DC

[Alec Mitchell]

I'll be in D.C. and would attend the meeting on whichever day it may be held.

Alec

On Mon, Jul 14, 2008 at 8:12 AM, Raphael Ritz <[EMAIL PROTECTED]> wrote:
> Wichert Akkerman wrote:
>>
>> Previously Tom Lazar wrote:
>>
>>>
>>> steve,
>>>
>>> that's an excellent idea!
>>>
>>> can we do a quick 'show of hands' here on the list, which framework  team
>>> meamber will be (if at all) when in DC? like so, perhaps?
>>>
>>>| from  | til
>>> -
>>> tomster | 6th   | 12th
>>> witsch  | 6th   | 12th
>>> wiggy   |   |
>>> raphael |   |
>>> danny   |   |
>>> martijn |   |
>>>
>>
>> I won't be in DC.
>>
>
> Me neither - unfortunately :-(
>
> Raphael
>
>> Wichert.
>>
>>
>
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: [Plone-developers] Plone 3.1 update: PLIPs have been merged

[Alec Mitchell]

You missed #217 - Workflow lookup by Adaptation, which is merged.

On Sun, Mar 2, 2008 at 6:12 AM, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Thanks to all the hard work from the PLIP authors we have finished
>  merging all the PLIPs in the Plone 3.1 tree. A total of 16 PLIPs
>  have been merged:
>
>   #184: Include more/improved portlets (Jon Stahl)
>   #195: Support product dependencies (Wichert Akkerman)
>   #200: Kupu formlib widget (Martin Aspeli)
>   #202: Support inline validation and editing for formlib forms (Martin 
> Aspeli)
>   #203: Manage portlet assignments with GenericSetup (Martin Aspeli,
>Geir Baekholt)
>   #204: Manage content rules using GenericSetup (Martin Aspeli)
>   #205: Flexibility Associating Portlet Types and Portlet Managers (George 
> Lee)
>   #207: Allow Custom Portlet Managers (George Lee)
>   #208: Adapter-Based Local Role Lookup (Alec Mitchell)
>   #209: Add buildout to Unified Installer (Steve McMahon, Wichert Akkerman)
>   #212: Use jQuery Javascript Library (Florian Schulze, Martijn Pieters)
>   #213: Prepare for better Syndication (Florian Schulze, Derek Richardson)
>   #215: Include new KSS versions (Balazs Ree, Godefroid Chapelle)
>   #218: Increase Restrictions, and Ability to Change, Addable Portlet Types
>by Interface (George Lee)
>   #220: Improve browser layer support (Wichert Akkerman)
>   #224: CSRF protection framework (Wichert Akkerman)
>
>
>  Unfortunately 2.2 PLIPs did not make it in this release:
>
>   #187: Working Out-of-the-box WebDAV (Sidnei da Silva)
> This was probably the most hotly debated PLIP. It does offer some
> very nice improvements for WebDAV but the initial implementation
> needed some cleanups and changes before it could be merged into
> Plone core. Sidnei has been working hard on those and has a cleaner
> implementation ready, but this needs a a new proper review. This
> already looks like an excellent candidate for Plone 3.2.
>
>   #201: Improve the UberSelectionWidget UI (Florian Schulze)
> The user interface for the UberSelectionWidget needs more work
> before it is ready for us mere mortals. I'm hoping this will be
> finished on time for Plone 3.2.
>
> A few improvements to the sources that make the existing
> UberSelectionWidget a bit easier to use have been merged in the 3.1
> tree.
>
>   #224: CSRF protection framework (Wichert Akkerman)
> The changes to plone.session to make it use the new keyring manager
> introduced too many migration problems and test failures in a lot
> of other places and have been reverted. The other parts of this PLIP
> have been merged.
>
>
>  this week we will be focusing on stabilizing the tree, fixing any test
>  failures that have surfaced and testing, testing and testing. And the
>  good news is everyone can help! Just grab that Plone 3.1 ploneout
>  branch, make an instance and start playing with it. The PLIP authors
>  are not the only one having fun, *you* can have some fun as well!
>
>  Wichert.
>
>  --
>  Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
>  http://www.wiggy.net/   It is hard to make things simple.
>
>  -
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
>  ___
>  Plone-developers mailing list
>  [EMAIL PROTECTED]
>  https://lists.sourceforge.net/lists/listinfo/plone-developers
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Framework Team membership, release manager, roles and responsibilities

[Alec Mitchell]

On Wed, Feb 27, 2008 at 8:29 AM, whit <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 27, 2008 at 4:25 AM, Graham Perrin <[EMAIL PROTECTED]> wrote:
>  > > From: Andreas Zeidler <[EMAIL PROTECTED]>
>  >  > Date: 26 February 2008 23:46:24 GMT
>  >  > To: George Lee <[EMAIL PROTECTED]>
>  >  > Cc: framework-team@lists.plone.org
>  >  > Subject: Re: [Framework-Team] Re: WebDAV changes
>  >  >
>  >  > On Feb 24, 2008, at 9:51 PM, George Lee wrote:
>  >  >
>  >  >> P.S. I think that as a matter of process it make sense that a
>  >  >> release manager can make / ask for a major revert for time's sake,
>  >  >> but that the framework team should then speak up on that because
>  >  >> ultimately it's supposed to be their decision and what they're
>  >  >> accountable for.
>  >  >
>  >  > no, not really.  the framework team's job is to review and give
>  >  > recommendations to the release manager.  the decision to merge or
>  >  > not to merge (or revert for that matter) is made by the release
>  >  > manager, though.
>  >  >
>  >  > cheers,
>  >  >
>  >  >
>  >  > andi
>  >  >
>  >  > ps: also see http://plone.org/development/teams/framework/faq
>  >
>  >  1) 
>  >  states that
>  >
>  >  > The Framework team is only responsible to accept/reject PLIPs
>  >
>  >  -- to me, that sounds like decision making ;)
>
>  but of something completely different.
>
>
>  >  OK so the preceding paragraphs, and   >  teams/framework/faq>, are more explicit, but   >  development/teams/framework/framework-team> in its entirety could be
>  >  misinterpreted.
>
>  framework team was never intended to make any decisions beyond
>  recommendations to the release manager on what to include in a
>  release.  This was part of the big reason to choose new members after
>  making the recommendation so the community would not mistake the power
>  of the framework team as extending beyond making recommendations and
>  acting as the gatekeeper for plips and the code associated with them.
>   Choosing new members frees up FWT members to work on the release
>  without any confusion by the wider community about them still making
>  decisions about what goes in release.
>
>  the framework team wasn't intended to be a primary decision making
>  body, but to aid to the release manager, who can take or leave what
>  the framework team recommends and has the latitude to make any
>  necessary decisions outside of those recommendation.
>
>  it seems this time around time obligations for review were a bit of a
>  problem. for next, I want to bring up an old option, the external
>  review. As long as the FWT makes sure someone relatively unbiased
>  reviewed the PLIP and voted on it, it didn't matter who did the
>  reviewing.  the main thing is someone conscientiously looks at the
>  code and writes a coherent review.Maybe next time around it would
>  be worthwhile to line up a few extras ahead of time to review code in
>  case of life offline happening ;)

+1 allowing FT members to bring in others to aid in the review process
can only help matters, both in terms of making their job more
manageable and making it clearer that the FT is not some all-powerful
cabal.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] PLIPS 208 and 217 Merged

[Alec Mitchell]

I merged PLIPs 208 and 217 tonight.  The following changes were made:

* The plip208 branch of borg.localrole was merged into trunk
* borg.localrole was added to the 3.1 branch of ploneout
* A migration and procedural GS import step were added to CMFPlone 3.1
branch, along with tests
* A minor fix was merged from the plip208 branch of PlonePAS into the 3.x branch
* Changes were merged into the trunks of ploneout, CMFPlone, and PlonePAS

* The adpaterized_workflow branch of CMFPlone was merged into the 3.1
branch and trunk
* A plone3.1 branch of CMFPlacefulWorkflow was created from the
plone3.0 branch, and the changes from the plip217 branch were merged
into the new branch
* Updated ploneout (3.1 and trunk) to use the plone3.1 branch of
CMFPlacefulWorkflow

Tomorrow I will merge the changes on the CMFPlacefulWorkflow plone3.1
branch into the CMFPlacefulWorkflow trunk (currently not used by any
of the plone setup, but likely to be used by 4.0 at some point).

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] PLIPs 208 and 217 Ready for Review

[Alec Mitchell]

Hi Team,

I've got a buildout for the local roles PLIP (208) ready:

https://svn.plone.org/svn/plone/review/plip208-localroles

It includes branches of borg.localrole and a branch of PlonePAS that
installs the borg.localrole plugin in place of the default one.  In
the course of my testing and creating the bundle I discovered a couple
flaws in the PlonePAS local role plugin.

1) getRolesInContext doesn't check if the principal it's looking at is
defined in the current security context as it traversed the
containment chain to find roles.  This is a pretty minor bug, but it
means that if there were e.g. a user named "plone" defined at the Zope
root and given the Manager role locally on the zope root, and another
user named "plone" defined at the portal root which wasn't given the
manager role, getRolesInContext would be incorrectly granting manager
to that user.  borg.localrole performs context checks at each
acquisition level.  The checkLocalRolesAllowed method had the correct
behavior.

2) The local role plugin in PlonePAS was taking responsibility for
returning the user's global roles as well, this seems very
inappropriate, though it is just a matter of convention.  Because I
didn't want to replicate this mis-feature in borg.localrole, I moved
the the inclusion of global roles from the the local role plugin's
getRolesInContext method to the user's getRolesInContext method.

There is one piece missing from the buildout which is a CMFPlone
migration step to replace the old local role manager in existing
sites.  That shouldn't hinder testing or review, but I didn't feel it
was worth branching CMFPlone for a minor thing which isn't needed
during review.


There's also a buildout for the workflow PLIP (217):

https://svn.plone.org/svn/plone/review/plip217-workflow

This adds branches of CMFPlone and CMFPlacefulWorflow.  The CMFPlone
branch includes the changes to the workflow tool, the default adapter,
and tests.  The CMFPlacefulWorkflow branch now uses an adapter in
place of the monkey patch and the code has been significantly
simplified.  There is one caveat, which is that the buildout test
runner seems to have trouble coping with two different
CMFPlacefulWorkflow products in different products folders.  Though it
runs the tests for the correct CMFPlacefulWorkflow (the one in
'products') it tries to use the 'Extensions/Install.py' from the wrong
one (the one in 'parts/plone').  So to run the CMFPlacefulWorkflow
tests, you will need to remove the product from 'parts/plone'.
There's probably some way to fix this, but I'm a buildout novice
really.

Both buildouts are based on the ZopeSkel 'plone3_buildout' template.

Thanks and happy reviewing,
Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP #217 & #221 Comments

[Alec Mitchell]

There are no tests and there's a fatal bug (queryAdapter instead of
queryMultiAdapter, and no interface to adapt to specified).  I will of
course be looking at it, at the very least for inspiration, when I
prepare the bundle tomorrow.  Thanks for the reminder.

Alec

On Jan 12, 2008 7:27 AM, Alan Runyan <[EMAIL PROTECTED]> wrote:
> Kapil's code can be found at:
>
> https://svn.objectrealms.net/svn/public/cmfblackbird/
>
> good code.
>
>
>
> On Jan 3, 2008 11:45 AM, Sidnei da Silva <[EMAIL PROTECTED]> wrote:
> > Please check the comments on PLIP #217:
> >
> > http://plone.org/products/plone/roadmap/217/#1197635650
> >
> > Apparently Kapil has a working implementation that can be used by the
> > person implementing those PLIPs.
> >
> > --
> > Sidnei da Silva
> > Enfold Systemshttp://enfoldsystems.com
> > Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
> >
> > ___
> > Framework-Team mailing list
> > Framework-Team@lists.plone.org
> > http://lists.plone.org/mailman/listinfo/framework-team
> >
>
>
>
> --
> Alan Runyan
> Enfold Systems, Inc.
> http://www.enfoldsystems.com/
> phone: +1.713.942.2377x111
> fax: +1.832.201.8856
>
>
> ___
> Framework-Team mailing list
> Framework-Team@lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] More worfklow adapters, status and history

[Alec Mitchell]

On Dec 19, 2007 1:07 PM, Martijn Pieters <[EMAIL PROTECTED]> wrote:
> On Dec 17, 2007 1:36 AM, Laurence Rowe <[EMAIL PROTECTED]> wrote:
> > Inspired by Alec's plip #217, I'd like to propose making workflow
> > history/status storage fully pluggable.
> >
> > http://plone.org/products/roadmap/221
> >
> > Though it is now perhaps a little late for 3.1, completing the
> > componentization of the workflow tool in one shot has its advantages.
>
> I must say I'd rather have this one go into the CMF directly. We have
> the people with the access, and I think your proposal should have no
> trouble being accepted for a future CMF version.
>
> In the same vein I'd rather see PLIP #217 go directly into the CMF, if
> it were not for the fact I'd like to see the CMFPlacefulWorkflow
> monkey patch disappear ASAP. Perhaps we should ensure that we port
> both PLIPs to the CMF ASAP.

That's the plan.  My understanding is that we're not likely to have a
new major release of the CMF for Plone 3.1. So if we want these
changes, then it makes sense to drop them into Plone and then merge it
into CMF for the next major release.  If the CMF situation changes,
then these should certainly go into CMF ASAP.  In fact I'd suggest
merging this stuff into CMF trunk as soon as the implementation in
Plone is done and reasonably tested.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] When do we hear?

[Alec Mitchell]

On Dec 19, 2007 2:54 PM, Andreas Zeidler <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007, at 9:43 PM, Martijn Pieters wrote:
> > On Dec 19, 2007 9:42 PM, Martijn Pieters <[EMAIL PROTECTED]> wrote:
> >> As you can see from the 3.1 release schedule as set by Wichert, the
> >> framework team has set itself this friday as the deadline for
> >> selecting the PLIPs for 3.1.
> >
> > Whoops, I meant to include a URL for the schedule:
> >  http://www.nabble.com/Plone-3.1-timeline-td13939050s6745.html
>
> you might also subscribe to 
> http://plone.org/products/plone/releases/3.1/timeline.ics
>   in your ical ;)

Excellent!!

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Re: PLIP #212: Use jQuery Javascript Library

[Alec Mitchell]

On Dec 14, 2007 10:12 AM, Florian Schulze <[EMAIL PROTECTED]> wrote:
> On Fri, 14 Dec 2007 19:00:43 +0100, Alec Mitchell
>
> <[EMAIL PROTECTED]> wrote:
>
> > On Dec 14, 2007 5:36 AM, Florian Schulze
> > <[EMAIL PROTECTED]> wrote:
> >> On Fri, 14 Dec 2007 07:37:14 +0100, Alec Mitchell
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >> > On Dec 12, 2007 9:27 AM, Florian Schulze
> >> > <[EMAIL PROTECTED]> wrote:
> >> >> Hi Framework Team!
> >> >>
> >> >>
> >> >> This is the other PLIP I want to propose besides #213. Martijn did
> >> all
> >> >> the
> >> >> hard work for it already.
> >> >>
> >> >> http://plone.org/products/plone/roadmap/212
> >> >
> >> > Just a comment from a non-FT member.  I think the work done for this
> >> > PLIP is great, and the simplification of the js code (less to
> >> > maintain) is very important.  However, I'm a bit disappointed that
> >> > it's not using KSS stylesheets to do the bindings, but instead using
> >> > jQuery directly.
> >>
> >> Another IMO big reason is that KSS bindings only work if the Browser
> >> supports AJAX and some things should still work without that IMO. Also
> >> some things can't be expressed as CSS selectors easily, so the only
> >> possible binding would be the onload handler. BTW, I'm not sure there is
> >> an ondomload in KSS, so for some things like the focus on first input
> >> element we should stick to the current way, because the latency is
> >> important in this specific case.
> >
> > I'm pretty sure the KSS load event is actually implemented as
> > ondomload, though it would be nice if it made a normal onload possible
> > as well.  Any event besides load is also easily bound using KSS.
> > Though I'm sure there exist a few things which aren't easily expressed
> > using KSS's declarative syntax, I'd be surprised if it were more than
> > a few corner cases.  Regarding AJAX requirements, I don't think this
> > is true at all.  KSS stylesheets simply provide a mechanism for
> > binding actions, when those actions are js actions on the client no
> > AJAX is needed at all (though AJAX can be used to trigger those
> > actions, which is an added bonus, a necessity even when you start
> > reloading significant portions of the page using ajax requests).  I'm
> > pretty sure the kss js still loads and operated for client actions
> > even on those clients that don't support xml requests.
>
> The KSS files are loaded by XMLHTTPRequest, so only browsers supporting
> this will get the bindings. And because it's a separate request, there is
> some slight latency involved. As with any additional requests, this highly
> depends on caching and how the browsers implement the various parts
> involved with this. I can't comment on any further details, because the
> exact implementation in current KSS is unknown to me. As you said this
> only affects some corner cases. One IMO is the autofocus, the other are
> the dropdowns, everything else shouldn't be critical and can be moved to
> use KSS binding at some point, though not for 3.1, as the implications
> aren't yet known (besides needing KSS in the first place).

Indeed, I had forgotten the the KSS files need to find their way to
the browser to begin with :-)  The latency should only be relevant for
the first page load in any given client, but the XMLHTTPRequest may
indeed be problematic for core functionality.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Two more PLIPs

[Alec Mitchell]

On Dec 14, 2007 8:44 AM, Andreas Zeidler <[EMAIL PROTECTED]> wrote:
> On Dec 14, 2007, at 9:11 AM, Alec Mitchell wrote:
> > Hi framework team members,
>
> hi framework team pioneer,
>
> > A couple more PLIPs to keep you guys busy:
>
> thank you very much. :)
>
> > Adapterized local role lookup (borg.localrole):
> > http://plone.org/products/plone/roadmap/208
>
> also very nicely written and convincing, +1 on the plip from me.
> benchmark results would be much appreciated during the review phase.
> oh, and btw, the example adapter should probably return a copy in
> `getAllRoles`, no?

Possibly, but the borg.localrole adapter which calls this method just
uses each of these results inside a mapping.update() call, so the
copying is implicit.  However, I just noticed that that implementation
is wrong because the method is supposed to return an iterator of
tuples, not a dict.  Will fix immediately.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PLIP #212: Use jQuery Javascript Library

[Alec Mitchell]

On Dec 14, 2007 5:36 AM, Florian Schulze <[EMAIL PROTECTED]> wrote:
> On Fri, 14 Dec 2007 07:37:14 +0100, Alec Mitchell
> <[EMAIL PROTECTED]> wrote:
>
> > On Dec 12, 2007 9:27 AM, Florian Schulze
> > <[EMAIL PROTECTED]> wrote:
> >> Hi Framework Team!
> >>
> >>
> >> This is the other PLIP I want to propose besides #213. Martijn did all
> >> the
> >> hard work for it already.
> >>
> >> http://plone.org/products/plone/roadmap/212
> >
> > Just a comment from a non-FT member.  I think the work done for this
> > PLIP is great, and the simplification of the js code (less to
> > maintain) is very important.  However, I'm a bit disappointed that
> > it's not using KSS stylesheets to do the bindings, but instead using
> > jQuery directly.
>
> Another IMO big reason is that KSS bindings only work if the Browser
> supports AJAX and some things should still work without that IMO. Also
> some things can't be expressed as CSS selectors easily, so the only
> possible binding would be the onload handler. BTW, I'm not sure there is
> an ondomload in KSS, so for some things like the focus on first input
> element we should stick to the current way, because the latency is
> important in this specific case.

I'm pretty sure the KSS load event is actually implemented as
ondomload, though it would be nice if it made a normal onload possible
as well.  Any event besides load is also easily bound using KSS.
Though I'm sure there exist a few things which aren't easily expressed
using KSS's declarative syntax, I'd be surprised if it were more than
a few corner cases.  Regarding AJAX requirements, I don't think this
is true at all.  KSS stylesheets simply provide a mechanism for
binding actions, when those actions are js actions on the client no
AJAX is needed at all (though AJAX can be used to trigger those
actions, which is an added bonus, a necessity even when you start
reloading significant portions of the page using ajax requests).  I'm
pretty sure the kss js still loads and operated for client actions
even on those clients that don't support xml requests.

> I agree that we should revisit all Javascripts (for 4.0?) and decide which
> can be bound by KSS or even replaced by it. Some key functionality should
> be done the old way though.

Those things which aren't naturally expressable with KSS-based
bindings shouldn't use KSS, of course.  But I think we'll find that
such things are rare, and in some cases probably poorly designed to
begin with. :-)

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PLIP: Template overrides

[Alec Mitchell]

On Dec 14, 2007 7:56 AM, Malthe Borch <[EMAIL PROTECTED]> wrote:
> > so, while i also like the idea, i'm not too sure if plone should ship
> > with it.  i'd agree with martin we should discuss and think this through
> > a little further.  nevertheless, i don't see why the plip wouldn't be
> > acceptable, so +1 on that.
>
> True. I say, let's think of z3c.jbot as inspiration and then accept the
> PLIP that we need some easy way of customizing the default plone skin.

I'd like to see some more detail on this PLIP.  Currently, it seems to
assume the reader is familiar with z3c.jbot, or requires the reviewer
to exaimine the jbot code/docs (which is an burden better left for the
code review phase).  Of course my opinion is irrelevant.  Also, I'm
very much in favor of easier template customization, provided it's
still relatively easy to figure out where a particular template/view
is coming from.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP #212: Use jQuery Javascript Library

[Alec Mitchell]

On Dec 14, 2007 12:02 AM, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Previously Alec Mitchell wrote:
> > On Dec 12, 2007 9:27 AM, Florian Schulze <[EMAIL PROTECTED]> wrote:
> > > Hi Framework Team!
> > >
> > >
> > > This is the other PLIP I want to propose besides #213. Martijn did all the
> > > hard work for it already.
> > >
> > > http://plone.org/products/plone/roadmap/212
> >
> > Just a comment from a non-FT member.  I think the work done for this
> > PLIP is great, and the simplification of the js code (less to
> > maintain) is very important.  However, I'm a bit disappointed that
> > it's not using KSS stylesheets to do the bindings, but instead using
> > jQuery directly.  We originally had one official way to do event
> > bindings (registerPloneFunction and friends), then we introduced KSS
> > which gave us a unified location to put bindings in a nice declarative
> > syntax.  Now instead of promoting the new way, we're adding a third
> > way (and reimplementing the first to use the third internally).  Why
> > aren't we unifying all of these?
>
> We don't load KSS for anonymous users due to its size.

Yes, but that's something we should be trying to fix (with better
compression on the RR ot KSS side, or just by encouraging people to
enable mod_deflate on their apache setup).  People are going to want
KSS-based functionality for anonymous users (even if Plone doesn't use
any right now).

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Two more PLIPs

[Alec Mitchell]

Hi framework team members,

A couple more PLIPs to keep you guys busy:

Adapterized local role lookup (borg.localrole):
http://plone.org/products/plone/roadmap/208

Adapterized workflow lookup:
http://plone.org/products/plone/roadmap/217

Feedback appreciated.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP #212: Use jQuery Javascript Library

[Alec Mitchell]

On Dec 12, 2007 9:27 AM, Florian Schulze <[EMAIL PROTECTED]> wrote:
> Hi Framework Team!
>
>
> This is the other PLIP I want to propose besides #213. Martijn did all the
> hard work for it already.
>
> http://plone.org/products/plone/roadmap/212

Just a comment from a non-FT member.  I think the work done for this
PLIP is great, and the simplification of the js code (less to
maintain) is very important.  However, I'm a bit disappointed that
it's not using KSS stylesheets to do the bindings, but instead using
jQuery directly.  We originally had one official way to do event
bindings (registerPloneFunction and friends), then we introduced KSS
which gave us a unified location to put bindings in a nice declarative
syntax.  Now instead of promoting the new way, we're adding a third
way (and reimplementing the first to use the third internally).  Why
aren't we unifying all of these?

KSS is currently using base2 internally for bindings, which is
apparently significantly faster than the jQuery mechanism (though as
Florian points out in another thread, jQuery is adopting some of those
optimizations).  Having all of our js bindings in one place also makes
it easier to change the underlying implementation when necessary, and
presents a clearer picture to developers and integrators.
Additionally, some of these js functions are potentially very reusable
(e.g., the collapsible sections).  If they were registered as KSS
actions and bound using KSS, it would make it much easier for
integrators and skin developers to see what is available for reuse and
how to reuse them.

I don't think this concern is enough to warrant rejecting the PLIP,
but I think it would be great if someone would take that extra step to
simplify our js story further.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: My PLIPs for 3.1

[Alec Mitchell]

On Dec 12, 2007 7:18 AM, Encolpe Degoute <[EMAIL PROTECTED]> wrote:
> Wichert Akkerman a écrit :
> > My personal non-framework team opinion:
> >
> > Previously Encolpe Degoute wrote:
> >> I'd like to see the following for 3.1:
> >>
> >> #196: GroupUserFolder removing
> >>
> >> There were and there are a lot of critical UI bugs around
> >> GroupUserFolder by PlonePAS. Because of these, several Plone release had
> >> to be delayed. We fix a lot of them in customer branch.
> >
> > I think this is a too large undertaking for 3.1 and I suspect that there
> > is too much code that uses GRUF-APIs that (Plone)PAS does support, which
> > means that that code will break. That is not allowed in a 3.x release.
>
> I can do the UI part without modifying portal_groups and portal_groupdata.
>
> > I love the idea though :)
>
> Me too: It's one less product to maintain.
>
>
> >> #214: Merge of CMFPlacefulWorkflow into CMFPlone/WorkflowTool
> >>
> >> CMFPlacefulWorkflow is now mature enough to be merge into the workflow 
> >> tool:
> >>
> >> * since two major version there's no critical bug on it
> >> * GenericSetup support is implemented in the trunk
> >> * let him outside the workflow tool would leave 2 more monkey
> >> patches in Plone bundle
> >> * all page templates can be merged into a plone_workflow skin with
> >> the #210
> >
> > How does the CMF workflow tool factor into this? I would be nice if we
> > can remove the CMFPlone WorkflowTool and use the CMF one, but I have no
> > idea how the CMF community feels about CMFPlacefulWorkflow.
>
> I never had any report or any comment from CMF users or developpers.

I will be writing a PLIP shortly which will hopefully make any merging
of CMFPlacefulWorkflow into the workflow tool unnecessary.  The idea
is adapter based workflow assignment.  By default all IDynamicType
objects would be assigned a workflow chain using an adapter that does
the normal lookup in portal_workflow, but alternate means could be
provided with simple adapters.  CMFPlacefulWorkflow/CMFPlone would
probably just override the default adapter with one that relies on
acquisition, but there may be an even more elegant way.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: The big 3.0 ;)

[Alec Mitchell]

On 4/3/07, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Wichert Akkerman wrote:
>> - Wicked
>> - Needs to use createObject?type_name=Document — the way it is
>>   set up now, anything spidering the site with credentials will
>>   create objects, and any object clicked will create objects
>>   (this change will make it invoke portal_factory)
>
> Hasn't happened.

Am I right in thinking this should be considered a seriousish bug?


I don't see why this should be considered any better/worse than the
content add menu which uses the exact same links and will be shown on
all such pages as well.  From a spiders point of view, it's not
different, AFAIK.  Not that this isn't an important issue, but we've
lived with it for a long time.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] NuPlone and Plone 3.0

[Alec Mitchell]

Franco Carinato, and to a lesser extent Rosario Di Somma, looked at it
a bit during the sprint.  I'm not sure how feasible it would be for
them to help get it into a usable state in the near future though.  We
really missed spliter at the sprint.

Alec

On 4/3/07, Wichert Akkerman <[EMAIL PROTECTED]> wrote:

I'm wearing my release manager hat today and was looking at NuPlone. At
the moment there are still a lot things that do not work or look bad in
NuPlone (IE support, form styling and control panel styling are easy to
find examples). That means that it is currently not in a state where I
want it to even ship with Plone 3.

So, what can we do about it? From what I gather:

- Cornelis does not have the time to work on NuPlone, but does not mind
 if others work on it. He does want to be consulted for any stylistic
 changes.

- Denis is willing to work on IE support for it

- Danny has a made a fair number of improvements on the Informaat
 NuPlone-based intranet design, which might be mergable into NuPlone
 directly. But he has no time to work on that.

This does not make me very optimistic for NuPlone's chances of staying
in. Unless something magic happens quickly I think we need to take it
out of the bundle and reconsider it for inclusion in Plone 3.5.

Wichert.

--
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] The big 3.0 ;)

[Alec Mitchell]

On 4/3/07, Wichert Akkerman <[EMAIL PROTECTED]> wrote:

some comments on this list, based on current status.

...

> - Combine delete confirmation page with integrity checking
>   (having to say yes/no on two separate pages sucks :)

Needs to happen soon or becomes 3.5 material.


I'm pretty sure you can't do this while maintaining post protection
for the delete action without adding some tremendous hack to delay the
deletion until a second post request, or by making the original delete
link a POST form submit.  Neither of these is really 3.0 material IMO.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PloneErrorReporting

[Alec Mitchell]

On 3/25/07, Hanno Schlichting <[EMAIL PROTECTED]> wrote:

Hi,

Alexander Limi wrote:
> Could we please remove PloneErrorReporting from Plone 3.0?

+1, as the current official maintainer I took the liberty to remove it
from the release and the bundle. One stupid thing less to take care of :)


Hanno,

I thought you were the one that added it to 2.5 on the grounds that it
had been in some past releases.  I think getting rid of it is a fine
idea.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Re: The big 3.0 ;)

[Alec Mitchell]

It's a fundamental HTML form issue.  No matter what the name of the
field (e.g. even if it has a ':boolean'), if the checkbox is not
checked then the input is not included in the request (so the value
won't be changed).  It may be possible to use a hidden field with a
False value, so that something is always submitted.  IIRC Zope will
interpret two fields with the same name as a list of values (even
without ':list').  So a hidden field that is False and a checkbox that
is checked will give [False, True] which will evaluate to True in a
boolean context, but an unchecked checkbox and a hidden False value
will just give the False value from the hidden field.  If that doesn't
work, then I think js is the only way to do this without introspecting
the schema to see what boolean fields may have been missing from the
form.

Alec

On 3/23/07, Alexander Limi <[EMAIL PROTECTED]> wrote:

On Fri, 23 Mar 2007 14:40:46 -0700, Geir Bækholt · Plone Solutions
<[EMAIL PROTECTED]> wrote:

>
> On 23. mar. 2007, at 13.03, Wichert Akkerman wrote:
>
>>> Who removed JS from checkboxes when?
>>
>> I did that, it worked correctly for me (and the old javascript did not
>> work with in-place edit iirc). I haven't tested why it doesn't work for
>> alex.
>
> I believe this is just a matter of adding hooks for the zope-typecasting
> syntax :boolean and it'll work again.

That's what we thought too (and I believe that was what was done), and it
doesn't work. If you can prove otherwise, please do.

--
Alexander Limi · http://limi.net


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Base tag

[Alec Mitchell]

On 3/10/07, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Geir Bækholt · Plone Solutions wrote:
> On 9. mar. 2007, at 17.22, Laurence Rowe wrote:
>
>>> I would vote for keeping the base tag anyway, as it would make the
>>> site not break if someone makes a wrong link somewhere.
>>> Another possibility to help this would be to make all folderish
>>> content redirect to get the trailing slash, like Apache does.
>> +1 on redirecting
>>
>> Historically the Zope mantra has been to return data rather than
>> redirect to save the overhead of processing an extra request. Plone
>> is a complex application and I suspect this overhead is negligible
>> compared to rendering a page. Matching Apache's behaviour would
>> make things conceptually simpler.


Also squid/varnish should be able to cache permanent redirects for all
users.  We just need to make sure we don't render the full page and
then redirect, which I don't think we're too careful about presently.
The redirect should also set a variable which causes the rest of the
template to stop rendering if possible.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: Fwd: [Framework-Team] Re: beta1 release timing

[Alec Mitchell]

On 3/8/07, Wichert Akkerman <[EMAIL PROTECTED]> wrote:

Previously Alec Mitchell wrote:
> On 3/8/07, whit <[EMAIL PROTECTED]> wrote:
> >
> >>
> >>  - Consider some kind of compitability alias mechanism, so that when
> >> people keep using getToolByName(context, 'portal_types') we translate
> >> that to getUtility(ITypesTool), for as long as we need to (but still
> >> warning).
> >+1... I mean chrissakes.. getToolByName was supposed to be future
> >proofing for this day...

That probably was before people started using interfaces and the CA :)

> Indeed and if the choice had been made to use named utilities
> getToolByName could just be a shorthand for
> getUtility(IBaseToolInterface, name).  As it is, it could still be
> made an alias for getToolByInterfaceName, though that's a little
> silly.

getToolByInterfaceName requires a dotted interface name, which is quite
different. Some tools already need to become a named utility or use marker
interfaces (our three catalogs for example).

Some arguments in favour of not using getToolByName:

- it allows you to do fun things like have local versions of utilities
  in your site
- it allows us to move tools out of the content space, reducing the
  clutter you see with FTP, WEBDAV and in the ZMI and making it possible
  to use non-persistent tools

to do that people should also stop using acquisition to get to a
tool and always use a utility function.

Of course we can keep getToolByName around for compatibility as a simple
wrapper around getUtility, taking advantage of the utility registry we
already have. This means that packages/products which include a tool
will need to add a little registration magic, but all usage of those
tools will just keep working. So there might not be a good reason to
deprecate it, aside from the fact that CMF does and we do not want to
stray too far from their practices.

> >+100 and someone should blog or write a tutorial about these changes
> >and how to utilize them.
>
> Another +100

We need that for all changes, not just this one.


To clarify, my +100 was to whit's +100, not to the tutorial
suggestion.  Though of course documentation is an unquestionable good.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Fwd: [Framework-Team] Re: beta1 release timing

[Alec Mitchell]

On 3/8/07, whit <[EMAIL PROTECTED]> wrote:


>
>  - Consider some kind of compitability alias mechanism, so that when
> people keep using getToolByName(context, 'portal_types') we translate
> that to getUtility(ITypesTool), for as long as we need to (but still
> warning).
+1... I mean chrissakes.. getToolByName was supposed to be future
proofing for this day...


Indeed and if the choice had been made to use named utilities
getToolByName could just be a shorthand for
getUtility(IBaseToolInterface, name).  As it is, it could still be
made an alias for getToolByInterfaceName, though that's a little
silly.


> Removing in 3.5 sounds completely unrealistic to me. If we find that
> by 4.0 most third party products that count (i.e. would be otherwise
> compatible) have been fixed, we can consider removal.
>
+100 and someone should blog or write a tutorial about these changes
and how to utilize them.


Another +100

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: A short update on performance

[Alec Mitchell]

On 3/7/07, Rocky <[EMAIL PROTECTED]> wrote:

On Mar 6, 9:05 am, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Previously Rocky Burt wrote:
> > On Mar 6, 4:52 am, "Alexander Limi" <[EMAIL PROTECTED]> wrote:
> > > - TypesTool in CMFCore - adding the threadlocal cache makes that part
> > > close to three times as fast, even after the recent Zope 2.10 fix. I think
> > > we should do this, as we already subclass TypesTool, and adding the
> > > optimization cache here is a quick win.
>
> > Yeah, theoretically the change should go into CMF's TypesTool and not
> > hours.  Perhaps if someone has time (not me at the moment) we could
> > submit a patch to the CMF group we just override in Plone.
>
> Why not optimise this in Zope? That is where the bottleneck is.

Making it work efficiently in zope is one thing.  Caching it to go
beyond imho is just not something Zope should be responsible for.
>From Zope's standpoint the call only takes a few milliseconds and is
only called a few times.  It's CMF that is calling it a zillion times
(why?).  So it is CMF that should avoid making so many calls... if
that means caching in CMF, so be it.


I'm 100% with rocky here, the major inefficiency he introduced is
resolved.  Checking the availability of particular factories has
always been one of our weak points, and ironically the huge slowdown
he introduced made it clear how we can do even better.  The
fundamental issue is not that product lookup is slow in zope, but that
CMF uses the Product lookup mechanism as a registry without any sort
of caching.  This is quite easy to fix either in Plone or in the CMF
depending on the timeframe we need it merged in for.  I initially used
a thread local for safety because I wasn't entirely sure what sorts of
things would end up in this cache.  However, by now it's pretty clear
to me that an instance level cache should be perfectly safe, which
should be a little faster yet.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Inline editing

[Alec Mitchell]

As one who compulsively clicks and highlights things while reading
them, I'm very much against single click edit. :-)  Then again, ui
decisions shouldn't be made based on the idiosyncrasies of weirdos
like myself.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: branching moment

[Alec Mitchell]

I'm +1 for keeping 3.0 on trunk until the RC phase at least.  People
wanting to do feature development post-freeze can do so on branches.

Alec

On 2/26/07, Alexander Limi <[EMAIL PROTECTED]> wrote:

+1 on keeping it until the release (or the RCs at the very least)

On Mon, 26 Feb 2007 07:54:07 -0800, Martin Aspeli
<[EMAIL PROTECTED]> wrote:

> I'd say even wait until the release is out. We don't really want to
> have an svn switch frenzy with things going into the wrong places when
> people are fixing last-minute issues with the RCs. I *believe* this is
> how it's been done in the past (branch on release date), but I may be
> wrong.
>
> Martin
>
> On 2/26/07, Wichert Akkerman
> <[EMAIL PROTECTED]> wrote:
>> With beta1 coming out soon I am wondering what the best moment would be
>> to branch off Plone 3.0 and open a new trunk. At the moment my
>> preference is to hold off until rc1 to make sure all attention stays
>> on 3.0. I would love some other opinions though.
>>
>> Wichert.
>>
>> --
>> Wichert Akkerman <[EMAIL PROTECTED]>
>> It is simple to make things.
>> http://www.wiggy.net/   It is hard to make things
>> simple.
>>
>> ___
>> Framework-Team mailing list
>> Framework-Team@lists.plone.org
>> http://lists.plone.org/mailman/listinfo/framework-team
>>
>>
>



--
Alexander Limi · http://limi.net


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: five.intid and object_implements index in Plone 3

[Alec Mitchell]

On 1/10/07, Rob Miller <[EMAIL PROTECTED]> wrote:

Alec Mitchell wrote:
> On 1/10/07, Rob Miller <[EMAIL PROTECTED]> wrote:
>> Alec Mitchell wrote:
>>
>> <--SNIP all the discussion about five.intid-->
>>
>> > Instead, why not make a simple addon product (with a simple GS
>> > profile) that installs these dependencies and the necessary utils and
>> > indexes, and attach it to a PLIP for 3.5?  Having intids would be
>> > great, but it would be better if it came along with a real zope 3-ish
>> > reference solution, not more portal_catalog bloat for convenience, and
>> > there's certainly no time for that now but it's probably a great thing
>> > to hack on in Sorrento.  :-)
>>
>> i pretty much agree w/ this, although i do think that adding an
>> object_implements index to the catalog (i thought it was there
>> already?) is A
>> Good Idea, and is low enough impact to be reasonable to do now.
>>
>> i'm even planning on refactoring membrane at some point to be able to
>> use this
>> interface, instead of needing the much slower "object implements or is
>> adaptable to" interface that it's currently using.
>
> I agree that an extra index would not be too bad to add, my only worry
> about it is that it might mean that we end up satisfied with half a
> solution to an important problem that probably deserves a bit more
> thought (and should really be solved at the zope level IMO).  Half a
> solution in the wrong place is better than no solution anywhere, as
> long as it doesn't end up discouraging development of a full solution.

having an object_implements index is generally useful in many ways, i don't
see it as "half a solution to an important problem" as much as a handy tool
that aids in solving many different problems.

-r

p.s.: did you mean to take this off of the framework-team list?


Oops, no I didn't; I'll send this to the list though as it contains
the full discussion.  :-)  I agree that it is very useful to have, but
I still think Zope needs and will eventually have a more general
solution for this sort of thing (along with the adaption aspect as
well), it's really essential.  That shouldn't prevent us from doing
something useful for us now of course.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: five.intid and object_implements index in Plone 3

[Alec Mitchell]

On 1/10/07, whit <[EMAIL PROTECTED]> wrote:

Martin Aspeli wrote:
> Hi Whit,
>
> On 1/10/07, whit <[EMAIL PROTECTED]> wrote:
>> Martin Aspeli wrote:
>> > Hi guys,
>> >
>> > I'm toying with the idea of introducing five.intid as a dependency for
>> > Plone 3. Whit is responsible for this creation, so I'd like this input
>> > as well, but from discussions with him it seems quite useful.
>> >
>> > - It can be combined with Zope 3's catalog implementation
>> > - It can act as a generic reference catalog
>> s/reference catalog/uid catalog/
>>
>> it is a catalog of references(keyreference object to be exact), but to
>> create an content object -> content object reference system ala AT
>> reference lite, we would need to whip up a bit more(though not too
>> much).
>
> Oh, yes, true. Well, a content object could potentially store a list
> of int ids its referencing, could it it not?
>
> Are int ids stable when objects move? Are modified?
>
> What about export/import?
they should be stable for both iirc. (if not, events should be able to
maintain this)
>
>> > - We (I) could simpilfy plone.app.redirector a little bit by using it
>> > instead of a custom path storage (well, the storage would still need
>> > to be there to remember where things used to be, but it would be a bit
>> > more standards-based)
>> my brain is tickled but I can't remember why
>
> :-)
>
> Just because I stole your code and concepts doesn't mean I can't take
> all the credit. ;)
/me laughs.

you deserve the credit ;)

I should remember the code better. I'm just glad someone salvaged it...
>
>> > - We could use intids in more generic places like that fabled
>> > selection widget. That is, we don't have to rely on context.UID().
>> >
>> this is a biggee.  In wicked, which hopefully soon will do all of it's
>> "relational" behavior internally, I've moved to only accessing uid via
>> an interface(IUID, a string or integer).  This opens up the ability to
>> say, make wicked links to AT content and listen content(done w/ plone
>> schemas).
>
> Yeah, that's my biggest win as well. Plus, it standarises us on what
> Zope 3 is using (more or less).
>
>> > - Add a subscriber for Products.CMFCore.IContentish, so that it takes
>> > care of all content
>> +1 to using IContentish, or maybe even constraining the interface more.
>> I discovered a ton of headaches as tried binding the subscriber from
>> IPersistent on inwards;  Plone and CMF do alot of ugly things with
>> persistence in site creation; intid is based on an object having an oid
>> and is subscribed to object create, therefore depends on fairly normal
>> ZODB behavior or you get ugly lowlevel errors.
>
> Right. I would've thought IContentish was safe, but we obviously need
> to test.
>
>> > - Does it work well with portal_factory?
>> seems to work ok... I would like to see more investigation.
>
> Cool. portal_factory basically clones objects in funny ways, so ids
> may change between the in-factory and out-of-factory objects. Still,
> that ought to be ok.
>
what do we currently depend on portal_factory for? any possibility we
could move to a fate style addforms by 3.5?(different topic)
>> > - Does it give any noticable overhead (looks OK to me)?
>> as long as the subscriber are reasonably constrained.
>
> My thought too.
>
>> > - Is it using Zope 2.10 or Zope 2.9's local component registrations
>> > (should be easy to fix up anyway)?
>> I wrote it against 2.9 so it's probably using that utility reg routine.
>
> Believe so. Anyway, doing it in 2.10 is easier :)
>
>> my main concern is getting five.intid hammered on and probably at this
>> early stage, not piling too many irreversible dependencies upon it.
>>
>> my reasoning: Much of what is scary to me about this code adapting intid
>> to zope2 is what made it so nice for mfaasen writing it in zope3.  It
>> works at what ends up in Plone being a very low level and during
>> development, when things broke, you couldn't even create a plone
>> site(plone site creation alerted my to a myriad of possible issues with
>> keyreferences and the myriad of things you can do with a
>> transaction).This got fire tested because during it's development I
>> was working with multiple other developers who just wanted to work on
>> site ui(was a real headache on a couple of occasions).
>>
>> I had to work very hard to get keyreferences and acquisition to play
>> nice.   Due to the tight relationship with the persistence mechanism,
>> when things do go wrong, you are often looking at errors upon
>> transaction commit rather than in the code that is causing the error.
>>
>> so that is my caveat emptor.  wiggy informed me that the cheeseshop link
>> for five.intid is broken. I'll try to fix this up, but otherwhise, just
>> do an svn pull for most current version.
>
> So how tested/stable would you say it is? Did you hammer it in the
> real world, or do you think there are problems you don't know how to
> resolve or areas which are largely untested?
>
real wo

Re: [Framework-Team] Re: [Plone-developers] Revisited: Some preliminary Plone 3.0 profiling results

[Alec Mitchell]

On 12/10/06, Justizin <[EMAIL PROTECTED]> wrote:

On 12/10/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:
> Alexander Limi wrote:
> > Breakdown of document_view shows (same order/units as above):
> >>> path: plone_view/globalize   0.232   10  0.0232
> >> path: plone_view/globalize  0.4314  10 0.04314
> >
> > path: plone_view/globalize  0.3136  10  0.03136
> >
> > Seems to have speeded up globalize a bit too, but still slower than my
> > initial benchmark (although I think it does more now).
>
> The only additional thing it does is to calculate hash keys. It works
> like this:
>
>   - globalize() defers to the views in plone.app.layout.globals,
> plone_context_state and plone_portal_state.
>
>   - these views have various methods (most of which are called in
> globalize()) which calculate values (previously calculated in
> globalize()); the methods are memoized in the request. Thus, they are
> only calculated the first time they are called and then stored in a
> cache bound to the request.
>
>   - The cache is keyed on a hash (using the Python hash()) function of a
> tuple that includes the context (if applicable), the view class name,
> the method name and the arguments to the method (if any). I don't know
> how expensive this call is, but it's the only thing I can think of that
> would be slower (there are also three view lookups in globalize(), using
> getMultiAdapter(), but I doubt they are the source of the slow-down).
>
>   - On subsequent calls to these methods in the plone.app.layout.globals
> views, the cache key is recalculated and the value looked up in the
> cache, if possible
>
> If anyone can suggest a faster, but still reliable, key, the code is in
> http://svn.plone.org/svn/plone/plone.memoize/trunk/plone/memoize/view.py
>

So, I was poking around this evening trying to decide where to go wrt
PageCacheManager and MemcachedManager, and I came across:

  zope.app.cache.ram.py

RAMCache in Zope3 is not thread-specific, and this code is in Zope 2.10.

Based on the cache keys you are using zope.app.cache.ram.RAMCache and
MemcachedManager should work properly, possibly giving increased
performance.


This code isn't about a RAMCache which lives across threads and
requests, but is a short-lived cache which is bound to a particular
request.  It's purpose is to make multiple calls to the same
methods/attributes in a given request use the same data, e.g. to
relpace the elemts in global_defines (now @@plone/globalize) with a
more general, transparent, and reusable way of making potentially
expensive calls repeatable for a given request.  It would certainly be
possible to use a RAMCache for this but it would probably be overkill,
simply because it would be need to be keyed in a very general way (per
user, per context, per view, possibly per time of last content change
for navigation related methods).  In other words, if we were using a
more general cache we'd need to use a much different and more complex
set of keys.  Of course, these cache decorators can easily be
rewritten at any time to use a different storage mechanism if that
turns out to be desirable, probably with no changes needed to code
that makes use of them.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Some preliminary Plone 3.0 profiling results

[Alec Mitchell]

On 11/14/06, Alexander Limi <[EMAIL PROTECTED]> wrote:

On Tue, 14 Nov 2006 06:14:38 -0800, Martin Aspeli
<[EMAIL PROTECTED]> wrote:

> This is some portlets BBB stuff for people with main_template
> customisations that make globalize do slightly silly things. We could
> probably cut that out if we don't mind breaking some customisations.

This seems to be a recurring theme. How about we ship Plone with a skin
layer plone_unoptimized that enables all these old uses of Plone overrides
that work in 1.x/2.x, but not let it be enabled by default, and put a big
"If you are experiencing problems with older products, you can enable the
plone_unoptimized layer as a transition strategy until your products and
customizations have been updated"?


For this case such a thing is complete overkill, all we need to do is
rewrite the existing default portlets so that they don't depend on
global_defines stuff, and fully utilize the new portlet machinery (so
classic.pt is never used).   This is not a large task.  Legacy
portlets will still work via classic.pt, but they will slow down the
site.  Maybe we can have an optimized_classic renderer for classic
style portlets that don't depend on global_defines crap even.

The portlets hardly depend on the global defines stuff at all, and
when they do it's only the least expensive bits of it.  Calling it for
every portlet is absurd, allowing old products to continue running by
calling it is acceptable (a deprecation warning should be issued for
all non-optimized classic portlets).

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP 178 review

[Alec Mitchell]

On 11/5/06, Wichert Akkerman <[EMAIL PROTECTED]> wrote:

I did a quick review of PLIP 178. This is based purely on the output
from:
  svn diff -r 11240:HEAD \
  
https://svn.plone.org/svn/plone/CMFPlone/branches/plip178-back-to-icons-as-images

which gives you a list of all changes from the trunk. I have not tried
to run the code.

PLIP 178 modifies the icon handling in templates to use img elements
instead of CSS classes. The icon is determined by calling a new getIcon
method on IPlone. This will try to adapt the object IContentIcon, a
simple adapter which returns all icon information. This approach makes
icon handling very flexible.

I have a few remarks on the implementation, most of which are trivially
fixe:

* folder_factories hardcodes the icon size; it should use the icon size
  as provided by the IContentIcon interface

* livesearch_reply does not set the width and height attributes on the
  img element; it probably should. For AAA reasons it probably should
  set an (empty?) alt attribute as well.

* I am wondering if there are there possible use-cases for still keeping
  the contenttype- CSS classes?


At least for BBB these should be kept (though how do you deprecate
something like this), it's quite likely people are using these classes
for some purpose.


* The interface for getIcon describes the return value as a
  dictionary, which is not true: it is either a dictionary or a
  IContentIcon instance. It should describe the the mandatory and
  optional attributes in the returned object, as well as what will
  be returned if there is no icon.

Finally something to think about: if we're extending things anyway,
would it be useful to add an option to request the icon in different
sizes? I can image that at some places in the UI you want to have a
large icon instead of a small one.


+1 we might as well gain some flexibility while revamping things.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Not possible to publish page in current bundle

[Alec Mitchell]

Looks like somebody tried to make the actbox_url in the workflow
transitions get utilized without handling the existing default values
(which point to non-existant forms).

Alec

On 10/13/06, Alexander Limi <[EMAIL PROTECTED]> wrote:

Try clicking State -> Publish on the front page on a fresh 3.0 install:

Zope has encountered a problem publishing your object.
Cannot locate object at:
http://localhost:8080/3.0/front-page/content_publish_form

--
_

  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



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: PLIP review overview

[Alec Mitchell]

On 10/5/06, Wichert Akkerman <[EMAIL PROTECTED]> wrote:

Previously Alexander Limi wrote:
> On Wed, 04 Oct 2006 16:53:06 -0700, Wichert Akkerman
> <[EMAIL PROTECTED]> wrote:
>
> >  PLIP 168 - integrate iterate for checkin/checkout/staging
> >
> >   Viewing a locked front page gave an error until the page was checked
> >   in.
>
> I was working with a customer, deploying iterate and CMFEditions earlier
> this week, and found it very impressive. I did make the following notes of
> things I'd like to see fixed:

[.. long list ..]

Thank you in advance for filing those at
http://plone.org/products/cmfeditions/issues ;)


Actually they are all iterate issues, the CMFEditions developers won't
be able to make heads or tails of these. ;-)

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP145 Locking - Review

[Alec Mitchell]

On 9/25/06, Helge Tesdal <[EMAIL PROTECTED]> wrote:

1. Overview
===
PLIP145 Locking

http://plone.org/products/plone/roadmap/145

2. Test setup
=
I wasn't actually able to test the review bundle now with Zope 2.10 from
SVN, so I'm basing this review on the demonstration during Archipelago
sprint and looking at code.


I wasn't able to test it either, but I looked at the code extensively.


3. How does it work
===
When editing content, an event is fired, and an event handler sets a
WebDAV lock to prevent concurrent editing. When editing ends or is
cancelled, an event is fired, and an event handler removes the WebDAV
lock. I believe you can also remove stale locks.

4. State of code

Implemented using view, events and event handlers. Not a lot of code (or I
missed some code), fairly easy to get an overview of and modify.


The existing code is a bit too invasive into Archetypes for my liking.
I think there are quite a few places where the CA could be used
instead of patching AT.  Of course this is partly because thingslike
events fired on add and edit didn't exist when the code was written,
and neither did the potential of content-providers and viewlets.
Hopefully instead of patches into AT, we can add extension points in
AT as needed and use those for this product.


5. Suggested improvements
=
This needs to be made compatible and aware of iterate. Event naming
conventions has to be harmonized with iterate. Furthermore, it should not
be possible to easily remove the lock set by iterate on the published
content (or locks set by any other applications for that matter). Check
the comments section of the PLIP page for specifics.


Yes there is some real overlap between these two, and we need to make
sure they fit together well.  The same goes for CMFEditions and the
existing history viewing support (though I neglected to mention it in
my comments there), the fancy ajax code for history support can
probably easily be grafted into CMFEditions to ensure we have a
consistent user experience.


6. Recommendation
=
+1 to including this in Plone 3 - provided the suggested improvements are
done.


I'm +0 for now because of my reservations about adding so much usecase
specific code directly into the Archetypes framework.  I think its
very important that we begin to consider the potential importance of
non-AT content, and not hinder plone by tying more core functionality,
which should be available to all types if possible, to that framework.
However, I'd be surprised if the team that created this code wouldn't
be willing and capable of decoupling it from AT.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PLIP168 Iterate - Review

[Alec Mitchell]

On 9/25/06, Helge Tesdal <[EMAIL PROTECTED]> wrote:

1. Overview
===
PLIP168 Iterate provides in-place staging in Plone for improved editing of
published content.

http://plone.org/products/plone/roadmap/168

2. Test setup
=
This was tested with Zope 2.10 from SVN and the review bundle.

svn co https://svn.plone.org/svn/plone/review/plip-168-iterate Products

3. How does it work
===
The action menu has a 'check out' option, to create a copy of the published
content. On checkout, an event is fired, and a reference linking the copy
to
the original is added. The copy has 'check in' and 'cancel checkout'
actions.
When checking in, an event is fired, and the published content is replaced
by
the edited copy.


The working copy has a marker interface applied on it which can allow
for other sorts of differentiation from the original (hopefully for
workflow, see below).  There is some reasonably easy to understaqnd
janitorial stuff that goes on during checkout/checkin for handling
references and the uids involved in a sane way.


4. State of code

Great. Cleanly laid out, customizable by adapters and events. Very
confidence
inspiring.


Yeah, it's really nice I must say.


5. Suggested improvements
=
When I tried to view the locked front page I had made a copy of, I got an
error and was unable to view the page until I checked in the copy. Didn't
look into it - assuming it's a minor issue, but has to be fixed before
merge.


This is a bug in Zope 2.10 apparently, which Kapil has a fix for.  It
does not affect 2.9


There are a couple of items in the todo list that will hopefully get some
more
attention if iterate is included in Plone 3, but iterate is useful in
Plone 3
even without those items.


Yes, I found that it was quite useful and relatively polished.  It
needs a little ui polish, and I think it's important that the working
copy of an object should not necessarily have the same workflow/state
as the published copy.  In particular checking out a published object
creates another publiched object called copy_of_blah, which seems
quite undesirable.  Though I wouldn't say this is critical for
inclusion, I think it is important functionality and development time
should be directed toward it as available.


6. Recommendation
=
+1 to including this in Plone 3.


Yes a non-counting +1 from me as well.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: FW: Plone site compromise epidemic!

[Alec Mitchell]

To say these sites are "compromised" is a bit extreme.  People who
were allowed to create profiles (i.e. this only happens to sites where
anybody can join) could take advantage of a minor XSS vulnerability to
seed google requests.  Additionally there was a apparently more common
avenue of attack for sites where normal self-joining users could add
content, whereby they could put arbitrary html in a File object and
have it render inline, scripts and all (which has more potential for
danger, as the portrait issue was manily visible only for search
engines).  These issues are both fixed.  In the end the abuse is only
a tiny bit more significant than the ubiquitous forum and blog spam
found all over the web.

Alec

On 9/14/06, Alexander Limi <[EMAIL PROTECTED]> wrote:

It has been fixed, that's what the 2.5.1 and 2.1.4 releases were about.

Full instructions are here:
http://plone.org/documentation/how-to/clean-up-link-spam-on-your-site

-- Alexander

On Thu, 14 Sep 2006 16:54:25 -0700, Alan Runyan
<[EMAIL PROTECTED]> wrote:

>
>
>  Alan Runyan
>  Enfold Systems, Inc.
>  http://www.enfoldsystems.com/
>  phone: +1.713.942.2377x111
>  fax: +1.832.201.8856
>
>
> -Original Message-
> From: Sean Duffy [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 13, 2006 10:45 AM
> To: [EMAIL PROTECTED]
> Subject: Plone site compromise epidemic!
>
> Hi,
>
> I have seen a recent flood of compromised Plone sites.
>
> A Google search for the terms plone_memberdata and viagra:
>
> http://www.google.com/search?q=portal_memberdata+viagra
>
> generates over half a million hits.  Someone should look into changing
> the 'out of the box' security settings & set up some hotfixes.
>
> Help!
>
> Sean
>
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>



--
_

  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



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: first comments on plip 148 (moving to CMF 2.1)

[Alec Mitchell]

On 9/13/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Indeed. My feeling is that GS has some evolution to do before it's
truly a solid replacement for what we currently do (which grantely
isn't so solid) - maybe we're just replacing one set of design
problems with another; not because GS is badly designed, but because
I'd argue that product install/uninstall isn't what it was designed to
do. Still, having used GS on b-org and partially on Ploneboard, it's
quite obviously a very useful way of doing installs (workflows, for
example, are senseless to do in Python).


I would say the same is true of:

FTIs
actions
portal permissions
tool properties (portal_properties, portal_factory, ...)
resource registry config
default content
probably a bunch of other stuff that I can't think of off-hand

However, I think we certainly need a way to preserve AT's automatic
procedural FTI setup, probably for as long as AT remains a viable
framework for product development.  However, any helper methods to
allow doing so should be in AT, not in Plone IMO.  And no
monkey-patches should be involved if at all possible.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: hard dependency on PIL?

[Alec Mitchell]

On 9/13/06, Raphael Ritz <[EMAIL PROTECTED]> wrote:

Wichert Akkerman schrieb:
> Previously Alec Mitchell wrote:
>> It's not possible to start Plone if PIL is not installed currently
>> (due to the member image fix).  PIL is included in all the installers
>> AFAIK, and is a package in every distro I've known.  So installing PIL
>> is generally as easy as installing python (whether you use your distro
>> packages or sompile from source).  It can also be as easy as doing:
>>
>> easy_install -f http://www.pythonware.com/products/pil/ Imaging
>
> That is actually not true: the success of that command is bound to be
> highly dependant on the development packages of the various graphic
> toolks you have installed.
>

that's what I meant by saying earlier that PIL isn't necessarily
trivial to install. But anyway, I consider my original question
answered: it wasn't introduced on purpose in the first place but
now that a security-related issue depends on it anyway (the
portrait checking) people are willing to accept this.


When I introduced the dependency for the portrait fix in 2.5 and 2.1
it was fully intentional.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: first comments on plip 148 (moving to CMF 2.1)

[Alec Mitchell]

On 9/13/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Hi,

> > As I said, I'm still wary of using GS as the main install mechanism,
> > even if the quickinstaller can now find them thanks to Hanno. The
> > uninstall question is still unresolved as far as I can see, in cases
> > where you need custom cleanup code, and the
> > re-run-all-import-steps-every-time idea scares me - it depends on
> > every extension profile being well-behaved with respect to
> > re-installation, which it very well may not be.
>
> Because Hanno's solution uses the QI, it has the same uninstall
> features as the QI, regardless of whether the install was procedural
> or done using GS.

I don't think Hanno's solution has an uninstall script (yet). As I
understood it, it can deal with the case where QI auto-uninstalls
things like FTIs and workflows, but not where you need to write an
uninstall() method of your own.


Perhaps not, but it's not as if this is a difficult thing to add.  In
fact I would be a little surprised if adding an Extensions/Install.py
with only an uninstall method didn't work already.


> The repeatability of install steps is important,
> but it was true for procedural installs with the QI too,

Was it? There is some ambiguity as to whether a re-install meant
re-initialise or don't re-initialise. Anyone who assumes it means
re-initialise when they write a custom GS import handler (the
out-of-the-box ones are fairly well-written, thankfully) will need to
ensure that their handlers are re-runnable without side-effect.

Basically, GS makes the re-install button a bit meaningless. If you
re-install a traditionally installed product, it calls
uninstall(reinstall=True); install(reinstall=True). If you re-install
a GS based product, it'll have to re-run all the import steps for
every GS-installed product. If I click re-install on Poi, it'll
re-install listen as well. That means that neither Poi nor listen can
really do any kind of re-initialisation upon re-install.


Hm, yes the QI makes it possible to really differentiate the reinstall
from install, bt practically no products that I have seen make
explicit use of this functionality (just as very few actually bother
to make custom uninstall methods).  During reinstall the default QI
uninstall essentially does nothing besides mark the product as
uninstalled, and the QI install method does the exact same thing it
did on plain install, unless it explicitly checks the reinstall
parameter (which is rare from what I've seen).  The big difference is
that in procedural installs it was common to check if something exists
before adding it, and skipping it if it does (this will likely be true
of the procedural handlers in GS installs since the same peope will be
writing them), but XML based installs do not do such checks, and that
is where problems might come in.


>I don't see
> the issue really.  If one has non-repeatable install steps in their GS
> profile they will figure it out very quickly dring development in my
> experience.

You have a lot more faith in third party developers than I do :)


It's not about faith, it's just very difficult to make a product
without having to reinstall it a couple of times.  If something breaks
on reinstall because certain handlers are not repeatable it will kind
of halt development, no?


The other issue, of course, is whether it's acceptable to tell people
to re-write all their install scripts. Again, we're talking about
breaking almost every third party product out there today if we
*require* GS (of course, supporting it where it's already in use is
great).


Because the solution is based on QI, people can continue using QI
based installs as long as they like (or until we deprecate it, which I
think there are no plans for currently).  I think the benefits of GS
based installs are pretty self evident, and people who like that kind
of thing will start using them.  Is anybody really talking about
requiring only GS based installs for this release?  The most we could
do is deprecate non-GS installs for removal in 4.0, and it's not clear
to me that we're even ready to take that step.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: first comments on plip 148 (moving to CMF 2.1)

[Alec Mitchell]

On 9/13/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Thanks for the summary, Raphael,

> 1. try by any means to support the "old" behavior (maybe
> the fti registering could be done by AT's process_types
> instead of CMF's ContentInit (I might actually try that
> - time permitting)
>
> 2. Switch to using GS for AT at least internally now!
>
> Anyone up for 2?

Switching all content types to use GS is fairly nasty. If they would
all break anyway for various other reasons, fine, but then we're
saying that 95% (or so) of third party products available today will
not work with Plone 3.0. That's fairly depressing.

As I said, I'm still wary of using GS as the main install mechanism,
even if the quickinstaller can now find them thanks to Hanno. The
uninstall question is still unresolved as far as I can see, in cases
where you need custom cleanup code, and the
re-run-all-import-steps-every-time idea scares me - it depends on
every extension profile being well-behaved with respect to
re-installation, which it very well may not be.


Because Hanno's solution uses the QI, it has the same uninstall
features as the QI, regardless of whether the install was procedural
or done using GS.  The repeatability of install steps is important,
but it was true for procedural installs with the QI too, I don't see
the issue really.  If one has non-repeatable install steps in their GS
profile they will figure it out very quickly dring development in my
experience.


I haven't gone through all the code to try for myself, but in *theory*
I would've thought that AT had enough information to construct FTIs
already. That is because we call registerType()  gets passed the class
and can extract the FTI metadata. installTypes() should be able to
just manually construct FTIs by looking at portal_types to ensure
uniquness, creating the necessary FTI object and settings its values.
At the end of the day, and FTI is just a class that you _setObject()
onto portal_types.


Yeah, an FTI is just a persistent object in the types tool that
implements a specific set of interfaces.  CMF certainly doesn't requie
GS to create these things, though some of the convenience APIs for
doing this are now gone, it's not so hard to do anyway AFAICT.  I
would suggest however that e.g. ArchGenXML start generating GS
profiles automatically for workflow and fti stuff, which would help
make it clear that the old AT magic class variable way is no longer
the "right" way".

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: Re: PLIP 48 review notes

[Alec Mitchell]

On 9/12/06, Alexander Limi <[EMAIL PROTECTED]> wrote:



On Tue, 12 Sep 2006 16:34:33 -0700, Alec Mitchell
 wrote:

> We need to make sure that it can be easily disabled in case the
> performance overhead of using Sessions is too much for some
> applications.

Does anyone have any idea what approach people like Google (Gmail etc) use
for their implementation? It certainly seems like the most sensible
implementation out there wrt. to end-user usability - and I'm pretty sure
it scales too.

Is the session overhead a Zope-specific problem because of the
implementation there, or is it something with using this approach
inherently?


Zope sessions are notoriously and, many think, unnecessarily heavy.
Though any session setup that is ZEO-compatible is going to be even
heavier.  One can use pound which ties a session to to a particular
ZEO client in order to avoid the extra overhead, but Zope sessions are
still relatively heavy AFAIK.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] [AJAX] - Bling vs. KSS round 1

[Alec Mitchell]

On 9/12/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Hi guys,

So, prepare yourselves. :) I'm going to try to break down the Bling and
KSS conundrum in a few different sections below. I think it's important
that we think through these issues, and that we get some debate going
fairly quickly. This is holding up other work, as you know.

First of all, I think we need to acknowledge that AJAX isn't something
we can just take lightly. We're talking about putting a lot more logic
into our front-end than what we've done so far, by making pages more
reactive, but also more complex. I've come to accept that there will be
a trade-off of features, flexibility and aesthetics.

1. Getting the bundles set up
=

I'd urge you to look at the code for yourself. Here's how to get it set up.

1.1. Bling
--

According to Limi, the new ZPT implementation in Zope 2.10 is causing
some problems with Bling. However, the bundle uses Plone 3.0 which
depends on Zope 2.10. I'm using 2.10 for now. I'm also using Firefox, no
luck with Bling in Safari.

svn co https://svn.plone.org/svn/plone/review/bling-plip-121-122-bundle

There are only Zope 2 products here. The non-standard bits are a custom
branch of Archetypes (for automatic validation and quick-edit mode) and
the Bling product, which provides various demos and the custom code.

The templates document_view, event_view, global_contentviews and
portlet_calendar are subject to skin customisations in Bling/skins.

You need to quick-install Bling.

Verify that bling.js is enabled in portal_javscripts - I had some
trouble with it.

Things to try:

  - Double-click the title, description or body text on a Page (e.g. the
front-page). You should get the inline editor. For the body text, you
should get a rich editor (tinyMCE not kupu, it's simpler).

  - Click the view, edit etc tabs - they *should* load without re-loading
the whole page. For me, this doesn't work, though. :-(

  - portlet_calendar I think is meant to have no-page-reload
next/previous month, but this doesn't work for me - I just get the
portlet rendered out-of-context when I click on it.

  - Edit an Archetypes field object, and get a validation error on a
field (e.g. leave title blank) after moving away from it. For me, at the
moment, this  is throwing a SiteError (which gets rendered *into* the
validation error box).

  - Add here/portlet_tags/macros/portlet to right_slots or left_slots.
Add a tag in the text box and press Enter. However, this results in a
SiteError for me at the moment.

As you can tell some things don't work. This is probably because of the
Zope 2.10 issue. Ben is rumoured to be working on fixes, though I'm not
willing to wait any longer to get this review work started.

I will describe Bling's architecture in more detail later, however.

1.2. KSS


The KSS bundle works on Zope 2.10, I used 2.10 svn from two weeks ago.
I've used both Safari and Firefox.

svn co https://svn.plone.org/svn/plone/review/kss-base-bundle

You will also need the Plone 3.0 bundle, as the KSS bundle does not
reference it directly in its Externals.

(if you get errors on startup about ChimeraAzax you probably have an
older bundle. Just remove this product, it's not that useful for the review)

Again, these all go in Products. There are no branches of CMFPlone, AT
or anything else. Instead, there are some overrides.

ATAzax customises AT's 'widgets' directory. The livesearch product
re-registers livesearch.js to use a KSS version. PloneAzax overrides
global_statusmessage, portlet_recent and portlet_calendar.

You need to quick-install PloneAzax, ATAzax, livesearch and
KSSMasterSelectWidget to see all the demos.

Things to try:

  - Calendar next/previous buttons reload inline

  - Click a contentviews tab (the green ones) - it should load inline.
Note that there is no feedback that it's thinking and it will take a few
seconds, so on first attempt, it'll seem like it's not working. This is
obviously a weakness (Balazs has said he will add a generic "spinner" soon).

  - Edit a Page and try to leave the title blank, then tab away from it.
You should get a validation error message. Note that validation is only
enabled for StringWidget at the moment. (I don't think it's hard to do
the validation for other types, but it does require that the AT widget
templates are touched to add a particular CSS class, see below. For now,
the KSS guys only did StringWidget as a demo).

  - Add a KSS Master Select Widget Demo Type object to see the
master-select widget in action. Obviously, this is just something for
demo purposes, not really related to any PLIP or necessarily important
for Plone

  - Do a LiveSearch. It should work as before, but it should be using
the 'livesearch' product which is KSS backed.

  - Open one browser window showing Plone, then open another. In the
second window, add a new object to a folder. Go back to the first
window, and wait a while (about 1 minute). Eventually, the "rece

Re: [Framework-Team] Re: PLIP 48 review notes

[Alec Mitchell]

On 9/12/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Wichert Akkerman wrote:

> I don't see any objections to merging it. The security benefits
> certainly make it a good idea.

+1 from me as well - I've needed this in the past, and I don't think
people quite understand the implications of SessionCrumbler, which is of
course the default now.

We need to get a good story together on the ZEO clustered session
storage though.


We need to make sure that it can be easily disabled in case the
performance overhead of using Sessions is too much for some
applications.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: hard dependency on PIL?

[Alec Mitchell]

On 9/12/06, Helge Tesdal <[EMAIL PROTECTED]> wrote:

On 3:12 pm 09/12/06 Martin Aspeli <[EMAIL PROTECTED]> wrote:
> I think a dependency is probably OK, even though it would annoy me to
> have to do it for all development instances. The swinger for me is
> the recent security problems that we've had to use PIL to get around.

Is it possible to disable member portraits if PIL is not installed?


It's not possible to start Plone if PIL is not installed currently
(due to the member image fix).  PIL is included in all the installers
AFAIK, and is a package in every distro I've known.  So installing PIL
is generally as easy as installing python (whether you use your distro
packages or sompile from source).  It can also be as easy as doing:

easy_install -f http://www.pythonware.com/products/pil/ Imaging

If you don't want to use distro packages.  If someone can point to a
sane way to make the import conditional without reopening the spam
hole, that would be great.  But, it's not really possible AFAICT to
tell whether member portraits are going to be a problem or not at
startup time.  Perhaps we can have a config flag that when disabled
makes the image check/transform a no-op, but that doesn't seem too
helpful as it still requies monkeying with the source.  The spam issue
is too serious to allow the fix to be disabled automatically if PIL is
not present (whatever warning we show during startup will likely be
ignored).

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: first comments on plip 148 (moving to CMF 2.1)

[Alec Mitchell]

On 9/12/06, Raphael Ritz <[EMAIL PROTECTED]> wrote:

Hanno Schlichting schrieb:
> Hello from the St. Augustin sprint :)
>
>
cheers from Berlin to all of you ;-)
(I wish I could be there ...)
> [..]
>>- Is it really necessary for AT/ATCT to still use the deprecated
>>  "manage_*" hooks instead of proper event subscribers?
>>  If the plan really is to also support Zope 2.11 with Plone 3.0
>>  this will cause trouble.
>>
> This is related to the biggest TODO item that I wasn't able to solve.
> While I tried to convert at least all cataloging infrastructure in
> Archetypes (and ATCT) to use events, I failed miserably on it and didn't
> have any time to look into this again. The current state is IMO not
> acceptable as it uses an ugly trick to not catalog items multiple times,
> which is to check if an object is already cataloged before indexing it
> and if it is still in the catalog before unindexing it. You can see
> behavior in the reindexing tests in Archetypes, where quite a few new
> indexing calls happen.
>
>
so who do we ask to take a look? Ben, Kapil, Sidnei, ...


I think we need to accept that for the time being at least we will
need to move back to an implementation that catalogs multiple times
per transaction in the wordt case.  Hopefully over the course of the
release we can do our best to minimize that, and possibly implement a
listener that uses end of transaction hooks to help.


[..]
>>- /extra2/Zope-2.10.0-b2/lib/python/zope/tal/talinterpreter.py:754:
>>  DeprecationWarning:*** *** Insertion of non-unicode non-ascii text
>>  in TAL is deprecated and will be broken in Plone 4.0 !!!
>> [..]
>>
> You might have noticed that I put quite some ugly patches into Plone
> trunk to deal with our mixed encoding situation. These patch into the
> guts of the Zope3 tal machinery, as it was the only way to get non-ascii
> characters working again right now.
>
>
OK, better working with a warning than not working at all


Yeah, this is a very thorny issue, though I'd say the warning message
should be a bit more adamant and say that we require uncode
everywhere.  Otherwise we are inviting a mix of unicode and ascii,
which, while guaranteed to work, is far from ideal IMO.  It's just a
matter of wording though
...

>>  What would be really nice to have for our add-on developers:
>>
>>- a hands-on, fool-proof guide on how to update 3rd-party products
>>  for Plone 3.0. In particular this should contain (pointers to)
>>  instructions on supporting and using GenericSetup and the new
>>  style action handling. I'm sure Hanno has gained much experience
>>  on this by doing it for Plone/AT/ATCT so he should be in an
>>  excellent position to sum that up ;-)
>>
> I'm sure I can write something up here, especially the common pitfalls I
> encountered. Luckily it's not too many changes but writing a product
> that works with both old-style and new-style actions is probably not an
> easy task or not possible at all.
>
Not sure it makes much sense to require both.
Old-style actions have been deprecated since CMF 1.5 I think.


Certainly not, most product developers and integrators should never
have to know about or worry about this change.  Generally the only
time one deals with the action API is when installing a product.  GS
fortunately makes knowledge of the underlying APIs unnecessary, so
generally only the framework bits should have to worry about this.
For people customizing bts of the framework that deal with actions,
the changes needed should be pretty self-evident IMO.


>>- An just in passing: is there really no sane way to fix
>>  'installTypes' from Archetypes.Extensions.utils?
>>  This will break **a lot** of 3rd-party products!
>>
> I'm sure there is a way, I just didn't have time to fix it. Help is
> welcome as always ;)
>
OK, I might take a look at this one myself.

I just find it somewhat funny that Plone 2.5 - which was advertized
as a "framework release" - didn't require much from add-on authors
to deal with while 3.0 - advertized as a "UI release" - looks like it
it's causing quite a change ...


Indeed, this will be a huge step for both Framework and UI, which is
why it's 3.0(!) after all.  It's important that we not get ambitious
beyond the manpower we have.  Nonetheless this CMF 2.x change is very
critical as far as I'm concerned, though so far only Hanno has had the
inclination to work on it


>
>>  Summary for now: I think it is no question that this PLIP has to be
>>  accepted as otherwise we would not catch up with our underlying
>>  framework (the CMF). I consider it ready for merge as soon as there
>>  is enough confidence in a 2.1 release of the CMF itself (at least an
>>  alpha out). The only open question I see is whether we really want to
>>  make PIL a hard dependency.
>>
> Actually I think unless we have fixed the Archetypes event story at
> least to an somewhat acceptable state, this PLIP should not be merged.
> We need 

Re: [Framework-Team] first comments on plip 148 (moving to CMF 2.1)

[Alec Mitchell]

On 9/12/06, Raphael Ritz <[EMAIL PROTECTED]> wrote:

Hello again,

this is just a service to those of you who do not follow the svn/plone
commits ;-)

2006-09-12  Raphael Ritz ([EMAIL PROTECTED])

  My test set-up: Python 2.4.3, Zope 2.10.0b2 release on Linux (FC5)

  First impression: excellent work Hanno

  Issues noticed so far:

- there is a hard dependency on PIL in CMFPlone/utils.py
  Do we really want that?


As of 2.5.1 there is a hard dependency on PIL in CMFPlone to ensure
proper validation of member portraits (and the scale them, which is
nice also).  So this is not something I'd be too concerned about.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] [PLIP144 Next/Previous] - Background and observations

[Alec Mitchell]

On 9/3/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Hi guys,

Since we need to get going, I thought I'd start with an easy one.

1. Overview
===

PLIP144 - Generalised Next/Previous Navigation, aims to make it easier
to navigate between items in a folder. The typical use case is a folder
full of photos, where you want to be able to go to the next or previous
photo without having to go up to a folder listing.

...

5. How does it work
===

CMFPlone.browser.interfaces.INextPreviousProvider looks like this:

class INextPreviousProvider(Interface):
 """A folderish component capable of describing the next and previous
 item relative to a particular id.
 """

 def getNextItem(oid):
 """Returns the next item in the container

 oid is the id of the current object being viewed.
 """

 def getPreviousItem(oid):
 """Returns the previous item in the container

 oid is the id of the current object being viewed.
 """

 def isNextPreviousEnabled():
 """Checks if the container has next / previous navigation
enabled"""

There is a general adapter from ATFolder to INextPreviousProvider which
can get the next and previous item in a folder. The 'enabled' status
comes from a new field in the ATFolder schema, found in
ATContentTypes.content.schemata.NextPreviousAwareSchema.


I would suggest that a pattern using a multi-adapter on context and
the folder might be a bit more flexible.  In particular for the case
of something like a smartfolder, where the id of the object may not be
sufficiently unique to determine which entry is being looked at.
Also, generally speaking when you have an adapter for which nearly
every method takes an argument that is related to some other object,
it is likely that what you want is a multi-adapter.  Otherwise this is
a great feature and the implementation I saw of it at the sprint
seemed (superficially at least) quite lovely.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] [AJAX] Please digest ...

[Alec Mitchell]

On 9/2/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:

http://azax.ree.hu/documentation/development-process-with-kss

 From Balazs and Godefroid, many thanks! This is a pretty short document
describing a real-world example of development with KSS.

It's probably good if we all read this and form some opinions on this
process.

However, if we can, I'd like to keep the discussion on whether this is
good or bad under wraps until I can produce the first email comparing
the two approaches (hopefully tomorrow unless things go badly). This is
just so that we don't start with a very one-sided discussion and find it
hard to come back to objectivity.


I just read it earlier today, and my opinion is that it is awesome. ;-)

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Now what do we do?

[Alec Mitchell]

On 9/1/06, Alexander Limi <[EMAIL PROTECTED]> wrote:

On Thu, 31 Aug 2006 10:52:21 -0700, Encolpe Degoute
<[EMAIL PROTECTED]> wrote:

> Our team wishes to highlight PLIP 154 as we think it is nearly
> implemented by FileSystemStorage + AttachmentField (still SVN).

By the time Plone 3.5 ships, it's highly likely that Zope has proper BLOB
support, and this will no longer be an issue. Zope 2.11 (the current
target) may even have a beta out by the time we ship our first betas, and
depending on the changes, we could possibly support both Zope 2.10 and
Zope 2.11 - we have been able to support two zope releases in all our
releases since Plone 2.0 so far.

While I think what you are doing is great, it feels like the wrong layer
to solve it at when it comes to embedding something in the core.


+1 to holding off on this (though like limi's, my vote doesn't count for much)

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: Let sleeping PLIPs lie...

[Alec Mitchell]

On 8/22/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:

Hi,

> http://plone.org/products/plone/roadmap/117 (AJAX dep)
> http://plone.org/products/plone/roadmap/116 (AJAX dep)
> http://plone.org/products/plone/roadmap/163 (AJAX dep)
> http://plone.org/products/plone/roadmap/124 (AJAX dep)

All of these are fairly obvious. There will naturally be tweaking and
iterations of the implementation, but I think that these types of
improvements can sometimes be done on trunk rather than in branches
where they either would affect several other branches (e.g. a new widget
that several new features may need) or where they are straightforward
and/or easily reversible (e.g. a template change can be reverted without
serious dependency breakage).

Let's see what does come in time for the deadline, but if some of these
don't, I'd be +1 to seeing them done afterwards *provided* that the beta
and RC deadlines are taken seriously!

Pragmatically speaking, as Limi points out, it's also a bit unfair to
penalise these PLIPs when we haven't got the AJAX story sorted out yet.
There is still too much uncertainty to start on any of these in earnest.

> http://plone.org/products/plone/roadmap/175 (sleeper PLIP)

This is a kind of meta-PLIP. Yes, we need more control panel pages. :)
Having people add them a bit later in the day should be fairly low-risk
though. It's only slapping a nicer UI on features we already have!

> http://plone.org/products/plone/roadmap/126 (sleeper PLIP)

Link type improvements would be nice to have, but needs a champion.

> http://plone.org/products/plone/roadmap/132 (limi was wrong)

I believe Florian was onto this as well (getIcon improvements). Again,
it's not terribly controversial.

> http://plone.org/products/plone/roadmap/176 (visual redesign pending)

If this is too invasive, it may be a bit risky and impact a lot of other
PLIPs. If the changes are relatively minor or gradual, they may be OK.
This sounds like branch work, though. :)

> A special one is:
> http://plone.org/products/plone/roadmap/134 (too important to be
> dropped, needs champion - also relatively easy to do)

We need a champion for this, badly. It's an important feature, and I've
seen a lot of users confused by the lack of editor/viewer local role
management on the sharing page. It's also relatively straightforward, it
just needs a person in charge. :-(


I would say that anything that doesn't have something valuable ready
by the PLIP review deadline should probably only be allowed in at the
sole discretion of the release manager.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Here a wiggy, there a wiggy

[Alec Mitchell]

On 8/9/06, Wichert Akkerman <[EMAIL PROTECTED]> wrote:

Previously Martin Aspeli wrote:
> Now that Wichert has been officially selected as release manager (and I
> whole-heartedly endorse that decision, he is a great choice), I'm wondering
> what that means for us.

The fact that I'm supposed to be one of the people advising me is a bit
odd. This makes me feel that perhaps the fwt should look for someone to
replace me. At least I'll withhold from voting in order to not have
conflicting roles.


I would say that your job as release manager doesn't really start
until after the Framework Team's job ends (e.g. after they give you
recommendations on products).  The fact that you are one of the people
involved in creating consensus on those recommendations isn't a
tremendous conflict in my mind.  However, if you are more comfortable
not participating, or participating only in case of a tie, that would
not be unreasonable.

Alec

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team