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

[Martin Aspeli]

On 26 February 2011 20:06, Alec Mitchell  wrote:
> 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.

+1 -  I found myself nodding a lot reading that wiki page.


> 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.

+1 also - 6 months feels about right. Time tends to fly!

Martin
___
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

[Martin Aspeli]

On 10 February 2011 04:00, Eric Steele  wrote:

> 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


+1 to all of that too :)

Martin
___
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

[Martin Aspeli]

On 16 January 2011 21:07, Geir Bækholt  wrote:
> On 14-01-2011 22:24, Elizabeth Leddy wrote:
>>
>> Whaddup FWT -
>>
>> I would like to get a conversation going about reworking the PLIP
>> process. We had some good conversations on IRC about making the process
>> mor continuous so I want to formalize the discussion a bit. Here are my
>> initial thoughts on how to revamp the process coupled with some
>> reactions to the current process:
>
> Another comment from the sideline, not from the FWT. I think these are very
> sane ideas and will help us do what we need: Smaller releases more often!
> From a marketing perspective, Plone really needs to show that there is a lot
> happening, — and one of the most important ways of doing that is making
> releases.
>
> The deadline-model we are currently using do not seem to work well enough to
> keep the pace up, even with the awesome efforts we have seen from release
> managers.
>
> Martin's concerns are valid, but i believe they can be overcome, and IMO
> they are far outweighed bu the benefits of the new proposed model.

I suspect they can be overcome by release managers setting target
dates, asking people to contribute to a particular milestone date for
a particular planned release, but not holding up a release if people
slip. Many smaller deadlines can be better than fewer big ones.

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

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

[Martin Aspeli]

Hi Elizabeth,

This is a little tl;dr for my current state of flu, but I wanted to
make one point: I, for one, need deadlines to get around to doing
things. Specific release dates and well-thought-out PLIP timetables
really help me structure my work and get things done and plan.

A slightly more cyclical approach may also allow for natural attrition
and replacement of FWT members.

Anyway, not necessarily disagreeing with you, but I feel these are
important points.

Martin

On 14 January 2011 21:24, Elizabeth Leddy  wrote:
> Whaddup FWT -
> I would like to get a conversation going about reworking the PLIP process.
> We had some good conversations on IRC about making the process
> mor continuous so I want to formalize the discussion a bit. Here are my
> initial thoughts on how to revamp the process coupled with some reactions to
> the current process:
>
> In general, let's move away from the fixed timeline of announcing,
> gathering, reviewing plips and towards a continuous integration of new
> features.
> Allow plips to be submitted at any time. Initial reviews would then be done
> on a fix times basis (e.g every two weeks). Dev can than begin at any point
> after approval. The important thing here is to be responsive. I think we can
> make up for the "deadline" motivation by just responding quickly.
> Plips are then submitted for review when they are done, not by date (to
> prevent untested/half done features from coming in). Small plips will
> obviously get through this process faster and then won't get held up by
> larger plips.
> Set a fixed time to do an initial review of each plip. For example, after a
> plip is submitted for review we "promise" that X team members will look at
> the plip within X weeks. It seems messy but I think this would be much nicer
> than the current blech of reviewing 8 plips in one month (eek!). This also
> means that FWT members who are particularly busy can opt out of reviewing
> particular plips for a short amount of time without having a slow down
> impact on the review process.
> FWT discusses status of plips that are submitted, in review, etc... every X
> weeks - consistently!!! This way things are always moving in all aspects of
> the process. This also prevents the "do we have a call today?" issue.
> After initial reviews, if the plip is going to be merged, assign it to a
> release. Give the developer X amount of time to respond and clean up any
> remaining issues such that it will be ready for merge without holding tup
> the release. This way if there are a LOT of changes that need to happen,
> just assign it to the next release and let things get done properly without
> having to go through the whole process again.
> Final reviews would be a followup of suggested changes/bug fixes and final
> confirmation before merge. I found the review process very confusing this
> time and would find it helpful to define what exactly an initial/final
> review is and where/when it fits into the process. A clearly documented
> process in general would be really helpful for everyone I'm sure.
> I also suggest that we add more people to the team, even if its just in a
> sense that they only do reviews. Maybe these are official "guest reviewers".
> These "guest reviewers" should be consistently participating and recognized.
> The consensus was that we wanted 3 reviews on every plip, which we didn't
> get with the current team. So let's fix it :)
> Somewhat related, I felt pretty uncomfortable voting on a plip which I did
> not personally review. If someone else did the initial review, then say I
> did the final review, I would have a much better opinion on the plip. If
> each plip gets 3 initial reviews, and then we have 2 OTHER people do the
> final review, we get 5 eyes on the plip and 5 votes on inclusion (5 also
> prevents ties).
> In order for the above to work well, I think the initial review discussion
> phase of each plip should have a product: a definitive list of exactly which
> bugs/tasks MUST to be completed to be merged (and what is nice to have).
> This is similar to the review process for a science paper. If they finish
> they tasks by date X correctly, then there is a 95% change it will be merged
> in release X. It's a lot easier to finish a feature with a tick list.
>
> This will also obviously require some sort of place to keep track of things
> but I don't see this as any huge overhead. The spreadsheet worked just fine
> for the current process and it would be a great jumping point for this. We
> could even make it public (gasp!) so that developers can see where their
> plip is at any time and how it's being received.
> I don't now if these changes have to affect the release cycle or not.
> Initially I don't think they need to but I can see how switching to a fixed
> time release schedule (Ubuntu style) could fit in nicely.
> The main issue I see with all this is the lack of "deadline" motivation but
> I really think that setting up a process where we promise to gi

Re: [Framework-Team] Plone roadmap

[Martin Aspeli]

On 21 October 2010 22:55, Chris Calloway  wrote:
> On 10/6/2010 2:17 PM, Jon Stahl wrote:
>> We already have mass upload, via collective.uploadify.
>>
>> We seem to have at least some work on mass download, via
>> http://plone.org/products/zipfiletransport
>>
>> I'm sure both could use refinement.
>>
>>> And search/replace-all TTW.
>>
>> http://plone.org/products/goreplace
>>
>> Seems like all of these could benefit from some
>> attention/love/polishing/PLIPing.
>
> These are all add-on products, not Plone. Plone already does these
> things via WebDAV. Taking WebDAV away means taking this function out of
> Plone and having to install products to get the function back, which
> leads to pain when products stop getting attention/love/polishing as
> they do. And these kinds of things are core to content management, not
> really add-on behavior.

I think the point was that *if* we decide to (have to?) drop WebDAV
support, we'd need to integrate these products or something like them
into Plone proper as a replacement for functionality we currently
support in the core.

Martin
___
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

[Martin Aspeli]

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.

Martin
___
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

[Martin Aspeli]

On 21 September 2010 10:42, Wichert Akkerman  wrote:

> On 9/21/10 10:49 , 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?
>
> I find email a much more natural discussion medium than trac or textfiles.
>

Well, email is certainly better than text files. :-)

I think the mailing lists are great for general discussion about the merit
and implementation specifics of a given PLIP. For the "official" FWT votes
and comments ("to be accepted, you must do X"), though, we need something a
bit more permanent and a bit easier to find. Trac comments work well for
this kind of thing.

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

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

[Martin Aspeli]

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?

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

[Framework-Team] PLIP for Plone 4.1 - plone.app.caching

[Martin Aspeli]

Hi folks,

Eric asked me to submit a PLIP for 4.1 to include plone.app.caching:
http://dev.plone.org/plone/ticket/11065

I haven't added a buildout yet, but you can test with the KGS at
http://good-py.appspot.com/release/plone.app.caching/1.0b1

If people agree with the idea of including it, I'll set up a buildout (I'd
like to fix a test failure first, which was caused by some recent changes to
use plone.app.registry a bit more efficiently).

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

Re: [Framework-Team] Plone roadmap

[Martin Aspeli]

On 5 September 2010 15:29, Hanno Schlichting  wrote:

>
> - With Zope 2.13 / Plone 4.1 we are cleaning up the "query" interface
> a bit. The catalog's search methods now all want a simple dictionary
> as the query specification and issue deprecation warnings for
> everything else.


Can I ask why we need to do this? It seems like an obvious use case for
keyword arguments, and this is a pattern we've been documenting and
promoting for a long, long time.

+1 to removing the REQUEST magic, though.


> Quite a bit of code will need to be updated to avoid
> using keyword arguments, passing in requests objects or mixtures of
> all of these. This will make it easier to switch to a different
> implementation later on, as we can keep the query syntax intact.


We could do that with a query syntax based on kwargs as well, of course. ;-)


> We
> have also deprecated the insane "empty query" behavior of the catalog.
> So far any query which didn't result in any index restriction returned
> the entire catalog content. Starting in Zope 2.14 you get an empty
> result instead.
>

+lots to this and everything else


> - Get a new plone.indexing package or extend plone.indexer to do the
> job of collective.indexing. Especially create indexing events which
> are managed by an index manager instead of relying on mix-in classes.
> This will replace object.reindexObject() and similar calls, CMF's
> CatalogAware and the various catalog multiplex solutions. This will
> need a rather long deprecation period as these calls are all over the
> place.
>

They are all over the place, but rarely customised/subclassed, so one thing
we can probably do is make some of these no-ops.

- Once we have intid's we can change the internal unique id of the
> catalog from the physical path over to an intid.


Perhaps we should consider using UUIDs instead of intids?


> - Once we have parent pointers we can probably ditch storing metadata
> in the catalog and load objects directly.


Why do __parent__ pointers help here?


> > The Publisher
> > -
> >
> > The Zope2 publisher has become incredibly complex, with numerous
> > different hooks. In the long run (Plone 6?) we should replace it with
> > our own simplified publisher which runs only in a WSGI pipeline. There
> > will be a lot to learn from BFG here, though that is probably too
> > simplistic for Plone.
>
> Concrete things I'd like to see:
>
> - Get a new round of community experimentation with WSGI now that's
> inside Plone 4.1. We have seen some good interest while repoze.zope2
> was new and shiny.


+1 - the downfall of repoze.zope2 was that it kept drifting out of sync with
Zope 2 and Plone.


> Hopefully wrap these things up and have Plone 4.2
> come with an official documented WSGI story. If things go well we can
> make WSGI the only supported deployment option for Plone 5. This
> should get us out of the business of maintaining a web server, but
> will also likely mean the loss of FTP and WebDAV support.


I don't think that's a good option. We may not need to support both, but
supporting one is probably quite important. For one thing, it'd kill Enfold
Desktop and similar integrations. WebDAV is also very useful for bulk
movement of images and documents.

Note that Dexterity has a pretty sane, pretty well documented WebDAV
approach. I can't see why it has to be incompatible with WSGI. Very little
of the DAV stuff is actually in the web server or publisher.

Once we have
> a good TTW multi-upload functionality this becomes possible (even
> though some people will complain, but they will need to maintain and
> evolve the code on their own - it's a niche requirement best done as
> an add-on, much like CMIS will be for quite a while).
>

TTW multi-upload certainly helps, but WebDAV has for a long time been our
answer for desktop integration, and I think jettisoning it would be a shame.

Multi-upload doesn't help you uploading a large folder tree with images or
files, downloading the same, opening and saving from desktop apps, etc.


> - Experiment again with a cleaned up request/response object based on
> WebOb. There's some insanities like the support for both getattr and
> getitem to access request values, the whole DTML automagic quote
> behavior and a ton more.
>

I think we can let Plone opt into a "simple" request object that doesn't
support getattr and DTML quoting and various stupid variables (_steps
anyone?).


> I think we have done some steps towards it, for example with
> supporting the standard dict API for accessing containers instead of
> objectIds and friends. If we can move the copy/cut/paste code over to
> a new approach we can avoid most of the manage_ hooks. Once we figure
> out a new pattern to do object construction (the new "invokeFactory")
> things will get easier.


You can use the ZTK createObject() method, which just looks up and calls an
IFactory utility by name. This is what Dexterity does, and it's pretty
straightforward. An IFactory is just a call

Re: [Framework-Team] Plone roadmap

[Martin Aspeli]

On 3 September 2010 17:03, Laurence Rowe  wrote:
> A few more points:
>
> Security
> 
>
> The current AccessControl security model has served us well. While
> some simplification may be possible by dropping unused legacy
> features, no major changes to functionality should be expected.
> Porting to Python 3 will be the obvious time to make any
> simplifications.

I agree that the model is good. However, I've spent more time with a
pdb deep into AccessControl than I'd care to think about. The code is
quite obscure and difficult to debug, even with "verbose security". I
think we need to clean the code up and document it properly. How many
people know how the various permission attributes work, for example?

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

Re: [Framework-Team] Plone roadmap

[Martin Aspeli]

Hi,

On 3 September 2010 15:18, Laurence Rowe  wrote:
> On 2 September 2010 22:16, Martin Aspeli  wrote:
>> Hi Laurence,
>>
>> +1 to everything here.
>>
>> Other big things for me:
>>
>>  - I think we want Deco GUI + Blocks rendering as an optional add-on
>> for Plone 4.x at some point, to get this tested properly.
>
> We certainly want more people to start using it and use it for
> customer projects. It does represent an invasive and radical change
> from the status quo, so it is much more of a risk to include in 4.x as
> a supported add-on than Dexterity for instance. It's certainly
> something we need to talk about more. (And in response to Roel, I'll
> certainly be at the conference and keen to talk about it there.)

I don't think we should say "this is supported". I just think we
should allow the *Deco* documentation to say "you can legitimately
test this with Plone 4.2" or whatever. That means we may need to PLIP
things for 4.x that enable Deco to work well, or "backport" things
that otherwise would be in Plone 5 only, if they can benefit users of
4.x. The reasons to do this would be to reduce the risk of Deco
bitrotting because no-one is able to use it except in
super-experimental setups. It won't be a mainstream option until Plone
5, but some greenfields projects may be able to become early adopters
if we don't make it *too* difficult for them.

>>  - I think we want WSGI as a supported deployment option in 4.x, 5.0
>> at the latest, via the Zope 2.13 WSGI work
>
> WSGI capability will be in Zope 2.13 / Plone 4.1 and while it will
> certainly be considered experimental rather than supported at first, I
> expect people will start gaining experience with it. I'm hopeful that
> we might be able to *require* wsgi for 5.0, but that will depend on
> how things work out over the next year or so with 4.x.

Right. I think this is similar: a legitimate option for those who know
what they're doing and are willing to help build the future.

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

Re: [Framework-Team] Plone roadmap

[Martin Aspeli]

Hi Laurence,

+1 to everything here.

Other big things for me:

 - I think we want Deco GUI + Blocks rendering as an optional add-on
for Plone 4.x at some point, to get this tested properly.

 - I think we want WSGI as a supported deployment option in 4.x, 5.0
at the latest, via the Zope 2.13 WSGI work

Martin

On 3 September 2010 04:39, Laurence Rowe  wrote:
> With the release of Plone 4.0, I thought it would be useful to set out
> my understanding of where we are headed with future releases. This
> draws heavily on conversations with Hanno and focuses on
> infrastructure rather than user visible changes.
>
> The intention is to spark a discussion from which I'll write up a roadmap on
> plone.org or dev.plone.org. All plans are of course subject to change - but
> it is useful to set out a direction.
>
> Over the years, Plone has accrued much code and added many concepts.
> In part this is a reflection of the vibrancy of the project, but it
> has come at a high cost in complexity.
>
> Hanno has been doing heroic work with Zope 2 and the ZTK recently, and
> we will soon be able to completely avoid the large chunks of old Zope
> 2 code we do not use at all.
>
> Acquisition
> ---
>
> Acquisition was introduced because the ZODB did not support reference
> cycles. As a programming paradigm though – at least in the implicit
> form used within Zope 2 – it has been a failure. It is strange and
> unfamiliar to new developers.
>
> It also prevents us from using some natural patterns: the catalogue
> indexes content by path rather than directly; references between
> content must be indirected through a path.
>
> Phillip and Hanno's work to enable Acquisition over __parent__
> pointers (included in Zope 2.12 / Plone 4) has given us a path out of
> our current dependency on it. This has already simplified
> BrowserViews. The next step is to make sure all content has __parent__
> pointers all the way to the application root. We should do this for
> Plone 5 and drop Acquisition entirely in a future version.
> http://wiki.zope.org/zope2/SetParentAndNameInOFS
>
> Catalogue and References
> 
>
> Once all content has __parent__ pointers to the root, we will be able
> to use standard ZTK catalog components. Using zope.intid for the
> catalogue keys allows result sets to be merged across catalogues.
>
> We'll also be able to store relations as simple references on content
> - related items can be stored as a simple list of objects on a piece
> of content. These can then be indexed in zc.relation directly.
>
> Archetypes
> --
>
> Plone 5 should be the last major release with Archetypes
> compatibility. For form based content types, Dexterity is the future.
>
> The Publisher
> -
>
> The Zope2 publisher has become incredibly complex, with numerous
> different hooks. In the long run (Plone 6?) we should replace it with
> our own simplified publisher which runs only in a WSGI pipeline. There
> will be a lot to learn from BFG here, though that is probably too
> simplistic for Plone.
>
> OFS and CMF
> ---
>
> Currently, all Zope2 content inherits OFS.SimpleItem. All Plone
> content also inherits from CMF. In the long run, content items should
> have simple classes with code in views. These are significant changes
> and are likely to be the most difficult.
>
> Restricted Python
> -
>
> This is another confusing hurdle for new developers and should be abandoned.
>
> Form Controller
> ---
>
> Other than the Archetypes edit forms, it would be best to remove all other 
> uses.
>
> Tools
> -
>
> The various tools should become utilities and views. Most of them need
> not be persistent as settings can be stored with plone.registry.
>
> Skins
> -
>
> Old style templates should be replaced with views. CSS/JS/Images
> should all migrate to resource directories.
>
> Python 3
> 
>
> In three to five years time we will have to have moved to Python 3. It
> seems likely that there will be others to help the ZTK porting effort,
> but little interest in porting Zope2. For the time being then, our
> focus should be on progressively removing our Zope2 baggage.
>
> WSGI
> 
>
> Various components should be move out of Plone and into the WSGI
> pipeline. This should allow us to share code with other projects.
> Prime contenders would be:
>
>  * Authentication
>
>  * Resource registries
>
>
> Laurence
> ___
> 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 #10778 (UUIDs) - ready for initial review

[Martin Aspeli]

On 30 August 2010 19:46, Maurits van Rees  wrote:
>  Op 29-08-10 07:24, Martin Aspeli schreef:
>> plone.uuid provides a simple API for generating and accessing UUIDs.
>
> If we use this to create uuids for non-content items, that cannot be
> traversed to, would that give any problems?

No, although the helper function that gets you a (content) item from a
UUID looks in portal_catalog, so you'd need a different mechanism if
you needed that kind of central lookup. The UUIDs will never clash,
though.

> For example, it might be nice to use this to create the secrets that the
> password reset tool sends out, or secrets used in a newsletter product.
> I had a few ideas some months back that may or may not ever get
> implemented. ;-)

For this, uuid.uuid4() is probably fine. What plone.uuid adds is a
(tiny) standard API for looking up a UUID for an object. If you had a
"newsletter" object and you wanted its UUID you could write an IUUID()
adapter for it.

> I'd guess that, as long as such a non-content item with a uuid does not
> end up in the portal_catalog, there is no way to accidentally try to
> traverse to such non-content.

Of course not.

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

Re: [Framework-Team] plone.uuid behaviour

[Martin Aspeli]

On 30 August 2010 18:03, Hanno Schlichting  wrote:
> On Mon, Aug 30, 2010 at 10:16 AM, Wichert Akkerman  wrote:
>> On 8/30/10 01:59 , Martin Aspeli wrote:
>>> On 30 August 2010 08:26, Wichert Akkerman  wrote:
>>>
>>>> Do you expect people to always use that calling convention?
>>>
>>> No, but I expect objects to always have a UUID. :)
>
> Should objects get a UUID when being created inside portal_factory?

This depends.

In the AT branch for PLIP #10778, IUUID(context) behaves exactly the
same as the context.UID(), and the UID is assigned at the exact same
time.

For non-AT objects, portal_factory is probably a non-issue.

> Kapil made a distribution
> (http://svn.plone.org/svn/collective/experimental.portalfactoryfix/trunk/)
> to make most of our code aware of portal_factory and avoid creating
> items in the first place. I think we want to merge this back into core
> and at that point the same logic should apply to plone.app.uuid.

I think the two issues are quite separate, but +1.

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

Re: [Framework-Team] PLIP #10778 (UUIDs) - ready for initial review

[Martin Aspeli]

On 29 August 2010 17:41, Wichert Akkerman  wrote:
> On 2010-8-29 07:24, Martin Aspeli wrote:
>> The principal API is the IUUID() adapter factory, which can be used to
>> return a (byte string) UUID. There is also an IUUIDGenerator utility
>> to generate new UUIDs. The default implementation uses the standard
>> library uuid.uuid1() method.
>
> Please change that to use uuid4() instead. uuid1() uses the unique
> hardware address of the machine it runs on to generate the UUID, which
> means the result UUID can be used to track down the specific machine
> used to generate it. This has been used succesfully to track down people
> and machines, and for that reason everyone has switched to the random
> based approach as implemented by uuid4().

Done.

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

[Framework-Team] PLIP #10778 (UUIDs) - ready for initial review

[Martin Aspeli]

All,

Following our rather lengthy discussion, I've made some changes to
PLIP #10778, which I hope alleviate the concerns associated with this
PLIP.

This is now ready for testing. I've piggy-backed on David's PLIP #9938
buildout (plips/plip9938-output-filters.cfg), since his improved
transforms will use the plone.uuid API to be non-Archetypes-specific.
I've offered to support him in that PLIP, so there may yet be some
changes desired in the PLIP #10778 code (plone.uuid, plone.app.uuid
and the plip10778-plone.uuid branch of Products.Archetypes), although
"on its own", I think this PLIP is now ready for review.

Instead of describing the changes from the "old" code, I'll try to
explain how the PLIP is now structured:

= plone.uuid =

plone.uuid provides a simple API for generating and accessing UUIDs.

The principal API is the IUUID() adapter factory, which can be used to
return a (byte string) UUID. There is also an IUUIDGenerator utility
to generate new UUIDs. The default implementation uses the standard
library uuid.uuid1() method.

plone.uuid provides a marker interface IUUIDAware. Objects with this
marker are expected to be adaptable to IUUID. There is an @@uuid view
which renders a UUID string for an IUUIDAware object. This is useful
in TAL, for example.

plone.uuid also provides a specialisation of IUUIDAware called
IAttributeUUID. Types that provide this interface get an
IObjectCreatedEvent handler that generates and assigns a UUID stored
in an attribute on the object, plus an IUUID adapter that looks up
this attribute.

= plone.app.uuid =

plone.app.uuid provides some Plone policy for UUIDs.

It contains a catalog indexer (using plone.indexer) for IUUIDAware
objects, using the IUUID adapter factory. The indexer name is "UID",
to be compatible with the existing UID index/metadata. Therefore,
there is (no longer) a separate catalog setup step, and no migration
required for existing Archetypes based content.

plone.app.uuid also provides a view, @@redirect-to-uuid, which can be
passed a UUID on the traversal subpath. This is then looked up in the
catalog, before a redirect response is sent to the object's current
location.

There are also some utility functions to find objects by UUID in various ways.

= Archetypes =

The branch of Products.Archetypes makes Archetypes use plone.uuid to
generate its UUIDs. The net effect is that the plone.uuid and
plone.app.uuid APIs work for all Archetypes content (without
migration), but can also be made to work with other objects.

Archetypes objects are marked with IUUIDAware (but not
IAttributeUUID). This makes the indexer, and @@uuid and
@@redirect-to-uuid views work.

UUIDs are still stored (in the _at_uid attribute) and created (by
voodoo-wielding elves) in the same way as before.

The make_uuid() function, which generates new UUIDs, now delegates to
the IUUIDGenerator utility[1]. There is no migration for old content,
but there isn't any need: UUIDs are still strings, and can't collide,
even though technically new content will use a different algorithm. I
did some tests TTW with references created "before" and "after", and
they worked fine.

There is an IUUID adapter factory for IReferenceable (which covers all
Archetypes objects and, insanely, reference objects[2]). This returns
the Archetypes UUID as stored in the _at_uid attribute, just as the
UID() method used to do.

The UID() method now does "return IUUID(self, None)". This means that
if someone wanted to implement a custom IUUID adapter, the UID()
method would follow suit.

In theory, we could probably deprecate context.UID() metod in favour
of IUUID(context) (in Python code) and context/@@uuid (in TAL), but
I'm not sure we'd want to. It's used quite a lot. The plone.uuid way
is more broadly compatible, though.

= Dexterity et. al. =

This isn't really part of the PLIP, but if the PLIP is accepted, I'll
add plone.uuid support for Dexterity objects. That'll be pretty easy:
just mark them with IAttributeUUID. We probably also want a migration
step that grants UUIDs to and re-catalogs old Dexterity content.

Presuming David finishes his work on plone.outputtransforms, this
means link-by-uid to Dexterity content becomes a reality. We can maybe
also make the standard reference browser widget work for non-AT
content. UUIDs also become a viable thing to store for portlets and
tiles that want to reference content.

I also think we should consider adding UUIDs to comments if the
plone.app.discussion PLIP is accepted.

Cheers,
Martin

[1] I also took the opportunity to remove some weird, unused code
attempting to use a Linux kernel UUID generator in /proc.
[2] Whoever though people would *really* need references to references
deserves to be locked in a room with Jeremy Beadle for two days
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Three PLIPs ready for review

[Martin Aspeli]

On 28 August 2010 23:54, Jon Stahl  wrote:
> On Sat, Aug 28, 2010 at 7:41 AM, Eric Steele  wrote:
>> On Aug 28, 2010, at 10:19 AM, Martin Aspeli wrote:
>>> Hi,
>>>
>>> The following are ready for review:
>>>
>>> https://dev.plone.org/plone/ticket/9472 - plone.app.registry
>>> https://dev.plone.org/plone/ticket/9473 - z3c.form
>>> https://dev.plone.org/plone/ticket/10856 - plone.testing
>
> I just want to comment that I am *very* impressed that we have
> reviewable PLIPs for 4.1 before 4.0 is formally out the door.  Nice
> work, Martin!

Mmm, technically these are kind of meta-PLIPs that only talk about the
inclusion of existing packages. I didn't actually do much work beyond
make a buildout. :)

That said, I'm working on the UUID PLIP now ;-)

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

[Framework-Team] Three PLIPs ready for review

[Martin Aspeli]

Hi,

The following are ready for review:

https://dev.plone.org/plone/ticket/9472 - plone.app.registry
https://dev.plone.org/plone/ticket/9473 - z3c.form
https://dev.plone.org/plone/ticket/10856 - plone.testing

They are all testable through the same buildout, since p.a.registry
depends on z3.form and plone.testing and I'm too lazy to crete three
buildouts. :)

This is in the 4.1 buildout under
plips/plip9472-9473-registry-z3cform.cfg. See comments in the file to
see which packages to run tests for (all tests pass here) and which
packages will eventually need to go into the Plone KGS.

Note that plone.registry and plone.app.registry point to branches
which contain some ZODB optimisation work. I've asked Laurence to take
a close look at this, since these changes were largely in response to
his critique. However, I don't think that should hold up review. In
time, I'll just merge these branches to trunk and update the PLIP
buildout.

Cheers,
Martin
___
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 Meeting Minutes - Aug. 24, 2010

[Martin Aspeli]

On 25 August 2010 04:57, David Glick  wrote:
> - 10804: Include workflow manager
>    - based on uwosh.northstar
>    - May need some input from the UI team to make it fit in with the
> rest of Plone's UI

Was this one accepted or rejected?

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

Re: [Framework-Team] PLIP #10961 File uploads to folder_contents

[Martin Aspeli]

On 24 August 2010 20:19, Hanno Schlichting  wrote:
> On Tue, Aug 24, 2010 at 12:16 AM, Laurence Rowe  wrote:
>> On 23 August 2010 18:18, Geir Bækholt · Jarn  wrote:
>>> On 23. aug. 2010, at 16:09, Laurence Rowe  wrote:
 I've added downloading multiple files as a zip archive to the proposal.

>>> Isn't that really something completely different than mass uploading?
>>> Separate plip?
>>
>> I persuaded myself that I could lazily add it to the same PLIP as it
>> could be thought of as part of the same 'story' - using Plone for
>> basic document management if you could upload a bunch of attachments
>> then you should be able to download them. That, and I stole both ideas
>> from Gmail ;)
>
> We had this type of download functionality since Plone 3. The code in
> ATConentTypes was unfinished though and we removed it for Plone 4.
>
> I haven't ever seen anyone interested in this type of feature and
> never seen a user request it.
>
> I would recommend to leave this part out and concentrate on the upload
> functionality. That's something a lot more people actually want.

+1

This is the kind of feature that's more fun to think of and implement
than it is actually useful to anyone. Those who need archive download
functionality usually have very specific reasons for wanting it, and
typically do not want to allow people to arbitrarily pick files from
the folder_contents listing.

Martin
___
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

[Martin Aspeli]

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. :-)

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.

> 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.

> 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
universally applied to all content, it needs to be a service provided
by Plone and in effect for all content and other objects, such as
comments and (possibly) users, groups, etc. Simply depending on the
package and using its API is not enough (if it was, I would never have
submitted the PLIP). At the very least, any and all packages wanting
proper UUIDs would need to provide a blunt installation step to
allocate and index UUIDs for all content, with some logic to
understand when this would be needed. Furthermore, divergent
implementations create non-trivial duplication of effort and catalogue
bloat.

Hanno already indicated he was uncomfortable with this as a
LinguaPlone requirement. So, at least, we have two "big" third party
packages - LinguaPlone and Dexterity - asking for this functionality
so that they themselves can move forward, with a view to improving
Plone core in the future.

The question to me is how we balance the risk of doing "too much" now
in terms of modifying existing core components, against the risk of
doing something that ultimately proves an inferior solution and
doesn't get used properly. I think this is the sort of evolutionary
argument we're always going to have for framework improvement work.

All that said, I think we may "solve" this problem by widening the
PLIP to include more of the AT changes up front, which is probably a
good thing anyway.

Also: this discussion now has more lines of text than plone.uuid and
plone.app.u

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

[Martin Aspeli]

On 20 August 2010 00:26, Steve McMahon  wrote:
> About a month ago, I spent some time with windmill, trying to do tests for
> plone.app.jquerytools.
>
> Windmill looked OK, but when I tried to automate the testing as a test case
> with niteoweb.windmill, I encountered lots of problems and ended up giving
> up on it. It looked like I was having trouble anytime content was changed by
> a test. Perhaps I wasn't patient enough, or misunderstood something about
> the framework, but it seemed at times like I was working in a multi-threaded
> environment where the threads weren't synchronized.

Strange. We've never seen anything to that effect. Oh well.

Martin
___
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

[Martin Aspeli]

On 19 August 2010 23:24, Godefroid Chapelle  wrote:

> First time I hear bad sound about Windmill. Happy that I am no the only
> one not convinced.

I hear "bad sounds" too from time to time, but no-one has yet been
able to tell me what the real problem is. I'd be quite interested in
any specifics.

Martin
___
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

[Martin Aspeli]

On 19 August 2010 16:57, Hanno Schlichting  wrote:
> Hi.
>
> On Thu, Aug 19, 2010 at 4:08 AM, Martin Aspeli  
> wrote:
>> 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.
>
> Please be aware that the link-by-uid functionality is multi-lingual
> aware. As such it relies on looking up the translations of any UID
> target. If you change the behavior to use a different uid mechanism,
> it becomes more expensive to calculate those translations, as we'd
> have to convert from AT UID's to uuid's a number of times.
>
> I'd prefer if we kept all reference / link related functionality to
> use the AT functionality for now.

I'd be very disappointed if we rewrote the link-by-uid feature and
still made it AT-specific. This seems like a step backwards.

That said, I'm sure we could make it intelligent enough to use AT's
UID() as necessary, but also allow other implementations (e.g. based
on plone.uuid).

One way to do that may simple be to let the link-by-uid use
plone.uuid's IUUID interface to look up a UUID, but have an
AT-specific implementation that returns the AT UID. The algorithm's
different, but it won't collide with uuid.uuid1(), which is what
plone.uuid uses.

> Once we have plone.uuid as part of core Plone, I'm planning to rewrite
> LinguaPlone to make use of this instead of the AT uid's. At that point
> we can more easily switch features over to the new mechanism. So far
> as I was hoping to see the plone.uuid feature to make it into 4.1,
> which would give me enough time to finish the LinguaPlone move for
> 4.2.

I guess this is kind of the opposite of what Alec wants. ;-)

> I can only work on this if we do get plone.uuid into 4.1 though.
> Requiring the complete uuid installation as part of a LinguaPlone
> upgrade is too much to ask from users.

Or for anything else that wants to UUIDs, hence the chicken-and-egg problem.

Martin
___
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

[Martin Aspeli]

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.

> 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.

> 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.

I agree with this, and I'm really not shy about keeping packages as
non-core dependencies. In this case, though, I think there are
compelling reasons to have a single API that is exposed as a service
by the core of Plone, as outlined in my original message above.

> 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.

I think we should be in the business of making Plone useful to
customers and integrators. Right now, our story for uniquely
identifying content and other objects (e.g. comments) sucks. It feels
half-baked compared to other CMS's. It makes it difficult to build
services on top of Plone that need to uniquely identify content.

In my previous project, here's where the lack of a proper UUID hurt:

 - We needed to write migrations, and we needed to identify
already-imported content to update or ignore
 - We needed link-by-UID for non-AT content
 - We needed to embed some content references in hidden form fields. A
UUID would've been a natural token here.
 - We wanted to expose certain things over web services that needed a
short token to identify particular content items, which would be
stable even if those items were moved

I know others have had similar concerns. It's difficult to work on
multilingual non-AT content, for example, without having a good UUID
implementation. Some of the w

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

[Martin Aspeli]

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. :)

Martin
___
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

[Martin Aspeli]

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.

Martin
___
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

[Martin Aspeli]

Hi folks,

A few comments on things I'm involved in.

>        • 9473 (z3cform)
>                • Ross: Better than Archetypes at form generation, better 
> documentation than formlib, but still requires a lot of knowledge of the 
> internals to work with.
>                • (Small?) improvement over formlib, extensive (but not very 
> approachable) documentation.
>                • Approachability can be improved with layers on top: 
> autoform, dexterity.
>                • Heavy Plone adoption will likely lead toward better 
> documentation.

I started writing some quite extensive, Plone-oriented, tutorial-style
documentation on plone.directives.form (the Grok-like way to build
z3c.form forms). I think it'd be quite feasible to copy this and
change it to cover the more "traditional" plone.app.z3cform. At the
moment, it's about 80% complete, but a big project + the new edition
of my book got in the way. If anyone is willing and able to run with
this, I'd be happy to assist.

>                • plone.app.registry makes it largely transparent
>                • Approved
>        • 9472 (plone.app.registry)
>                • Is a win for persistent settings storage
>                • Form proxying makes it easy
>                • "It just works"
>                • Needs ui work

I'd like to know what UI work it needs at this point. The
portal_registry UI is basic, for sure, but functional, moderately good
looking, and works pretty efficiently now that we have p.a.jquerytools
overlays. It'd be nice to have a JavaScript based substring match
search, perhaps. Beyond that, though, "proper" UI should go into
dedicated control panels (which p.a.registry helps you build)

>                • Approved
>        • 10776 (Zope 2.13)
>                • Keep up with Zope, don't get behind like we did in the past
>                • WSGI support: Is it ready yet? It's

You mean "it is"? If so: w00t!

>        • 10846 (plone.testing/plone.app.testing)
>                • Looks great
>                • Do we say this is the best practice?
>                        • Wait
>                        • Just including this in our KGS for now should steer 
> people towards it

+1 to this sentiment

>                • Eat our own dogfood. Implement some core package tests using 
> this.
>                        • Does this need its own PLIP?
>                        • We're opening the door for that to show up in the 
> future.
>                        • Great 2010 conf sprint topic

I suggest we just encourage new packages for 4.1 and onwards to use
it. I'd be happy to make plone.[app.]uuid use this, for example.

>                • PLIP could make it clearer how best to encourage movement to 
> new framework over existing framework

I think this needs wider discussion first, but agreed.

>                • Approved
>        • 10778 (Stand-alone UUID)
>                • Required step toward allowing Dexterity to work well in a 
> Plone site
>                • Community confusion that IntIds are unique identifiers, 
> needs to be corrected
>                • Exist as a well-used add-on that Dexterity depends on

Well, not yet, but soon - especially if #9938 makes it - see below.

>                • It's definitely necessary functionality, but is it 
> worthwhile in 4.1 if nothing in 4.1 using it?
>                • Do we say "This is great, please make the package. We'll 
> include it later, when it's in use." ?
>                • Martin's never been afraid to create new packages
>                • Looking for our blessing as the designated way forward?
>                • Small change to Plone (catalog index)
>                • Held

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.

 - It's difficult for third party packages to depend on this kind of
thing (as we saw with zope.intid), because to be useful, it requires a
new catalogue index and a full re-index on existing sites. That's the
kind of thing that people may expect in a Plone .x release, but not
necessarily just to install a product that happens to depend on it.

>        • 9938 (Factor custom output transforms out of editors)
>                • Yes!
>                • Why don't we do this already?
>                • Reduces risk (listed risk is more of a deliverable. ;) )
>                • Approved

I think if we do this, we should also do #10778. One of the big things
I really, really want is proper link-by-uid for Dexterity content. We
can't do that if the link-by-uid transforms use Archetypes' UID(), and
making a new, future-oriented package for this that's tied to AT seems
like a step backwards and an invitation for future migration pain (uid
links end up being embedded in content, after all).

Martin
__

Re: [Framework-Team] z3c.form PLIP?

[Martin Aspeli]

On 9 August 2010 21:31, Hanno Schlichting  wrote:
> On Mon, Aug 9, 2010 at 12:45 PM, Laurence Rowe  wrote:
>> On 9 August 2010 01:52, Martin Aspeli  wrote:
>>> I can own this, although I'm not quite sure what a PLIP should look
>>> like? The actual work is in rewriting the control panel forms. The
>>> only thing the PLIP would say is "ship with p.a.z3cform + dependencies
>>> as a dependency of PLIP 10359".
>>
>> We already have: Include z3c.form - https://dev.plone.org/plone/ticket/9473
>
> Thanks, I was referring to that one and the points it lists.
>
> I think the code for this one is basically done. But it needs a code
> review, needs a review from the UI team on usability of the widgets
> and the generated markup. There's also translation and documentation
> to be updated. Someone knowing the code needs to act as a contact
> person for these things.

I can help with the plone.z3cform and plone.app.z3cform aspects at
least. If specific work needs to go into widgets and markup, I'll need
support with that. I'd be really surprised if the basic widgets were
any worse than formlib, though. :)

> I would also love to see someone bring some stability into the
> plone.z3cform and plone.app.z3cform packages and release proper 1.0
> releases. All the last minor have been backwards incompatible with
> changes in the form wrapping approach (plone.app.discussion has been
> one victim of this, always having to pin versions to one exact
> combination at a time). We cannot do that any longer when these things
> are part of Plone.

That's a shame - and basically a bug. It was meant to be fully
backwards compatible. The change was somewhat painful, but necessary
to bring some sanity to the way we do templates and template
overrides, and making the forms more like regular views and easier to
work with. I think the form wrapping thing was always a mistake, but
then hindsight is a wonderful thing. :)

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

Re: [Framework-Team] z3c.form PLIP?

[Martin Aspeli]

Hi,

On 8 August 2010 20:33, Hanno Schlichting  wrote:
> Hi.
>
> My controlpanel PLIP 10359 (http://dev.plone.org/plone/ticket/10359)
> depends on someone else doing the base work of getting z3c.form into
> 4.1.
>
> There's a PLIP at http://dev.plone.org/plone/ticket/9473 for this, but
> currently nobody stepped forward to actually own it for 4.1.
>
> Are there any volunteers? Otherwise I'll have to withdraw my own PLIP.
> I'm not familiar enough with z3c.form and its Plone integration layers
> to own this base part.

I can own this, although I'm not quite sure what a PLIP should look
like? The actual work is in rewriting the control panel forms. The
only thing the PLIP would say is "ship with p.a.z3cform + dependencies
as a dependency of PLIP 10359".

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

Re: [Framework-Team] Using plone.testing / plone.app.testing in Plone 4.1

[Martin Aspeli]

On 2 August 2010 16:35, Martijn Pieters  wrote:
> On Sun, Aug 1, 2010 at 16:50, Martin Aspeli  wrote:
>> 1) Stay with the status quo, and hope that
>> plone.testing/plone.app.testing become the standard for Plone 5. In
>> the meantime, people can use it in non-core packages only.
>> 2) Use them as test dependencies, and let people choose how to set up
>> their own tests
>> 3) Write a separate PLIP for the inclusion of these two packages into
>> our KGS (but not for the porting of all existing PTC tests, since
>> that'd be a pretty big task)
>
> I'd go with option 3, for the same reasons as Hanno's.

Here we go: https://dev.plone.org/plone/ticket/10846

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

Re: [Framework-Team] Using plone.testing / plone.app.testing in Plone 4.1

[Martin Aspeli]

On 1 August 2010 23:27, Eric Steele  wrote:
> On Aug 1, 2010, at 10:50 AM, Martin Aspeli wrote:
>> Hi team,
>>
>> This weekend, I worked on plone.uuid and plone.app.uuid, part of PLIP
>> #10778 (which is now mostly implemented, by the way). These are both
>> quite simple packages. Obviously, both have tests.
>>
>> When writing them, I wanted to use the new plone.testing /
>> plone.app.testing packages. However, I'm not sure whether this is
>> something we need to PLIP separately or not. Certainly, I think a
>> wholesale move away from PloneTestCase is infeasible for Plone 4.x.
>> However, for new packages, I'd like to use the cleaner, leaner "new"
>> packages. A few good reasons include:
>>
>> * They make test runs slightly faster
>> * They are better documented
>> * They make it easier to make custom layers
>> * They provide better test isolation by not relying on global state
>> * They standardise test setup and patterns, e.g. how to use layers 
>> effectively
>> * They use the new Python 2.7 standard library unittest module (via 
>> unnittest2)
>>
>> The main downside is possible confusion, since we can't deprecate
>> ZTC/PTC at the present time. They're also much younger and less well
>> tested, obviously, although they clearly draw their heritage from
>> ZopeTestCase and PloneTestCase, respectively.
>>
>> I've got the tests to work with plain unittest.TestCase and
>> PloneTestCase, so there's no *pressing* need for this, but equally I'd
>> like these packages to be an example of "good practice". Right now, I
>> feel a bit iffy about using PloneTestCase, since I feel plone.testing
>> provides a better alternative that ought to become commonplace in the
>> future.
>>
>> So, we can either:
>>
>> 1) Stay with the status quo, and hope that
>> plone.testing/plone.app.testing become the standard for Plone 5. In
>> the meantime, people can use it in non-core packages only.
>> 2) Use them as test dependencies, and let people choose how to set up
>> their own tests
>> 3) Write a separate PLIP for the inclusion of these two packages into
>> our KGS (but not for the porting of all existing PTC tests, since
>> that'd be a pretty big task)
>>
>> My preference is for option 2.
>>
>> Thoughts?
>>
>> Cheers,
>> Martin
>
> Nice work Martin. As you know, I'm already using this in a project and 
> absolutely loving it. I'm really excited to try some selenium testing now 
> that that last issue has been fixed.
>
> I think we do need to PLIP the inclusion of plone.testing/plone.app.testing 
> as a dependency. We ran into a similar issue with plone.app.registry and 
> z3c.form when considering plone.app.discussion for 4.0. The FWT wanted the 
> opportunity to give them an official review and also have the opportunity to 
> potentially declare them as current best practice for new features.
>
> I'd certainly love to see all core packages move to using 
> plone.testing/plone.app.testing (death to bin/alltests!), but I agree that 
> it'd be a huge undertaking. I'd like to propose a fourth option -- that we do 
> #3 above, but have the FWT vote on declaring that the current best practice 
> for new packages for 4.1 and beyond.

Sounds good. Once dev.plone.org stops looking like someone
regurgitated a Plone 2 site all over it, I'll add a PLIP. ;)

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

[Framework-Team] Using plone.testing / plone.app.testing in Plone 4.1

[Martin Aspeli]

Hi team,

This weekend, I worked on plone.uuid and plone.app.uuid, part of PLIP
#10778 (which is now mostly implemented, by the way). These are both
quite simple packages. Obviously, both have tests.

When writing them, I wanted to use the new plone.testing /
plone.app.testing packages. However, I'm not sure whether this is
something we need to PLIP separately or not. Certainly, I think a
wholesale move away from PloneTestCase is infeasible for Plone 4.x.
However, for new packages, I'd like to use the cleaner, leaner "new"
packages. A few good reasons include:

* They make test runs slightly faster
* They are better documented
* They make it easier to make custom layers
* They provide better test isolation by not relying on global state
* They standardise test setup and patterns, e.g. how to use layers effectively
* They use the new Python 2.7 standard library unittest module (via unnittest2)

The main downside is possible confusion, since we can't deprecate
ZTC/PTC at the present time. They're also much younger and less well
tested, obviously, although they clearly draw their heritage from
ZopeTestCase and PloneTestCase, respectively.

I've got the tests to work with plain unittest.TestCase and
PloneTestCase, so there's no *pressing* need for this, but equally I'd
like these packages to be an example of "good practice". Right now, I
feel a bit iffy about using PloneTestCase, since I feel plone.testing
provides a better alternative that ought to become commonplace in the
future.

So, we can either:

1) Stay with the status quo, and hope that
plone.testing/plone.app.testing become the standard for Plone 5. In
the meantime, people can use it in non-core packages only.
2) Use them as test dependencies, and let people choose how to set up
their own tests
3) Write a separate PLIP for the inclusion of these two packages into
our KGS (but not for the porting of all existing PTC tests, since
that'd be a pretty big task)

My preference is for option 2.

Thoughts?

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

Re: [Framework-Team] Access to archetypes repository

[Martin Aspeli]

On 1 August 2010 09:50, Alex Clark  wrote:
>
>
>
> On 7/26/10 6:41 AM, in article 4c4d6662.7000...@bubblenet.be, "Godefroid
> Chapelle"  wrote:
>
>> Le 19/07/10 20:48, Geir Bækholt a écrit :
>> On 19-07-2010 19.09, Dorneles
>> Treméa wrote:
>>> +1, status quo
>>
>> I agree. Big +1
>
> I received only +1s
>> :
>
> Since July 2010, 26th, write access to Archetypes repository will be
>>
> granted to each requester (as it is already the case for the collective
>>
> repository).
>
>
>
>
> Since this is the case, does it make any sense to try and commbine the AT
> repo with the collective repo?
>
> That'd mean one less repo to manageŠ

Only if you can keep all checkout URLs and revision numbers 100% the
same, which I think is more or less impossible. Repository moves are
painful for anyone working on the software.

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

[Framework-Team] PLIP submission for Plone 4.1 - Standalone UUID implementation

[Martin Aspeli]

Hi,

Following Hanno's lead, I've submitted a PLIP for Plone 4.1:
http://dev.plone.org/plone/ticket/10778

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

Re: [Framework-Team] Improving the process -- PLIP UI and Documentation

[Martin Aspeli]

2010/5/22 Eric Steele :
> FWT!
>
> I want to introduce two additions to the PLIP process that I'd like us to add 
> into the Plone 4.1 process.

+1 to both

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

[Framework-Team] Re: Plone 5 - rough roadmap

[Martin Aspeli]

Tres Seaver wrote:


The decision is not really in this group's hands, though:  XDV is a
project which has its own life outside of Plone.


Agree - hence my comment that we'd need to seek broader community input.

Before we can do that, we'd need to have a better proposal, though.

And in the meantime, I want a new XDV + collective.xdv release. ;-)

Martin

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


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

[Framework-Team] Re: Plone 5 - rough roadmap

[Martin Aspeli]

Alexander Limi wrote:

On Wed, Mar 24, 2010 at 12:45 PM, Steve McMahon
mailto:st...@dcn.org>> wrote:

How about "Pastiche" ? http://en.wikipedia.org/wiki/Pastiche


Or the simpler http://en.wikipedia.org/wiki/Pastis — which seems
appropriate. ;)

(not being serious here, I also think pastiche is way too hard for most
people to remember the spelling of :P )


Yeah, I don't think that has any advantage over XDV in case of 
discoverability.


Martin

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


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

[Framework-Team] Re: Plone 5 - rough roadmap

[Martin Aspeli]

Jon Stahl wrote:

On Wed, Mar 24, 2010 at 2:38 AM, Martin Aspeli  wrote:

Geir Bækholt wrote:

On 23-03-2010 22.52, Alexander Limi wrote:

+1 to xdv as long as it gets a decent new name. ;)

YES! — And let's make sure to rename it soon, before it gets widespread
mainstream acceptance

If someone has a really great name, I'd consider it, but I think the ship
may've sailed. Renaming now is likely to cause a lot of confusion.


How about something very simple like "Theme Builder"?
(collective.themebuilder).  Short, says what it does, sounds
"approachable."   We can pretty easily refer to it as "Theme Builder
(formerly XDV)" for a little while.

What I learned in the last year at Groundwire (formerly ONE/Northwest)
is that changing the name of something is easier than you'd think, if
the thing you're renaming is something people like and want to work
with. :-)


It's not *quite* that easy, though, because people will have things like 
collective.xdv in their buildouts. If an "upgrade" means installing 
something else, then in the worst case that something else could 
actively conflict with an old installation, and we're in trouble.


It's also not so easy because at least two books in print mention XDV, 
as do three or four tutorials on plone.org.


I think we need a damned good reason to rename, more so than "this name 
is cooler". I also think we should ask the broader community's reaction 
first.


Martin

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


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

[Framework-Team] Re: Plone 5 - rough roadmap

[Martin Aspeli]

Geir Bækholt wrote:

On 23-03-2010 22.52, Alexander Limi wrote:

+1 to xdv as long as it gets a decent new name. ;)


YES! — And let's make sure to rename it soon, before it gets widespread
mainstream acceptance


If someone has a really great name, I'd consider it, but I think the 
ship may've sailed. Renaming now is likely to cause a lot of confusion.


Martin

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


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

[Framework-Team] Re: Plone 5 - rough roadmap

[Martin Aspeli]

Tom Gross wrote:

On 03/12/2010 04:07 PM, Hanno Schlichting wrote:

Hi there,


...

On the "future" side we have:

- Chameleon
- Deco / Blocks
- Dexterity
- WSGI
- xdv as the default theming story


Is there still discussion space to choose between xdv and Deliverance.
I'm not to deep in the subject but I have heard that Deliverance can be
used with other web-applications, but xdv is Plone specific.
If this is true, Deliverance would open Plone to a broader community.


Where did you hear that? It's not correct. ;-)

Deliverance is a Python-based implementation. It is used either as a 
standalone proxy or in a WSGI pipeline. As such, it may be attractive to 
people with a WSGI-oriented stack. It also has more client-side tools 
and is generally broader in scope than XDV.


XDV is an XSLT-based implementation. You compile theme + rules into an 
XSLT, which is then deployed either in a WSGI pipeline step, or in a web 
server like nginx or Apache. As such, it is even broader in scope in the 
sense that it's not tied to Python.


collective.xdv is a Plone control panel + hook to apply an XDV theme 
without the need for a fronting web server. This is a good solution for 
people with no further integration needs. However, the same theme + 
rules can be compiled and deployed as an XSLT if that's desirable.


Probably the most important deciding factor is that XDV is more 
lightweight, overlaps less with existing tools, should be faster, and - 
crucially - has more uptake in the community. With Plone 3 and Plone 4 
at least it's also easier to set up and deploy than Deliverance, which 
ether requires a standalone process that proxies to Zope, or adoptation 
of repoze.zope2 to get a WSGI stack in Zope.


Martin

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


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

[Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form

[Martin Aspeli]

David Glick wrote:

On 3/21/10 12:21 PM, Hanno Schlichting wrote:

Is that a -1 on Martin's dict context / getContent() suggestion?
I'd like to have those forms be good examples of using z3c.form, so
I'd like to use whatever is considered to be best practice. The
use-case is having standalone forms which pull their data from a
different place.


Most z3c.forms I've seen use a pattern similar to formlib forms, where
the form context is adapted to the interface a field came from, and then
values are retrieved/set via attribute access.

I've also done something akin to Martin's suggestion, where getContent()
is responsible for retrieving all the values from the context (and then
memoizing the result), and a custom form action takes care of writing
the values back to the appropriate locations.

The first way probably results in less code in cases where the context
already provides the interface you're using for the form.  The second
way probably results in less code in other cases.  The first way is
easier to override, since the reading/writing is factored out to a
separate component from the form.  The second way is probably a bit
easier for newbies to figure out what's going on.

So I guess it's not clear to me that there is one best practice, or at
least not one that is best in all circumstances.


To me at least, the idea that we pick an arbitrary context (the Plone 
site root) and then write a one-off adapter from that to some schema 
interface that happens to represent the fields we want (the schema is 
almost always form-specific, since we want to control fields, ordering, 
fieldset grouping etc), register it in the CA (even though it's going to 
be used only for the form) and then let the form framework look it up on 
a field-by-field basis seems entirely like CA abuse. It's also quite 
difficult to understand if you're reading the code.


Martin

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


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

[Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form

[Martin Aspeli]

Hanno Schlichting wrote:

Hi there,

I've written a new PLIP that I'll hope to submit for Plone 4.1
"Convert control panels to use z3c.form" available at
http://dev.plone.org/plone/ticket/10359.

I'll start the work on the PLIP shortly, so if anyone sees any major
problems with it or has other suggestions, I'd welcome any early
feedback.


I suggest we use the dict context (implement getContent() and return a 
dict) instead of all those adapters to get/set values as we do presently.


Also, use trunk of z3c.form, plone.z3cform and plone.app.z3cform for the 
time being - important cleanups have happened.



This PLIP is dependent on someone owning the general z3c.form / Plone
integration PLIP (http://dev.plone.org/plone/ticket/9473) - I hope
someone will be up to that task :)


I can at least help, though I'll need to see closer to the actual 
deadline where I can own it.


Martin

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


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

[Framework-Team] Re: Plone 5 - rough roadmap

[Martin Aspeli]

Hanno Schlichting wrote:

Hi there,

with Plone 4 beta 1 out the door and the 4.0 framework team having
done its job, it's time to look ahead into the future a bit.

Eric has started the discussion around Plone 4.1 already, I'll let him
drive that process :)

But I had a look at the PLIP's we have seen and feature discussion we
had in the past.

Currently listed for Plone 4.x are things like:

- Include plone.app.registry
- Include z3c.form
- Improved commenting infrastructure
- Improving the event type with recurrence, etc.
- New roles : Webmaster/site administrator and novice users
- Unified interface for lists of content
- New collections UI
- Well formed, valid XHTML (as a foundation for easier theming via xdv)
- ... tons of new or better features

I think there's lots of good stuff in there. I think with Plone 4.0 as
a new technical basis we need some time to make Plone the product
better again. Image and media handling, better usability, better
support for common tasks, more content lifecycle management, ...
there's a lot we can and should do here. Figuring out what exactly
should be part of Plone Core won't be easy, but I have a feeling our
feature set is lacking behind the competition in various ways now.

On the "future" side we have:

- Chameleon
- Deco / Blocks
- Dexterity
- WSGI
- xdv as the default theming story
- deprecate portal_skins
- ...

I don't want to go into the details of any one of those, but my
general feeling is that none of these are anywhere ready to be shipped
as part of Plone Core.

My current idea would therefor be to aim for a Plone 5.0 release
roughly 18 to 24 months after Plone 4.0 final is released. We could
aim for 18 months if we only do a 4.1 release, but I assume we are
going to do a 4.2 release as well (both taking about 9 months from
experience). At that point 24 months is more realistic.

That means these technologies and projects will need to evolve outside
the core for some time. I'd hope they could bring up some PLIP's for
4.1 and 4.2 which will make their life easier - much like Dexterity
has already done with CMF 2.2 and Plone 4.0. Sometimes these might
just be events, interfaces and some more adapters to make things
independent of Archetypes.

Does this kind of roadmap has general agreement?


+1

I think that in trying to build the "real" Deco + Dexterity + WSGI 
publisher + Chameleon + Skins deprecation as add-ons for Plone 4.0 
*now*, we'll end up driving features for Plone 4.1. That is, the work 
for Plone 5 probably starts in parallel with the work for Plone 4.1, 
i.e. very soon if not already.


Martin

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


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

[Framework-Team] Re: Body class

[Martin Aspeli]

Hi,

2010/1/17 Hanno Schlichting :
> On Sun, Jan 17, 2010 at 4:24 PM, Martin Aspeli  wrote:
>> Any chance we could put this in a separate view utility instead of the
>> @@plone one, so that it's more sane to override?
>
> Yeah. With bodyClass already being on that view, it felt ok-ish. But I
> guess there's a couple of "visual policy" methods in there which
> should go into their own view somewhere in plone.app.layout.

+1

> Just looking at the methods, I'd move the following to a new view
> (leaving BBB support in the old place):
>
> mark_view
> have_portlets
> hide_columns
> renderBase
> bodyClass
>
> These all feel like things that influence CSS classes or UI policy in some 
> way.

I think mark_view should probably stay, or at least be separate. It's
both fundamental to other functionality and easy to screw up. +1 for
the others, though.

Martin

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

[Framework-Team] Re: Notes from Joel on simplifying Plone

[Martin Aspeli]

Thanks for doing this, Jon!


Most of the increased complexity stems from our past choices to adopt
new technologies that we didn't build ourselves, without adequately
considering how well they fit our average integrator's knowledge or
skills.  In many cases these new technologies offered considerable
benefits, but also had significant missing features or
confusing/awkward aspects that we failed to address.


And sometimes failed to deliver features present in the technologies 
they were intended to replace, leading to a hybrid approach that is more 
confusing still.



1) Viewlets and viewlet managers.

While viewlets and viewlet managers provide some clear benefits to
add-on product authors, they are very clumsy and confusing for more
basic theming tasks. The biggest specific problem is that our current
design doesn't allow us to move viewlets between viewlet managers
without writing code and ZCML.  This makes a complete through-the-web
viewlet manager like GloWorm impossible to realize.

We need to rethink the design of viewlets (in a backwards compatible
way) so that a tool like GloWorm can move viewlets, create new
viewlets and customize existing viewlets through-the-web, THEN dump
the results to a disk-based product.   We believe that this kind of
workflow would transform average integrators' loathing of viewlets
into love.


A bit aha for me when we started talking about Deco was that the 
viewlets use case is basically this: A third party product needs to plug 
itself into a part of Plone's UI in a semantic location. For example, 
plone.app.iterate puts a message about the existence of a working copy 
into a space you could logically call the "notice area". It can do this 
quite nicely with marker interfaces.


The use case for viewlets is *not* to replace ZPT macros as a way to 
package up re-usable components. Unfortunately, that's what we did. You 
could argue that zope.conentprovider (the low-level package on which 
zope.viewlet is built - basically, a contentprovider is something you 
can insert via the provides: expression) is such a thing. However, 
there's no easy way to register a content provider, so we have viewlets 
instead.


The ability to move/re-order viewlets is semi-useful, but I think a 
model based on moving named things around a template is more useful 
still. The viewlet manager abstraction is still pretty arbitrary, not at 
least because we use names based on location ("above content") instead 
of meaning ("notice area").


Of course, the solution to all this is likely to be:

 - Deliverance/XDV for broad-brush re-branding
 - Deco/Blocks/Tiles for pluggable, re-organisable UIs

In Plone 5, I hope we'll have three or four viewlet managers, 
representing such thing as "HTML head", "notice area" or "end of page" 
(for late-bind JavaScript stuff). Some of these may even be contained 
within tiles, allowing administrators to move the areas around on the 
site layout.



2) ZCML-wired page templates

It is currently too difficult to override a default Plone template.
We need to have a mainstream, best-practice way "wire-by-name" way to
add new templates, override templates in themes (layers) and override
things that are already overridden.

Jbot is a good portion of the way there, we don't know if it can go
all the way, but we certainly hope so.We need to move this type of
solution to the front and center of our template customization story.


I couldn't agree more.

I'm leaning toward something that allows people to use Grok-style 
convention-over-configuration when they want a Python class, but allows 
configuration without the class (and allows you to add the class later 
if you decide you need it). This needs to work the same for overrides 
(which z3c.jbot handles pretty well) and new templates (which it doesn't 
address at all). The basic principle needs to be that you can get pretty 
far with just TAL-in-a-directory.


We also want TTW customisation with filesystem export, which David Glick 
is working on right now. ;-)



3) Product installation with buildout

Buildout offers many benefits, but also presents a learning curve for
new site integrators, especially w/r/t add-on product installation.
Some specific challenges and ideas for improvement include:

- There's no obvious, easy way to find out the name of an egg from the
product listing on Plone.org.  This is easy to fix in PSC.

- The redundant need to add many products to both "eggs" and "zcml" is
very, very confusing and frustrating to new users.  With Plone 3.3, we
finally have the capability to use autoinclude, but we have to
aggressively get product authors to update their products to take
advantage of this capability, or else sprint through the collective
and do it for them. Let's get this done!


+1

As a general principle: if the package is a Plone Product (as opposed to 
a lower level library) it should have this in setup.py:


entry_points = """\
[z3c.autoinclude.plugin]
target = plone
"""


- Right now, 

[Framework-Team] Re: incorrect URL for repoze.xmliter?

[Martin Aspeli]

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Aspeli wrote:

Nate Aune wrote:

I just tried running the Plone 4 coredev buildout
(http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/)
with deco.cfg last night, and it was failing when trying to check out
repoze.xmliter. So I had to change this line in experimental/deco.cfg to
get the buildout to run:

- repoze.xmliter= svn
svn+ssh://rep...@svn.repoze.org/svn/repoze.xmliter/trunk
<http://rep...@svn.repoze.org/svn/repoze.xmliter/trunk>
+ repoze.xmliter= svn
http://svn.repoze.org/repoze.xmliter/trunk/

Also added to the plone-deco issue tracker on google code:
http://code.google.com/p/plone-deco/issues/detail?id=15

This happens because you don't have commit privileges in the repoze svn.
Leaving it with the public URL is better, though.


Why depend on SVN checkouts, rather than working to get the package
released?  Martin, you are the last one to touch it, looks like.


There is nothing in "proper" Plone that depends on this. 
experimental/deco.cfg is only really to be used by the Deco developers 
and is pretty rough still. A release would be good, it just isn't the 
top of the list.


Martin

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


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

[Framework-Team] Re: incorrect URL for repoze.xmliter?

[Martin Aspeli]

Nate Aune wrote:

I just tried running the Plone 4 coredev buildout
(http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/)
with deco.cfg last night, and it was failing when trying to check out
repoze.xmliter. So I had to change this line in experimental/deco.cfg to
get the buildout to run:

- repoze.xmliter= svn
svn+ssh://rep...@svn.repoze.org/svn/repoze.xmliter/trunk

+ repoze.xmliter= svn
http://svn.repoze.org/repoze.xmliter/trunk/

Also added to the plone-deco issue tracker on google code:
http://code.google.com/p/plone-deco/issues/detail?id=15


This happens because you don't have commit privileges in the repoze svn. 
Leaving it with the public URL is better, though.


Martin

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


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

[Framework-Team] Re: Plone 4 - holidays are over :)

[Martin Aspeli]

Hanno Schlichting wrote:

A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark 
had never heard of bin/instance console. We need to document the crap out of 
that.


Eh, how do you guys start an instance without the forced debug mode of
"fg"? You don't use "start" for that, do you?


I guess I never do that. :)


Since when have we had that?


Since we use buildout or to be more precise, April 2008. Let me quote
the PyPi page:

1.8 (2008-04-05)

Added console command to the instance script, which is equivalent to
fg but does not implicitly turn on debug mode but respects the
zope.conf setting. [hannosch]

One month later we changed it not to fork a process internally, so
this is what we've been using for supervisord configurations for
years.


Heh, good. :) I've been using a lower level script (run.py or something, 
deep inside Zope) in supervisord that I guess does the same thing.


Martin

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


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

[Framework-Team] Re: Plone 4 - holidays are over :)

[Martin Aspeli]

Eric Steele wrote:


Personally I disagree with some of the choices mentioned in the PLIP
(like shipping the unmaintained Clouseau, using eggtractor where
buildout covers the same use-case today, turning on debug-mode in
zope.conf, which should only be done via bin/instance fg vs.
bin/instance console)


A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark 
had never heard of bin/instance console. We need to document the crap out of 
that.


You mean that wasn't a typo?

/me is astonished. :)

Since when have we had that?

Martin

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


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

[Framework-Team] Re: more feedback on plone.app.discussion

[Martin Aspeli]

Hi David,

Thanks for the detailed review!

>
> - The configuration UI works okay, but it would be nice if all the options
> relating to commenting were available in one place (including, e.g., things
> like which content types have comments enabled, whether or not moderation is
> enabled, etc.)  We can always write a form adapter that saves these options
> however we like, even if the settings are also available in the other places
> they are now, like the Types configlet.
>
>
We spoke about this when Timo built this part. My advice then was that as
long as p.a.d was a separate package, duplicating what was already in the
Types control panel would be confusing.


> - Currently moderation is a global setting (based on whether the Comment
> type has the comment_moderation_workflow or not).  It would be nice to be
> able to configure it so that comments are moderated for anonymous users, but
> not for users with some particular permission (e.g. "plone.app.discussion:
> Skip moderation").  For users with that permission, comments with a
> moderation workflow would get automatically published when the comment is
> submitted.
>

This can be done with an automatic transition guarded by this permission.


> - Is there a recommended way to provide e-mail notifications based on
> commenting (e.g. e-mail to the site owner when a new comment is submitted
> for moderation; e-mail to the commenter when it is approved; e-mail to the
> commenter when someone posts a reply...)


I hope we can make that happen with content rules. We may need to register
some new event types for the content rules engine, but that's easy enough.

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

[Framework-Team] Re: [Plone 4] Final PLIP reviewing and voting

[Martin Aspeli]

Eric Steele wrote:

FWT!,

It's final review time for 4.0. We currently have 6 PLIPs awaiting  
final review and merge vote:


9186Set Image IDs from Title field
9259Group dashboards
9285Show blocked portlets in management interface
9263GenericSetup syntax for importing Sharing page roles
9272Exposing and editing Dublin Core properties
9305Use real names instead of usernames


What does this mean for the other PLIPs?

 - the author hasn't completed required showstopper changes in time?
 - the reviewer hasn't reviewed their changes?

I think the CMF add-views PLIP should be ready as well, as mentioned on 
the ticket and this list.


Martin

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


___
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 Minutes – Sept 16, 2009

[Martin Aspeli]

Alec Mitchell wrote:

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.


We can certainly add these roles back, though again I think it's outside 
the scope of the PLIP (which merely makes it easier for people to add 
them themselves using GenericSetup).


I'm -1 on adding Owner: I think it causes a lot of confusion. That said, 
we could maybe have it managed in another way, whereby you get a 
different form for "change ownership" that lets you assign multiple 
owners (maybe with one designed as "primary"). This would set the 
Contributors metadata and assign the Owner role to multiple people.


I'm +0 on adding Manager. It's certainly useful in a lot of situations. 
In theory, yes, they could go add a bunch of stuff to the ZMI, but for 
most sites that's not an issue, and sometimes you *do* want to delegate 
the role.


Martin

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


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

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

[Martin Aspeli]

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.


#9264: David: Non-controversial. Saw performance degradation in early  
look, Martin has updated. Ross: Seeing performance degradation in read  
only tests, which is unexpected. David will ask Martin if there's any  
reason for it that he's aware of.


As mentioned on the ticket, the Read Only tests must be bogus. They run 
at something like 3 requests per second even in the (non-PLIP) baseline, 
and the PLIP is marginally worse.


The functionality isn't even executed on anonymous requests, so I 
largely ignored this issue. For the Read-Write tests, the PLIP is faster.


I don't know enough about the load test setup to diagnose why those 
tests were not working as expected.


Martin

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


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

[Framework-Team] PLIP9263 (sharing.xml syntax) is ready for merging

[Martin Aspeli]

Hi,

https://dev.plone.org/plone/ticket/9263 is ready for merging.

See my comments for notes about the review feedback.

Cheers,
Martin

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


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

[Framework-Team] PLIP 9264 (CMF add view support) is ready for merging

[Martin Aspeli]

Hi,

David reviewed PLIP #9264[1] and found in favour, except for a concern 
about performance. I believe that's now addressed, and the latest load 
tests for content creation shows a slight improvement with the PLIP 
branch over plain 4.0 (note that the read-only tests are red, but those 
tests must be wrong as they peak at 3 req/sec even on the plain 4.0 
branch, and this PLIP has no bearing on folders where you don't have add 
permissions).


Cheers,
Martin

[1] http://dev.plone.org/plone/ticket/9264

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


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

[Framework-Team] Re: Framework Team: Time is short, we need your reviews.

[Martin Aspeli]

Martin Aspeli wrote:


7822Make standard file content types use ZODB BLOB support


Review added here:

http://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.0/plips/plip7822-review-optilude.txt?rev=29687

My non-FWT vote is +1, provided we can fix the test failures and one or 
two outstanding bugs.


I'd also say that in my opinion this (along with Zope 2.12 support, and 
possibly the new theme + the unify folder implementation PLIP) is one of 
those PLIPs that we positively have to get into Plone 4. It's too 
disruptive for a 4.1+ release, and very important for regular 
integrators to be able to scale Plone with large files. That means we 
need to give Andreas the support he needs to get this done, and help 
test and fix issues.


Martin

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


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

[Framework-Team] Re: Framework Team: Time is short, we need your reviews.

[Martin Aspeli]

Martin Aspeli wrote:

9256	Expand variable substitution in mailing action of  
plone.app.contentrules


I've added a review here:

https://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.0/plips/plip9256-review-optilude.txt?rev=29683

My guidance vote is +1, though I'd like to see a couple of minor 
improvements.


Martin

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


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

[Framework-Team] Re: Framework Team: Time is short, we need your reviews.

[Martin Aspeli]

Martin Aspeli wrote:


8808Require Python 2.5 or 2.6, Zope 2.12, and CMF 2.2 for Plone 4.0


I reviewed this too, although it's a difficult one to review in the same 
way as the other PLIPs are being reviewed.


My notes are here: 
https://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.0/plips/plip8808-review-optilude.txt?rev=29679


I've suggested +1 :-)

Martin

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


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

[Framework-Team] Re: Framework Team: Time is short, we need your reviews.

[Martin Aspeli]

9249Add TinyMCE as the default visual editor


I've added a guest review and voted +1.

I can't update the spreadsheet on Google Docs, though.

Martin

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


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

[Framework-Team] Re: Framework Team: Time is short, we need your reviews.

[Martin Aspeli]

Hi,

During this week's FWT call, we waved 11 PLIPs through to the next  
stage and closed 2 others. The remaining 20 still need one (or two in  
some cases) reviews before we're comfortable considering them:


I can help review the following four PLIPs this weekend if all that's 
required is to write a review like the ones I've seen done for my PLIPs:



7822Make standard file content types use ZODB BLOB support


I use plone.app.blob in a project right now, so I have some experience 
there. This would be a second review, correct?



8808Require Python 2.5 or 2.6, Zope 2.12, and CMF 2.2 for Plone 4.0


Not sure what more is required here than "it works", but I can help have 
a look if anything specific needs review.



9249Add TinyMCE as the default visual editor


I'm using this in production as well now, so I can help review. This 
would be a second review too?


9256	Expand variable substitution in mailing action of  
plone.app.contentrules


I'm using its cousin, collective.contentrules.mail, so I can help review 
this. This would be a second review too?


...

Then comments on two of my PLIPs:


9263GenericSetup syntax for importing Sharing page roles


This one's not been reviewed, but it's very simple. I hope someone can 
take a look.



9264Merge backport patches from plone.app.dexterity into Plone


I've addressed, I hope, the initial performance concerns (the load tests 
seem to bear this out) so I hope this one's ready for merging, too. 
There's not very much to it.


Cheers,
Martin

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


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

[Framework-Team] PLIP 9259 (group dashboards) is ready for merge

[Martin Aspeli]

See https://dev.plone.org/plone/ticket/9259 for details.

Thanks to the reviewers for helpful suggestions!

Cheers,
Martin

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


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

[Framework-Team] Re: DataGridField for z3c.form?

[Martin Aspeli]

Wichert Akkerman wrote:

On 9/10/09 16:57 , Martin Aspeli wrote:

I don't think anyone's yet built a good composite form solution. I
suspect that z3c.form at least has the power to let you do so in a way
that's going to end up being usable by mere mortals, even if it errs a
little on the side of generalisation in providing hooks to those solving
that rather complex use case.


Unfortunately I strongly feel that z3c.form is based on a basic 
principle I disagree with: it tries to support everything you may want 
to do in a form. As a result it has become a large and complex framework 
that can handle many things, but not something I enjoy using. I prefer 
simple things that do very little, but allow me to easily extend them 
whenever I need something non standard. For me something between 
repoze.formapi and FormEncode is ideal. I do see that z3c.form can be 
very useful for environments such as Plone, but it does mean that I am 
not going to put a much energy into improving it as my interests lie 
elsewhere. z3c.form can be cleaned up without too much work, but someone 
else will need to champion that effort.


If you're actively discouraging the solution we do have that works 
today, you're not interested in improving it, and you'd like to see some 
other solution that doesn't exist yet take its place, then I fear we're 
at an impasse and we'll never get anywhere.


As you say, z3c.form (in design principle if nothing else) meets a need 
(schema-based forms) that is quite common in Plone. When we did the UI 
support for Dexterity, it was the only good alternative we had, since 
formlib was both being abandoned by its maintainers and proved too 
inflexible and awkward to work with, and hand-written forms would be, 
well, silly.


I won't claim that z3c.form is perfect, but I will say that we'd be 
better off trying to work with what we have today. It doesn't sound like 
you're about to champion a new comprehensive forms solution that will be 
usable in the next few weeks or months. :)


I'd also guess that the HTML markup from the default widgets is probably 
not as important to everyone else as it seems to be to you.


Martin

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


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

[Framework-Team] Re: DataGridField for z3c.form?

[Martin Aspeli]

Martin Aspeli wrote:

- z3c.form produces very awful HTML


Does that apply to the general case, or only to the case of nested 
structures like this?


The markup of the widgets I've seen has generally been pretty good. I 
think we need a much richer, mainly JavaScript-driven and probably less 
generalised widget for the "grid" use case anyway.



- z3c.form produces very confusing user interfaces


Again, I think that applies to


- z3c.form documentation is indeed incomplete (no mention of
   ObjectFactory)


It's certainly better than formlibs. ;-)


- z3c.form you can do cool stuff with it, although I am not convinced
   it is much better than hand-coding the form


One of the reasons we had a woefully incomplete Plone control panel and 
relied on the ZMI for far too much up until Plone 3 was that no-one 
likes or bothers with hand-coding forms for things like that. The same 
goes for content add/edit menus and anything else that is largely schema 
driven. There's definitely a place for hand-coded forms, but it's not a 
panacea either.


And the reason I cc'ed the framework team: I strongly feel that until 
the generated markup and user interfaces from z3c.form are improved to 
meet Plone standards Plone itself should start using it.


I think you're over-generalising. The output of a z3c.form form is not 
any worse than what we have with formlib or Archetypes (in fact, it's 
probably better, and it's certainly easier to standardise). There may be 
reasons for and against z3c.form, and the complex nested forms stuff is 
probably not quite mature, but it's not any less mature than it is in 
anything else.


There is another important factor too: z3c.form is seeing active 
development and has a committed maintainer, who cares about 
compatibility with Plone. I'm sure he'd appreciate patches and 
constructive feedback, rather than negative generalisations.


I don't think anyone's yet built a good composite form solution. I 
suspect that z3c.form at least has the power to let you do so in a way 
that's going to end up being usable by mere mortals, even if it errs a 
little on the side of generalisation in providing hooks to those solving 
that rather complex use case.


Martin

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


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

[Framework-Team] Re: DataGridField for z3c.form?

[Martin Aspeli]

- z3c.form produces very awful HTML


Does that apply to the general case, or only to the case of nested 
structures like this?


The markup of the widgets I've seen has generally been pretty good. I 
think we need a much richer, mainly JavaScript-driven and probably less 
generalised widget for the "grid" use case anyway.



- z3c.form produces very confusing user interfaces


Again, I think that applies to


- z3c.form documentation is indeed incomplete (no mention of
   ObjectFactory)


It's certainly better than formlibs. ;-)


- z3c.form you can do cool stuff with it, although I am not convinced
   it is much better than hand-coding the form


One of the reasons we had a woefully incomplete Plone control panel and 
relied on the ZMI for far too much up until Plone 3 was that no-one 
likes or bothers with hand-coding forms for things like that. The same 
goes for content add/edit menus and anything else that is largely schema 
driven. There's definitely a place for hand-coded forms, but it's not a 
panacea either.


And the reason I cc'ed the framework team: I strongly feel that until 
the generated markup and user interfaces from z3c.form are improved to 
meet Plone standards Plone itself should start using it.


I think you're over-generalising. The output of a z3c.form form is not 
any worse than what we have with formlib or Archetypes (in fact, it's 
probably better, and it's certainly easier to standardise). There may be 
reasons for and against z3c.form, and the complex nested forms stuff is 
probably not quite mature, but it's not any less mature than it is in 
anything else.


Martin

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


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

[Framework-Team] Re: [Plone-developers] Framework Team: Time is short, we need your reviews.

[Martin Aspeli]

Alexander Limi wrote:

Boo! Hiss!

:)


/me gets the tomatoes...


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

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

[Martin Aspeli]

This is really good stuff!

I must admit, I don't understand the graphs or the tables-of-graphs at
all, though. Is there a quick explanation somewhere about how to read
them?

Martin

Ross Patterson wrote:

You can find funkload load test benchmark reports and comparisons at:

http://weblion.psu.edu/static/loadtesting/plone4.0/plips.html

The buildout logs for the individual plips can be found with the same
name as the *.cfg file substituting .log for .cfg in:

http://weblion.psu.edu/static/loadtesting/plone4.0/

So if a PLIP looks like it has erroneous results take a look at the log
and let me know if there's anything to be done to get valid results.  Do
this soon since the EC2 instance is costing me money so I will take it
down soon and I won't want to set the whole thing up again once I take
it down.

You may also be interested in the following:

  - Plone 4.0 base against Python 2.4, 2.5, and 2.6
http://weblion.psu.edu/static/loadtesting/plone4.0/base.html

  - Plone 4.0 against Plone 2.5, 3.0, and 3.3
http://weblion.psu.edu/static/loadtesting/plone4.0/versions.html

  - Plone 3.3 write conflict error comparison
http://weblion.psu.edu/static/loadtesting/plone4.0/threads-retries.html
(interesting how well 1 ZEO client with 1 thread does against 2 ZEO
clients with 1 thread each)

Limi and I are working on adding some explanatory text and legends to
these reports but for now this is all you get.  :)  Click through and
around and if there's anything you still can't make sense of, ask and
I'll see what I can do.

Ross





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


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

[Framework-Team] Three PLIPs ready for review

[Martin Aspeli]

Hi folks,

Just a quick note: I'm now done with the implementations of:

 https://dev.plone.org/plone/ticket/9259 (group dashboards)
 https://dev.plone.org/plone/ticket/9263 (sharing roles GS syntax)
 https://dev.plone.org/plone/ticket/9264 (add_view_expr support)

I'll be on holiday from August 15th-22nd, but hopefully you should be 
able to review without too much drama. There are PLIP buildout configs + 
notes for all, and the tickets include references to all relevant 
changesets.


Cheers,
Martin

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


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

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

[Martin Aspeli]

Alec Mitchell wrote:

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.


+1


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)?


+1

Martin

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


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

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

[Martin Aspeli]

2009/7/30 Erik Rose :
>> 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?
>
> -1. Why make it harder for people to contribute?

By that argument, we'd have nothing in the Plone svn repository, and
nothing covered by the contributor agreement. That's just silly.

The contrib agreement and Foundation ownership are there for good reasons.

Martin

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

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

[Martin Aspeli]

Wichert Akkerman wrote:

The whole point of the agreement and the conservatory is that we have a 
solid legal basis. I would really like to see an informed legal opinion 
on the requirements for moving existing code to foundation ownership. 
Without that I fear we may be on dangerous ground and risk making the 
separate repository useless.


If someone has the time to do this and it doesn't cost anything, go ahead.

But don't let it stop or discourage people from doing what's right. The 
Contributor Agreement is pretty clear reading, especially the front page 
matter: http://plone.org/foundation/contributors-agreement/agreement.pdf


People get far too worked up over the What Would A Layer Do question, 
probably in the belief that there is in fact a black-and-white answer 
that they're just not qualified to know. I can understand it coming from 
Americans. They probably have wristbands with that written on them. Less 
so from the Dutch. :)


Martin

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


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

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

[Martin Aspeli]

Wichert Akkerman wrote:

On 7/29/09 7:51 AM, Jon Stahl wrote:

On Tue, Jul 28, 2009 at 12:07 AM, Geir Bækholt · Jarn  wrote:

There is a step missing here: contributors must not only have signed the
agreement, they must explicitly allow that specific code to be donated to
the foundation. Signing the contributor agreement does not mean all your
code can be moved at will to the foundation.

Yes, of course. Implied but omitted. My bad. Thanks.

So, my question is: what qualifies as "explicit" agreement?  Does it
have to be "on the permanent record" in some manner?


You'll have to ask the PF legal counsel I'm afraid. I don't know the 
right answer.


I suspect you don't need to ask. :)

If all contributors of all lines of code that are being moved consent, 
and have signed the contributor agreement, then there really is no issue.


We're now getting into a technical argument about what constitutes 
"consent", but it's hardly that difficult. You ask. They say yes or no. 
An email trail would be nice.


In reality, whenever we deal with these kinds of things, we operate 
within some margin of acceptable risk. A risk always has a probability 
of occurring and a probable impact if it does occur. The acceptability 
of a risk depends on these two factors. Equally, there's a (usually more 
measurable) cost and sometimes other risks associated with doing nothing.


So, in this case, we're deciding whether to move a product into the PF 
repository.


There are risks and costs associated with not doing this, that is, the 
usual risks to Plone associated with code not covered by the agreement.


There are risks associated with going ahead with the move, such as:

 - Rob may lie about some contributor having consented
 - Rob may misinterpret a particular response as consent
 - Someone may indicate consent and then lie about it later, pretending 
they didn't consent, and try to raise hell
 - We may have it all wrong, and it may turn out there is some 
convoluted legal procedure we *have* to follow, and if we don't, men in 
expensive suits are going to come after us


The probability of any of those occurring I'd say is very low. The 
impact would also likely be very low if any of these things did occur. 
Most likely, the worst that would happen is that the PF board would need 
to discuss it for a bit. In the worst case, we move the code back to the 
Collective.


Let's try not to use the "we're not lawyers" argument as self-censorship 
stop energy. The reality is that there's a big grey zone that we all 
operate in every day, whether we are aware or not, and in reality the 
spirit of the contributor agreement and the conservancy model matters 
infinitely more than the technical details.


Furthermore, I suspect if you asked two lawyers, you'd get at least two 
different answers.


Of course - I'm not a lawyer. But I do deal with these kinds of 
questions quite often over commercial matters where there is a lot more 
at stake than there is here, and a much higher probability of actual, 
quantifiable losses if important steps are missed.


Martin


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


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

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

[Martin Aspeli]

Jon Stahl wrote:

On Tue, Jul 28, 2009 at 12:07 AM, Geir Bækholt · Jarn wrote:

There is a step missing here: contributors must not only have signed the
agreement, they must explicitly allow that specific code to be donated to
the foundation. Signing the contributor agreement does not mean all your
code can be moved at will to the foundation.



Yes, of course. Implied but omitted. My bad. Thanks.


So, my question is: what qualifies as "explicit" agreement?  Does it
have to be "on the permanent record" in some manner?


In our business, an email that you keep tends to be enough. I would:

 - Ask the relevant people by email
 - Ask them to reply by email giving explicit consent
 - Store those emails "forever"
 - Make a note in a CONTRIBUTORS.txt or similar that these people
consented on a particular date

If that's ever in dispute, you can go back to those emails.

I don't see a reason for any kind of "wet signature" so long as
they've signed the contributor agreement. We're not *trying* to be
difficult. :)

Martin

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


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

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

[Martin Aspeli]

Rob Gietema wrote:

Correct me if I'm wrong, but I can't find any usecase where someone 
would want to import something from Products.TinyMCE.


What about persistent data, e.g. the tool? Can be fixed with module 
aliases, though.


Martin

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


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

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

[Martin Aspeli]

Rob Gietema wrote:

Hi,

I'm currently working on TinyMCE for Plone 4 and would like some 
feedback on two issues:


Yay! I'm using it in a project right now, and really like it.

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

This means the copyright transfers to the Foundation, so if anyone other 
than you worked on it, you may need their approval.


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 if it'll break imports for people who've got Products.TinyMCE now and 
upgrade.


+0 otherwise.

Martin

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


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

[Framework-Team] Merging PLIPs and the Zope 2.12 work

[Martin Aspeli]

Hi,

My PLIPs for 4.0 are all just merging things form add-on products into 
the core. I don't think it makes sense to do that until the Zope 2.12 
branch is merged.


So:

 - how likely is it that this work will be done in the next few weeks?

 - is the August 16th deadline merely a "code review" deadline? If so, 
it may make sense to just review the code where it is now, in a couple 
of add-on products, to give the thumbs up or down. I'll obviously 
provide some guidance on how to do this effectively. :)


The PLIPs are:

 http://dev.plone.org/plone/ticket/9259 (group dashboards)
 http://dev.plone.org/plone/ticket/9263 (sharing page roles GS syntax)
 http://dev.plone.org/plone/ticket/9264 (CMF compat patches)

Cheers,
Martin

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


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

[Framework-Team] Re: [Plone 4] Framework Team PLIP votes (and scheduling)

[Martin Aspeli]

Eric Steele wrote:
Alec has been kind enough to set up a Google spreadsheet for tracking  
PLIP votes (hat tip also to Matt for suffering through the creation of  
a Trac version that we dumped). It's publicly viewable at http://spreadsheets.google.com/ccc?key=rR4UAIObeTZtdUExfYophHw 
  . Plone 4 FWT members should have received an email giving them  
write access.


Consider this a nudge to get voting!

Also, for those of you who haven't filled in your weekly availability  
for phone calls (yes, again), please do so now. http://www.doodle.com/zf9hkvyexzgi98tt 
  Erik has voted twice, but note that it will not count towards his  
final score.


Great to see this. :)

Two questions:

 - Are you still going to comment with +1/-1 on the PLIP tickets 
themselves? I find this (plus some justification if it's a -1) very 
valuable.


 - It'd be nice to have the PLIP titles on the spreadsheet in addition 
to the numbers to get a better overview of what's being voted up and down


Martin

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


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

[Framework-Team] Re: PLIP Change Mailing List

[Martin Aspeli]

Steve McMahon wrote:
All the 4.0 PLIPs now have 
plip-advisor...@lists.plone.org 
 in the 
CC list.


If you want to subscribe, visit: 
http://lists.plone.org/mailman/listinfo/plip-advisories


Most were added in the last few minutes, so previous activity is not in 
the archives.


Can we add it to gmane too?

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


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

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

[Martin Aspeli]

Alec Mitchell wrote:


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


I suggested a few principles in my original mail.

However, I'm not advocating that we try to limit the scope, only that we 
don't let the release by delayed by an overwhelmed framework team.


Cheers,
Martin

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


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

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

[Martin Aspeli]

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".


Martin

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


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

[Framework-Team] Re: [Plone 4] Working out a timeline

[Martin Aspeli]

Eric Steele wrote:

Ok, so I promised a draft timeline before our meeting on Tuesday.

Here's what I've got:

- Aug 16 initial implementation


Oh what? Each PLIP?


- Aug 30 first review due
- Sept 13 revisions due
- Sept 27 review of revisions / vote
- Oct 4 Alpha 1 release
- Oct 25 Beta 1 Release (or directly after the conference?)
- Dec 1 Final Release


Sound good to me on a brief look.

I'm ending everything on a Sunday to allow everyone to get a full  
weekend's work. I'll be blocking off the majority of my Mondays to do  
my part.


Awesome! :)

And from this point on, I'd like to adopt Wichert's "Midnight your  
time, whenever that is" stance on time zones. If I have to do math  
each time I send out a reminder mail, we're in for a logistical  
nightmare.


+1


Thoughts?


I think the challenge is going to be finding time to assess and review 
all the PLIPs that are in Trac. I wrote some suggestions on how to 
manage that with a 4.1 milestone and some tighter criteria for 4.0 in 
the thread Joel started.


Martin

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


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

[Framework-Team] Re: update on supporting Python 2.6 / Zope 2.12 / CMF 2.2

[Martin Aspeli]

Hi Hanno,




Well, I really hate having default content around, that I have to
delete all the time and people use in tests that later on break if we
change it. The initial content just won't make sense for many sites
and people waste huge amount of times to try to get the initial
content to match some form of uber-use-case. Has anyone looked at how
much time people spent of fixing the nested "past events" collection?
Except that everyone really thinks that nested collections are a bad
idea in general and they actually don't really work? And then we have
the infamous "front-page" which welcomes our users to Plone 3.0 with
the exact same message up until today? We don't update these things
and there's no one driving it. I'd just rather have something be part
of the installers that welcomes new users and points to some section
on plone.org for continuously updated information. An updated guide on
plone.org about "Your first steps with Plone - how to create content"
and a "How to organize your content (simple information architecture)"
stuff would be more helpful and allow users to feel in charge of the
content in their site. Right now first time users can't really tell,
if those initial folders are content or part of the application logic
and won't dare to change them. Not to mention that they create hard
problems in multi-lingual settings, where you actually want to layout
your site quite differently. So +1 one a "welcome screen" that isn't
content in itself but a big -100 on any content in a new site. That's
what demo.plone.org would be for.



That was a long paragraph.

I think it's important that Plone has at least a welcome page when you 
install it. Staring at a blank folder_listing is going to put off new 
users. We can probably bet rid of the News and Events collections, though.



We need an instance of some sort to have a place for the zope.conf and
site.zcml and start/stop script for one. Since we want to support ZEO
and the http port of the webserver is in the zope.conf file, we need
the ability to have multiple instances. Since we will need to change
quite a bit of that stuff when WSGI hits, I'd rather try to mimic the
current behavior / layout as closely as possibly for 4.0, so we don't
invalidate the documentation twice.


Yeah, +1

Martin

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


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

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

[Martin Aspeli]

Joel Burton wrote:

Hello, Framework Team!


A lot of very sensible things were said in this thread.

I have two concerns:

 1) We shouldn't let 4.0 be the excuse to let trunk languish 
indefinitely. There are important, innovative things we want to do there 
(like Deco and Tiles) that we need to be moving ahead with to stay 
competitive in the WCMS world.


 2) We shouldn't let 4.0 get so big that it pushes into Q1/Q2 2010. 
That's a real risk at this point, given the sheer number of PLIPs in the 
tracker.


So, based on that, I think the following would work (mostly as suggested 
by Hanno and others).


 - We stick to the original mantra for 4.0 of being mostly about 
packaging up things that have already been build and bringing them 
forward so people can start using them. Zope 2.12, CMF 2.2, blobs, a 
more Deliverance-friendly default theme, etc.


 - We also include a few good-but-low-risk things. Again, largely 
things that already have an implementation in the wild. The idea is that 
once the 4.0 base settles down (based on David's backporting branches), 
we can quickly merge these things in and get an alpha out.


 - 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.


Looking at the current list, I think it should be possible to designate 
PLIPs as 4.0 and 4.1 in this manner. The controversy will probably come 
about when delaying a PLIP to 4.1 would mean a more substantial change 
in 4.1, thus breaking the expectation of stability in point releases. In 
that case, we need to either bring it forward into 4.0, which would 
require pretty strong commitment to get it done quickly or an existing 
implementation to start from, or push it back as a 5.0 feature.


To illustrate this, here are a few examples that I think could follow 
this rule:


 #8808 - Require Python 2.6, Zope 2.12, and CMF 2.2 for Plone 4.0

No-brainer for 4.0. Same with #7822 (blobs).

 #9249 - Add TinyMCE as the default visual editor

If we are to do this before 5.0, it needs to be in 4.0, because it's too 
radical a change to go into a 4.x release. Doing this would require some 
strong commitment to do the work and keep up with maintenance and bug 
fixes. If we have that, I'd vote +1 to 4.0. Not that my vote counts. :)


 #9214 - support logins using e-mail address instead of user id

Possible for 4.0 because there's an existing implementation in a third 
party product. If there hadn't been, I would've said this was more 
suitable 4.1.


 #9292 - Group management delegation

This would be a nice feature to have, but the PLIP author hasn't thought 
about how to implement it yet. :) This should be aimed at 4.1 IMHO.


Martin

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


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

[Framework-Team] Re: update on supporting Python 2.6 / Zope 2.12 / CMF 2.2

[Martin Aspeli]

Hi David,

Hello!  I'm hoping to give an update on my work this past week and get  
some feedback on whether I'm heading in the right direction.


I suspect you are. ;-) And let me just say I, for one, am really 
grateful you're doing this.


As some of you may have noticed, I've been working on a branch that  
can hopefully become the basis of Plone 4, including support for  
Python 2.6, Zope 2.12 (which is the first Zope 2 supporting python 2.6  
and also the first official eggified Zope2) and CMF 2.2 (which will be  
the first CMF release that doesn't rely on Zope 2-style interfaces,  
which were removed in Zope 2.12...and also adds a few handy extension  
points).  My basic approach is to start with the packages that make up  
Plone 3.3, and then backport the changes from trunk that seem non- 
risky.  So far I haven't gotten through the entire history of CMFPlone  
trunk, nor through all of the rest of the packages, but I have at  
least gotten far enough to start up Zope and successfully add a Plone  
site.


w00t. :)

Do you have an idea of how much work is left?


Some of the changelogs that are relevant here, FYI:
Zope 2.12 release notes: http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html
Zope 2.12 changelog: http://docs.zope.org/zope2/releases/2.12/CHANGES.html
CMFCore 2.2 changelog: 
http://svn.zope.org/Products.CMFCore/trunk/Products/CMFCore/CHANGES.txt?view=auto
CMFDefault 2.2 changelog: 
http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/CHANGES.txt?view=auto

As I've worked my way along, I've found myself making a number of  
judgment calls on where to draw the line between bugfixes and changes  
that are significant enough to warrant discussion.  In case anyone  
cares to object, here are a few things I opted to include that I  
thought might be controversial:

- some optimizations coming out of the 2 performance sprints


+1

- switching action icons to use icon_expr instead of  
portal_actionicons (hannosch) — see also http://dev.plone.org/old/plone/ticket/8801


+1 - I think this maybe deserves some discussion, but getting rid of 
portal_actionicons would be really good.



- switch to png icons (wiggy, dannyb)


+0 - maybe this will break some overrides, but it'd be nice to 
standardise on one format


- conversion of migration step registration to be based on GS upgrade  
steps (hannosch) - see also http://dev.plone.org/old/plone/ticket/8802


+1 - I think this will help our migration efforts in general

- c22120 and following - removal of the globalized variables for  
performance reasons (malthe, hannosch)


+1 - we need to do this sooner or later


- c22987 - remove unused Favorite content type (hannosch)


+1 - if someone is using this, it can be factored out to an add-on.

There were also a number of things I decided not to merge immediately  
until we can have some more discussion or finish some needed tasks.   
Some of these may not actually be desired until 5.0...  I would really  
appreciate feedback here especially.
- c20188, c20190, c23197 — removal of PloneFolder (hannosch) — need to  
double check whether this requires a migration for any persistent  
objects, and write that if necessary


+0 to remove.

- c20337, c20338, c22979, c22981, c22988 - switch the control panel to  
be based on normal actions in a new action category, rather than using  
a special control panel tool (hannosch) — see also http://dev.plone.org/old/plone/ticket/8804


+0 - we need to make sure the existing controlpanel.xml import step 
continues to work.


- c20365, c20368, c20369 — moved fullscreen css to a separate file  
(spliter) — needs a migration


+0

- c22831, c22832, c22891, c22951 — remove external editor (hannosch) —  
see http://dev.plone.org/old/plone/ticket/8592


-0 - people do use this. what's the cost of keeping it?

- c22847 — remove wicked from core (hannosch) — see http://dev.plone.org/old/plone/ticket/8593 
  (but note that as of this week Carsten Senger has been doing some  
maintenance...yay!)


+0 to make this an add on people can install if they need it, but we 
should endeavour to make it work for migrated sites


- c22969 — removal of AT reference graphviz visualization (hannosch) —  
needs a migration to update actions for existing types


+1 to remove

- c23193 — turning default_error_message into a browser view  
(hannosch) — seems like a decent idea to me, but as implemented here  
it removes the redirector and content search features


+0 - I think ideally plone.app.redirector should just override this view 
and do nothing if not explicitly installed. I'm not sure we have time to 
do that properly, though.


- c23198, c23199 — removal of portal_interface tool (hannosch) — if we  
remove this then we lose the way to check for marker interfaces from  
action expressions, for instance. also, it's missing a migration


+0 to remove. Doesn't plone.app.layout.globals have something for this 
that's based on a view rather than a tool?


- c23226, c23233 —

[Framework-Team] Re: PLIPs in Trac

[Martin Aspeli]

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.

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.
- 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.
- 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.
- 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.

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.

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
- After the community has provided feedback and you got some positive
feedback, you proceed to write down a more detailed description of the
problem and the exact way you want to technically solve it
- You put this detailed text in as a PLIP into the designated spot
(which used to be PSC)
- The framework team sets a deadline on when they will evaluate the
PLIP's targeted for a specific release and the last date they accept
new contributions for evaluation
- ... and so on with a first feedback round on the general idea,
opportunities for polishing by the PLIP author and some more process
around actually doing the technical work and reviewing it

What has been missing for most recent tickets, is the entire community
discussion and feedback step. What has also been missing is a clearly
defined description of this process and a template to use for a PLIP
and a list of points that need to be addressed in it, to make
something a valid PLIP.

I think blaming a software for any of these last points isn't helpful.
Restricting the ability to add PLIP's to a smaller group in PSC has
helped to minimize some of the effects, but it's not a good solution
to restrict contribution in that way.


I wrote a big reply to Matt, and ditched it. +100 to everything you said. :)

I'd suggest that:

 a) We now formally ask PLIP authors to write to the plone-dev list 
(not this list!) announcing their PLIPs and asking for feedback. We can 
use a convention like prefixing the subject with [PLIP]. Anyone PLIPs 
that don't have this degree of commitments should be ignored straight away.


 b) At the same time, the FWT can go and unassign the milestone for any 
PLIP that is obviously a feature request or lacks detail. Just do that 
with a comment explaining why. If the PLIP gets fleshed out (maybe 
following a), we can always re-assign it.


 c) We communicate a deadline for PLIP evaluation. We'll need to leave 
a couple of weeks for this discussion/fleshing out to happen, I think. 
But not too long. Two or maybe three weeks max, I reckon.


 d) We get into the habit of sending reminders to plone-dev (and 
possibly planet.plone.org for the important ones) when deadlines are 
approaching. I think it needs to be part of the release manager's job to 
send a "2 week" reminder, a "1 week" remind

[Framework-Team] Re: [Plone 4] Getting Started

[Martin Aspeli]

Eric Steele wrote:

Features? Well, that's your job, but I can certainly push a few of my  
favorites. ;) I'd really, really like to see us get to Zope 2.12/ 
Python 2.6; 


I'd like to see us move to CMF 2.2. In this case, I'd also like to move 
some monkey patches for backports out of plone.app.dexterity and into 
Plone (or remove them altogether).


Martin

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


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

[Framework-Team] Re: congratulations, Eric Steele: release manager for "the new" Plone 4!

[Martin Aspeli]

Eric Steele wrote:

As far as the stipend is concerned, Mike Halm at WebLion has been  
fantastic enough to allow me to devote 20% of my work week to taking  
on Plone 4, the remainder coming out of my personal time. Since this  
is now a part of my job, it'll likely be Penn State sending the  
invoice, but we'll get that all worked out over the coming months. The  
great thing about this is that we've already earmarked what funds come  
in to help pay for myself and other WebLion staff to get to as many  
Plone events as possible.


This is really great! Thank you WebLion! :)

I'm very excited about Plone 4 now. :)

Martin

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


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

[Framework-Team] Re: [Plone-developers] The new Plone 4.0

[Martin Aspeli]

Alexander Limi wrote:
On Tue, 05 May 2009 15:56:36 -0700, Ricardo Alves  
 wrote:



Steve McMahon wrote:

My only concern about calling Hanno's incremental change list 4.0 is
that we don't suffer from big-number expectation syndrome.
This is the biggest risk I guess, a major release with just a minor set  
of visible (UI) improvements, will bring bad publicity.


I agree — this is the biggest risk in terms of calling it 4.0 instead of  
3.5. The consensus to call the 2009 release 4.0 makes sense to me — so +1  
on that decision.


One way to mitigate this — and make Plone seem a bit more modern along the  
way — could be to apply the new typography/theme that I'm currently  
applying to trunk. This is essentially the typography from the plone.org  
redesign along with a color-neutral design for the navigation and other UI  
elements. The goal is to make something that you can put the company logo  
on, and it looks relatively decent, no matter what your company colors are.


This would make 4.0 seem "fresh" out of the box, make it look like an  
application from 2009, and let us ship with considerably more  
efficient/smaller CSS files.


The risk would be that we need to do some IE6 testing on it, but that  
might not be a bad thing, since we know much more about IE6 workarounds at  
this point than we did when the original CSS was written.


I'd support this, *if* it follows the usual PLIP process and we actively 
encourage outside review from the get-go. That process may mean the 
theme change gets a thumbs-down.


Personally, I think it's a good idea, but in the past, we've had a lack 
of commitment/follow-up with CSS/theme stuff, and a last-minute rush to 
put in dozens of template and CSS changes which then cause breakage in 
release candidates.


We'd also need to find a way to not break all existing themes.

A small visual refresh would be welcome, though. Plone is looking a bit 
last millenium. :-/


Martin

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


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

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

[Martin Aspeli]

Rob Gietema wrote:


 > I'd nominate the incumbent 3.x team for this; this team already has
 > the mindset to get this going; the future plone team (trunk team?) is
 > focusing on vision right now, which I think may not be what's needed
 > for an in-between team.

On second thought; this may be a significant enough release, with it's
own 4.x release series, that perhaps a new team altogether is
warranted?


It would be a shame if the development of Plone trunk will get less 
focus from the FWT when working on Plone 4. So it might indeed not be a 
bad idea to have 2 teams, one team for Plone 4 and one team for Plone trunk.


I agree. I really wouldn't want to disband or repurpose the "trunk" 
framework team or release manager. We probably want to look for a new 
team, maybe with a bit more overlap with the existing/trunk teams than 
usual.


Martin

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


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

[Framework-Team] Re: Plone 3.5

[Martin Aspeli]

Jens W. Klein wrote:

I just can say here: I agree to delay features and make the next major 
4.0 and not 3.5. Dont make the same mistakes again (looking at 2.5).


Who said anything about delaying features?

This proposal suggests a feature set that is incremental to the 3.x 
series, way less than what we've been tabling for 4.0 so far, but still 
a bit too much for a 3.x under the current stability packt.


Or did you mean to vote against the proposal wholesale, and have no 
half-way between 3.x and 4.0?


Martin

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


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

[Framework-Team] Re: Plone 3.5

[Martin Aspeli]

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 major release was quite nasty, it  
confused people about what was a major release and what isn't.  We've  
made a commitment to 3.x being stable, I think we should keep to it.   
Releasing a Plone 3.5 would confuse the matter.


It's tricky, and we discussed this back and forth a few times before 
this proposal was formulated. I still think the version numbering is up 
for discussion.


The thinking is basically:

 - We'd like to move to ZODB 3.9 (blobs), Zope 2.11 (Zope 3.4), and 
possibly CMF 2.2 (trunk). Those changes are too big for the stability 
promise in 3.x.


Note that there's a certain imperative in this. In particular, I *hope* 
that we can get unofficial Python 2.5 support for Zope 2.11. Zope 3.3 is 
also becoming kind of painful as a platform. And blobs are way overdue.


 - We'd like to integrate some new features. Not critical stuff that 
couldn't be done with surgical add-ons, but nice-to-haves that will 
improve the experience for a lot of people.


 - However, to end users, this is still incremental stuff - not really 
enough for the kind of marketing push we'd like to attach to a 
'point-oh' release.


 - The term "Plone 4" is already out there meaning trunk, deco, 
deliverance, dexterity, unified types, tiles, and all that jazz. If we 
suddenly now start talking about a much more incremental "Plone 4", 
we'll cause a lot of confusion.


So, 3.5 is a compromise. The skipping of 3.4 actually helps back the 
story up. We could try something else, like Plone 2009, but I'm pretty 
sure we'd regret that in 2010 for one reason or another. And PyPI 
wouldn't like it.


However, it would be interesting to open the new features to a wider  
audience ASAP.  I'd be in favour of this if:


- It wasn't called Plone 3.x or 4.x (Dunno what though)


Yeah, thanks for helping. :p


- We maintained 3.x as officially supported


I think that'd be the case under the "two supported versions" policy.

Martin

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


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

[Framework-Team] Re: Reminder: PLIP merges are due

[Martin Aspeli]

Wichert Akkerman wrote:


- PLIP 239: Adapterise the Extensible Indexable Object Wrapper


Now merged. I have:

 - Merged the Plone plip-239 branch into the 3.3 branch
 - Added plone.indexer to plonenext/3.3 in etc/sources, etc/versions 
and version.cfg (is this correct?)

 - Released plone.indexer 1.0a1 to PyPI

The test pass, save for some Plone tests that seem to be related to the 
link type changes.


If I missed something, please let me know.

It's not entirely clear to me how plonenext works when you can have a 
non-develop Plone egg, if we're merging things to Plone/branches/3.3. I 
think it should fail gracefully in this case (you just won't get the new 
indexer functionality) if you have the old Plone release, but it is a 
bit silly.


Cheers,
Martin

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


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

[Framework-Team] Re: PLIP #234 Review Revisions

[Martin Aspeli]

Calvin Hendryx-Parker wrote:

I'd be open for suggestions for other tests.  A majority of the fixes  
were templates and they were to use an already existing bit of code  
functionality that I didn't add like you said.  The viewlets were  
modified to support this and I have the test to confirm it in the base  
class for the viewlets.


If there are some specific tests you'd like to see I'd be happy to add  
them, but in the end the trickiest piece of code I updated was the  
calendar tool modifications and I added tests there also.


FYI...  we have released collective.lineage which depends on many of  
these fixes and I believe will expand the number of people using this  
functionality.  There are a lot of people excited about this new  
product and are wanting to deploy it.  We actually have 1 site in  
production with it already.  Since this functionality was already in  
Plone before I got ahold of it I still see this PLIP as a large bug  
fix that really should be included.


FWIW, I think much of Calvin's work could've gone into a 3.2.x release 
as bug fixes. If he doesn't break tests, and writes a few tests for 
truly new code, then I think that's probably sufficient in most places.


Having done something similar in the past (but not read Calvin's diff in 
detail), I suspect most of his changes were simply to stop people making 
use of portal_url() when they should've used get_navigation_root(). 
There may be cases when we could add a "defect" type test to show that 
the navigation root didn't work before, but now does, but let's not 
create too much work for what is, in many cases, more about analysing a 
problem and applying a few surgical fixes, than writing a ton of new code.


Martin

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


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

[Framework-Team] Re: PLIP #239 ready for review

[Martin Aspeli]

Martin Aspeli wrote:

I've just finished the base implementation of PLIP #239, adapterise the 
ExtensibleIndexableObjectWrapper, for your review.


A review buildout can now be found here:

 https://svn.plone.org/svn/plone/review/plip239-indexer

Cheers,
Martin

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


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

[Framework-Team] Re: NuPlone and Plone 3.2

[Martin Aspeli]

Martin Aspeli wrote:

Hi,

Why on earth is Products.NuPlone not in the Plone 3.2 egg?

Is this in purpose or just a gross oversight?


Ok, I've released Products.NuPlone 1.0b3.

This one should be compatible with 3.2. You can use it straight away by 
adding Products.NuPlone to your eggs.


The question now is how we deal with the release. We could:

 - Add Products.NuPlone as a dependency of the Plone egg. This would 
mean 'Plone' always comes with NuPlone, but there's no reason overt for 
the dependency.


 - Add it to the [versions] block, but require people to list it 
explicitly in their buildout's eggs section.


 - Do this, but let the installers default to having it listed in the 
eggs section.


Thoughts?

Martin

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


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

[Framework-Team] PLIP #239 ready for review

[Martin Aspeli]

Hello team,

I've just finished the base implementation of PLIP #239, adapterise the 
ExtensibleIndexableObjectWrapper, for your review.


I've not created a branched buildout, mainly because it takes so long to 
check out a full coredev. Instead, please follow the following instructions:


 $ cd 
 $ cd src
 $ svn co https://svn.plone.org/svn/plone/plone.indexer/trunk plone.indexer
 $ cd ../Plone
 $ svn switch https://svn.plone.org/svn/plone/Plone/branches/plip-239
 $ cd ../../
 $ ./bin/buildout

The bulk of the code is in a new package, plone.indexer. You can read 
its doctest here: 
http://dev.plone.org/plone/browser/plone.indexer/trunk/plone/indexer/README.txt


I've tried to make this test read as a manual for how to write new 
indexers. In short, you do:


 @indexer(IMyType)
 def index_my_attribute(object, **kargs):
 return "some value to index"

 

The changes to Products.CMFPlone are just to load plone.indexer and use 
it instead of the old ExtensibleIndexableObjectWrapper.


There is one outstanding change that I'll do if and when I merge this: 
in plone.app.content, we need to add a deprecated deferred-import for 
the IIndexableObjectWrapper interface, which I've moved to the new 
plone.indexer package.


I've updated http://plone.org/products/plone/roadmap/239 to reflect the 
current state of the PLIP.


Cheers,
Martin

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


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

[Framework-Team] Re: NuPlone and Plone 3.2

[Martin Aspeli]

Martin Aspeli wrote:

Hi,

Why on earth is Products.NuPlone not in the Plone 3.2 egg?

Is this in purpose or just a gross oversight?


It seems the consensus is that it's an oversight.

I tested trunk last night, and it appears to be in a good state. I tried 
to release it to PyPI, but alas I don't have PyPI rights. From what I 
can tell, only Wichert does.


Wichert - I'm assuming you've been away for the weekend, but once you 
get this, could you at least grant a few people, including me, PyPI 
access to Products.NuPlone? We then also need to make the 3.2.1 release 
that includes NuPlone ASAP.


Martin

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


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

[Framework-Team] Re: NuPlone and Plone 3.2

[Martin Aspeli]

Matthew Wilkes wrote:

On 3 Jan 2009, at 07:55, Graham Perrin wrote:


In partial answer,





Regards
Graham


Those are all Plone 4, not 3.2.  I'm guessing NuPlone simply wasn't  
added as to the new Plone distribution after the bundle was abandoned.


This is actually really bad, and I think it should block the 3.2 full
release (i.e. with installers).

Anyone who has a site with NuPlone installed will find that it breaks
when they upgrade to 3.2. This is precisely the kind of thing we said we
wouldn't do in the 3.x series, and in 3.2 in particular, which was
supposed to be feature-identical, just re-packaged.

I did try to add Products.NuPlone as an egg manually, but that doesn't
work either, because it has a spurious dependency on Products.CMFPlone.

I think we need to:

  1) Get a release of Products.NuPlone that works with 3.2 out to PyPI
and dist.plone.org immediately.

  2) Update the Plone egg to depend on it in a 3.2.1 release.

  3) Base the installers and the release announcement on this version.

Wichert, what do you think?

Martin

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


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

[Framework-Team] NuPlone and Plone 3.2

[Martin Aspeli]

Hi,

Why on earth is Products.NuPlone not in the Plone 3.2 egg?

Is this in purpose or just a gross oversight?

Martin

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


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