[Framework-Team] [PLIP 125 Link Integrity] - Review notes, part I
Andreas Zeidler
az at zitc.de
Fri Sep 15 08:58:39 UTC 2006
On Sep 15, 2006, at 1:00 AM, Martin Aspeli wrote:
> Hi guys,
hi,
first of all, thanks for the review, martin. imho it's very
attentive as you've already mentioned pretty much all of the little
things and side-notes i was worried about yourself -- i'm impressed
(once more)! :) anyway, i'll add a few comments if i may...
> These notes only cover part I. Part II is envisaged to be delivered
> via whit's topp.rose product, which Andi is currently looking into.
atm i'm trying to get topp.rose to work with zope 2.10, which turned
out to be a bit tricky. i hope to get this sorted out today, though,
and once i have the initial integration into zope should be rather
easy, imo.
> *Note* - I'm getting an exception raised if I try to cancel the
> delete. I think this is something that's crept in very recently,
> and I've told Andi about it. This fix should be trivial, though -
> for now, just click on another link (e.g. the navtree) to prove
> that the object is not gone.
>
> [...]
>
> - If the user clicks No, the whole deletion operation is aborted
actually, the exception is intended as an indication for the link
integrity breach. imo the code invoking the deletion should handle
it, because there is no other way to respond to the cancelled request
in a generic way. or at least i couldn't think of any -- a
redirection would be possible here, of course, but where should it
redirect to?
however, the specific exception martin was talking about gets raised
when the item is deleted via 'object_delete', that is through the
link in the item's actions. this needs to be handled gracefully by
plone, of course, but the problem here really was that i've only
covered 'folder_delete' in that sense so far, since i very rarely use
that link myself. so i just haven't thought of that case before
while trying to fix some more important issues first -- shame on
me... luckily, it should be trivial to fix, though. :)
btw, this is also the reason i wasn't aware of the "doubled"
confirmation page until hanno pointed it out to me yesterday.
> ===========================
> 3. Concerns and suggestions
> ===========================
>
> - The confirmation page needs a touch of visual love
i'm fine with doing the work if someone provides me with a better
layout for that. limi? :)
> - There is already a "delete confirm" page when you select the
> Delete action from the actions drop-down (I believe this used to be
> a JS pop-up). It'd be nice of the delete protection could be
> applied here so that you don't potentially get two confirmation pages.
my fault as mentioned above... :)
> ==============================
> 4. Recommendations and caveats
> ==============================
>
> If/when we merge, this could move to the plone.app space. That'd be
> purely aesthetics, though. The LinkIntegrity skin layer does
> contain a customised version of folder-delete to work around some
> over-zealous exception checking, but this is easily merged into
> Plone core. At this point, LI won't require a quick-install at all.
yes, the seperate product is a legacy issue. the changes should be
integrated imho, too. once it's ready and accepted, that is... :)
regards,
andi
--
zeidler it consulting - http://zitc.de/ - info at zitc.de
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
keine softwarepatente in europa! - http://noepatents.eu.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20060915/799cbf7d/attachment.sig>
More information about the Framework-Team
mailing list