Ticket #9327 (closed PLIP: fixed)

Opened 7 years ago

Last modified 4 years ago

unified interface for lists of content

Reported by: elvix Owned by: elvix
Priority: n/a Milestone: 4.2
Component: General Version: 4.1
Keywords: Cc: csenger, plip-advisories@…, grahamperrin@…, ldr

Description (last modified by elvix) (diff)

Proposer: Geir Bækholt

Seconder: Laurence Rowe

Motivation

Content objects or some representation of them (like catalog brains) are listed many different places in Plone: Folder listings, folder contents, search results, portlets, collection results, etc.

Many of the views listing content are simply legacy templates from old Plone version rewritten as views. There is no coherent logic and no unified way of how content listing is done or should be done.

This is the root of several problems:

  • It is hard to understand for a new integrator or developer what is the right way to fetch and list content.
  • It is also hard to cut and paste code between integration templates and customisations since the different views and templates use different markup, syntax, objects and methods for getting at content.
  • It is not currently possible to take one template and apply it to some arbitrary content list. It would be useful if the templates we have for listing content in portlets, in search results, in tables, in listings, would all be reusable across folders, collections etc. without modifications.

Assumptions

We will not touch the navigation tree and sitemap for this, only flat lists.

Proposal & Implementation

What needs to be done, and how should it be done?

Decide on a unififed interface for listing content or stuff that looks like content. This should be an interface that should be usable for normal content objects, catalog brains, — and anything else that looks like content (ORM results, SQL rows etc…).

Locate all occurences of content being listed in Plone

Replace all listing implementations with new ones based on this interface.

Remove a lot of now-redundant view and template code.

Deliverables

What code and documentation needs to be produced? Standard items:

  • An interface for listing content objects
  • Documentation for the interface and suggested use examples
  • Replacement views for places content or brains are listed
  • Replacement templates for where content or brains are listed
  • Unit tests
  • Localization of the new templates

Risks

What are the risks of implementing this proposal? What incompatibilities can it cause?

Risk of breaking third party add-ons that depend on existing implementation details for listing content

Risk of breaking customised templates on top of views that will change.

Participants

Who is signed up to do the work? Geir Bækholt, Laurence Rowe and more…

Progress

being discussed

Change History

comment:1 Changed 7 years ago by elvix

  • Description modified (diff)

updating trac syntax errors. removing Hanno.

comment:2 Changed 7 years ago by elvix

  • Description modified (diff)

comment:3 Changed 7 years ago by csenger

  • Cc csenger added

The system should make it possible to customize the snippets for an entry on a per portal_type basis. Atm you have to customize the folder_listing every time you want to treat a content type specially. Add-ons can't customize the folder_listing at all.

I thought about a PLIP implementing this: Call IFolderListingEntry(brain) to render the entry for an ICatalogBrain. This tries to render IFolderListingEntry(brain, name=brain.portal_type) first, then ...name=brain.meta_type), and at least renders the snippet itself. Integrators or Add-on developers then can overwrite a snippet or customize them in portal_view_customizations. For consistency reasons, listings with real objects should work the same way. It's a bit cheating, but should work well as it's a portal_types oriented system anyway.

comment:4 Changed 7 years ago by pupq

I'd say "go cautiously" here. These things are among the most-customized by integrators, so, yes, something that makes this easier will help. But these are also among the things most customized by them already--so let's try to make sure that a customized search results page will still work, if possible (ie, the underlying script is there, etc.)

It's hard for me to say whether integrators would find this easier/harder without the real detail of exactly what would change.

comment:5 Changed 7 years ago by davisagli

I agree with Joel...this sounds pretty risky, though it's possible that a more specific proposal would convince me to be in favor. This is definitely a pain point I've experienced (in many projects I have adjusted search results and Collage views to be based on folder_listing) but the current ways of dealing with the limitations are also well documented and understood. Maybe your effort should go into designing a generic listing tile for Plone 5, rather than trying to target Plone 4? Certainly don't count this note as stop energy; I'm also very interested in exploring the possibilities for what could be done in this area.

I do like csenger's idea re adapterizing the rendering of particular items, provided the performance penalty is negligible.

comment:6 Changed 7 years ago by erikrose

Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)

comment:7 Changed 7 years ago by alecm

  • Owner set to elvix

This is essentially guaranteed to break numerous template customizations. The end result will need to be worth those incompatibilities. It may make sense to save this for 5.0, when we'll supposedly break everything anyway :-) This will also need to be done in a way that ensures that non-python-developers will be able to easily understand and customize these templates.

comment:8 Changed 7 years ago by elvix

I discussed this with Laurence a bit. We think we can do this without breaking any of the old parts in Plone 4. We can provide this alternative (simpler to integrators) way, but leave the old scripts and methods for backwards compatibility until Plone 5. The important bit is to get this in to let people start switching and have a proper single way to list content so that we can document this to integrators and make it simpler to relate to content.

The biggest risk seems to be time for implementation. We don't think we can realistically have this tested and solid enough in time for Plone 4.0. Not that it'll stop us from trying ;)

Would something like this be possible to do for 4.1?

comment:9 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

comment:10 Changed 7 years ago by MatthewWilkes

I think bumping this to 5.0 is a good idea. If you can get something that convinces us that it's safe for integrators in 4.1, I will gladly be +1.

FWT Vote: -1

comment:11 Changed 7 years ago by rossp

FWT vote +1. I'd like to see #9271 and #9282 merged into this PLIP. Since 4.0 is a major release, I think this is the right time to break backwards compatibility and I think this could be a big win. Maybe we can make an incremental mitigation of disruption to integrators by using layers or somesuch to make it easy to switch back to the old templates.

comment:12 Changed 7 years ago by davisagli

FWT vote: +1, though what version this can land in depends a lot on the actual implementation delivered.

comment:13 Changed 7 years ago by calvinhp

FWT Vote: +1 but I would suggest that we only do this in a way that would allow for the old templates to still be used as rossp mentions. It would make sense to get this new unifed listing API settled now so any new views created during this release use it, but I wouldn't make it a priority to break any old ones yet.

comment:14 Changed 7 years ago by raphael

FWT Vote: +1 provided the old stuff stays available for some transitional period as well.

comment:15 Changed 7 years ago by MatthewWilkes

I've thought about this some more in the last few days, and gradually convinced myself to become +1, but not sure if it'll happen in time.

Therefore, FWT Vote (changed): +1

comment:16 Changed 7 years ago by esteele

Approved by FWT vote.

comment:17 Changed 7 years ago by elvix

  • Status changed from new to assigned

comment:18 Changed 7 years ago by elvix

Reducing the scope to having the interface and implementation available, but not changing all templates for Plone 4. That is simply too much work to be done on time.

comment:19 Changed 7 years ago by elvix

(In [28627]) PLIP-implementation status document for Contentlistings interface. refs #9327

comment:20 Changed 7 years ago by elvix

(In [28636]) add review config file. refs #9327

comment:21 Changed 7 years ago by elvix

(In [28655]) branc for plip implementation refs #9327

comment:22 Changed 7 years ago by elvix

ready for review

comment:23 Changed 7 years ago by elvix

FYI: Most or all the risk in this should be considered removed by not messing with the scripts or macros people depend on for their customisations.

comment:25 Changed 7 years ago by davisagli

(In [29406]) add FWT review of PLIP #9327 (refs #9327)

comment:26 Changed 7 years ago by davisagli

(In [29499]) added an addendum to my PLIP review with corrected benchmark data, refs #9327

comment:27 Changed 7 years ago by davisagli

(In [29633]) another addendum to this review (note my changed vote), refs #9327

comment:28 Changed 7 years ago by esteele

Your PLIP has passed the Framework team's initial review. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 30.

comment:29 Changed 6 years ago by esteele

  • Status changed from assigned to closed
  • Resolution set to wontfix

Closing this PLIP as it wasn't completed for 4.0. Please feel free to reopen and submit to a 4.x release.

comment:30 Changed 6 years ago by elvix

  • Status changed from closed to reopened
  • Resolution wontfix deleted
  • Milestone changed from 4.0 to 4.x

comment:31 Changed 6 years ago by grahamperrin

  • Cc grahamperrin@… added

comment:32 Changed 6 years ago by limi

  • Priority changed from minor to n/a
  • Milestone changed from 4.x to 4.1

Moving to 4.1 at Geir's request.

comment:33 Changed 6 years ago by elvix

Technical implementation for this PLIP is largely complete. Documentation still lacking.

comment:34 Changed 6 years ago by esteele

Your PLIP has been accepted for consideration for Plone 4.1.

Framework Team voting on this PLIP was: Alec +1 Craig +1 Elizabeth +1 Laurence +1 Martijn +1 Matthew +1 Rob +1 Ross +1

The initial implementation deadline for your PLIP is October 1st, 2010. The Framework Team would certainly appreciate you finishing beforehand so that they may begin evaluating it as soon as possible. Announce its readiness here once your implementation is ready for review.

comment:35 Changed 5 years ago by elvix

Although there are a few more details to handle, this PLIP is ready for review:

Review documentation available at. https://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.1/plips/plip9327.contentlisting.txt

comment:36 follow-up: ↓ 37 Changed 5 years ago by cah190

I committed a review here:  http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip9327-review-cah190.txt Not sure why the svn commit hook didn't update this ticket.

However, I was unable to get reasonable results as the Zope/Plone instance created by the buildout would not start with the following traceback:

Traceback (most recent call last):
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/Zope2-2.13.0-py2.6.egg/Zope2/Startup/run.py", line 72, in <module>
    run()
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/Zope2-2.13.0-py2.6.egg/Zope2/Startup/run.py", line 21, in run
    starter.prepare()
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/Zope2-2.13.0-py2.6.egg/Zope2/Startup/__init__.py", line 86, in prepare
    self.startZope()
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/Zope2-2.13.0-py2.6.egg/Zope2/Startup/__init__.py", line 259, in startZope
    Zope2.startup()
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/Zope2-2.13.0-py2.6.egg/Zope2/__init__.py", line 47, in startup
    _startup()
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/Zope2-2.13.0-py2.6.egg/Zope2/App/startup.py", line 118, in startup
    load_zcml()
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/Zope2-2.13.0-py2.6.egg/Zope2/App/startup.py", line 52, in load_zcml
    load_site()
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/Zope2-2.13.0-py2.6.egg/Zope2/App/zcml.py", line 46, in load_site
    _context = xmlconfig.file(site_zcml)
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/zope.configuration-3.7.2-py2.6.egg/zope/configuration/xmlconfig.py", line 653, in file
    context.execute_actions()
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/zope.configuration-3.7.2-py2.6.egg/zope/configuration/config.py", line 606, in execute_actions
    callable(*args, **kw)
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/AccessControl-2.13.3-py2.6-macosx-10.6-x86_64.egg/AccessControl/security.py", line 165, in protectClass
    permission = getUtility(IPermission, name=permission_id)
  File "/Users/cah/src/plone4.1/buildout/plips/eggs/zope.component-3.9.5-py2.6.egg/zope/component/_api.py", line 169, in getUtility
    raise ComponentLookupError(interface, name)
zope.configuration.config.ConfigurationExecutionError: <class 'zope.component.interfaces.ComponentLookupError'>: (<InterfaceClass zope.security.interfaces.IPermission>, 'cmf.ModifyPortalContent')
  in:
  File "/Users/cah/src/plone4.1/buildout/src/plone.app.layout/plone/app/layout/viewlets/configure.zcml", line 319.4-325.10
      <browser:viewlet
          name="plone.lockinfo"
          manager=".interfaces.IAboveContent"
          class="plone.locking.browser.info.LockInfoViewlet"
          permission="cmf.ModifyPortalContent"
          for="plone.locking.interfaces.ITTWLockable"
          />

comment:37 in reply to: ↑ 36 Changed 5 years ago by elvix

I just built a new instance from this cfg. I am unable to reproduce your problem. Is that a vanilla install?

comment:38 Changed 5 years ago by rossp

(In [46185]) No need to use instance:zcml since z3c.autoinclude handles this. Refs #9327.

comment:39 Changed 5 years ago by rossp

Reviewed:  https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip9327-review-rossp.txt

I feel like we're in a bit of a pickle here.

The goals of this PLIP are good but without documentation or switching folder_contents, folder_listing, and plone.portlet.collection (and maybe also atct_topic_view) to use these new interfaces, then no one will be able to use this new integration point. Furthermore, instead of *integrating* content listing throughout Plone, we'll have in fact further fragmented it. Now you have folder_listing, folder_contents, plone.portlet.collection, *and* plone.app.contentlisting. On that basis alone I would be -1 for merging.

OTOH, PLIPS #9352 "Improved search results" and #10902 "New collections" are both nifty and sorely needed and depend on this. I'd really hate to see those two not merged.

One solution may be to fix just the documentation for plone.app.contentlisting so that we can accept the package into Plone core as a dependency for plone.app.search and plone.app.collection. Then this PLIP can be postponed for 4.2 when folder_contents, folder_listing, and plone.portlet.collection can be updated to use this new integration point.

comment:40 Changed 5 years ago by rossp

(In [46189]) Reviewed a PLIP. Refs #9327.

comment:41 follow-ups: ↓ 42 ↓ 68 Changed 5 years ago by rossp

(In [46195]) Add some FWT discussion notes. Refs #9327.

From the FWT discussion, getting the plone.app.contentlisting package documented is a must have for accepting this PLIP. Once that is done, we'd very likely merge this PLIP. Can you add detailed developer documentation in the form of "If you want to customize ??? you can do ???". Can you please also add the missing docstrings and comments necessary for ongoing maintenance and approachability?

comment:42 in reply to: ↑ 41 Changed 5 years ago by rossp

Replying to rossp:

(In [46195]) Add some FWT discussion notes. Refs #9327.

From the FWT discussion, getting the plone.app.contentlisting package documented is a must have for accepting this PLIP. Once that is done, we'd very likely merge this PLIP. Can you add detailed developer documentation in the form of "If you want to customize ??? you can do ???". Can you please also add the missing docstrings and comments necessary for ongoing maintenance and approachability?

Geir Bækholt · Jarn writes:

I will be able to do this the coming weekend.

comment:43 Changed 5 years ago by spliter

(In [46236]) Added plone.app.contentlisting as a dependency for the plone.app.search. References #9352 and #9327

comment:44 Changed 5 years ago by elvix

Updated Plone and CMFPlone packages with this plip. No more failures running the Plone tests.

comment:45 Changed 5 years ago by cah190

(In [46282]) Updated review for PLIP 9327. Refs #9327

comment:46 Changed 5 years ago by elvix

response to cah190 on equality testing:

You are right that the eq method is inadequate at the moment. It is meant to support multiple ways of checking if two objects are the same. i just don't know the uuid behavior. Can it be read as a property directly from an object? are they indexed? If not, we should perhaps revert to the path being the universal identifier, until we have a unififed unique id system?

comment:47 Changed 5 years ago by elvix

Thanks for useful feedback, cah190.

Have started documentation: https://dev.plone.org/plone/browser/plone.app.contentlisting/trunk/README.txt

have fixed eq problem. It is now up to each object to provide a way it can be compared to something else with its uniqueIdentifier method. we can add uuid support to that one too. At the moment, is uses either UID or path. Should cover most cases.

comment:48 Changed 5 years ago by cah190

That's a great solution and a good start on the documentation.

I believe the current uuid implementation reuses the UID index. To fetch an object's uuid we use something like:

from plone.uuid.interfaces import IUUID
uuid = IUUID(obj) # returns uuid or throws TypeError
safeuuid = IUUID(obj, None) # returns uuid or None if no uuid

Hopefully that helps. Thanks for your efforts, elvix!

comment:49 Changed 5 years ago by elvix

Feedback to the PLIP-evaluation.

  • I'll keep working on the documentation to ensure it'll be up to par.
  • I will also try to convert those of Plone's default templates i feel is safe without breaking add-on compatibility
  • I will seek guidance from my more up-to-date-on-python-y colleagues on the types of classes (old-style vs new) used.

comment:50 Changed 5 years ago by jaroel

comment:51 Changed 5 years ago by rossp

Documentation and code documentation is much improved. I think it should be improved further but now that we have a base to work from, contributors can improve it from there based on what they find is actually unclear. I'm +1 for merging now.

comment:52 Changed 5 years ago by esteele

  • Milestone changed from 4.1 to 4.2

Moving to 4.2 milestone. I want this one. :)

comment:53 Changed 5 years ago by eleddy

elvix - can you please confirm that you are still interested in finishing up this plip for 4.2???

comment:54 follow-up: ↓ 55 Changed 5 years ago by elvix

Yes. I am.

It would be good, however, to get a clear idea of what the FWT wants to see in place for it to be included.

Should we convert all templates to use it, some templates, all portlets, etc? — or is it enough to have the search depend on it?

comment:55 in reply to: ↑ 54 Changed 5 years ago by davisagli

Replying to elvix:

Yes. I am.

It would be good, however, to get a clear idea of what the FWT wants to see in place for it to be included.

Should we convert all templates to use it, some templates, all portlets, etc? — or is it enough to have the search depend on it?

Speaking personally, I would like to at least see a roadmap for how we switch all these things over -- ideally including some work on prototypes. It's probably fine if we don't switch everything for 4.2 as long as we have a plan.

comment:56 Changed 5 years ago by rossp

It's my memory that this one was ready to go for merge and only didn't get merged because nothing that depended on it got merged and we didn't want to add a core dependency that was unused in core. So from my recollection, this should be merged as long as one or both of those PLIPs that depend on it are merged.

That said, I think it would be a great plus to convert some of the core templates to use it.

comment:57 Changed 5 years ago by eleddy

+ 1 on converting some templates and a plan. That was a major sticky point in discussions.

comment:58 Changed 5 years ago by rossp

After discussing this, the FWT decided that we would like the core Plone templates converted to use this new package.

Firstly, the only reason I was concerned about converting the core listing templates was the possibility of breaking commonly customized templates in a minor release. In today's call cah190 pointed out that changing templates in core plone wouldn't necessarily break customized templates. Secondly, and more importantly, if this PLIP includes changing the core Plone templates then it is no longer dependent on one of the other PLIPs that use plone.app.contentlisting being accepted. We really want to merge this PLIP and converting the templates means it won't get hung up on others. Finally, converting the core templates actually accomplishes the primary goal of this PLIP, to reduce the number of way we list content.

So please go ahead and convert the following core content listing templates in your PLIP branch:

  • all the views behind the folder display menu options
  • all the views behind the collection display menu options
  • portlets: review list, news, events, collection
  • folder_contents

comment:59 Changed 5 years ago by rossp

Poke! Can you briefly reply to the previous comment? Let us know if you can do this and when you think you might be able to do this?

We also discussed the possibility of adding test coverage to assure that we don't break backwards compatibility for anyone who's customized any of the templates.

comment:60 follow-up: ↓ 62 Changed 5 years ago by elvix

Repoke!

Yes! I can handle some or all of those templates.

I tried for last release, however, and realized that several of them are insanely contrived and complex. This is probably from a mix of backwards-compatibility and historical reasons. The only really sane way i can see is to re-write them completely and untangle the folder ones from the collection ones.

I will attempt to convert all, at least directly with all the cruft. — The optimization and big cleanup gain may have to wait.

comment:61 Changed 5 years ago by ldr

  • Cc ldr added

comment:62 in reply to: ↑ 60 Changed 5 years ago by rossp

Replying to elvix:

Thanks for following up. The deadline for feature freeze is June 30th, so we need to start doing implementation reviews as soon as possible. Is this ready for implementation review?

comment:63 Changed 5 years ago by elvix

No. I have done just a slight bit of template conversion. The template work is horrendously painful and demotivating. I am tempted to make a bigger plip and just rip them all out.

comment:64 Changed 5 years ago by elvix

…i will still try to convert enough for a review in the coming week.

comment:65 Changed 5 years ago by kleist

see also #11869 (the same ComponentLookupError as cah described in comment 37)

comment:66 Changed 5 years ago by rossp

Since we need to have a feature freeze by June 30th, we need implementations finished by next week's framework team meeting on Tuesday, June 14th. IOW, implementation will need to be finished on Monday, June 13th.

Will you be able to have the implementation done by then?

comment:67 Changed 5 years ago by rossp

The FWT is going to treat this implementation as complete enough and start reviews.

comment:68 in reply to: ↑ 41 Changed 5 years ago by rossp

(In [50575]) Update implementation review of #9327.

Can't run tests or instance. I assume its because recent changes in CMFPlone haven't been merged into the branch. Please merge ASAP so we can finish review.

comment:69 Changed 5 years ago by rossp

(In [50576]) Oops, wrong python version. Refs #9327.

comment:70 Changed 5 years ago by esteele

(In [50611]) Merge (lots and lots of) changes from trunk. Refs #9327.

comment:71 Changed 5 years ago by esteele

(In [50612]) The changes requiring trunks of plone.testing and plone.app.testing have been merged. Refs #9327.

comment:72 Changed 5 years ago by esteele

(In [50613]) Add missing file. Refs #9327.

comment:73 Changed 5 years ago by hannosch

I worked on the code a bit. The following points from the reviews should be addressed now:

  • no more old-style classes (cah190)
  • plone.uuid support throughout (cah190)
  • renamed the uniqueIdentifier method to uuid and let it use always IUUID() (cah190)
  • fixed readme, so it calls context/@@folderListing to make it clear it's a view and not a method on content objects (rossp)
  • Removed the empty sections from the readme, the usage examples are at the top of the file (rossp)
  • Eric merged the latest CMFPlone trunk, so the tests pass now and the instance should start up (rossp)
  • zLOG isn't used anymore (rossp)
  • logging in catalog.py has been removed, so its not a bottleneck anymore (rossp)

I'll continue working on the plone.app.search code and will move the 'SearchResults' view and its tests over there.

I think converting any existing listings in CMFPlone is outside the scope of the PLIP now. It will only be used as a basis for p.a.search and p.a.collection. Geir could prove me wrong by actually doing the template changes by I doubt it ;)

comment:74 Changed 5 years ago by cah190

(In [50802]) PLIP review update. Refs #9327

comment:75 follow-up: ↓ 76 Changed 5 years ago by elvix

Cah190 said: "The implementation of the content listing interface is ready for merge. The updated folder_listing.pt should not be merged at this time; it may be more suitable for a major Plone release."

I agree that this is a safe approach.

Aiming for a major release for the templates will also allow us to clean out a lot more of the old backwards-compatibility-cruft that is currently in them.

comment:76 in reply to: ↑ 75 Changed 5 years ago by rossp

Replying to elvix:

Cah190 said: "The implementation of the content listing interface is ready for merge. The updated folder_listing.pt should not be merged at this time; it may be more suitable for a major Plone release."

I agree that this is a safe approach.

Aiming for a major release for the templates will also allow us to clean out a lot more of the old backwards-compatibility-cruft that is currently in them.

Keep in mind that the fact that none of the core templates were converted and no PLIP that depended on plone.app.contentlisting was accepted is exactly why this PLIP wasn't merged into 4.1.

comment:77 Changed 5 years ago by rossp

(In [50809]) Finish updating my review. Refs #9327.

Now that esteele and hannosch have fixed things I was able to finish my review. I'm +1 for merge minus the CMFPlone templates branch and as long as either #9352 or #10902 are merged.

comment:78 Changed 5 years ago by rossp

FWT voted to merge this PLIP.

comment:79 Changed 5 years ago by esteele

  • Status changed from reopened to closed
  • Resolution set to fixed

(In [51129]) Add plone.app.contentlisting to the 4.2 build. Closes #9327.

comment:80 Changed 4 years ago by fmoret

  • Status changed from closed to confirmed
  • Version set to 4.1

Hello, I'm testing Plone 4.2rc2 and I'm having an issue when I try to use @@folderListing(batch=true). It seems that IContentListing(batch) is not able to get values or attributes from the Batch class. Here is the traceback:

    Module zope.tales.expressions, line 217, in __call__
    Module Products.PageTemplates.Expressions, line 147, in _eval
    Module zope.tales.expressions, line 124, in _eval
    Module Products.PageTemplates.Expressions, line 77, in boboAwareZopeTraverse
    Module zope.traversing.adapters, line 136, in traversePathElement
    __traceback_info__: (<plone.app.contentlisting.contentlisting.ContentListing object at 0x11046510>, 'pagenumber')
    Module zope.traversing.adapters, line 47, in traverse
    __traceback_info__: (<plone.app.contentlisting.contentlisting.ContentListing object at 0x11046510>, 'pagenumber', [])
    Module plone.app.contentlisting.contentlisting, line 19, in __getitem__
    Module Products.CMFPlone.PloneBatch, line 139, in __getitem__

IndexError: pagenumber 

Fabien

comment:81 Changed 4 years ago by esteele

  • Status changed from confirmed to closed

Moved the bug report to #12973. Reclosing PLIP ticket.

comment:82 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.