On 2/23/06, Michael Wechner <[EMAIL PROTECTED]> wrote:
> Andreas Hartmann wrote:
> > Michael Wechner wrote:
> >> Andreas Hartmann wrote:
> >>> Michael Wechner wrote:
> >>>> Andreas Hartmann wrote:
> >>>>> Before building our own dependency resolving mechanism, I'd rather
> >>>>> review the Cocoon block concept again (maybe they allow external
> >>>>> blocks by now) and convert modules to blocks if this is appropriate.
> >>>> sure, but as said it's not about building something very complex,
> >>>> but very simple.
> >>>> It's basically parsing publication.xconf and check if the modules
> >>>> listed there are
> >>>> actually available ...
> >>> I'm generally against introducing a custom mechanism for something
> >>> that is already supported by a product which Lenya is based on.
> >> well, modules are no blocks, right? Are we going to change this? And
> >> if so, by when?
> > This has to be analyzed and decided. As soon as I find the time
> > I'll take a look at blocks again - I hope next week.
> >> Does it bother you if the publication.xconf is being checked and will
> >> help you to
> >> save time instead wasting time on debugging why something doesn't work?
> > I'm not against the concept of dependency checks, I'm just against
> > hurriedly implementing a custom mechanism when a mature solution
> > exists for the problem. I'd rather invest the time to see what Cocoon
> > does
> that's your time ;-)
> > - but of course that's just my personal opinion.
I am a little confused about how this would work, and doubt any
existing code would handle it properly. The code must check inherited
Templates, and that is a Lenya-specific feature. Three Templates
could have identically named Modules; this Publication only cares
about the Module it inherits.
I created the bugzilla about the Xalan libraries because, at the time,
it seemed every third thread on the mailing list was caused by
library issues. Checking for the files during the first boot would
have great ROI, and later boots could just check if the files found
were unchanged, unless a command line option, or a flag is configured
when Lenya had certain errors, forced a complete check during the next
launch. The administrator could look at the console window or a log
file to see the problem.
Missing modules is a completely different issue. Lenya will run
without a Module. A Publication will run as long as the default
Module (usually "live") exists. The Publication or Module may be
inactive; should there be error messages when the code is unused? The
big question is when would the Module dependency check happen, and how
would it be reported.
Consider these situations:
- A visitor mistypes a URL with a bad ModuleID..
- A visitor enters a URL for a Module that is not configured for this
Publication.
- A visitor enters a URL for a Module that is configured but missing
from the Publication.
- A visitor enters a URL for a Module they are not authorized to use.
- A visitor enters a URL for a Module that is broken.
True security demands that all of these return the same error page.
If the visitor complains, the administrator should:
- Check publication.xconf to see if the Module is configured for this
Publication.
- Check publication.xconf to see if the Module is configured.as
"external" for this Publication.
- Check if the Modules can be found in the Publication or its inheritance.
- Check if this visitor is allowed to use the Module. (They may do
this first by checking the URL with their superuser login.)
- Check if the Module is broken.
We could assist the first three items by having a Publication "Modules
Status" admin screen:
ModuleID, External?, Directory/Files found?
If the ModuleID is not listed, external is false, or no
"modules/{moduleid}/sitemap.xmap" is found in the inheritance, then
the admin knows the problem. If those settings are good, and it is
not an authorization issue, then the admin knows the Module is broken
(and tells a developer.)
Is there a better method for reporting about missing Modules?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
