Joern Nettingsmeier wrote:
Michael Wechner wrote:
Jörn Nettingsmeier wrote:
hi everyone!
does anyone use the publication.xml files for anything interesting?
if not, would you object to removing the mechanism altogether and
move all important information from there into publication.xconf
benefits:
* gets rid of a number of pipelines in the global sitemaps
* gathers all publication metadata into publication.xconf, where it
belongs imho.
* gets rid of a number of important-looking but undocumented and
apparently non-functional fields (lenya-revision, lenya-version,
cocoon-version) and the bogus <module/> list that looks like it's
important somehow and does nothing more than display a <ul/>.
If you use Lenya in production, then this info makes perfectly sense
agreed. but imnsho it does not warrant a special mechanism comprised
of 2 stylesheets, an undocumented ad-hoc xml namespace and number of
pipelines in the global sitemap. the version information will be moved
to publication.xconf.
check the archives and you will see that we actually agreed to such a
merge quite some time ago ;-)
* provides a generic welcome page with standardized information and
the same reader/editor links for everybody.
i guess people will generally be hiding this page from the public
anyways...
yes, from the public, but not for administrators, etc.
right. my current approach provides a generic listing of the
publication's configuration plus the usual links to docs and login -
i.e. stuff that is of interest to admins and editors.
+1 to merge, but merge the whole structure.
the whole structure cannot be merged iiuc. publication.xconf is a
Configurable data file, and the Configurable interface supports only a
subset of XML - notably, mixed content is not supported, which would
be natural for a "readme" section.
therefore my current approach is to allow only simple fields in
publication.xconf.
i'm also thinking of providing a global "readme.xml" that is called
via fallback. it can be used by developers to inform users about
important changes and required tweaks, and publications could override
it to add their own information.
I don't think that makes sense. This is what namespaces are good for.
Btw, you might also want to consider RDF for this.
lazy consensus in effect ;)
based on what definition? I mean about many days are we talking? What
about weekend, business days, people on vacation?
I think it's important to get this straight, otherwise it's just
meaningless
note the smiley. i was grinning because i anticipated the usual
situation: /me starts hacking frantically, and everybody else is out
of office until monday...
it is not my intention to sneak something in without proper review and
discussion.
i'll post a patch for you to review before anything will be committed.
at the moment, the patch is at 557 lines out, 258 lines in, with a
slight gain in functionality (which is how i like things to be ;)
I do not consider "lazy consensus" as something which we should toy
with, but a clear definition for a process. As said I am not sure if we
actually defined it clearly. Any pointers are very welcome.
Cheers
Michi
regards,
jörn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
