Andreas Hartmann wrote:
Richard Frovarp schrieb:
Andreas Hartmann wrote:
[...]
I did some more tests - maybe I did missed something before, but now
I get different results which resemble my expectations.
* same setup as above
* Lenya 2.0.2-dev without modifications
* Fallback source URI caching enabled
a) standard publication.xml: avg. 1200 ms
b) publication.xml contains only modules with menus: avg. 800 ms
In case b), the aggregated menu XML is cached because the include
transformer didn't come across any non-existing sources and
therefore the validity could be computed.
At the moment b) can't be enforced because the publication.xml
entries are also used for i18n. But I'm confident that we would find
another way to assemble the modules i18n catalogue.
WDYT - can we require that publication.xml contains only modules
which provide a menu, and throw an exception otherwise?
I would assume you could get away with a blank menu? Still, requiring
a menu seems to be a bit of a kludge when it isn't necessary for the
module (prettyprinting for example).
We wouldn't require that the module contains a menu - the implication
of the test result is that the performance degrades if the
publication.xml contains references to modules which don't contain a
menu. At least this is my interpretation, and a debugging session
indicated that this is really the case.
So a possible approach to enforce a performant configuration would be
not to deliver an empty menu XML for those modules but to throw an
exception instead, so that the user is forced to remove the
"offending" module references from publication.xml.
-- Andreas
Our documentation states that the modules need to be listed to generate
the menus and to access i18n messages. Something like notification
doesn't have menus, but does need i18n. How would that work?
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
