#10902: New collections (merged plip)
---------------------+------------------------------------------------------
Reporter: elvix | Owner: elvix
Type: PLIP | Status: new
Priority: minor | Milestone: 4.1
Component: Unknown | Resolution:
Keywords: |
---------------------+------------------------------------------------------
Description changed by elvix:
Old description:
> == 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
New description:
== 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.
[[Image(Picture 8.png)]]
== 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
--
--
Ticket URL: <http://dev.plone.org/plone/ticket/10902#comment:1>
Plone <http://plone.org>
Plone Content Management System
_______________________________________________
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories
