Re: plans for reference management
Christian Zagrodnick <cz-w5oghCfH6z/[email protected]>
| Newsgroups | gmane.comp.web.zope.silva.devel |
|---|---|
| Message-ID | <[email protected]> |
On 19.04.2005, at 00:16, Clemens Klein-Robbenhaar wrote: > > Hi Martijn, Roman: > > [...] >>> But it may be too late after publishing the document that an author >>> is >>> informed about broken links. So, he has to alter and >>> publish the document again to fix the broken links. That are to >>> steps to >>> get a document with correct links in it. But you're right, if the >>> document contains a vast amount of links, it'll be overkill... >> How slow is checking a link for existence in this system? If this is >> reasonably fast, then it's quite doable to do it on every kupu save. >> Harder, especially due to the feedback to user issue, might be the >> forms editor, where only parts of the document get edited, and you >> don't want the whole document be checked each time. You could of >> course extract the links from only the part but it'd be hairy. >> Perhaps Clemens' later proposal about a button to check references >> makes most sense, especially as a first step. > > If I understand the lms correctly it is about first registering the > links with the link checker; the results can be fetched later. Sort of. Only you don't fetch the results but are notified if a link changes its status. > So it is maybe not too inefficient on the Silva side just to register > the link (it may be inefficient for the lms to check them while > they get swapped away with the next edit). Even less performance > problems > for references, I guess. > The reason why I initially thought about checking the links on > approval > is that after approval it seems to make some sense to me to include > the references into reference management. However there seems to be > some > consensus we should not talk about that now but target at goals closer > by, > so that idea goes off topic. > > Again, if I understand the lms right, one could have a simple summary > (including a "check in progress" stat) on the main edit page > relatively cheap. This is basicly the 'initiated' state. When a link is initiated you know the lms didn't now an immediate result but needs to check. > Looking in the cold ashes of my last attempt to improve the reference > service (quite a year ago ..) I found ruins of something which tried > to do > something vaguely similar to the "LinkDatabase" of the CMFLinkChecker > -- i.e. store the links/references so they do not have to be fetched > on every run. As this would have replaced the current > "SilvaReferenceChecker" > anyway, by importing my sources I do not mean to make any predecision > about how to proceed, e.g. if to port CMFLinkChecker or just port the > part > using the lms and grow its own instead. (We can reuse the part > retrieving > the references anyway, I hope.) It would be great if we could share some code parts. CMFLinkChecker is not *that* tightly bound to Plone that it wouldn't possible. If would me nice to have the generic Zope part factored out an then having a Plone or Silva version on top. But even if it doesn't happen, we at least share the lms, right :) -- Christian Zagrodnick gocept gmbh & co. kg · schalaunische strasse 6 · 06366 koethen www.gocept.com · fon. +49 3496 3099112 · fax. +49 3496 3099118 _______________________________________________ silva-dev mailing list silva-dev-IAPFreCvJWM6s/[email protected] http://lists.infrae.com/mailman/listinfo/silva-dev
smime.p7s
(application/pkcs7-signature, 2.3 KB) - not displayed