Ticket #10902 (closed PLIP: fixed)
New collections (merged plip)
Reported by: | elvix | Owned by: | jaroel |
---|---|---|---|
Priority: | minor | Milestone: | 4.2 |
Component: | Unknown | Version: | |
Keywords: | Cc: | csenger, plip-advisories@…, |
Description (last modified by elvix) (diff)
Proposer: Geir Bækholt
Seconder: Laurence Rowe, Denys Mishunov
Motivation
Collections in Plone are the most powerful tool content editors and site managers have to construct navigation and site sections. They do, however create somewhat of a mess in their current form and are still hard to use.
This proposal is for supplying a replacement type for collections, using ajax/javascript to make a simpler, more sane and streamlined user experience for using collections and having a more lightweight backend that does not depend on many nested criteria types.
The criteria (i.e the internal implementation details) of old style collections are implemented as Archetypes content types. This has a number of unfortunate side-effects:
- Performance. Content objects take a long time to save and are heavyweight objects. Using many of these for internal structure causes large overhead.
- UI pain. These internal types pop up in a lot of lists and preference screens designed for managing content. It is currently necessary for developers to maintain lots of exceptions and filters and double lists to not show these non-types to users.
- The user-interface forms for collections have also proven to be almost impossible for normal users to use. THey must be modernised and improved.
Assumptions
This work will not touch existing ATTopic, but replace it with an alternative implementation. To avoid massive migration headaches, we will leave ATTopics in place and just add a new type for new collections. A migration path is outside the scope of this PLIP.
Proposal & Implementation
Implement a new content type that can replace ATTopic. Use a lightweight backend for storing the query (currently uses a string) instead of using criteria subobjects.
An interactive JS/AJAX-driven form where the user can add one line (i.e one clause to the query) at a time. Adding a clause/line will narrow the resultset immediately. If the user changes or adds criteria, the bottom area will update a tally of how many results are found immediately. — and also a preview list of the first few results.
Adding a line/clause/criteria will be a simple one-step process, not the current two step process where users first save their criteria type, then return to the form to fill data. The current form process is extremely confusing to users.
See attached screenshot for example of a way the criteria form can look.
Deliverables
- reusable query code (can be used for portlets, tiles, advanced search etc)
- content type with query form UI
- tests
- i18n
Risks
- A rather big implementation job, but most of the work is already complete.
- Introduces dependencies (plone.app.registry)
- Possible confusion for people migrating existing sites that we leave old collections in place, and introduce new ones with new UI. Must be solved by documentation.
This PLIP is a combination of the previously approved yet not completed PLIPs #9295 and #9283
Attachments
Change History
comment:3 Changed 6 years ago by elvix
- Description modified (diff)
Most of the implementation is already done. Several people are involved in the implementation, including Eric Steele, Matthew Wilkes, the fourdigits team and myself.
comment:4 Changed 6 years ago by eleddy
This is beautiful and clear. Thanks for pushing ahead on this.
comment:5 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:7 Changed 5 years ago by rossp
While trying out some Hudson stuff, I ran alltests for this PLIP:
comment:8 Changed 5 years ago by jaroel
A migration script is currently under development. ETA: next weekend.
comment:9 Changed 5 years ago by jaroel
I've added a start for a conversion script to the branch http://svn.plone.org/svn/plone/plone.app.collection/branches/upgradepath/ . I'll continue to work on it, but I also consider it out-of-scope.
comment:10 Changed 5 years ago by rossp
The implementation is slick and really nice to use. It's a vast improvement over what we have currently. I'd love to see it included in 4.1.
Having said that I don't think I'm comfortable merging it as-is, but the changes required seem to be pretty doable. If more complete docstrings, comments, and interfaces are added, the test failures are addressed, and the BadRequest errors are addressed, I'm a strong +1 for merging.
comment:11 follow-up: ↓ 13 Changed 5 years ago by jaroel
- Owner changed from elvix to jaroel
I'll fix them asap. Is there a deadline?
comment:12 Changed 5 years ago by eleddy
comment:13 in reply to: ↑ 11 ; follow-up: ↓ 15 Changed 5 years ago by rossp
Replying to jaroel:
I'll fix them asap. Is there a deadline?
We haven't heard any more regarding work addressing review feedback. Can you give a status update ASAP?
As for deadlines, I apologize for not following up on this ticket, but the deadline mentioned on the list has already passed. However, if you can get things fixed within the next couple weeks in time for alpha 2 we'd still like to merge it.
comment:14 Changed 5 years ago by esteele
- Milestone changed from 4.1 to 4.2
Moving to 4.2 milestone. I want this one. :)
comment:15 in reply to: ↑ 13 Changed 5 years ago by rossp
Replying to rossp:
We'd love to see this make it into 4.2. Are yall still around? Can you address the above feedback? Anyone else wanna pick this one up?
comment:16 Changed 5 years ago by jaroel
I'm still around :)
Most issues should take more then an hour to fix, but there are a bunch of them :/ Sadly I do not have a lot of time, so if someone wants to help out, they are more than welcome.
At least p.a.collection is usable, the 'Duplicate profile ID' errors are gone and some more work is done.
comment:17 Changed 5 years ago by jaroel
*shouldn't take more then an hour.
comment:18 Changed 5 years ago by rossp
Poke! What the status on this work?
comment:19 Changed 5 years ago by jaroel
I haven't gotten around doing anything on this since last update. Just to be clear: I want this one too :)
comment:20 Changed 5 years ago by rossp
Great! More importantly, however, what are the rough chances you'll be able to address all the issues by the end of May?
comment:21 follow-up: ↓ 22 Changed 5 years ago by jaroel
Looks like we're sprinting on this next friday. That should be enough, but we'll know by then :P
comment:22 in reply to: ↑ 21 Changed 5 years ago by rossp
Replying to jaroel:
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:23 Changed 5 years ago by jaroel
Not yet, I'll plan another sprint to make this happen.
comment:24 Changed 5 years ago by jaroel
I've added responses to the reviews and a todo list. https://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.1/plips/plip10902-review-responses.txt https://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.1/plips/plip10902-todo.txt
The todo list is mainly documentation and finishing touch stuff.
comment:25 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:26 Changed 5 years ago by rossp
In the FWT meeting it was revealed that this PLIP's implementation is finished and ready for review.
comment:27 Changed 5 years ago by rossp
comment:28 Changed 5 years ago by eleddy
comment:29 Changed 5 years ago by cah190
comment:30 Changed 5 years ago by eleddy
Hey guys - Can you comment on whether or not you are using the same timeout that livesearch is between keypresses before firing off ajax requests? Just want to be consistent here and make sure we aren't pounding someones server.
Thanks!
comment:31 Changed 5 years ago by rossp
FWT voted to merge this PLIP.
comment:32 Changed 5 years ago by alecm
For some advice on how migration should be handled, I recommend the following thread ( http://comments.gmane.org/gmane.comp.web.zope.plone.teams.framework/3593). I asked Plone community members with extensive experience providing training and support a variety of Plone sites how the replacement of the collection type might impact those sites which already make use of AT Collections. That thread contains their responses. In addition to the on-list responses, I received one off-list response from Sam Knox (who does training for Groundwire clients) which provided the same conclusion as the rest:
"The bottom line is that I think it's a good idea to force 4.2 sites to be able to only add the new Collection type. We've had sites in the past using both Topic and Rich Topic and that did get confusing at times."
There seems to be broad consensus that the least confusing route would be to disable and re-title the old AT Collection type during migration, while making it clear how to re-enable adding it for those users who require AT Collections for some add-ons or custom templates.
comment:33 Changed 5 years ago by esteele
- Status changed from new to closed
- Resolution set to fixed
comment:34 Changed 5 years ago by spliter
comment:35 Changed 5 years ago by spliter
Hi Roel,
The Plone UI team would like to inform you that we have reviewed your PLIP and put it into http://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.2/plips/plip10902-review-uiteam.txt
Please consider checking it. In our opinion there are quite a few UI-related moments that have to be fixed. Moreover we have found a couple of bugs that are in the review as well.
If you need help or have any question, don't hesitate to contact us any time. Good luck.
comment:36 Changed 5 years ago by seanupton
I respectively disagree with the UI team's assessment that all text-index searches (Title, Description, SearchableText) should be collapsed into one search of SearchableText. I have use cases for collections searching for a partial word or phrase on the title, and I suspect many others do as well.
By analogy: I search emails all the time for some partial text in the subject-line only; I expect and have an application need to search similarly for a word in the title only in a collection. My current use case is to allow users to collect and link to items where the last name of a person is in some document titles.
I'm ambivalent about Description -- that could get lumped with SearchableText, but distinct text search on title matters to me.