[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