Mailing list for the Plone Framework team

Eric Steele | 2 Apr 2012 01:04

Collections portlets

So now that we've got plone.app.collection in 4.2, how do we want to handle collections portlets?

We currently ship with plone.portlet.collection. plone.app.collection adds its own, largely the same (though missing some of the more recent features/fixes added to the other).

Should the p.a.collection version be made the default (and updated for parity with p.portlet.collection) or should p.portlet.collection be updated to handle the newer collections (and remove the portlet functionality from p.a.collection)?

Seems like the latter would be the simpler option.

Eric

<div>
<div>
                    <span>So now that we've got plone.app.collection in 4.2, how do we want to handle collections portlets?</span>
                </div>
<div><span><br></span></div>
<div><span>We currently ship with plone.portlet.collection. plone.app.collection adds its own, largely the same (though missing some of the more recent features/fixes added to the other).&nbsp;</span></div>
<div><span><br></span></div>
<div><span>Should the p.a.collection version be made the default (and updated for parity with p.portlet.collection) or should p.portlet.collection be updated to handle the newer collections (and remove the portlet functionality from p.a.collection)?</span></div>
<div><span><br></span></div>
<div><span>Seems like the latter would be the simpler option.</span></div>
<div><span><br></span></div>
<div><span>Eric</span></div>
                <div></div>
</div>

headers

David Glick | 9 Apr 2012 08:00

Re: Collections portlets

On 4/1/12 4:04 PM, Eric Steele wrote:

So now that we've got plone.app.collection in 4.2, how do we want to handle collections portlets?

We currently ship with plone.portlet.collection. plone.app.collection adds its own, largely the same (though missing some of the more recent features/fixes added to the other).

Should the p.a.collection version be made the default (and updated for parity with p.portlet.collection) or should p.portlet.collection be updated to handle the newer collections (and remove the portlet functionality from p.a.collection)?

Seems like the latter would be the simpler option.

I made some progress toward supporting new-style collections in plone.portlet.collection (by adding a backward-compatible queryCatalog method to the collection class in plone.app.collection...really not too hard except for figuring out how to get non-IContentListing-wrapped results out of the query builder). Remaining tasks:
- The code path for when the 'random order' option is selected is currently broken. To fix it the BBB queryCatalog needs to accept a sort_on parameter and pass it through to where the query is constructed.
- The plone.portlet.collection functional test needs to be updated to create a new-style collection instead of a Topic.
- We need to figure out what to do with the unnecessary portlet in plone.app.collection. (There have been releases of plone.app.collection so it doesn't seem like we should just remove it. A migration will be a pain since it'll have to find all the portlet assignments to update them. If the 2 portlet assignment classes have the same attributes maybe we can use a module alias, but I haven't evaluated that.)

David Glick Web Developer davidglick-jwYafjbudsc+uJoB2kUjGw@public.gmane.org 206.286.1235x32
GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to Groundwire as part of this community-wide day of giving.

<div>
    On 4/1/12 4:04 PM, Eric Steele wrote:
    <blockquote cite="mid:40F84218D5D44583B7E2FFE1A21DC880@..." type="cite">
      <div> <span>So now that we've got
          plone.app.collection in 4.2, how do we want to handle
          collections portlets?</span> </div>
      <div><span><br></span></div>
      <div><span>We currently ship with
          plone.portlet.collection. plone.app.collection adds its own,
          largely the same (though missing some of the more recent
          features/fixes added to the other).&nbsp;</span></div>
      <div><span><br></span></div>
      <div><span>Should the p.a.collection
          version be made the default (and updated for parity with
          p.portlet.collection) or should p.portlet.collection be
          updated to handle the newer collections (and remove the
          portlet functionality from p.a.collection)?</span></div>
      <div><span><br></span></div>
      <div><span>Seems like the latter would be
          the simpler option.</span></div>
    </blockquote>
    <br>
    I made some progress toward supporting new-style collections in
    plone.portlet.collection (by adding a backward-compatible
    queryCatalog method to the collection class in
    plone.app.collection...really not too hard except for figuring out
    how to get non-IContentListing-wrapped results out of the query
    builder). Remaining tasks:<br>
    - The code path for when the 'random order' option is selected is
    currently broken. To fix it the BBB queryCatalog needs to accept a
    sort_on parameter and pass it through to where the query is
    constructed.<br>
    - The plone.portlet.collection functional test needs to be updated
    to create a new-style collection instead of a Topic.<br>
    - We need to figure out what to do with the unnecessary portlet in
    plone.app.collection. (There have been releases of
    plone.app.collection so it doesn't seem like we should just remove
    it. A migration will be a pain since it'll have to find all the
    portlet assignments to update them. If the 2 portlet assignment
    classes have the same attributes maybe we can use a module alias,
    but I haven't evaluated that.)<br><p>&nbsp;</p>
<table border="0" cellspacing="10" cellpadding="10" width="600">
<tr>
<td valign="top" width="250">
      <div>
      <p><span>David Glick</span><br><span><span>Web Developer</span><br></span><span>davidglick@...<span><br><span><span>206.286.1235x32 
      </span></span></span></span><span><span></span></span></p>
</div>
</td>
    <td valign="top" width="318">
      <div>
      <p></p>
</div>
</td>
</tr>
<tr><td colspan="2">
      <p><span><span>GiveBIG 
      is coming! Mark your calendar for May 2 and <a title="" href="http://www.seattlefoundation.org/npos/Pages/Groundwire.aspx">get 
      ready to give big to Groundwire</a>&nbsp;as part of this community-wide 
      day of giving.</span></span></p>
</td></tr>
</table>
<p></p>
<br>
</div>

headers

David Glick | 10 Apr 2012 08:32

Re: Collections portlets

On 4/8/12 11:00 PM, David Glick wrote:

On 4/1/12 4:04 PM, Eric Steele wrote:

So now that we've got plone.app.collection in 4.2, how do we want to handle collections portlets?

We currently ship with plone.portlet.collection. plone.app.collection adds its own, largely the same (though missing some of the more recent features/fixes added to the other).

Should the p.a.collection version be made the default (and updated for parity with p.portlet.collection) or should p.portlet.collection be updated to handle the newer collections (and remove the portlet functionality from p.a.collection)?

Seems like the latter would be the simpler option.

I made some progress toward supporting new-style collections in plone.portlet.collection (by adding a backward-compatible queryCatalog method to the collection class in plone.app.collection...really not too hard except for figuring out how to get non-IContentListing-wrapped results out of the query builder). Remaining tasks:
- The code path for when the 'random order' option is selected is currently broken. To fix it the BBB queryCatalog needs to accept a sort_on parameter and pass it through to where the query is constructed.

Fixed.

- The plone.portlet.collection functional test needs to be updated to create a new-style collection instead of a Topic.

Done.

- We need to figure out what to do with the unnecessary portlet in plone.app.collection. (There have been releases of plone.app.collection so it doesn't seem like we should just remove it. A migration will be a pain since it'll have to find all the portlet assignments to update them. If the 2 portlet assignment classes have the same attributes maybe we can use a module alias, but I haven't evaluated that.)

A module alias turned out to work great. So I removed the bulk of the implementation and just left that alias.

David

David Glick Web Developer davidglick-jwYafjbudsc+uJoB2kUjGw@public.gmane.org 206.286.1235x32
GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to Groundwire as part of this community-wide day of giving.

<div>
    On 4/8/12 11:00 PM, David Glick wrote:
    <blockquote cite="mid:4F827B06.9060405@..." type="cite">

      On 4/1/12 4:04 PM, Eric Steele wrote:
      <blockquote cite="mid:40F84218D5D44583B7E2FFE1A21DC880@..." type="cite">
        <div> <span>So now that we've got
            plone.app.collection in 4.2, how do we want to handle
            collections portlets?</span> </div>
        <div><span><br></span></div>
        <div><span>We currently ship with
            plone.portlet.collection. plone.app.collection adds its own,
            largely the same (though missing some of the more recent
            features/fixes added to the other).&nbsp;</span></div>
        <div><span><br></span></div>
        <div><span>Should the p.a.collection
            version be made the default (and updated for parity with
            p.portlet.collection) or should p.portlet.collection be
            updated to handle the newer collections (and remove the
            portlet functionality from p.a.collection)?</span></div>
        <div><span><br></span></div>
        <div><span>Seems like the latter would
            be the simpler option.</span></div>
      </blockquote>
      <br>
      I made some progress toward supporting new-style collections in
      plone.portlet.collection (by adding a backward-compatible
      queryCatalog method to the collection class in
      plone.app.collection...really not too hard except for figuring out
      how to get non-IContentListing-wrapped results out of the query
      builder). Remaining tasks:<br>
      - The code path for when the 'random order' option is selected is
      currently broken. To fix it the BBB queryCatalog needs to accept a
      sort_on parameter and pass it through to where the query is
      constructed.<br>
</blockquote>
    <br>
    Fixed.<br><blockquote cite="mid:4F827B06.9060405@..." type="cite">
      - The plone.portlet.collection functional test needs to be updated
      to create a new-style collection instead of a Topic.<br>
</blockquote>
    <br>
    Done.<br><blockquote cite="mid:4F827B06.9060405@..." type="cite">
      - We need to figure out what to do with the unnecessary portlet in
      plone.app.collection. (There have been releases of
      plone.app.collection so it doesn't seem like we should just remove
      it. A migration will be a pain since it'll have to find all the
      portlet assignments to update them. If the 2 portlet assignment
      classes have the same attributes maybe we can use a module alias,
      but I haven't evaluated that.)<br>
</blockquote>
    <br>
    A module alias turned out to work great. So I removed the bulk of
    the implementation and just left that alias.<br><br>
    David<br><p>&nbsp;</p>
<table border="0" cellspacing="10" cellpadding="10" width="600">
<tr>
<td valign="top" width="250">
      <div>
      <p><span>David Glick</span><br><span><span>Web Developer</span><br></span><span>davidglick@...<span><br><span><span>206.286.1235x32 
      </span></span></span></span><span><span></span></span></p>
</div>
</td>
    <td valign="top" width="318">
      <div>
      <p></p>
</div>
</td>
</tr>
<tr><td colspan="2">
      <p><span><span>GiveBIG 
      is coming! Mark your calendar for May 2 and <a title="" href="http://www.seattlefoundation.org/npos/Pages/Groundwire.aspx">get 
      ready to give big to Groundwire</a>&nbsp;as part of this community-wide 
      day of giving.</span></span></p>
</td></tr>
</table>
<p></p>
<br>
</div>

headers

Elizabeth Leddy | 12 Apr 2012 19:52

Re: [Plone-developers] PlonePAS portrait handling


On Apr 11, 2012, at 2:28 PM, Jens W. Klein wrote:

> Products.PlonePAS handles every user data as some property on a 
> propertysheet, except the portrait photo.
> 
> The portrait is stored at portal_memberdata - which is fine - but it is 
> not exposed on the property sheet nor is it fetched as such.
> 
> In my opinion its a must to handle the portrait photo the same way as 
> all userdata. Exposing a photo from a different source - i.e. ldap, sql, 
> remember - means now to patch PlonePAS - and this is ugly and error-prone.
> 
> I'd like to change PlonePAS in a way to support this, but before I start 
> I'd like to read your opinions.
> 
> My proposed changes are:
> 
> - add a new mutable propertysheet dealing with one property 'portrait'
>   and use current portal_memberdata storage
> 
> - change the methods used to fetch, store and delete the portrait on
>   portal_membership and portal_memberdata to use the propertysheet.
> 
> - add a traverser to the photo to support non-zodb data.

I would like this but, how would this work? How does the PAS story fit in here?

> 
> - add tests
> 
> Code using the current API would not be affected. Supporting a different 
> data source for the photo would follow the usal PAS API.
> 
> What do you think?
> 
> Do we need a PLIP for this?

I'm all for this idea. I feel like a plip would just help with the review process more than anything. I
wouldn't mind deprecating the old way either and making a plip would help this happen. I doubt the FWT would
say no to this and I know I have a project that could use this functionality.

Liz

> 
> regards Jens
> -- 
> Klein & Partner KG, member of BlueDynamics Alliance
> 
> 
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second 
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers

headers

Eric Steele | 19 Apr 2012 02:47

PLIP #11965 (Resource Bundles)

Since this one is relatively minor and has been done for some time, I've made the executive decision to just include it in Plone 4.2. (Doing so allows me to clear up some HTML 5 that snuck into the 4.1 branch) So it's completely on me if I've gone and blown everything up.

Eric

<div>
<div>
                    <span>Since this one is relatively minor and has been done for some time, I've made the executive decision to just include it in Plone 4.2. (Doing so allows me to clear up some HTML 5 that snuck into the 4.1 branch) So it's completely on me if I've gone and blown everything up.&nbsp;</span>
                </div>
<div><span><br></span></div>
<div><span>Eric</span></div>
                <div></div>
</div>

headers

David Glick | 24 Apr 2012 21:03

minutes of April 24 framework team meeting

April 24, 2012 – Framework Team Meeting
Attending: Eric Steele, David Glick, Ross Patterson, Alec Mitchell, 
Craig Haynal, Laurence Rowe, Liz Leddy

- PLIP 11965 (ResourceRegistries resource bundles): Eric merged for 4.2. 
Clearing up test failures introduced.

- PLIP 8699 (Published date): framework team has no concerns, go ahead 
with implementation.

- Discussion on lists re theme control panels: Agreement that having 2 
control panels is non-ideal, but not sure best way to resolve. 
Suggestions welcome.

- PLIP 12844 (Switch to new version of TinyMCE): Approved for core. Next 
step is review of implementation. davisagli is champion, eleddy will 
also review.

- Jens Klein's proposal about handling portraits via property sheets. 
Liz will follow up to get him to submit a PLIP

- PLIP 10886 (new event type): still in progress, may not be ready for 4.3.

- PLIP 12110 (plain text searches ignore accents): ready for merge.

- PLIP 10959 (API for password validation policy) and 12521 
(Customizable password generation & validation): Liz will touch base and 
ask them to coordinate.

- PLIP 11773 (Dexterity): David will merge soon.

- PLIP 11838 (z3c.form support for portlets): ready for merge.

- PLIP 12024 (Non-inherited portlet assignment context): closed due to 
lack of response from author.

- PLIP 12266 (add adjustable css class option on static portlet and 
collection portlet): ready for review. Ross and Alex will review.

- PLIP 12350 (Integrate selected portions of jQueryUI - DRAFT): Eric 
will ask Steve McMahon to champion. Okay for 4.3 if it's ready but won't 
hold up 4.3 for it.

- PLIP 12238 (Add multi-sources personalize form extension): Clarified 
that this was rejected some time ago.

----------		
David Glick
 Web Developer
 davidglick@...
 206.286.1235x32

GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to Groundwire
on this community-wide day of giving.

http://www.seattlefoundation.org/npos/Pages/Groundwire.aspx

5	May 2013
20	April 2013
4	March 2013
4	February 2013
10	January 2013
10	December 2012
21	November 2012
27	October 2012
17	September 2012
7	August 2012
1	July 2012
4	June 2012
7	May 2012
6	April 2012
13	March 2012
4	February 2012
7	January 2012
4	December 2011
18	November 2011
1	October 2011
24	September 2011
4	August 2011
17	July 2011
16	June 2011
8	May 2011
1	April 2011
18	March 2011
26	February 2011
22	January 2011
20	December 2010
14	November 2010
34	October 2010
57	September 2010
112	August 2010
21	July 2010
16	June 2010
30	May 2010
5	April 2010
75	March 2010
34	January 2010
5	December 2009
3	November 2009
34	October 2009
70	September 2009
82	August 2009
50	July 2009
103	June 2009
129	May 2009
29	April 2009
67	March 2009
69	February 2009
122	January 2009
124	December 2008
73	November 2008
179	October 2008
73	September 2008
38	August 2008
12	July 2008
12	June 2008
12	May 2008
5	April 2008
11	March 2008
251	February 2008
93	January 2008
253	December 2007
51	November 2007
2	October 2007
3	September 2007
5	August 2007
24	July 2007
18	June 2007
11	May 2007
50	April 2007
131	March 2007
70	February 2007
67	January 2007
134	December 2006
61	November 2006
82	October 2006
168	September 2006
59	August 2006
50	July 2006
5	June 2006
42	May 2006
40	April 2006
36	March 2006
31	February 2006
12	December 2005
16	November 2005

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30