Previously Martin Aspeli wrote: > Hi guys, > > I think LinkIntegrity is nearly ready for merging. Before doing so, I > have a few caveats, and I'd like to have someone else take a look over > the code. > > Good points: > > 1) It works > 2) It requires very little integration; a marker placed on the request > in folder_delete.cpy (to avoid an annoying re-run confirmation), and a > triggering of a monkey patch (see below) > 3) It's very ubiquitous - it will work almost anywhere that objects > are deleted in the Plone UI > 4) It's very well documented and commented > 5) It's very well tested (see doctests in docts/) > > Worrying points: > > 1) It's very pervasive :) For example, you'll get delete confirmation > (in Plone) if you try to delete an object in the ZMI. I'm not entirely > sure, but I think you may even if the delete is happening from a script. > Whether this is good or bad will probably depend on the use case. I > believe it's possible to bypass confirmation by putting the appropriate > marker in the request (all managed via a well-defined adapter), but it's > more of an opt-out than an opt-in > > 2) It does monkey patch the publisher (in a pretty sane way). Note > that this patch would go away if FiveException was merged into Zope 2, > which is not completely unlikely, especially if we push for it. > > 3) It monkey patches parts of the test framework to work around bugs > there, but these could be fixed. > > My recommendation: > > (*) We merge, provided: > > a) We merge the one template override (folder_delete.cpy) into > CMFPlone, which should be harmless > b) We make an on/off switch to turn off the behaviour globally (Andi > is working on this) > c) We make it into plone.app.linkintegrity rather than > Products/LinkIntegrity (trivial) > > The code is here: http://svn.plone.org/svn/collective/LinkIntegrity/trunk/ > > Just install in a Plone 3 instance using quickinstaller, and you can > test it. Add some documents, make some links in HTML between various > documents, and try do delete a document that's referenced from another. > > Tests and use cases also here: > http://svn.plone.org/svn/collective/LinkIntegrity/trunk/docs > > Note that there is a kind of "Plan B" - we keep the link parsing and > reference building, but lose the pervasive checks that handle all kinds > of deletes; instead, we build warnings into Plone's existing > delete_confirm pages. This is obviously less strong and requires a more > direct dependency in CMFPlone. > > Given the amount of work (and tests!) that have gone into LinkIntegrity > to date, and the fact that it does seem to work so well in the UI, I'd > say we should keep the deeper integration as it is now, but I want to > make sure people are aware of the options and implications. > > What do you think? We can have this ready for merge by the end of the > year if we get the +1.
+1 definitely Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team