Ticket #9258 (closed PLIP: fixed)
Replace Products.ATReferenceBrowserWidget with archetypes.referencebrowserwidget
Reported by: | tom_gross | Owned by: | tom_gross |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | Archetypes | Version: | |
Keywords: | Cc: | plip-advisories@… |
Description
Overview
Replace the Products.ATReferenceBrowserWidget with archetypes.referencebrowserwidget. The archetypes.referencebrowserwidget is tested, stable and in use in some production sites and is UI-compatible with the ATRefBWidget
Tasks
The current implementation of archetypes.referncebrowserwidget is stable and works with Plone 3.3rc3 and the current trunk. The effort for changing code here will be minimal, if any. Most changes will take place in Products.ATContentTypes, where some import locations need to be fixed. And probably there need to be fixed some egg dependencies depending on Products.ATReferenceBrowserWidget.
Risks
A risk is to break backwards compatibility or existing sites by changing the name of the widget. Thus there is a wrapper for Products.ATReferenceBrowserWidget which may provide the current locations for a certain deprecation time. No persistent components are involved so changing completely in some time (Plone 5) will be no issue.
Change History
comment:2 Changed 7 years ago by erikrose
- Owner nouri deleted
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:4 Changed 7 years ago by rossp
I'm a little unclear on why archetypes.referencebrowserwidget was started. Was it just to add test coverage? If so, why wasn't that added to Products.ATRBW? Is it a better implementation? If so, can we get some details? For now, my FWT vote is -0.
comment:5 follow-up: ↓ 7 Changed 7 years ago by tom_gross
archetypes.referencebrowser was mainly written because
- Products.ATRBW is untested
- Products.ATRBWs performance on large containers is very bad, since it calls getObject for every item.
Actually it started with a patch of Products.ATRBW, but the maintainer then (hannosch) suggested to create a new package. See http://thread.gmane.org/gmane.comp.web.zope.plone.devel/19818
The advantages of archetypes.referencebrowser over Products.ATReferenceBrowserWidget today are:
- The code is well tested.
- The implementation is catalog-only, which gives a way better performance on containers many objects.
- The widget supports ordered references out-of-the-box.
- The widget is easily extensible and adaptable to custom reference implementations (e.g. plone.app.relations).
- The necessary JavaScript uses jQuery and doesn't depend on cssQuery.
- It supports custom sized popups.
- It works with current Plone trunk ;-).
- It is more or less PEP-8 compatible.
comment:6 Changed 7 years ago by MatthewWilkes
Based on that email thread, it seems the better widget. As long as existing code will still work, which it sounds like it does, I think this is appropriate.
FWT Vote: +1
comment:7 in reply to: ↑ 5 Changed 7 years ago by rossp
Replying to tom_gross:
Some how my previous comment seems to be lost. Sorry if this ends up repeating.
As long as the detail above is included in the PLIP description, my FWT vote is +1
comment:8 Changed 7 years ago by davisagli
Thanks for the additional info, Tom, which was very helpful. I assume that you will be the implementer of integrating this; if that is correct please take ownership of this ticket.
FWT vote: +1.
comment:9 Changed 7 years ago by tom_gross
- Owner set to tom_gross
- Status changed from new to assigned
comment:10 Changed 7 years ago by raphael
FWT vote: +1
comment:11 Changed 7 years ago by calvinhp
FWT Vote: +1 sounds solid
comment:12 Changed 7 years ago by esteele
Approved by FWT vote.
comment:13 Changed 7 years ago by tom_gross
comment:14 Changed 7 years ago by tom_gross
The PLIP is ready to review.
comment:15 Changed 7 years ago by alecm
comment:16 Changed 7 years ago by esteele
Your PLIP has been reviewed by the Framework team. 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 23.
comment:17 Changed 7 years ago by esteele
comment:18 Changed 7 years ago by tom_gross
The PLIP is ready to merge. Thanks for the reviews.
Another test scenario is the use of atref-widget in collections with path-criteria.
About the funky jQuery stuff I'm unsure.
- What about users who have turned of JavaScript?
- I would need help with the jQuery stuff. I never worked with it comprehensively.
comment:19 Changed 7 years ago by alecm
I'd suggest you seek guidance from Steve Mcmahon as this would probably be a task for jQuery Tools overlay (see #9250). If you're going to be in Budapest for the sprint, perhaps we can have a track dedicated to adding nice little jQuery Tools touches to the Plone interface.
I believe the current reference browser required javascript to function, so requiring js is not a major concern. Apparently, having the form inserted into a modal window in the current DOM is better for accessibility than a popup.
comment:20 Changed 6 years ago by esteele
comment:21 Changed 6 years ago by MatthewWilkes
FWT vote on merging: +1
comment:22 Changed 6 years ago by rossp
FWT vote: +1 for merging
comment:23 Changed 6 years ago by esteele
This PLIP has been accepted for merging into Plone 4.0
The final vote was: Alec Mitchell +1 David Glick +1 Erik Rose +1 Laurence Rowe +1 Matthew Wilkes +1 Ross Patterson +1
Please merge your branches into the Plone 4.0 head by end-of-day Friday Oct 16. If you need assistance with merging, please contact me.
We'll be assigning a documentation ticket to this PLIP shortly. Please assist the docs team in documenting the changes and new features that this PLIP introduces.
comment:24 Changed 6 years ago by esteele
Please assist the doc team in creating/updating documentation relating to this PLIP. See #9605.
comment:25 Changed 6 years ago by tom_gross
- Status changed from assigned to closed
- Resolution set to fixed
The PLIP has been merged to the trunk.
+1
I'd like to hear what the Products.ATRBW maintainer thinks about this proposal, but it certainly sounds like a good idea to replace untested code with compatible tested code.