[Framework-Team] Feedback on New Collections for Plone 4.2

[Jon Stahl]

On Tue, Jul 5, 2011 at 3:45 PM, Alec Mitchell <alecpm at gmail.com> wrote:

> On Tue, Jul 5, 2011 at 2:46 PM, Jon Stahl <jonstahl at gmail.com> wrote:
> > Couple of thoughts and some background questions, thanks for starting
> this
> > thread, Alec.
> >
> > 1) Is it feasible to optionally automatically migrate old-style
> Collections
> > to New Collections (as I'll refer to them here)?  If not, why not?  This
> > seems like it would be hugely valuable, and eliminate most if not all of
> the
> > pain we are anticipating.
>
> It's likely to be a significant undertaking, fraught with potential
> pitfalls.  AFAIK, there is no one currently interested in writing such
> a migration, but there is a great deal of interest in replacing the
> current unintuitive Collection type.  Content migrations are almost
> always painful, and are probably best avoided when possible.  If a
> migration is provided, it would probably need to be optional and user
> initiated.
>
> As the person who wrote most of the CMF Topic to ATCT Topic migration
> code (which was significantly more straightforward than this would
> be), I don't think a migration is necessary here.  Migrating existing
> collections would not solve any of the issues that my message was
> concerned with, and would create or exacerbate some issues.  For
> example template incompatibility issues will have no impact on
> existing sites if we don't migrate Collections, but the impact could
> be very large if we did.  We cannot make the new type fully backward
> compatible, so performing migrations would probably just exacerbate
> the incompatibilities.
>

Thanks, good to know.



>
> > 2) Thinking over Groundwire's 150+ launched Plone sites (going all the
> way
> > back to 2.0.5), I'm having trouble thinking of more than a handful where
> we
> > trained clients on building/modifying their own Collections.  And those
> few
> > whom we have are quite sophisticated and I'm sure would have zero
> difficulty
> > picking up the new UI.  So I'm not too concerned there.
>
> This is very good to know, thanks!
>
> I imagine these sites would be upset if their existing collections
> suddenly behaved differently (due to the inevitable unforeseen
> migration glitch) or their custom templates no longer worked or their
> migration failed entirely (not an uncommon thing when arbitrary
> content needs to be migrated in-place).  This is the primary reason
> why a migration, even if created, would likely be optional (as was
> true for blob storage).
>
> > 3) Where I am concerned, though, is with add-on products. I can think of
> > quite a few widely used add-on products that provide custom views on top
> of
> > Collections (or Folders).  I'm thinking of products like:
> >
> > * Scrawl (and similar blog products)
> > * PloneTrueGallery (and similar photo gallery products)
> > * EEAFacetedNavigation
> > * collective.flowplayer
> > * The various "fullcalendar" products e.g. solegma.fullcalendar
> >
> > Would these products all break?  Do we yet know how much work it would be
> to
> > update them for New Collections?  If there is work involved to upgrade,
> can
> > we work to ensure that product authors have the information and time they
> > need to upgrade their products before 4.2 launches?
>
> The original collection type would continue to be present in the
> system, so any existing collections would still work with these
> products.  If we migrated collections, then these products would
> almost certainly no longer work with either new or existing content.
>
> Leaving the collection type addable with an altered title would allow
> people to continue to be able to add new collections that are
> compatible with these products (documentation would probably need to
> be updated to reflect the title change).
>
> In order to work with the new collection type, these products will
> certainly need to be updated.  Some updates will be fairly trivial
> (e.g. eea.facetednavigation which doesn't use any actual collection
> features), others will probably require more extensive updates.
> Nonetheless these products will not break, because the original type
> will remain unchanged as will existing content.
>

Makes sense, seems reasonable.

>
> > 4) A meta-point: as I mentioned on IRC, and especially if no automatic
> > migration from Old to New Collections is possible, I think it's pretty
> > important to solicit some wider input/raise awareness about this well
> before
> > 4.2 goes live.  I'd suggest engaging in some wider discussion on
> > plone-developers and product-developers.
>
> Perhaps, but I think we can have that discussion later.  For now
> we're, looking for some specific answers from a specific audience.  A
> broader discussion could, for example, easily get sidetracked into a
> discussion about whether content should be migrated and the various
> ways add-on products might need to be updated, which is something
> entirely different from what I had intended to get at :-)
>
>
> Fair enough.  :-)  To answer your original question then:


"Do you, as people with extensive support and training experience, feel
that it would be acceptable to disable adding of AT collections in
favor of the new more usable collections during migration?  Is it
likely that a significant number of deployments would be negatively
impacted by such a switch?  If the old type were disabled, would clear
documentation describing how to re-enable adding it be a sufficient
mitigation?  Would it be preferable to keep the old Collection type in
the add menu, but change the title to one which makes it clear that it
is no longer recommended (e.g. "Old-Style Collections")?"

My feeling is that very few of Groundwire's existing deployments would be
harmed by disabling adding of Old Collections in favor of New Collections.
Clear documentation about how to re-enable them would suffice for the tiny
minority of exceptions.  I'd prefer to keep superfluous stuff out of the Add
menu by default.  Alternatively, demoting it to the "more..." section of the
Add menu would be fine, too.

:jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20110705/3451e432/attachment-0001.html>