You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.com> on 2006/02/22 22:22:02 UTC
Addressing Modules
Hi
I think each module should have a descriptor (similar to publication.xml
resp. publication.xconf) where the module is being described and also
"addressed"
with
- name (e.g. atom-entry)
- namespace (e.g. http://lenya.apache.org/2006/1.0)
- version (e.g. 1.0)
in order to avoid conflicts.
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Addressing Modules
Posted by so...@apache.org.
On 2/24/06, Bob Harner <bo...@gmail.com> wrote:
> On 2/23/06, Michael Wechner <mi...@wyona.com> wrote:
> > solprovider@apache.org wrote:
> > >The important information is:
> > >- name (which must match the directory name)
> > >- (Boolean) allowed in URLs (to distinguish between Modules accessible
> > >by visitors and internal Modules used by other Modules.)
> > >- (optional) TemplateID if inheriting is not from the Template
> > >specified for the Publication.
> > ><module name="live" external="true" template="default">
>
> I think you would also want a "description", which would be needed to
> make the "Choose Modules for Publication" administration screen
> usable.
We are discussing two different things.
"publication.xconf" needs to know what Modules are included in the
Publication, whether to allow visitors to access the Module directly,
and the inheritance to find the files for the Module that are not
overridden by the Publication.
"module.xml" describes the Module similar to how "publication.xml"
describes a Publication. It should contain:
- Human readable name of Module (possibly translated into several languages?)
- Default external status
- A short description of what it does.
- Documentation about how the pipelines are accessed (the public API),
and which files are normally overridden.
- A version number.
- Minimum version of Lenya.
- Minimum version of Cocoon.
- Filenames of any other documentation: changelog, license, readme.
I think all of this should be optional. If a Module does not include
a "module.xml", then the ModuleName is the same as the ModuleID
(directory name), and the other fields are assumed blank. A blank
minimum version assumes any version will work.
Example:
publication.xconf:
<module id="live" external="true">
<parameter name="cache">disabled</parameter>
</module>
modules/live/module.xml:
<lenya:module>
<lenya:name>Live</lenya:name>
<lenya:external>true</lenya:external>
<lenya:module-version>1.0</lenya:pub-version>
<lenya:lenya-version>1.4</lenya:lenya-version>
<lenya:cocoon-version>2.1.6</lenya:cocoon-version>
<lenya:description>Basic visitor access to a Publication</lenya:description>
<lenya:help>The Live Module allows access to Documents with
navigation and formatting . Override "page2xhtml.xsl" and "page.css"
to create a unique look. Pages can be cached on first use with the
parameter "cache" set to "enabled".</lenya:help>
</lenya:module>
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Addressing Modules
Posted by Bob Harner <bo...@gmail.com>.
On 2/23/06, Michael Wechner <mi...@wyona.com> wrote:
> solprovider@apache.org wrote:
>
> >The important information is:
> >- name (which must match the directory name)
> >- (Boolean) allowed in URLs (to distinguish between Modules accessible
> >by visitors and internal Modules used by other Modules.)
> >- (optional) TemplateID if inheriting is not from the Template
> >specified for the Publication.
> ><module name="live" external="true" template="default">
I think you would also want a "description", which would be needed to
make the "Choose Modules for Publication" administration screen
usable.
> >
> >
>
> I have checked something in for the following modules:
>
> jackrabbit/module.xml
> jcrsource/module.xml
> jcr/module.xml
> repository/module.xml
>
> to discuss
>
> Michi
>
> --
> Michael Wechner
> Wyona - Open Source Content Management - Apache Lenya
> http://www.wyona.com http://lenya.apache.org
> michael.wechner@wyona.com michi@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Addressing Modules
Posted by Michael Wechner <mi...@wyona.com>.
solprovider@apache.org wrote:
>The important information is:
>- name (which must match the directory name)
>- (Boolean) allowed in URLs (to distinguish between Modules accessible
>by visitors and internal Modules used by other Modules.)
>- (optional) TemplateID if inheriting is not from the Template
>specified for the Publication.
><module name="live" external="true" template="default">
>
>
I have checked something in for the following modules:
jackrabbit/module.xml
jcrsource/module.xml
jcr/module.xml
repository/module.xml
to discuss
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Addressing Modules
Posted by Michael Wechner <mi...@wyona.com>.
solprovider@apache.org wrote:
>On 2/22/06, Michael Wechner <mi...@wyona.com> wrote:
>
>
>>I think each module should have a descriptor (similar to publication.xml
>>resp. publication.xconf) where the module is being described and also
>>"addressed"
>>with
>>- name (e.g. atom-entry)
>>- namespace (e.g. http://lenya.apache.org/2006/1.0)
>>- version (e.g. 1.0)
>>in order to avoid conflicts.
>>
>>
>
>I have no objections to a descriptor file "module.xml", but will it be
>mandatory?
>
yes, I think it should be required
> The primary use would be to add descriptions for the
>"Choose Modules for Publication" administration screen. It should be
>mandatory for all modules included with Lenya, but any use of it
>should survive the file not existing. I quickly create Modules for
>testing features, and requiring this file would slow development
>without adding any value.
>
>
well, having a readable name/description of the module and the Lenya
version cannot
be that much effort ;-)
Michi
>publication.xconf should have the list of Modules used in this
>Publication. Most standard Modules will not need a directory in the
>Publication unless they are being customized. Almost everybody will
>customize "page2xhtml.xsl" in the "live" Module, but very few will
>customize the "authoring" Module, and it should be able to be included
>or excluded for each Publication.
>
>The important information is:
>- name (which must match the directory name)
>- (Boolean) allowed in URLs (to distinguish between Modules accessible
>by visitors and internal Modules used by other Modules.)
>- (optional) TemplateID if inheriting is not from the Template
>specified for the Publication.
><module name="live" external="true" template="default">
>
>The "external" Boolean flag is "true" for "live", "authoring",
>"search", and other frontend Modules, but should be "false" for
>"breadcrumbs", "menu", "tabs", "lucene" and other backend Modules that
>should not be accessible by visitors. This flag could default to a
>value from "module.xml". (We may need a Publication-level
>"ignoreExternal" Boolean so all Modules are accessible on development
>servers. It is very useful to check the XML output from each Module
>during development.)
>
>If external is "true", then:
> http://server/pub/moduleID
> http://server/pub/...?lenya.usecase=moduleID
> http://server/pub/...?lenya.module=moduleID
>will work. If it is "false", they all return the "Sorry" page.
>
>Your other post was about adding a namespace to "publication.xconf".
>I prefer working without namespaces when possible, but if others think
>it useful, then it should wait until the elements are stable.
>
>solprovider
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Addressing Modules
Posted by so...@apache.org.
On 2/22/06, Michael Wechner <mi...@wyona.com> wrote:
> I think each module should have a descriptor (similar to publication.xml
> resp. publication.xconf) where the module is being described and also
> "addressed"
> with
> - name (e.g. atom-entry)
> - namespace (e.g. http://lenya.apache.org/2006/1.0)
> - version (e.g. 1.0)
> in order to avoid conflicts.
I have no objections to a descriptor file "module.xml", but will it be
mandatory? The primary use would be to add descriptions for the
"Choose Modules for Publication" administration screen. It should be
mandatory for all modules included with Lenya, but any use of it
should survive the file not existing. I quickly create Modules for
testing features, and requiring this file would slow development
without adding any value.
publication.xconf should have the list of Modules used in this
Publication. Most standard Modules will not need a directory in the
Publication unless they are being customized. Almost everybody will
customize "page2xhtml.xsl" in the "live" Module, but very few will
customize the "authoring" Module, and it should be able to be included
or excluded for each Publication.
The important information is:
- name (which must match the directory name)
- (Boolean) allowed in URLs (to distinguish between Modules accessible
by visitors and internal Modules used by other Modules.)
- (optional) TemplateID if inheriting is not from the Template
specified for the Publication.
<module name="live" external="true" template="default">
The "external" Boolean flag is "true" for "live", "authoring",
"search", and other frontend Modules, but should be "false" for
"breadcrumbs", "menu", "tabs", "lucene" and other backend Modules that
should not be accessible by visitors. This flag could default to a
value from "module.xml". (We may need a Publication-level
"ignoreExternal" Boolean so all Modules are accessible on development
servers. It is very useful to check the XML output from each Module
during development.)
If external is "true", then:
http://server/pub/moduleID
http://server/pub/...?lenya.usecase=moduleID
http://server/pub/...?lenya.module=moduleID
will work. If it is "false", they all return the "Sorry" page.
Your other post was about adding a namespace to "publication.xconf".
I prefer working without namespaces when possible, but if others think
it useful, then it should wait until the elements are stable.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org