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

[Wichert Akkerman]

On 2011-2-25 21:02, Elizabeth Leddy wrote:

I cannot remember any Plone releases that only took 6 months - even
when we tried hard. I'd usually expect a 50% overrun from any stated
timeline, so while aiming for 6 months we can manage to do a release
after 9 months. We'd have to aim for a 3-4 months cycle to actually be
able to do two releases in a year.


Excellent points.

About how long would you say it takes to flush out the alphas and betas?
It would be great to say 6 month cycle, feature freeze 4 months in or
something specific like that.


Realistically you can spend forever doing alphas and betas, since no 
matter what you say people never seem to start doing real testing until 
you declare something release critical or make a real release. It's 
almost tempting to just skip doing betas and go straight to release 
candidate when all PLIPs have been merged. 2 months for beta/release 
candidate state should suffice.


Wichert.

--
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Framework-Team mailing list
Framework-Team@lists.plone.org
https://lists.plone.org/mailman/listinfo/framework-team

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

[Wichert Akkerman]

On 2011-1-16 22:46, Martin Aspeli wrote:

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.


If you have many small deadlines they effectively become meaningless 
since people will just wait for the next one (to fly by). I've always 
tried to advocate a more continuous development pattern and I love 
Elizabeth's proposal.


Wichert.

--
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

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

[Wichert Akkerman]

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.

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

Re: [Framework-Team] [Plone-cvs] r40085 - buildouts/plone-coredev/branches/4.1/plips

[Wichert Akkerman]

On 9/20/10 17:58 , Rob Gietema wrote:
 Author: robgietema
 Date: Mon Sep 20 15:58:35 2010
 New Revision: 40085

 Added:
 buildouts/plone-coredev/branches/4.1/plips/plip10778-review-robgietema.txt
 Log:
 Added review for PLIP10778.

 Added: 
 buildouts/plone-coredev/branches/4.1/plips/plip10778-review-robgietema.txt
 ==
 --- (empty file)
 +++ 
 buildouts/plone-coredev/branches/4.1/plips/plip10778-review-robgietema.txt
 Mon Sep 20 15:58:35 2010
 @@ -0,0 +1,55 @@
 +PLIP 10778: Standalone UUID implementation
 +==
...
 +- The test code is in testing.py and tests.py, I prefer this being in a tests
 +  folder to not mess up the package root.

testing.py is something else: it contains utility code for writing 
tests. It does not contain tests itself. This is a common pattern.

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

Re: [Framework-Team] Plone roadmap

[Wichert Akkerman]

On 2010-9-5 17:29, Hanno Schlichting wrote:
 PluggableAuthService
 --

 There's tons of code based on this. I imagine we can first move the
 authentication API's into a WSGI middleware querying PAS as the
 backend.

This sounds like the mistake repoze.who 1 made. It turns out that for 
almost every use case you want more control over handling login 
behaviour than WSGI middleware can provide. It is much simpler to have a 
simple API to an AAA service and use that than to try pushing this into 
middleware.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

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

[Wichert Akkerman]

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

Wichert.

-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] plone.uuid behaviour

[Wichert Akkerman]

I'm noticing something odd with plone.uuid: if you use the adapter on an 
object which is marked with IAttributeUUID but which does not have a UID 
you get an Could not adapt TypeError when you do IUUID(obj). That 
error is misleading and confusing: the adaption worked fine, but ZCA 
does not like an adapter factory returning None. That makes the API a 
bit awkward, so I would suggest to replace the IUUID adaptor based 
approach with a simpler helper function.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] plone.uuid behaviour

[Wichert Akkerman]

On 2010-8-30 01:21, Martin Aspeli wrote:
 On 30 August 2010 07:37, Wichert Akkermanwich...@wiggy.net  wrote:
 I'm noticing something odd with plone.uuid: if you use the adapter on an
 object which is marked with IAttributeUUID but which does not have a UID
 you get an Could not adapt TypeError when you do IUUID(obj). That
 error is misleading and confusing: the adaption worked fine, but ZCA
 does not like an adapter factory returning None. That makes the API a
 bit awkward, so I would suggest to replace the IUUID adaptor based
 approach with a simpler helper function.

 -1 -- We need to have an adapter for looking this up. For example, the
 AT integration needs a different storage than IAttributeUUID, which is
 only one choice.

I did not see not use an adapter. I said use a simple method to make the 
API nicer. That method can use an adapter internally. For example:

_marker=[]
def getUUID(obj):
 u=IUUID(obj _marker)
 if u is _marker:
 raise TypeError(UUID not supported)
 return u

 You can do:

 uuid = IUUID(context, None)

Do you expect people to always use that calling convention? My guess is 
that it will forgotten more often than not, resulting in hard to 
interpret errors too often. The wrapper method has the advantage of
having a more intuitive name and can distinguish between missing UUID 
support and a None UUID, while not loosing any functionality.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

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

[Wichert Akkerman]

On 8/24/10 13:55 , Martin Aspeli wrote:
 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.

Isn't the FTP interface much easier for those people anyway?

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

Re: [Framework-Team] PLIP Ticket # 10687

[Wichert Akkerman]

On 2010-7-21 20:15, Christopher Warner wrote:
 It's just nomenclature. Essentially Aol, Yahoo, Google etc all provide
 login via OpenID. However they also provide or use other Federated or
 One sign-on to rule them all authentication systems. For instance;
 Facebook has an openid endpoint (which tends to work sporadically); They
 also have Facebook connect. Google tends to stick with email address or
 OpenID. Aol the same.

 Most of these services don't publicly advertise their use of OpenID as
 it kills mindshare and brand. Why sign-in to facebook with openid when
 you could sign in via Facebook connect which essentially gets one to
 login and use Facebook services. Same with all the others. You won't see
 Yahoo promoting Google by saying Did you know that you can login using
 your Google account. Or vice versa. Since Plone as a CMS doesn't have
 to be concerned about such things; we can be concerned about the overall
 confusion the user must experience with the OpenID URL dialog and do so.

 So, the idea is to concentrate solely on OpenID as the solution to
 single sign on and as Plone already supports OpenID. It's a two bird one
 stone equation. A user will understand logging into Yahoo or Google more
 readily than providing an OpenID URL. Thus, technically, any way you
 look at it. By easing the opportunity via a click, they are using
 OpenID, which makes it* *an easy and ubiquitous solution.

What will the result be? Will people be able to use the email address 
from their Google account on a Plone site? Or their facebook login?

Wichert.

-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] PlonePAS 3.x errors

[Wichert Akkerman]

On 2010-6-3 03:11, Laurence Rowe wrote:
 http://dev.plone.org/collective/changeset/118407 – plone pas cookies
 path set for /plone_site instead of always root - ticket #5665 –
 introduced a couple of test failures in Plone:

That changeset will break cookies as soon as you use virtual hosting. It 
needs to be reverted.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.

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

Re: [Framework-Team] [Plone-developers] PlonePAS 3.x errors

[Wichert Akkerman]

On 6/3/10 03:11 , Laurence Rowe wrote:
 http://dev.plone.org/collective/changeset/118407 – plone pas cookies
 path set for /plone_site instead of always root - ticket #5665 –
 introduced a couple of test failures in Plone:

I've reverted that change.

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

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

[Wichert Akkerman]

On 3/16/10 12:34 , Laurence Rowe wrote:

On 15 March 2010 09:13, Alexander Limil...@plone.org  wrote:

2010/3/12 Hanno Schlichtingha...@hannosch.eu


On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowel...@lrowe.co.uk  wrote:

On 12 March 2010 15:07, Hanno Schlichtingha...@hannosch.eu  wrote:

Currently listed for Plone 4.x are things like:

...

- Well formed, valid XHTML (as a foundation for easier theming via xdv)


That's really good to hear. Though I think semantic HTML or
sensible ids/classes to identify elements in pages is what I had in
mind with this point. Well besides the valid XHTML which is a
requirement for Chameleon as well.


It's also likely that we'll transition to using HTML5 (the XHTML-compatible
phrasing, ie. HTML5, but close your tags), and Deco as a layout engine
will be much happier if we do a revamp of the existing HTML structure. It's
quite messy in parts from the 8+ years in production, and while it has held
up well, it's time to adjust to how the web has evolved since then,
especially with focus on our upcoming theming capabilities.


We will almost certainly have to use an obsolete permitted doctype
string to get lxml / libxml2 to output xhtml correctly. This means
the intersection of the lists in
http://svn.gnome.org/svn/libxml2/trunk/xmlsave.c and
http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string
- xhtml 1.0 strict.


I'ld like to see a list of pros and cons of using HTML 5 as well. I am 
quite worried by the lack of proper support in existing browsers. None 
of them implement any of the existing HTML standards properly, and I 
fear that switching to the still unfinished HTML5 would be a several 
steps too far at this point in time.


Wichert.

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

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

[Wichert Akkerman]

On 3/16/10 18:40 , Alexander Limi wrote:

On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net
mailto:wich...@wiggy.net wrote:

I'ld like to see a list of pros and cons of using HTML 5 as well. I
am quite worried by the lack of proper support in existing browsers.
None of them implement any of the existing HTML standards properly,
and I fear that switching to the still unfinished HTML5 would be a
several steps too far at this point in time.


What parts in particular do you find are not working?


Some very basic things I've run into: some browsers can't style the 
legend tag, some browsers can't style input (esp. file) elements, some 
browsers drop the value of button elements, some browsers do weird 
things if you offset the body (to the point where jQuery no longer even 
tries to support that).


Given that today you can use div elements with classes to get the same 
results as HTML5 would give I don't see any point in trying to hasten a 
change to HTML5.


Wichert.

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

Re: [Framework-Team] Re: A suggestion to egg on add-on product authors

[Wichert Akkerman]

On 2010-3-12 19:37, David Glick wrote:

On 3/12/10 10:22 AM, Bill Campbell wrote:

On Thu, Mar 11, 2010, Alexander Limi wrote:


On Thu, Mar 11, 2010 at 4:24 PM, Eric Steeleems...@psu.edu  wrote:



On Mar 11, 2010, at 8:00 PM, Eric Steele wrote:

Thanks, Jon! I'll take care of this tonight. :)

Eric


On second thought, I'll hold off on this until we have installers
available.



Good move. Nothing is more frustrating to people than not having installers


Not having uninstallers is high on my list of frustrations.


Assuming you used the unified installer everything is self-contained, so
you can just delete the Plone directory it created.


I suspect he means uninstall support for add-on products. Neither 
GenericSetup nor CMFQuickInstaller properly support that.


Wichert.

--
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.

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

Re: [Framework-Team] Re: Body class

[Wichert Akkerman]

On 2010-1-17 21:36, Hanno Schlichting wrote:

On Sun, Jan 17, 2010 at 9:19 PM, Wichert Akkermanwich...@wiggy.net  wrote:

On 2010-1-17 16:52, Hanno Schlichting wrote:


mark_view
have_portlets
hide_columns
renderBase
bodyClass


is_view_template or whatever it is that manages IViewView. We've found it to
be very painful to manage IViewView now. In particular it appears to be
impossible to set when you render a template from a browser view.


mark_view actually sets the IViewView interface. The main_template does:

view nocall:view | nocall: plone_view;
dummy python: plone_view.mark_view(view);

which you should be able to do in any template that doesn't use
main_template. Otherwise it should work just fine to add
implements(IViewView) to your browser view class.

But maybe I'm missing what exactly you want to do.


This:

class MyView(BrowserView):
def __call__(self):
return aq_inner(self.context).some_template()

and make sure that IViewView is set when some_template is rendered. 
Currently that is impossible since mark_view does checks that are 
impossible to influence from the outside, and there is nothing MyView 
could set IViewView on itself.


Wichert.



--
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.

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

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

[Wichert Akkerman]

On 2009-9-25 17:09, Eric Steele wrote:

If there are no staunch objections to the above, I'll move forward with it.


I still object on the grounds that the markup produced by z3c.form is 
too different from standard Plone markup, which means using it in a site 
will complicate theming: themers will have to style two types of form 
markup. z3c.form provides the hooks to fix that, but someone needs to do 
the work.


Wichert.

--
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.

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

[Framework-Team] Re: [Plone-cvs] r29756 - plone.app.layout/branches/2.0/plone/app/layout/viewlets

[Wichert Akkerman]

That needs to throught the FWT at the very least. You can't just change 
that markup structure without some approval process - this can break 
every third party theme.



On 2009-9-17 08:04, Alexander Limi wrote:

If it broke the standard theme, I need to fix that too. We're putting
the personal tools in a pulldown regardless of whether the new theme lands.

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


On Wed, Sep 16, 2009 at 10:52 PM, Wichert Akkerman wich...@wiggy.net
mailto:wich...@wiggy.net wrote:

Shouldn't this be in a sunburst branch? I suspect this broke the
standard Plone skin.

On 2009-9-17 07:06, Alexander Limi wrote:

Author: limi
Date: Thu Sep 17 05:06:13 2009
New Revision: 29756

Modified:

  plone.app.layout/branches/2.0/plone/app/layout/viewlets/personal_bar.pt 
http://personal_bar.pt
Log:
Turn the personal actions into a pulldown menu.

Modified:
plone.app.layout/branches/2.0/plone/app/layout/viewlets/personal_bar.pt
http://personal_bar.pt

==
---
plone.app.layout/branches/2.0/plone/app/layout/viewlets/personal_bar.pt
http://personal_bar.pt (original)
+++
plone.app.layout/branches/2.0/plone/app/layout/viewlets/personal_bar.pt
http://personal_bar.pt Thu Sep 17 05:06:13 2009
@@ -6,21 +6,18 @@

h5 class=hiddenStructure
i18n:translate=heading_personal_toolsPersonal tools/h5

-ul id=portal-personaltools
-tal:condition=python:view.user_actions or not view.anonymous
-class=visualInline
-tal:block condition=not: view/anonymous
-lia
-   id=user-name
-   tal:attributes=href view/homelink_url
-img src= tal:replace=structure context/user.gif /
-span class=visualCaseSensitive
- tal:content=view/user_name
+dl class=actionMenu id=portal-personaltools
+tal:condition=python:view.user_actions or not view.anonymous
+tal:block condition=not: view/anonymous !-- TODO: Can we
nest these in a better way? --
+dt class=actionMenuHeader
+!-- The following a-tag needs to be clicked to dropdown the
menu --
+a id=user-name
+   tal:attributes=href view/homelink_url
+   tal:content=view/user_name
  John
-/span
-/a/li
-/tal:block
-
+/a
+/dt
+dd class=actionMenuContent
tal:actions repeat=action view/user_actions
li tal:define=icon action/icon|nothing;
  icon python:icon is not None and icon
or view.getIconFor(action['category'], action['id'], None);
@@ -36,6 +33,16 @@
/a
/li
/tal:actions
+/dd
+/tal:block
+/dl
+
+dl class=actionMenu id=portal-personaltools
+tal:condition=view/anonymous
+dt
+a href=
+   tal:attributes=href
string:${view/navigation_root_url}/loginLog in/a
+/dt
+/dl

-/ul
/div


--
Come build with us! The BlackBerryreg; Developer Conference in
SF, CA
is the only developer event you need to attend this year.
Jumpstart your
developing skills, take BlackBerry mobile applications to market
and stay
ahead of the curve. Join us from November 9#45;12, 2009.
Register now#33;
http://p.sf.net/sfu/devconf
___
Plone-CVS mailing list
plone-...@lists.sourceforge.net
mailto:plone-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plone-cvs



--
Wichert Akkerman wich...@wiggy.net mailto:wich...@wiggy.net   It
is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.





--
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.


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

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

[Wichert Akkerman]

I found myself having the same need as Vincent so I looked a little bit 
at z3c.form. The end result is very much a mixed blessing. As Vincent 
discovered it is not very hard to get z3c.form 2.1 to manage a list of 
items. In my example I have this interface which is repeated:


class IInformationLink(Interface):
A link to more information related to a risk.

url = schema.URI(
title = _(uURL),
required = True)
description = schema.TextLine(
title = _(uDescription),
required = False)


this has to be an Interface: if you use a zope.schema.Schema things 
break badly. You can then use this in your main interface like this:


class IRisk(form.Schema, IRichDescription, IBasic):
A possible risk that can be present in an organisation.

links = schema.List(
title = _(uInformation links),
description = _(uA list of links to webpages which provide
u more information on this risk.),
required = False,
value_type = schema.Object(
title = _(uLink),
schema = IInformationLink))

This works, but the resulting markup from z3c.form is quite ugly: a big 
mess of divs, nested divs, label elements inside div.label elements, 
etc. The UI it presents is also very confusing: 
https://photos-1.getdropbox.com/i/o/JmLD1SNVPJbwy12pgo-FYOWLsG-9L9lKNdBCm6yIfok 
is an example. Notice how it is very unclear that the Add/Remove buttons 
at the button belong to the 'Links' field. It gets even worse if you try 
to insert some data: 
https://photos-1.getdropbox.com/i/o/ZrPquRJE5oEOZn1DhCdS6ZTDArNqKhAZ15UGtF-3sqA 
. Part of this is a flaw in zope.schema which does not except URLs 
without a http: prefix (which will confuse users). The 'The system could 
not process the given value' is a mysterious one and reveals an 
essential bit that is not documented: z3c.form requires a IObjectFactory 
factory for the IInformationLink interface. This is an multi-adapter 
(with 4 facets, almost none of which you will ever need) and requires 
the name of the adapter to be set to the interface (feels like ZCA abuse 
to me):


from zope.interface import Interface
from zope.interface import implements
from zope.component import adapts
from z3c.form.interfaces import IObjectFactory

class InformationLinkFactory(object):
adapts(Interface, Interface, Interface, Interface)
implements(IObjectFactory)

def __init__(self, context, request, form, widget):
pass

def __call__(self, value):
return dict(value)

which you can register in zcml like so:

adapter factory=.risk.InformationLinkFactory
  name=euphorie.content.risk.IInformationLink /

and then it still does not work since it requires that your object 
factory returns something that zope.schema.Object can handle. In other 
words: it is not possible to return dictionaries.


Next attempt: use a simple object that can implement IInformationLink:

class InformationLink(object):
implements(IInformationLink)

def __init__(self, value):
self.url=value[url]
self.description=value[description]


class InformationLinkFactory(object):
adapts(Interface, Interface, Interface, Interface)
implements(IObjectFactory)

def __init__(self, context, request, form, widget):
pass

def __call__(self, value):
return InformationLink(value)


and that finally works. The lessons I have learned from this are:

- z3c.form produces very awful HTML
- z3c.form produces very confusing user interfaces
- z3c.form documentation is indeed incomplete (no mention of
  ObjectFactory)
- z3c.form you can do cool stuff with it, although I am not convinced
  it is much better than hand-coding the form

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.


Wichert.

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

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

[Wichert Akkerman]

On 9/10/09 16:43 , 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?


To the general case. There are lots of unneeded divs, weird things like
div class=errordiv class=errorerror message/div/div or
div class=labellabelsome label/label/div and even some empty 
divs divdiv//div. I suspect that at least 50% of the markup 
generated by z3c.form can safely be removed and the rest replaces with a 
simple set of fieldset, label, legend and form elements with perhaps an 
extra p or em for error messages.



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


It's certainly better than formlibs. ;-)


The z3c.form documentation seems to follow the implementation structure 
and often reads like a doctest instead of human friendly documentation. 
It's nice that there is documentation, but it is not ideal.



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


I think there are two reasons that that is true: Plone did not have 
anyone the last few years with both the right skillset and necessary 
time to make good forms, and none of the form-frameworks support a mix 
of hand-written and generated forms (or perhaps they do and there is 
just no documentation for it). Going forward we should aim to do better 
and not use existing form frameworks as excuse for not doing better.



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


From what I've seen today it is worse than Archetypes. Perhaps we have 
different criteria of what good markup should look like.


Wichert.



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

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

[Wichert Akkerman]

On 2009-9-10 17:23, Martin Aspeli wrote:

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 am saying that for Plone z3c.form is a possibly good alternative for 
generated forms, but that right now in my opinion it needs some work to 
meet Plone user interface and markup standards. I am also saying that I 
personally am not willing to do that work since my priorities are 
elsewhere. I am not trying to provide stop energy here - my only goal is 
to make sure that we are not going to reduce the Plone UI because our 
attention is too focused on shiny new technology.



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.


The markup for z3c.form is both overly complex as well as very different 
than the markup patterns Plone uses. This means that styling a Plone 
site which uses z3c.form as well as Archetypes is twice as hard since it 
requires writing CSS for two different markup patterns.


Wichert.

--
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.

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

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

[Wichert Akkerman]

On 2009-8-20 06:54, Andreas Zeidler wrote:

On Aug 13, 2009, at 10:18 PM, Wichert Akkerman wrote:

On 2009-8-13 22:16, Alexander Limi wrote:

FWIW, Mozilla runs their entire project without a contributor agreement
— so we are already way ahead of what most large open source projects do
on this front. :)


Or way behind when shit hits your fan. Those agreements exists for
good reasons.


i think alex' we referred to plone here, not mozilla... ;)


yay for language ambiguity :)

Wichert.


--
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.


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

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

[Wichert Akkerman]

On 8/7/09 12:13 , Wichert Akkerman wrote:


I'm afraid I also don't buy the lookup mechanism mentioned in the PDF:
you are essentialy creating a persistent cache system, which means that
suddenly page views can trigger ZODB writes, which is very bad for high
performance sites. It also will miss all user changes created directly
in external user sources such as LDAP, AD and SQL databases, leading to
incorrect and possibly correct behaviour.


That should be 'possibly confusing'

Wichert.


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

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

[Wichert Akkerman]

On 8/7/09 12:20 , Ralph Jacobs wrote:

Wichert Akkerman wrote:

On 8/7/09 12:13 , Wichert Akkerman wrote:


I'm afraid I also don't buy the lookup mechanism mentioned in the PDF:
you are essentialy creating a persistent cache system, which means that
suddenly page views can trigger ZODB writes, which is very bad for high
performance sites. It also will miss all user changes created directly
in external user sources such as LDAP, AD and SQL databases, leading to
incorrect and possibly correct behaviour.


That should be 'possibly confusing'

Wichert.


Hi Wichert,

This all has been discussed in the PLIP proposal, so please contact the
framework team for that.


I just checked the history of the trac ticket since I was surprised the 
framework missed this. The framework team has only voted on the idea of 
using a users full name instead of the userid in the Plone user 
interface. The implementation proposal was added three weeks, and will 
be taken into account in the next review round when the PLIP 
implementations will be reviewed. So please consider this a very early 
(and very unofficial since I am not a framework team member) review 
comment: I do like the idea to use a users full name, but I do see some 
problems with the current implementation strategy that should be addressed.


Wichert.


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

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

[Wichert Akkerman]

On 2009-8-6 06:30, David Glick wrote:

Does anyone know the background or justification for
http://dev.plone.org/old/archetypes/changeset/9318 where the switch to
an IPublishTraverse adapter first happened? Wichert?


The reasoning behind that is a) we want to get rid of __bobo_traverse__ 
methods and b) this change transparently exposes all image where the 
original code only hardcoded exposure of a field with the name 'iage'.


I don't quite see what the problem is with that code; can someone 
explain that?


Wichert.


--
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.

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

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

[Wichert Akkerman]

On 7/30/09 2:00 AM, Martin Aspeli wrote:

2009/7/30 Erik Rosepsuc...@grinchcentral.com:

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.


Indeed: to protect code that makes up the Plone CMS application. I don't 
think a wrapper for a third party javascript editor is really that 
important that we require it be owned by the foundation.


Wichert.

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

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

[Wichert Akkerman]

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

On Tue, Jul 28, 2009 at 12:07 AM, Geir Bækholt · Jarnbaekh...@jarn.com  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.


Wichert.


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

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

[Wichert Akkerman]

On 7/29/09 8:09 AM, Martin Aspeli wrote:

Jon Stahl wrote:

On Tue, Jul 28, 2009 at 12:07 AM, Geir Bækholt ·
Jarnbaekh...@jarn.com 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. :)


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.


Wichert.

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

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

[Wichert Akkerman]

On 7/27/09 10:52 PM, Geir Bækholt · Jarn wrote:


On 27. juli. 2009, at 22.12, Jon Stahl wrote:


Absolutely. Getting the code into the Foundation's long-term
conservancy is very much worth doing if it's not too terribly hard.
I've not been through the process before of moving Collective code to
the Foundation, but I know Jarn has done this, so perhaps Geir can
enlighten us there on whether any additional steps are required other
than making sure all contributors have signed the Contributor
Agreement.



I don't know of any special considerations beyond the normal ones.
- Code must meet Plone's quality assurance level. (i.e pass PLIP review)
- All contributors must have signed the agreement.
- Some sort of consensus that the code is of general use to Plone and
the community, and that the community is the best entity to manage
maintenance long term.
- Licensing


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.


Wichert.

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

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

[Wichert Akkerman]

On 7/27/09 4:56 PM, Rob Gietema wrote:


This shouldn't be an issue at all since 99.9% of the code is done by me,
just some small bugfixes by others who also have commit access to Plone
SVN and I'm sure won't mind.


That's not good enough: you need explicit approval.

Wichert.


___
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

[Wichert Akkerman]

On 7/27/09 1:38 PM, Rob Gietema wrote:

Hi,

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

1) The current code base is located in the Collective. Since TinyMCE
will be the default editor in Plone 4 should I move (copy) the code base
to Plone SVN?


-0

I see no reason to move it.


2) I'm currently using the Products namespace for the package. Would it
be better to switch to the plone(.app) namespace for Plone 4 (and keep
the Products.TinyMCE for Plone 3)?


-1

There is no benefit to moving, and this will make it harder to maintain 
Plone 3 and 4 trees in parallel.


Wichert.

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

[Framework-Team] Plone 4 dependencies

[Wichert Akkerman]

I seem to remember the plan was to target Plone 4 for CMF 2.2 and Zope
2.11, but as you can see below that does not appear to be possible.

Wichert.


- Forwarded message from Jens Vagelpohl j...@dataflake.org -

From: Jens Vagelpohl j...@dataflake.org
To: Zope-CMF List zope-...@zope.org
Subject: Re: [Zope-CMF] Zope dependency
Message-Id: 7d23df64-b4dc-4c8e-8a51-188e8b34a...@dataflake.org
Date: Tue, 26 May 2009 10:57:08 +0200
X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.3

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On May 26, 2009, at 10:21 , Wichert Akkerman wrote:

 Previously Jens Vagelpohl wrote:
 The CMF eggs, even on trunk, still advertise compatibility with Zope
 2.10. I believe we had agreed to target Zope 2.12 with trunk - please
 correct me if that's wrong. If we do want Zope 2.12 I would like to  
 go
 through before the first CMF 2.2 beta and do the following:

  - adjust all setup.py files to show the Zope2 egg as dependency,
 which will imply the Zope2 = 2.12dev dependency

  - go through and delete all BBB code for Zope versions earlier than
 2.12

 If anyone thinks that's a bad idea please speak up.

 I think we are targetting Plone 4 at CMF 2.2 and Zope 2.11 at the
 moment, so that would be bad for us.

I'm guessing you are not aware that there already is a hard dependency  
in CMFDefault. In essence, I would not be setting a new policy, I  
would document the current situation.

jens



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkobruQACgkQRAx5nvEhZLJadACfa9oLhpOAluaPN4QNqGf8UW26
4V8AmwSNnABEZwAQwpq1XddErphVHW0o
=o1v4
-END PGP SIGNATURE-
___
Zope-CMF maillist  -  zope-...@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

- End forwarded message -

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Framework-Team] Plone 3.3rc3 tagged and uploaded

[Wichert Akkerman]

I have tagged and uploaded Plone 3.3rc3. This is the third release
candidate for Plone 3.3, and hopefully the last. It restores IE6 support
in KSS, and features translations improvements and compatibility with
chameleon.

If no critical bugs are found we will release this unmodified as 3.3
final in two weeks. If any changes are necessary we will make another
release candidate and repeat the process.

Regards,
Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

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

[Wichert Akkerman]

Can we please stop the cc-o-rama? Seeing the entire thread tree times is
a bit much..

Previously Martin Aspeli wrote:
 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.

+1

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] Re: Plone 3.5

[Wichert Akkerman]

Previously Andreas Zeidler wrote:
 Andreas Zeidler wrote:
 Hanno Schlichting wrote:
 The general idea that seems to have met some consensus is to go for a
 Plone 3.5 release up next.
 
 sounds good to me, +1.
 
 actually, i think it should still be plone 4.0 (with the remaining 
 features deferred to 5.0 or later).  otherwise i think it's a good idea 
 in the sense of release early, release often.

+1

In hindsight I feel it was a mistake to assign a version number to Plone
trunk. It might end up being Plone 5, 6, 7 or 3000. Using Plone 4
instead of 3.5 means that we will not break  our promise to never break
stability in the 3.x, something I feel quite strongly about.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] Re: Version Support Confusion

[Wichert Akkerman]

Previously Carsten Senger wrote:
 Hi Steve,
 
 Steve McMahon schrieb:
 Here's a draft for a public policy statement. I invite feedback and
 wordsmithing.
 
 Thanks for writing the draft. I've only 2 comments.
 
 1. I saw different working names for the policy and I think it should be 
 something obvious like Plone [Version] Support Policy or Plone 
 Lifecycle Support Policy.
 
 2. A table with the current/future versions would help. It's not really 
 part of the policy, but a table helps to understand it and gives an idea 
 how long the support cycles are.
 
  (supposable)
 Series   Release Date
 2.53.x4.x
 Release
 2.5  M  -  -  Sep 2006
 
 3.0  M  M  -  Aug 2007
 
 3.1  S  M  -  May 2008
 
 4.0 EOL M  M  2010 or 2011 (???)
 
 4.1 EOL S  M  undecided

This table is incorrect: you should consider all 3.x series to be a
single 3.x release. When 3.1 was released we stopped all support for
3.0. When 3.2 was released we stopped support for 3.1. And when we
release 3.3 we will stop supporting 3.2. The 3.x releases try very
hard to maintain compatibility, so this should not be problematic.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] Version Support Confusion

[Wichert Akkerman]

Previously Steve McMahon wrote:
 Unless anyone can make a case for re-evaluation, I hope we can take a
 common line on this in discussions in the other lists. In particular,
 we should be careful in any statement that Plone 2.5.x is unsupported
 to make sure that this only refers to active maintenance and not to
 security support.

Just as important: we should communicate this policy clearly. I suggest
a post to plone-announce describing this policy and an easily findable
document on plone.org (preferably reachable in 2 or 3 clicks from the
frontpage).

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Framework-Team] [Fwd: Re: [Checkins] SVN: z3ext. do not use z3c.autoinclude]

[Wichert Akkerman]

This is possibly a valid concern for us as well. I wonder if there is 
room for optimization here - our startup time is already quite slow.



 Original Message 
Subject:Re: [Checkins] SVN: z3ext. do not use z3c.autoinclude
Date:   Mon, 06 Apr 2009 18:11:52 +0600
From:   Nikolay Kim fafhr...@gmail.com
To: Wichert Akkerman wich...@wiggy.net
CC: check...@zope.org




 Previously Nikolay Kim wrote:


 Log message for revision 98920:
   do not use z3c.autoinclude



 Out of curiosity: why?



too slow. i create z3c.recipe.autoinclude instead of z3c.autoinclude.
z3c.recipe.autoinclude generates static list of includes
startup time with autoinclude ~ 40 sec.
with static list ~ 17 sec

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

Re: [Framework-Team] [Fwd: Re: [Checkins] SVN: z3ext. do not use z3c.autoinclude]

[Wichert Akkerman]

On 4/6/09 4:03 PM, Andreas Zeidler wrote:

On Apr 6, 2009, at 2:14 PM, Wichert Akkerman wrote:
This is possibly a valid concern for us as well. I wonder if there is 
room for optimization here - our startup time is already quite slow.


have you informed/asked ethan about this?


I couldn't find a working email address for him since he left TOPP.

Wichert.



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

[Framework-Team] Plone 3.3rc2 tagged and uploaded

[Wichert Akkerman]

I have tagged and uploaded Plone 3.3rc2. This is the second release
candidate for Plone 3.3, and fixes several problems that where found in
3.3rc1.

If no critical bugs are found we will release this unmodified as 3.3
final in two weeks. If any changes are necessary we will make another
release candidate and repeat the process.

Regards,
Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Framework-Team] Re: [Plone-installers] [Plone-developers] Plone 3.3rc11 tagged and uploaded

[Wichert Akkerman]

On 4/2/09 9:42 AM, Vincent Fretin wrote:

Hi Wichert,

Can you release Products.CMFEditions 1.2? There is an i18n fix in it.
   


Can you port those changes to trunk first? I don't want to cut a release 
until all fixes have been merged to trunk to prevent future regressions.


Wichert.

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

Re: [Framework-Team] Plone 3.3rc11 tagged and uploaded

[Wichert Akkerman]

On 3/31/09 6:12 AM, Jon Stahl wrote:

Wichert Akkerman wrote:

I have tagged and uploaded Plone 3.3rc1. This is a first release
candidate, so please everyone: test the hell out of it!
If no critical bugs are found we will release this unmodified as 3.3 
final in two weeks. If any changes are necessary we will

make another release candidate and repeat the process.

Should this be announced more broadly?  Framework  dev lists are 
pretty small and haven't seemed to create enough testing for some past 
releases (in my casual observations).   Do you want feedback/testing 
from the larger world of plone-users?


Yes, but I want to have installers ready before doing that.

Wichert.

--
Wichert Akkermanwich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.


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

[Framework-Team] Re: [Plone-developers] Plone 3.3rc11 tagged and uploaded

[Wichert Akkerman]

Previously robert rottermann wrote:
 Wichert Akkerman schrieb:
  I have tagged and uploaded Plone 3.3rc1. This is a first release
  candidate, so please everyone: test the hell out of it! 
  
 
 hi there,
 Is there a way to use buildout for this?

If you have a Plone 3.2 buildout just change the version number in your
buildout.cfg to 3.3rc1 and rerun buildout.

The plone3_buildout template from the latest ZopeSkel release should be
able to create a 3.3rc1 buildout dircetly.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Framework-Team] Plone 3.3rc11 tagged and uploaded

[Wichert Akkerman]

I have tagged and uploaded Plone 3.3rc1. This is a first release
candidate, so please everyone: test the hell out of it! 

If no critical bugs are found we will release this unmodified as 
3.3 final in two weeks. If any changes are necessary we will
make another release candidate and repeat the process.

Regards,
Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] concerns about our beta process

[Wichert Akkerman]

Previously Jon Stahl wrote:
 I am a little concerned, though, that our beta process is not getting us 
 the feedback we need.  To but it briefly: there's no easy way to get the 
 beta and try it out.  I can't find any place to download it, or any 
 documented instructions for getting it via buildout.  
 http://plone.org/products/plone/releases/3.3, which seems the most 
 logical place, offers no clue.

That is simply because the installers have not yet been generated. I
expect Steve and Sidnie to finish them soon.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] Re: Quick team meeting

[Wichert Akkerman]

Thanks for the excellent summary!

Previously Ross Patterson wrote:
 The last item concerned future meetings.  When should we do this meeting
 in the future?  Every other week or every third work?  Thursday?
 Friday?  Would all of the FWT members weigh in with both preferences and
 outright scheduling conflicts for future meetings.  Then we can
 reconcile that information and schedule a regular meeting.

Workdays do not work for me. Mornings in the weekend are probably best.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] Quick team meeting

[Wichert Akkerman]

Previously Tom Lazar wrote:
 On 11.03.2009, at 21:25, Calvin Hendryx-Parker wrote:
 
 Actually, I don't think it would be a bad thing for the 3 team to  
 join.  It would help with the project continuity.
 
 agreed. in this case, however, i'll be en route from norway, and so  
 will andi.

Fridays are never doable for me. Saturday mornings (say 10h CET or so)
are probably best for me.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Framework-Team] Plone 3.3b1 tagged and uploaded

[Wichert Akkerman]

I have tagged and uploaded Plone 3.3b1. This is a first beta release, so
please everyone: test the hell out of it!

Unless any unexpected problems surface I intend to make a release
candidate release in 3 weeks.

Regards,
Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Framework-Team] Reminder: PLIP merges are due

[Wichert Akkerman]

The response to my mail from last week about PLIP merges has been a
disappointing: only 4 out of 12 PLIPs have been merged so far. In
order to prevent this from becoming an everlasting process I am going
to set a deadline:

  PLIPs have to be merged by the end of Saturday, March 7. Any PLIPs not
  merged by then will be postponed until Plone 3.4.

When merging keep in mind that you should not modify any branches that
are used by Plone 3.2 (or older versions). That might mean you will have
to create a new maintenance branch for Plone 3.x and update plonenext
3.2 and plone-coredev.

This is the list of unmerged PLIPs:

Maurits van Rees:
- PLIP 197: Add FeedParser as external requirement instead of shipping with it

Florian Schulze:
- PLIP 232: Resource Registries Improvements

Calvin Hendryx-Parker
- PLIP 234: Standardizing our use of INavigationRoot

Martin Aspeli:
- PLIP 239: Adapterise the Extensible Indexable Object Wrapper

Andreas Zeidler:
- PLIP 241: Clean up auto-sort: auto-order code
- PLIP 246: View for rendering events as an iCalendar file

Ethan Jucovy:
- PLIP 247: Automate ZCML Loading for Plone Plug-ins

Regards,
Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] Re: Final review report

[Wichert Akkerman]

On 2/5/09 9:45 AM, Raphael Ritz wrote:

Andreas Zeidler wrote:

hi wichert,

On Feb 4, 2009, at 10:11 AM, Wichert Akkerman wrote:

The deadline for the PLIP review report was four days ago. From what I
can see not all reviews are in, and no report has been written yet.

Can I please get a proper report which covers the PLIPs that 
have been

reviewed properly, and a date when the rest will be ready as well?


steve has compiled and posted an overview last saturday. 


Which I had updated on Sunday

 http://lists.plone.org/pipermail/framework-team/2009-February/002675.html 



to include my late coming reviews as well.

Regarding a date when the rest will be ready
is pure guess work. Of course ASAP - whenever
that my be. (I hope to get my last one in
tonight or tomorrow).

I don't know how other reviewers see this but
at least I didn't consider my positive responses
in all cases to mean ready for merge as we are
entering a second round now: authors picking up
on reviewer comments.


Interesting, that is not how I interpret a +1 at all. To me there are 
two possible outcomes right now: declare a PLIP ready for merging, or 
declare it unready for merging for a number of reasons. There are PLIPs 
that are fit for merging right now. How would you score those if your +1 
has another meaning?



Example:

 http://svn.plone.org/svn/plone/review/plip246-ical-feed/REVIEW-NOTES.txt

What I mean here is that even if merged as is
right now I would consider it OK yet I seriously
think that at least the first two points I mention
in my review notes would improve things even
further. But maybe others have different views
on that?


With that reasoning in my opion that is a negative for merging right now 
with those two points as criteria that need to be met before merging later.


So... now that the meaning of +1 is suddenly no longer sure, can I 
please get a list of PLIPs that are ready for merging right now?


Wichert.


--
Wichert Akkermanwich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.


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

[Framework-Team] Final review report

[Wichert Akkerman]

The deadline for the PLIP review report was four days ago. From what I
can see not all reviews are in, and no report has been written yet.

Can I please get a proper report which covers the PLIPs that have been
reviewed properly, and a date when the rest will be ready as well?

Regards,
Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] plone.z3cform and absoluteURL

[Wichert Akkerman]

Previously Laurent Mignon wrote:
 How can I do to have getMultiAdapter((myWrappedForm, request),
 IAbsoluteURL) working when myWrappedForm is a z3c.form wrapped py
 plone.z3cform.layout.FormWrapper?

This sounds like a question for another list (product-developers or
possible plone-develop).

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Framework-Team] Re: Final review report

[Wichert Akkerman]

On 2/4/09 5:48 PM, Steve McMahon wrote:

Hi Wichert,

Does this give you what you need? If not, I'll be happy to add detail.
   


Please add some detail. In particular for rejected PLIPs it should state 
why they were rejected and what the PLIP author has to do to get them 
accepted in the next round.


Wichert.



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

Re: [Framework-Team] PLIP Tallies

[Wichert Akkerman]

On 1/31/09 2:18 PM, Tom Lazar wrote:
i've updated my local buildout and the the site works fine now, i do 
get some 404 for the images in the timeline 
(http://localhost:8080/newsite/history_compare_with_current.png) etc, 
no showstopper, obviously, but if you can fix that still today i can 
give your review an unconditional +1


I can't, as I stated in the readme I need some help with that due to my 
complete lack of graphic skills. I'll try to get Danny to do that.


Wichert.

--
Wichert Akkermanwich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.


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

Re: [Framework-Team] Re: NuPlone and Plone 3.2

[Wichert Akkerman]

On 1/27/09 1:28 PM, Andreas Zeidler wrote:

On Jan 13, 2009, at 12:01 AM, Martin Aspeli wrote:

Martin Aspeli wrote:

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.


you got the release year wrong, but that's just a minor detail...

apart from that i'm wondering what the status is?!  it's been two full 
weeks since the last post in this thread and 3.2.1 is still not out.  
is anything blocking this or why does it take that long?  wichert, can 
you comment, please?


There was never a rush to do a 3.2.1 since this is something that can be 
(and was) fixed fully in the installers. For the rest we'll do 3.2.1 
according to the normal schedule next week.


Wichert.


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

[Framework-Team] Concern about review progress

[Wichert Akkerman]

We are not almost a week into the two review period, and at this point
two out of the required 22 reviews have been done, two PLIPs have not
been assigned a second reviewer and none of PLIPs have received UI
feedback. That lack of progress has me a bit worried.

Please do not make this a last-minute review rush! 

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] PLIP 197 ready for review: feedparser as external dependency

[Wichert Akkerman]

How come this PLIP has not been reviewed yet? I think we agreed to
encourage people to submit PLIPs early so the framework team can start
earlier as well in order to reduce the workload?

Wichert.


Previously Maurits van Rees wrote:
 
 The buildout is here:
 https://svn.plone.org/svn/plone/review/plip197-feedparser
 
 Note that I will not be online the next few days, so be patient when
 you have questions.
 
 I'll paste the README.txt below for convenience.
 
 
 PLIP 197: Add FeedParser as external requirement instead of shipping with it 
 
 
 See http://plone.org/products/plone/roadmap/197
 
 Basically the only thing that needs doing is:
 
 - Remove portlets/feedparser.py from plone.app.portlets.
 
 - Instead add FeedParser as requirement in setup.py.
 
 This has been done on this branch (see src/plone.app.portlets in this
 buildout):
 
 
 https://svn.plone.org/svn/plone/plone.app.portlets/branches/plip197-feedparser-as-external-egg
 
 
 One possible gotcha is that the *package* is called ``FeedParser`` and
 the *module* contained in that package is called ``feedparser``.
 ``easy_install`` can handle both spellings just fine.  But I once
 encountered problems when using the lowercased name in setup.py.  See
 http://dev.plone.org/plone/ticket/7299 (which is where this plip
 originated).  I could not reproduce that later, but I say we call the
 dependency ``FeedFeeder`` and everything should work.
 
 ``bin/test`` will run the plone.app.portlets tests.
 
 
 Happy New Year!
 
 -- 
 Maurits van Rees | http://maurits.vanrees.org/
 Work | http://zestsoftware.nl/
 This is your day, don't let them take it away. [Barlow Girl]
 
 
 ___
 Framework-Team mailing list
 Framework-Team@lists.plone.org
 http://lists.plone.org/mailman/listinfo/framework-team

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Framework-Team] PLIP 238 review buildout available

[Wichert Akkerman]

I have just created the review buildout for PLIP 238. For reference I
have included the implementation notes below.


Implementation notes


This buildout contains the base implementation for PLIP 238: disable
inline edit by default.

The implementation is trivial: the option introduced in
http://dev.plone.org/plone/changeset/21784 is used to disable inline
edit.

This is only done for new sites: no migration is added to prevent
unexpected behavioural changes in existing sites.


Needed documentation changes


User manuals should be updated to reflect that inline edit is disabled by
default, and can be enabled through the ZMI.


Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] Multiple workflows (Was: PLIP lifecycle)

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 Tres Seaver wrote:
 
 You can actually have multiple workflows for a given type.  I may be the
 only person who has ever actually used the feature, but it is truly
 helpful at times.
 
 I'd be interested to hear what kind of situations it's useful for?

I saw a use case recently where there were separate workflows for edit
and view permissions.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] Re: PLIP's for 3.x releases in Trac???

[Wichert Akkerman]

Previously Matthew Wilkes wrote:
 
 On 25 Dec 2008, at 17:39, Hanno Schlichting wrote:
 
 we just decided to move all
 PLIP's to Trac for Plone 4 and no longer use plone.org/products/plone
 for it.
 
 Incidentally, I missed this, where was it discussed?  Are we going to  
 have a new workflow for PLIPs?

I was wondering the same thing. It very much looks like the framework
team selection process somehow always invented a new PLIP process behind
closed doors.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

[Framework-Team] Re: [Plone-developers] Plone 4 Framework Team Selection List

[Wichert Akkerman]

Previously Steve McMahon wrote:
 The Plone 4 Framework Team has been selected. Congratulations to:
 Matthew Wilkes, David Glick, Calvin Hendryx-Parker, Laurence Rowe,
 Martijn Pieters, Erik Rose, and Ross Patterson. As anyone who's been
 following Plone development will immediately see, this is an awesome
 team!

That is an excellent group of highly skilled people, my congratulations
to them.

I am however very disappointed by the fact that this framework team only
consists of highly skilled developers and does not have anyone with user
interface design experience. Plone used to have a very clean and simple
interface, but over the years it has become more complex and
disorganised, and as a result we now too often see new people being
confused by Plone's user interface. The people who used to have a lot of
influence over the user interface design of Plone (people like Alexander
and Geir) are too busy with other things these days, and that is very
noticable. Plone desperately needs to make good UI design part of its
process again, and that is something that developers simply can not do.
I have had the pleasure to work a lot with UI designers this year and I
have learned very directly that our developer minds are simply not
wired correctly for it.

For the Plone 3 framework team we have Danny on the framework team: he
is not a top-notch developer but has he a lot of UI design experience,
and that has already proven to be a very positive influence.

For Plone 4 that kind of experience is even more critical since we aim
to not only refactor a lot of the Plone codebase but also its entire
user interface. Hence my surprise when the new framework team does not
contain anyone with proper UI design skills. I have heard the argument
that the framework team will consult with UI designers where needed, but
that is exactly the wrong approach and will lead to the situation we
have right now. User interface design needs to be part of the process,
not an optional component.

I strongly suggest that this decision is reconsidered and someone with
proven UI design experience is added to the framework team.

Regards,
Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Plone-developers] [Framework-Team] Re: Plone 4 Framework Team Selection List

[Wichert Akkerman]

On 12/18/08 11:43 AM, Tom Lazar wrote:

and therefore should be reflected in the membership of the
group which makes decisions based on those factors.


i think that conclusion is the only part where we disagree. can we 
agree at least on that? ;-)


Not without a way to guarantee that user interface will be a full part 
of the process, which incudes the guarantee that everything will go 
through a proper user interface review done by people with the right 
skillset, and can be rejected even if just the user interface is not up 
to par.


Wichert.


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

Re: [Plone-developers] [Framework-Team] Re: Plone 4 Framework Team Selection List

[Wichert Akkerman]

Previously Tom Lazar wrote:
 this is a fundamental change in how the framework team will operate  
 from now on. we're no longer just a group of individuals who quietly  
 need to make some sense of PLIPs and their implementation on their own  
 but more of a clearing house.

So, do I understand correctly that the group of people that selected the
framework team (which does not include those selected people itself) has
also gone one step further and defined a whole new process for how that
team will work?

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

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

Re: [Framework-Team] Supported Plone Releases

[Wichert Akkerman]

Previously Calvin Hendryx-Parker wrote:
 I just noticed that on the PSC the Plone 2.5.5 release is listed as  
 not supported.  I'd suggest that unless we have sent an email to the  
 announce list that the latest 2.5.x relases still be supported.  I  
 also noticed that some of the older 3.1 releases are still listed as  
 supported.  Is there a reason that those aren't listed as unsupported  
 since there is a 3.1 that would supersede them?

Why bring this up on the framework team list? The framework team is not
a governing body.

Wichert.

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

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

Re: [Framework-Team] Supported Plone Releases

[Wichert Akkerman]

On 12/10/08 5:24 PM, Calvin Hendryx-Parker wrote:



On Dec 10, 2008, at 11:22 AM, Wichert Akkerman wrote:


Previously Calvin Hendryx-Parker wrote:

I just noticed that on the PSC the Plone 2.5.5 release is listed as
not supported.  I'd suggest that unless we have sent an email to the
announce list that the latest 2.5.x relases still be supported.  I
also noticed that some of the older 3.1 releases are still listed as
supported.  Is there a reason that those aren't listed as unsupported
since there is a 3.1 that would supersede them?


Why bring this up on the framework team list? The framework team is not
a governing body.



I was pointed this direction by Steve,  where should this go?


Likely candidates would be: the foundation board, the 2.5 release 
manager and the developers list.


Wichert.



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

Re: [Framework-Team] atreferencebrowserwidget switch discussion

[Wichert Akkerman]

Previously Lucie Lejard wrote:
 I wanted to bring your attention to this ticket that I just opened:
 https://dev.plone.org/plone/ticket/8779
 
 And hannosch comment:
 I think it might be worth considering it for Plone 3.3. Since the PLIP 
 deadline is over, it might have to wait for 3.4, though.

It's definitely too late for 3.3.

Wichert.

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

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

Re: [Framework-Team] Re: Fwd: Including a Documentation section in each PLIP

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 I do agree that documentation should be part of PLIPs. One simple thing 
 would be to just have a free-text on the PLIP that identifies the 
 documentation that is either required or extant for the PLIP, so that 
 people who look at the PLIP later can find a pointer to where there's 
 more documentation.

I would much rather see the equivalent of the what-is-new-in-python-x.y
documents: a thorough explanation of every change, its rationale, and
the inpact that has on both existing and new code. That would then be a
very useful starting point for the documentation team to update/extend
other documentation.

Wichert.

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

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

Re: [Framework-Team] Re: Fwd: Including a Documentation section in each PLIP

[Wichert Akkerman]

Previously Israel Saeta Pérez wrote:
 On Sat, Nov 15, 2008 at 5:08 PM, Wichert Akkerman wrote:
  Previously Martin Aspeli wrote:
  I do agree that documentation should be part of PLIPs. One simple thing
  would be to just have a free-text on the PLIP that identifies the
  documentation that is either required or extant for the PLIP, so that
  people who look at the PLIP later can find a pointer to where there's
  more documentation.
 
  I would much rather see the equivalent of the what-is-new-in-python-x.y
  documents: a thorough explanation of every change, its rationale, and
  the inpact that has on both existing and new code. That would then be a
  very useful starting point for the documentation team to update/extend
  other documentation.
 
 If the documentation has to wait for version releases it will always
 be behind code, which leads (among other causes) to the actual state
 of some areas of the plone.org documentation: outdated. Of course the
 documentation team has great responsibility here, but trying to keep
 code as important as code will help.

You misunderstood my point. What I want to see is for each PLIP to have
the equivalent of a section of the what-is-new-in-python-x.y documents.
That does not require waiting for a release.

Wichert.

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

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

Re: [Framework-Team] 3.3 timeline

[Wichert Akkerman]

The proposal we came up with today at lunch is:

The PLIP implementation deadline will be half January, after which the
framework team has a two week period to review all PLIPs. This will be
followed by a week during which developers can rework their
implementation (code, UI or documentation) to solve any problems found
by the framework team. The framework team will then have another week
during which is will re-evaluate previously rejected PLIPs. That means
that half February we will have a final verdict for all PLIPs.

In addition people are highly encourages to submit their implementation
before the deadline, and the framework team will try to review PLIPs as
soon as they are submitted. PLIPs submitted after the deadline will have
to wait for 3.4.

Steve and Jon will be asked to manage the process and make sure everyone
is playing by the rules.

Wichert.

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

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

Re: [Framework-Team] Nomination

[Wichert Akkerman]

Previously Matthew Wilkes wrote:
 Well, I'll get the ball rolling on this.
 
 I'd be interested in serving on the 4.x team.  Although I've not made  
 masses of commits to Plone I do know the internals very well, I think  
 I must have pdbed or read most of it over the years and I'm  
 comfortable with development versions.  I think the current team has  
 done a great job in not breaking Plone 3.x as its progressed and I'm  
 keen to see that continue with 4.x (x  0).  I'm used to working in a  
 development team for my day job, including code reviews for other  
 programmers, so I don't think there's anything in the job that I won't  
 have some experience with.

Do you see yourself as someone who:

- excels at reading and understanding other people's code
- is excellent at reviewing documentation and release notes
- loves to make sure a user interface is as simple as possible

It would be nice if the team will have a balance between those
qualities.

Wichert.

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

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

Re: [Framework-Team] PLIP Tallies

[Wichert Akkerman]

Previously Steve McMahon wrote:
 Here are my 3.3 PLIP tallies as of 5:45 2008-10-28 (UTC). These include some
 unambiguous votes pulled from e-mail messages to the FWT list.

Can this be turned into a result? What I would like to have is a list of
PLIPs, with for each plip the result (accept/recept) and if the result
is a reject a rationale for the rejection. We can then post that list to
plone-announce so everyone sees what has been decided and why.

Wichert.

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

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

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

[Wichert Akkerman]

Previously Alan Runyan wrote:
 On Tue, Oct 28, 2008 at 10:46 AM, Alec Mitchell [EMAIL PROTECTED] wrote:
  Is it really that much work to fix the ui for starting an edit?  I
  think there are a lot of people who like this feature, but are
  frustrated by the UI.  Disabling it does nothing to fix that though,
  it's just another regression to work around what many consider a real
  UI bug.
 
 I agree.  Who owns this part of the UI?

No part of the UI is 'owned'. If someone has a better implementation I'm
all for that, but I don't have the right skillset to implement it. Until
then this PLIP improves the currently situation quite a bit.

Wichert.

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

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

Re: [Framework-Team] Comments on PLIP 244

[Wichert Akkerman]

Previously Ricardo Alves wrote:
 Hi framework team,
 
 I'm sorry I didnt' comment on the previous discussion about PLIP #244, 
 but I wasn't subscribing this list. Anyway, I'd like to comment on some 
 of the objections already posted in the PLIP page.
 
 About the usefulness of site-wide portlets, let me give an example: you 
 have a static portlet assignment at a folder, and that portlet makes 
 sense only in the context of that folder, so you want to block it in 
 subfolders but keeping site-wide portlets visible (e.g. like news, 
 review list, events, etc). Currently you can't do this, unless you 
 manage to setup some weird combination using the other categories...

I disagree. Again you are just describing a special case of a more
generic problem: the lack of ability to selective block (and perhaps
unblock) portlets. I can not think of a single situation where site
portlets would make sense.

Wichert.

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

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

[Framework-Team] review deadline: this monday

[Wichert Akkerman]

Might I remind everyone that the review deadline is this Monday? Will
someone gather the results and report them?

Wichert.

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

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

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

[Wichert Akkerman]

Previously Martin Aspeli wrote:
  - Create a site wide portlet category for portlets that should show 
 on all pages (unless blocked). Currently, people have to use contextual 
 portlets at the root of the site for this, which gets cumbersome since 
 if you block them in one folder, you need to re-add all portlets in 
 subfolders.

This feels like a workaround for the fact that you can not selectively
block portlets. I would prefer a method where you can both block
individual portlets, and block only for the current object is, similar
to how you propose a flag to only show a portlet in the current object.

Wichert.

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

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

[Framework-Team] PLIP 242: Move manage-portlets link to site actions

[Wichert Akkerman]

I'm too late for my own deadline, so I have no expectation that the 
framework can review this on time time. If you guys have a bit of spare time 
I would appreciate it though :)


I want to propose PLIP 242 for Plone 3.3: Move manage-portlets link to site 
actions.


Motivation
==

Both portlet columns feature a manage portlets link at the bottom. This
has several problems:

* the location of the link and the fact that each column has its own manage
  portlet link leads users to believe that that link will go to a page to
  configure that specific column, which is not true.
* Many (if not most)l custom themes style the portlet column and have no
  room for the manage portlets-link below the portlets.
* all configuration options are in site or document actions, except for
  manage portlets- a needless inconsistency.

Proposal


Remove the manage portlets-link from the default portlet renderer template 
and replace it with a site action.



Wichert.


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


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

[Framework-Team] PLIP 231: Optionally copy roles from parent when blocking inheritance

[Wichert Akkerman]

Another one from Danny..

http://plone.org/products/plone/roadmap/231
Optionally copy roles from parent when blocking inheritance

Wichert.

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

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

Re: [Framework-Team] PLIP 323: Resource Registries Improvements

[Wichert Akkerman]

Previously Raphael Ritz wrote:
 I think we have this on the radar already
 (seeing comments from most team members
 on the plip page)

The framework team desparately needs someone who coordinates things and
keeps lists of PLIPs that are being reviewed. I hope that the team can
elect someone to take that role during their meeting this week.

Wichert.

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

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

[Framework-Team] Forgotten PLIPs

[Wichert Akkerman]

There appear to be a fair number of PLIP that are marked as being
proposed but never made it to this list. I would like to encourage the
framework team to take a look at the current list of PLIPs and see if
there are any that should be rejected or should be considered for 3.3 or
4.0.

Wichert.


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

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

Re: [Framework-Team] PLIP 242: Move manage-portlets link to site actions

[Wichert Akkerman]

Raphael Ritz wrote:

Wichert Akkerman wrote:
I'm too late for my own deadline, so I have no expectation that the 
framework can review this on time time. If you guys have a bit of 
spare time I would appreciate it though :)


Hi Wichert,

don't worry too much.
At least I planned to start reviewing only after
the conference sprints.



I want to propose PLIP 242 for Plone 3.3: Move manage-portlets link to 
site actions.


While I think I see your point I'm not sure it's the right
place to move it to.

First, I agree that the current situation isn't perfect.

But: those assignments are context depended and site
actions are typically used for (site) global settings.
Now while you can always link to the right URL, of course,
I'm not sure that that would be less confusing.

 From this POV the document actions might be more appropriate,
don't know. Or some new, location specific management category
could be introduced which could also be home for some of
the things we currently put on the edit form for lack of a
better place (like 'exclude from navigation' to give
one example).


I did mention that on the web-version of the PLIP. Site actions works since 
it mostly contains rarely-used items, which includes manage portlets. But 
you are very correct in that document actions would technically be more 
correct.


Wichert.

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


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

[Framework-Team] PLIP 236: Move Display menu to edit and allow for custom properties

[Wichert Akkerman]

I think Danny wanted to propose this for 3.3 but forgot to mail this
list? The workflow status shows that he proposed it.


Motivation
==

The display menu is a setting that controls how an object presents
itself to the user. Right now it suggests it is a switch that every user
can change at will not knowing it is persistent among all the users.
Therefore this menu should be part of the settings tab in the edit form.
Assumptions

 
Proposal


First: remove the Display menu and add a field to the settings tab of
the edit form where it belongs.

Second: a Display view should be able to provide a custom property sheet
that is loaded into this settings form whenever you pick a display type.
These properties give the user options to set parameters for the chosen
view. A thumbnail view for instance could provide an option telling how
many thumbs are shown. The point is that you don't know this in advance
so the view should somehow provide this property sheet.


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

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

Re: [Framework-Team] OT: problems with Gmane misinterpretations of browse back/forward and other key combinations

[Wichert Akkerman]

Previously Graham Perrin wrote:
 To seasoned Framework Team users of Gmane, a plea:
 
 How do I prevent Gmane from misinterpreting key combinations?

I see more and more complaints about gmane. Personally I really wish
people who just use the mailing list directly instead of using gateway
like gmane or nabble for posting. 

We can not support gmane, so questions like this should be send to the
gmane team, not to us.

 (I'm using Gmane now only because there's no plone.org interface to  
 this list, reasons for which I understand.)

We have http://lists.plone.org/pipermail/framework-team/ which works
perfectly for reading the list. And you can use your normal email client
to post to the list.

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

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

Re: [Framework-Team] Re: random thought: identify the components that lack owners

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 Wichert Akkerman wrote:
 Previously Martin Aspeli wrote:
 For example, I think we are missing a trick currently with the way we 
 manage maintenance releases. We do a good job of setting deadlines and 
 not missing them by too much. What we don't do, is build any sense of 
 urgency or importance around getting things done for those deadlines.
 
 We give people windows to hit if they happen to have something in 
 progress. This consists of one or two emails to the list. That's only 
 half the story though. We need to think much more constructively about 
 the process people go about in getting something going in the first 
 place, and encouraging that.
 
 I'm hoping that plonenext can help a bit with that. If people make a new
 release the release manager can include that in plonenext, which makes
 it immediately available to people developing against that. I have long
 wanted a way to motivate people to make releases when they are ready
 instead of only when I send out a call for releases. I'm hoping
 plonenext will help with that.
 
 plonenext will definitely help with that, but that wasn't quite what I 
 meant. This still assumes that people are actually in the middle of 
 working on something that they want to release.

Sure. Perhaps my view is a bit slanted because I am always working in
several different things at any point in time.

 Now, of course that happens some of the time, when there are external 
 drivers, such as customer projects that spin off generic components. 
 However, we are not doing enough to get people to start working on 
 contributions in good time.
 
 On past experience, there are a few things that make this happen:
 
  - Setting a deadline. This is a necessary, but not a sufficient, 
 condition. No-one does anything unless there's a deadline. However, by 
 the time the deadline is set, it's usually too late to *start* working 
 on something, so something has to be in progress (conversely, the 
 deadline is too far in the future, it doesn't feel like a deadline and 
 gets forgotten about).
 
 I think this is in danger of happening for 3.3. Ask how many people feel 
 like there's a deadline coming up, and ask how many people feel they 
 have a responsibility to get something done for that deadline. I suspect 
 you won't get many replies.

Deadlines are one of those things that you can't live without even
though you don't like them.

  - Setting a shared vision. I think this is what Jon is talking about. 
 We have talked about (and have even put into practice) having loosely 
 defined themes for a release, e.g. 3.2 is the eggs release. These 
 discussions tend to be led by a few people, e.g. you (Wichert), Alex, 
 Hanno, me. I think possibly could have some conventions for making these 
 discussions happen, e.g. a way to propose and then discuss themes.

I suspect there is a lot of shared vision, but that we are not very good
at writing it down. Partially because we are afraid to since it might
look more like a dictate, and partially because we have no good process
for it. I think emergent visions are fine, but I do think we need to
set some solid directions.

I just wrote down a few pages on directions that I think we need to look
at and mailed those to the developers list.

 By the way, I suggest we call Plone 4.0 Snow Plone (like Snow Leopard, 
 geddit?).

I don't get it.. The naming for Plone releases has always been a mystery
to me but luckily we never actually use those names anyway. I don't know
why we bother :)

  - Following up. Ask people how they're getting on. Make them feel like 
 what they're doing actually matters to other people. Alex has done this 
 in the past, but this is a bit too ad-hoc. The framework team could 
 feasibly do this for submitted PLIPs, but there's often a need to do 
 this before we have PLIPs also. I think this process has to be informal, 
 but we should encourage more of it.
 
  - Lavish praise. If someone does something for Plone out of their 
 spare time, be that to fix a bug, contribute a feature, do some 
 pre-release testing, or documentation, or whatever - make them 
 understand that their contributions are appreciated by the whole 
 community. If someone makes a mistake, don't shoot them down for it, but 
 rather try to be constructive and appreciate that their feelings 
 probably will be hurt if we revert their changes. Sometimes we have to, 
 of course, but the way in which that message is delivered is an 
 important determinant for whether that person contributes again.

I know I am not always the most subtle person out there. It might be a
cultural thing - we tend to be more direct here. You do touch on 
something important though: we have almost no after-merge process. There
is no process for QA testing, writing or updating documentation for
changes, getting press and praise out, etc. This is becoming more and
more critical now that there is a growing number of projects that share
some

Re: [Framework-Team] Re: random thought: identify the components that lack owners

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 [1] Perhaps the KSS vs. Bling debate of yore came close

dexterity vs devilstick could be the next one


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

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

[Framework-Team] PLIP 228: Restore 'Add Item..' menu on all pages

[Wichert Akkerman]

I guess I'm the first one. I want to propose PLIP 228 for Plone 3.3.

I feel that removing the removal of the 'Add Item' dropdown in many
places in Plone 3 is a regression in behaviour, and makes adding content
a lot more cumbersome. The PLIP has so far only received positive
responses from several people.

The full PLIP can be found here:
http://plone.org/products/plone/roadmap/228

Wichert.

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

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

Re: [Framework-Team] PLIP 228: Restore 'Add Item..' menu on all pages

[Wichert Akkerman]

Previously Wichert Akkerman wrote:
 I guess I'm the first one. I want to propose PLIP 228 for Plone 3.3.

Ok, second, Hanno got there first :)

Wichert.

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

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

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

[Wichert Akkerman]

I want to propose PLIP 238: Disable inline editing by default

Motivation
--
I suspect that by now most of us have realized that the current inline editing
behaviour in Plone 3 is not very practical. It has two main problems:

* it is very easily triggered by default, which causes unwanted edit fields to
  be opened which have to be manually closed. This happens because many,
  if not most, people click accidentily, select text to keep track of
  the reading position, try to select text to copypaste it or for other
  reasons. Since every single click activates inline edit this happens
  all too often and becomes very frustrating over time.

* as Alexander mentioned in his new UI proposal what you really want is
  a quick option to go to a full edit-mode. Editing a single field is a
  much less common operation than we were expecting.

I can't think of a single Plone deployment I have been involved in for
the last 6 months where we have not disabled inline editing, which
strengthens my believe that the current default is wrong.

Proposal
-

Current Plone releases have a simple toggle to enable or disable inline
editing. I propose that we change the default for newly created sites to
disabled.

Please note that I do not propose to disable inline field validation in
edit screens: that is a very useful and desirable feature.

Wichert.

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

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

Re: [Framework-Team] random thought: identify the components that lack owners

[Wichert Akkerman]

Previously Jon Stahl wrote:
 We were just chatting a bit here at ONE/Northwest global HQ and the following 
 idea came up...
 
 Hanno pointed out to me a short while ago that a number of key core Plone 
 components don't really have strong, active owners.  e.g. Wicked, Users + 
 Groups UI, etc.
 
 However, there's really no definitive list of these that we can use to 
 recruit more talent.
 
 Could y'all put your heads together via email and draft up such a list, which 
 we could then use to do some targeted recruiting?

I'm wondering why this would be a task for the framework team? 

Wichert.

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

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

Re: [Plone-developers] [Framework-Team] Re: Plone 3.2 and 3.3 planning

[Wichert Akkerman]

Previously Tom Lazar wrote:
 if any of my previous conferences and sprints are an indicator, i just  
 *know* that i won't be doing any actual fwt review work while in DC.  
 but that's not important. review work is 'fleissarbeit' to use a nice  
 german term here and can easily be done alone, whenever one can find  
 some time. i'd like to use the time at the conference to discuss  
 actual ideas/plips and to brainstorm the future fwt process, so i have  
 no problem with a post-conference plip deadline (although, it  
 shouldn't be too far after the conference as to not remove momentum  
 from the ideas/plips that have been fleshed out during the conference.  
 so, i guess, i'm +1 on wichert's deadline of one week after the  
 conference. in fact, i think it's pretty much perfect...

Keep in mind that at this stage the review will not involve code at all,
only ideas/proposals. Which seems to fit with what you're doing at the
conference  :)

Wichert.

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

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

[Framework-Team] Re: [Plone-developers] Plone 3.2 and 3.3 planning

[Wichert Akkerman]

Previously Alexander Limi wrote:
 On Thu, 11 Sep 2008 00:50:44 -0700, Andreas Zeidler  
 [EMAIL PROTECTED] wrote:
 
  so personally i'm still undecided and would like to hear some more
  opinions.  spontaneously i think i'd rather leave the window open,
  but i'd like to contemplate about it a bit more...
 
 Please leave the window for PLIPs open until after the conference. Most of  
 our best thinking happens at conference sprints, and that's the part that  
 you can't replicate anywhere else — once the PLIP is written, you can  
 pretty much work on it anywhere, you don't need a sprint for that  
 (although it does help with blocking out time).

My memory made me think PLIPs are generally not written at conferences
so I did a bit of analysis on the creation date of all PLIPs on
plone.org. That showed that are definite peaks in PLIP productivity but
they do not match with a conference at all. The latest big peaks are
December 2007, August 2006, March 2006 and December 20205. All other
months only show 0-3 PLIPs while each of those peaks is 10.

With this evidence I'm even more convinced that it makes more sense to ask
people to create PLIPs now and let the framework team disucss those at
the conference, providing immediate feedback to the PLIP authors.

Wichert.

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

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

[Framework-Team] Re: [Plone-developers] Plone 3.2 and 3.3 planning

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 Discussions will happen regardless, of course. Maybe we should make some 
 intelligent use of the sprint time to connect the FWT with PLIP authors 
 for some workshops/brainstorming?
 
 Should we just put this to a vote? I think the main impact here is on 
 the current FWT (especially since Wichert regrettably won't be at the 
 conference), so IMHO it should be up to them.

The most important thing that I want to happen is to be absolutely sure
that PLIPs are reviewed promptly. Since almost the entire framework team
will be present at the conference I think it makes sense to take that
opportunity to get them to work together in reviewing the PLIPs and
possibly discussing their internal procedures as part of that process.
Hence the deadlines I set.

If people write PLIPs during the proposal and the framework team is
willing to include those in its review work than I have no problem with
that. There is even room for that since the review deadline is set a
week after the conference (I was expecting this response). I'm not
willing to move deadlines for it. 
 
 As a data point, I'm in the same boat as Limi. It's extremely unlikely 
 that I'll even have time to think about any PLIPs until the conference. 
 My life's pretty much on hold due to work until then. Obviously I don't 
 warrant an exception or special treatment (nor does Limi), but I 
 wouldn't be surprised if other people had similar ideas.

As a data point it seems neither of you have ever written a PLIP during
a conference, which is perfectly understable: both of you are way too
busy preparing your talks, talking to people, organizing various and
socializing. That was true of previous conferences and will be true for
this one as well. 

Wichert.

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

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

[Framework-Team] Plone 3.2 and 3.3 planning

[Wichert Akkerman]

We need to get Plone 3.2 and 3.3 on the road. Contrary to previous 
releases I am not going to produce a complete schedule for the whole 
release process this time around - we've seen too often that those 
schedules keep changing anyway. Instead I'll keep planning the next two 
steps in the process for each release.


Lets start with Plone 3.2. This release will be a maintenance release 
for Plone 3.x in all aspects except packaging technology: it will be 
fully egg based. The first two steps for this release are:


   * egg releases of all components ready before October 1st
   * first alpha release during the Plone Conference


For Plone 3.3 we will start with a round of PLIP previews, during which 
the framework team can provide a verdict on the desirability of proposed 
PLIPs. The criteria are correct technical design, correct user interface 
design, and the need merge the PLIP in core instead of maintaining or 
maturing it as an add-on. The dates are:


   * PLIPs to be submitted before October 5th
   * framework team gives verdict on all PLIPs before October 20th

The planning is geared around the Plone conference; I am hoping that the 
framework team will be able to take schedule one or more discussions 
there to discuss these PLIPs, if possible with the PLIP authors present.


Wichert.

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

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

Re: [Framework-Team] Fwd: [Plone-developers] Plone 3.2 and 3.3 planning

[Wichert Akkerman]

Previously Chris Calloway wrote:
 On Sep 7, 2008, at 3:37 PM, Alexander Limi wrote:
 On Sun, 07 Sep 2008 03:34:58 -0700, Martin Aspeli
 [EMAIL PROTECTED] wrote:
 
 That's a good idea. On the other hand, I wonder if it would be nice  
 to
 give people a chance to come up with and work on PLIPs during the
 post-conference sprint. In the past, we've seen a spike in PLIPs  
 around
 sprints as people focus on one thing or another.
 
 +1.
 
 I would love to see someone step forward to champion this and so note  
 on the sprint wiki in order to generate interest:
 
 http://www.openplans.org/projects/plone-conference-2008-dc/sprint
 http://www.openplans.org/projects/plone-conference-2008-dc/sprint#topics

-1 to making 'invent PLIPs' a sprint topic. PLIPs come up as a result of
work on a topic or of free brainstorming. You can't just sit down and
invent PLIPs.

Of course existing sprint topics may spwan a PLIP, or they may not.
There is no way to tell in advance.

Wichert.

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

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

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

[Wichert Akkerman]

Previously Tom Lazar wrote:
 steve,
 
 that's an excellent idea!
 
 can we do a quick 'show of hands' here on the list, which framework  
 team meamber will be (if at all) when in DC? like so, perhaps?
 
   | from  | til
 -
 tomster   | 6th   | 12th
 witsch| 6th   | 12th
 wiggy |   |
 raphael   |   |
 danny |   |
 martijn | |

I won't be in DC.

Wichert.

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

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

[Framework-Team] availability over the next 5 months

[Wichert Akkerman]

Can the members of the framework team mail me some information on their 
availability for the next couple of months? If there are periods of a 
week or longer that you know you will not be able to dedicate enough 
time to framework team business I'ld like to know so I can take it into 
account when planning the next release(s).


Wichert.

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


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

Re: [Framework-Team] 3.2 Release Manager

[Wichert Akkerman]

Previously Spanky wrote:
 I was following the thread re: Plone 3.2 release, and I volunteered to 
 help manage this release.  After getting no replies, I asked in #plone 
 and got the response (from limi) that this team choses the release 
 manager, and that some kind of track record is expected.  This is 
 understandable.

As far as I know I'm still release manager for 3.x. I've been waiting
for the foundation board (in the person of that same limi) to answer
some questions I asked about the release manager stipend. Once those
have been answered I'll start planning a 3.2 release.

Wichert.

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

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

[Framework-Team] moving description to a viewlet

[Wichert Akkerman]

The way we currently handle the description is a bit painful: Plone uses 
the description as a proper description in places such as folder 
listings and search results, but it also uses the description field as 
introduction text when showing an object. This is awkward when writing 
text: it is very hard or impossible to write text that works well for 
both purposes in many cases.


For this reason it is not entirely uncommon to not want to show the 
description field at all, or to display it somewhere else. This is 
currently not possible since all content view templates have rendering 
of the description field hardcoded. Even using archetypes.schemaextender 
to mark the field as invisible in view mode does not work due to that 
hardcoding.


To improve things a bit I propose that move the rendering of the 
description field to a viewlet and put that in the 
plone.abovecontentbody slot. That is trivial to do, does not change our 
current pages and makes it possible to customize rendering of the field.


Long term I feel that we need to stop showing the description field in 
view templates at all and only use it as a proper description of the 
object, which can be shown instead of the content in places like search 
results. Perhaps something to consider for Plone 4 :)


Wichert.

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


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

[Framework-Team] Re: [Plone-developers] moving description to a viewlet

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 -1
 
 This is a fairly substantial (if subtle) change. As soon as you do this, 
 everyone who's got a custom view template that follows the conventions 
 (i.e. tons of third party products and custom content types) will start 
 to see the description twice. That's unacceptable and will require 
 everyone to rewrite.

Fair enough.

 Turning a viewlet off for one type only is also a bit awkward. You end 
 up having to customise for the given context type with a viewlet that 
 renders nothing.

Hmm hmm. Perhaps there is an abstraction or hook missing here. It's a
shame the viewlet mechanism does not have an available flag like
portlets do. Still, you could add that to the __call__ method.

 I'd rather just advise people to hide the documentDescription div with 
 CSS if they want it gone site-wide, and to customise if they want it on 
 a per-template basis. It's way easier to customise a template and remove 
 or move a div than it is to find out where the damned viewlet came from. :)

You'ld have to customize every view template for every content type in
your site. That can be quite painful. For a site I'm working on now that
would easily be over 20 separate templates. Creating/overriding a single
viewlet is much simpler and much more maintainable.

 To make this argument a bit more general - viewlet managers are 
 primarily slots in which generic UI can be plugged in. For example, if 
 you have a tagging solution and want to show a tag cloud for all 
 supported types, you could insert that as a viewlet without having to 
 customise every template. Ditto with the way Iterate displays messages 
 depending on whether the IWorkingCopy marker is set.

I want something just as general. I want that bit of metadata (which the
description really is, and if Plone didn't show it in so many places I
would move it to a different fieldset as well) to go away from my
content views everywhere.

 An object's description is intimately tied to its schema. A description 
 renderer probably isn't a useful concept on its own. The decision on 
 whether and how to render the description is part of the view logic of 
 the object in question and should thus, IMHO, remain closely linked into 
 the view template, not indirected away to a place where it's harder to 
 manipulate.

I just feel that the description is not part of the content. It is
metadata: it describes what the object is about. As such it does not
have business appearing in view templates, especially not in the way
it does now. That is a mistake Plone made long ago, and something we
should fix at some point.

Wichert.

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

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

Re: [Framework-Team] Re: Merged PLIPs 184, 200, 202, 203 and 204

[Wichert Akkerman]

Martijn Pieters wrote:

On Sat, Mar 1, 2008 at 7:20 PM, Martin Aspeli [EMAIL PROTECTED] wrote:

  (1) Why is the line
 
five:registerPackage package=. initialize=.initialize /
 
  added -- isn't this only to allow a package to be installable as a Zope2
  product? Is this needed for plone.app.portlets?

 It probably isn't. Can you take it out and verify that everything still
 works? If so, please commit the removal.


If it doesn't work, do please remove the 'initialize' attribute and
the initialize method from __init__.py. You only need those when
registering object factories with Zope (so content types, tools, etc).


Or when you want the quickinstaller to be aware of your package.

Wichert.

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


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

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

[Wichert Akkerman]

Thanks to all the hard work from the PLIP authors we have finished
merging all the PLIPs in the Plone 3.1 tree. A total of 16 PLIPs
have been merged:

 #184: Include more/improved portlets (Jon Stahl) 
 #195: Support product dependencies (Wichert Akkerman) 
 #200: Kupu formlib widget (Martin Aspeli) 
 #202: Support inline validation and editing for formlib forms (Martin Aspeli) 
 #203: Manage portlet assignments with GenericSetup (Martin Aspeli, 
   Geir Baekholt) 
 #204: Manage content rules using GenericSetup (Martin Aspeli) 
 #205: Flexibility Associating Portlet Types and Portlet Managers (George Lee) 
 #207: Allow Custom Portlet Managers (George Lee) 
 #208: Adapter-Based Local Role Lookup (Alec Mitchell) 
 #209: Add buildout to Unified Installer (Steve McMahon, Wichert Akkerman) 
 #212: Use jQuery Javascript Library (Florian Schulze, Martijn Pieters) 
 #213: Prepare for better Syndication (Florian Schulze, Derek Richardson) 
 #215: Include new KSS versions (Balazs Ree, Godefroid Chapelle) 
 #218: Increase Restrictions, and Ability to Change, Addable Portlet Types
   by Interface (George Lee) 
 #220: Improve browser layer support (Wichert Akkerman) 
 #224: CSRF protection framework (Wichert Akkerman)


Unfortunately 2.2 PLIPs did not make it in this release:

 #187: Working Out-of-the-box WebDAV (Sidnei da Silva)
This was probably the most hotly debated PLIP. It does offer some
very nice improvements for WebDAV but the initial implementation
needed some cleanups and changes before it could be merged into
Plone core. Sidnei has been working hard on those and has a cleaner
implementation ready, but this needs a a new proper review. This
already looks like an excellent candidate for Plone 3.2.

 #201: Improve the UberSelectionWidget UI (Florian Schulze)
The user interface for the UberSelectionWidget needs more work
before it is ready for us mere mortals. I'm hoping this will be
finished on time for Plone 3.2.

A few improvements to the sources that make the existing
UberSelectionWidget a bit easier to use have been merged in the 3.1
tree.

 #224: CSRF protection framework (Wichert Akkerman)
The changes to plone.session to make it use the new keyring manager
introduced too many migration problems and test failures in a lot
of other places and have been reverted. The other parts of this PLIP
have been merged.


this week we will be focusing on stabilizing the tree, fixing any test
failures that have surfaced and testing, testing and testing. And the
good news is everyone can help! Just grab that Plone 3.1 ploneout
branch, make an instance and start playing with it. The PLIP authors
are not the only one having fun, *you* can have some fun as well!

Wichert.

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

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