Eric Steele | 2 Apr 01:04 2012
Picon

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>
David Glick | 9 Apr 08:00 2012

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>
David Glick | 10 Apr 08:32 2012

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>
Elizabeth Leddy | 12 Apr 19:52 2012
Picon

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

Eric Steele | 19 Apr 02:47 2012
Picon

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>
David Glick | 24 Apr 21:03 2012

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


Gmane