You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lenya.apache.org by ts...@apache.org on 2005/03/15 20:50:15 UTC
svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Author: tschlabach
Date: Tue Mar 15 11:50:15 2005
New Revision: 157582
URL: http://svn.apache.org/viewcvs?view=rev&rev=157582
Log:
Moved config/menus/generic.xsp from publication to core lenya/cmsmenus.xsp
Added:
lenya/trunk/src/webapp/lenya/cmsmenus.xsp
Removed:
lenya/trunk/src/webapp/lenya/pubs/default/config/menus/generic.xsp
Modified:
lenya/trunk/src/webapp/lenya/pubs/default/menus.xmap
Added: lenya/trunk/src/webapp/lenya/cmsmenus.xsp
URL: http://svn.apache.org/viewcvs/lenya/trunk/src/webapp/lenya/cmsmenus.xsp?view=auto&rev=157582
==============================================================================
--- lenya/trunk/src/webapp/lenya/cmsmenus.xsp (added)
+++ lenya/trunk/src/webapp/lenya/cmsmenus.xsp Tue Mar 15 11:50:15 2005
@@ -0,0 +1,169 @@
+<?xml version="1.0"?>
+<!--
+ Copyright 1999-2004 The Apache Software Foundation
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- $Id: generic.xsp 155806 2005-03-01 17:55:42Z andreas $ -->
+
+<!--+
+ | This XSP builds that standard CMS menu
+ | It moved here from $PUB_HOME/config/menus/generic.xsp
+ +-->
+
+<xsp:page
+ language="java"
+ xmlns:xsp="http://apache.org/xsp"
+ xmlns:xsp-request="http://apache.org/xsp/request/2.0"
+ xmlns:input="http://apache.org/cocoon/xsp/input/1.0"
+ xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
+ xmlns:wf="http://apache.org/cocoon/lenya/workflow/1.0"
+ xmlns:uc="http://apache.org/cocoon/lenya/usecase/1.0"
+ xmlns="http://apache.org/cocoon/lenya/menubar/1.0"
+>
+
+ <xsp:structure>
+ <xsp:include>org.apache.lenya.cms.publication.Document</xsp:include>
+ <xsp:include>org.apache.lenya.cms.publication.Publication</xsp:include>
+ </xsp:structure>
+
+ <menu>
+
+ <xsp:logic>
+ String documentId = <input:get-attribute module="page-envelope" as="string" name="context-prefix"/> + "/" + <input:get-attribute module="page-envelope" as="string" name="publication-id"/> + "/authoring" + <input:get-attribute module="page-envelope" as="string" name="document-id"/> + "_" + <input:get-attribute module="page-envelope" as="string" name="document-language"/>;
+ String area = <input:get-attribute module="page-envelope" as="string" name="area"/>;
+
+ Object documentObject = <input:get-attribute as="object" module="page-envelope" name="document"/>;
+ Document document = null;
+ if (documentObject != null && !"".equals(documentObject)) {
+ document = (Document) documentObject;
+ }
+
+ boolean isDocument = false;
+ String docType = "";
+ try {
+ if (document != null && document.exists()) {
+ isDocument = true;
+ docType = <input:get-attribute as="string" module="page-envelope" name="document-type"/>;
+ }
+ }
+ catch (Exception e) {
+ throw new ProcessingException(e);
+ }
+ </xsp:logic>
+
+ <menus>
+ <menu i18n:attr="name" name="File">
+ <block>
+ <item uc:usecase="site.create" href="?doctype=xhtml"><i18n:text>XHTML Document</i18n:text></item>
+ <item uc:usecase="site.create" href="?doctype=links"><i18n:text>Links Document</i18n:text></item>
+ </block>
+ <block>
+ <item uc:usecase="site.createLanguage" href="?"><i18n:text>New Language Version</i18n:text></item>
+ <item uc:usecase="site.deleteLanguage" href="?"><i18n:text>Remove Language Version</i18n:text></item>
+ </block>
+ <block>
+ <item uc:usecase="ac.logout" href="?"><i18n:text>Logout</i18n:text></item>
+ </block>
+ </menu>
+
+ <menu i18n:attr="name" name="Edit">
+
+ <block info="false">
+ <item wf:event="edit" uc:usecase="kupu" uc:step="open" href="?"><i18n:text>With Kupu</i18n:text></item>
+ <item wf:event="edit" uc:usecase="bxe" uc:step="open" href="?"><i18n:text>With BXE</i18n:text></item>
+ <item wf:event="edit" uc:usecase="edit" uc:step="open"><xsp:attribute name="href"><xsp:expr>"?form=" + docType</xsp:expr></xsp:attribute><i18n:text>With Forms</i18n:text></item>
+ <item wf:event="edit" uc:usecase="1formedit" uc:step="open" href="?"><i18n:text>With one Form</i18n:text></item>
+ </block>
+
+ <block info="false">
+ <item wf:event="edit" uc:usecase="info-meta" uc:step="showscreen"><xsp:attribute name="href"><xsp-request:get-context-path/>/<input:get-attribute module="page-envelope" as="string" name="publication-id"/>/info-<input:get-attribute module="page-envelope" as="string" name="area"/><input:get-attribute module="page-envelope" as="string" name="document-url"/>?</xsp:attribute><i18n:text>Edit Metadata</i18n:text></item>
+ <item wf:event="edit" uc:usecase="site.changeLabel" href="?"><i18n:text>Edit Navigation Title</i18n:text></item>
+ </block>
+
+ <block authoring="false">
+ <item uc:usecase="site.cut" href="?"><i18n:text>Cut</i18n:text></item>
+ <item uc:usecase="site.copy" href="?"><i18n:text>Copy</i18n:text></item>
+ <item uc:usecase="site.paste" href="?"><i18n:text>Paste</i18n:text></item>
+ </block>
+
+
+ <block authoring="false">
+ <item uc:usecase="site.changeNodeID" href="?"><i18n:text>Rename URL</i18n:text></item>
+ <item uc:usecase="site.changeLabel" href="?"><i18n:text>Edit Navigation Title</i18n:text></item>
+ </block>
+ <block authoring="false">
+ <item uc:usecase="site.nudge" href="?direction=up"><i18n:text>Move Up</i18n:text></item>
+ <item uc:usecase="site.nudge" href="?direction=down"><i18n:text>Move Down</i18n:text></item>
+ </block>
+ <block authoring="false">
+
+ <xsp:logic>
+ {
+
+ if (isDocument &&
+ !"/index".equals(<input:get-attribute module="page-envelope" as="string" name="document-id"/>)) {
+ <item wf:event="delete" uc:usecase="site.delete" href="?"><i18n:text>Delete</i18n:text></item>
+ <item wf:event="archive" uc:usecase="site.archive" href="?"><i18n:text>Archive</i18n:text></item>
+ }
+ else {
+ <item><i18n:text>Delete</i18n:text></item>
+ <item><i18n:text>Archive</i18n:text></item>
+ }
+
+ if (isDocument && (area.equals(Publication.TRASH_AREA) || area.equals(Publication.ARCHIVE_AREA))) {
+ <item wf:event="restore" uc:usecase="restore" uc:step="showscreen" href="?">Restore</item>
+ }
+ else {
+ <item><i18n:text>Restore</i18n:text></item>
+ }
+ }
+ </xsp:logic>
+
+ </block>
+
+ </menu>
+
+ <menu i18n:attr="name" name="Workflow">
+ <block>
+ <item uc:usecase="workflow.submit" wf:event="submit" href="?"><i18n:text>Submit</i18n:text></item>
+ <item uc:usecase="workflow.reject" wf:event="reject" href="?"><i18n:text>Reject</i18n:text></item>
+ <item uc:usecase="workflow.publish" href="?"><i18n:text>Publish</i18n:text></item>
+ <item uc:usecase="workflow.deactivate" href="?"><i18n:text>Deactivate</i18n:text></item>
+ </block>
+ <!--
+ <block>
+ <item uc:usecase="schedule" uc:step="showscreen" href="?"><i18n:text>Schedule</i18n:text></item>
+ </block>
+ -->
+ </menu>
+
+ <menu i18n:attr="name" name="Help">
+ <block>
+ <item href="http://lenya.apache.org/docs/index.html"><i18n:text>Documentation</i18n:text></item>
+ <item href="http://wiki.apache.org/lenya/"><i18n:text>Wiki</i18n:text></item>
+ </block>
+ <block>
+ <item><xsp:attribute name="href"><xsp-request:get-context-path/>/index.html</xsp:attribute><i18n:text>Apache Lenya Homepage</i18n:text></item>
+ <item><xsp:attribute name="href"><xsp-request:get-context-path/>/about.html</xsp:attribute><i18n:text>About Apache Lenya</i18n:text></item>
+ </block>
+
+ <block>
+ <item uc:usecase="view-logs" uc:step="overview" href="?"><i18n:text>View Task Logs</i18n:text></item>
+ </block>
+ </menu>
+ </menus>
+
+ </menu>
+</xsp:page>
Modified: lenya/trunk/src/webapp/lenya/pubs/default/menus.xmap
URL: http://svn.apache.org/viewcvs/lenya/trunk/src/webapp/lenya/pubs/default/menus.xmap?view=diff&r1=157581&r2=157582
==============================================================================
--- lenya/trunk/src/webapp/lenya/pubs/default/menus.xmap (original)
+++ lenya/trunk/src/webapp/lenya/pubs/default/menus.xmap Tue Mar 15 11:50:15 2005
@@ -39,14 +39,16 @@
</map:match>
<!-- document type: links -->
+ <!--
<map:match type="doctype" pattern="links">
<map:generate type="serverpages" src="config/menus/links.xsp"/>
<map:serialize type="xml"/>
</map:match>
+ -->
<!-- all other document types: xhtml, ... -->
<map:match pattern="**">
- <map:generate type="serverpages" src="fallback://config/menus/generic.xsp"/>
+ <map:generate type="serverpages" src="fallback://lenya/cmsmenus.xsp"/>
<map:serialize type="xml"/>
</map:match>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@lenya.apache.org
For additional commands, e-mail: commits-help@lenya.apache.org
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Gregor J. Rothfuss wrote:
>
>> tschlabach@apache.org wrote:
>>
>>> Author: tschlabach
>>> Date: Tue Mar 15 11:50:15 2005
>>> New Revision: 157582
>>>
>>> URL: http://svn.apache.org/viewcvs?view=rev&rev=157582
>>> Log:
>>> Moved config/menus/generic.xsp from publication to core
>>> lenya/cmsmenus.xsp
>>
>>
>>
>> i don't think that is a good idea. the menu is currently
>> default-publication specific..
>
>
>
> agreed. I would suggest that we move that back.
+1
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> tschlabach@apache.org wrote:
>
>> Author: tschlabach
>> Date: Tue Mar 15 11:50:15 2005
>> New Revision: 157582
>>
>> URL: http://svn.apache.org/viewcvs?view=rev&rev=157582
>> Log:
>> Moved config/menus/generic.xsp from publication to core
>> lenya/cmsmenus.xsp
>
>
> i don't think that is a good idea. the menu is currently
> default-publication specific..
agreed. I would suggest that we move that back.
Thanks
Michi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - 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: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Torsten Schlabach wrote:
> Andreas,
>
> > But more general:
> >
> > In my opinion, we should move away from the concept of overriding core
> > components in publications, at least in certain areas. It is very
> difficult
> > to declare contracts this way. IMO we should rather provide simple
> methods
> > to create components using core components. This supports modularity and
> > service-oriented development.
> >
> > To apply this to the menu concept:
> >
> > I don't like the idea of having a core menu. This would mean that the
> > integrator is forced into a certain menu structure. Maybe she doesn't
> want
> > a menu at all? I'd rather have the creation of menus as simple as
> possible
> > (removing logic is one aspect), so that creating a publication menu is a
> > dead-simple task.
>
> Well, I fear that we don't lower the barrier for a new project to use
> Lenya but we make it even harder.
I share these concerns, but I guess I’d prefer a different approach.
IMO simplifying publication development means
- providing clear, unambiguous, well-documented concepts and contracts
- reducing implementation flexibility (only one way to do things)
- providing examples
- providing publication templates to base custom publications on
- providing easy-to-integrate components (plug-ins?) for common tasks
I still hope that we can simplify setting up a publication without
reducing functional flexibility and without narrowing the focus of
Lenya.
From the user's point of view, creating a publication could involve
1. select the basic publication type (choose a template)
2. select additional functionality (select some plug-ins)
(this should be possible later on)
3. configure components (access control, workflow, ...) if necessary
4. start editing & publishing
> I was thiking along the lines of
> separating the editing framework from the content and making the editing
> framework as well as the doctypes more modular, so I could for example
> have XHTML and Blogg components mixed together in one publication.
Yes, but this could be achieved without a pre-defined core menu.
> But in an ISP scenario where we want to convince our customers to use
> Lenya instead of uploading XHTML via FTP, we need the "New Publication
> Task" which will allow people to seed a new website by just giving it a
> name and starting to build a sitetree.
IMO this should be done using publication templating. We could
introduce a function to "materialize" a publication (i.e. disconnect
it from its template), if you want to change the template and be
sure the publication still works.
> Yes, I know, there will be
> websites that don't have a sitetree! But I try to catch the 95%.
>
> What I am heavily against (personally) is to move Lenya in a direction
> where starting a new publicarion (read: website) takes a very skilled
> and trained XSLT / Java / Avalon developer who has a deep knowledge of
> the internals of Lenya.
I agree. That is one reason why publication templating was introduced.
> I understand this is also against the goal on
> the roadmap which is to lower the entry barrier.
>
> It comes down a bit to the question: What should Lenya be and what
> shouldn't it be. If you want to build a website and you don't need 3/4
> of what I think Lenya is all about (acess control, metadata, workflow),
> then why don't you go and use Cocoon directly?
IMO this is not the point. Lenya is open source, you don't pay for
the components you don't use. If you can setup a publication with
just BXE and a publishing usecase, why shouldn't you use Lenya?
IIUC you mean that the integrator shouldn't be forced to bother
about concepts she doesn't need. I completely agree, but that doesn't
mean that we have to reduce the functional flexibility of Lenya.
IMO these are two completely different stories.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Torsten Schlabach <ts...@apache.org>.
Andreas,
> But more general:
>
> In my opinion, we should move away from the concept of overriding core
> components in publications, at least in certain areas. It is very
difficult
> to declare contracts this way. IMO we should rather provide simple
methods
> to create components using core components. This supports modularity and
> service-oriented development.
>
> To apply this to the menu concept:
>
> I don't like the idea of having a core menu. This would mean that the
> integrator is forced into a certain menu structure. Maybe she doesn't
want
> a menu at all? I'd rather have the creation of menus as simple as
possible
> (removing logic is one aspect), so that creating a publication menu is a
> dead-simple task.
Well, I fear that we don't lower the barrier for a new project to use
Lenya but we make it even harder. I was thiking along the lines of
separating the editing framework from the content and making the editing
framework as well as the doctypes more modular, so I could for example
have XHTML and Blogg components mixed together in one publication.
But in an ISP scenario where we want to convince our customers to use
Lenya instead of uploading XHTML via FTP, we need the "New Publication
Task" which will allow people to seed a new website by just giving it a
name and starting to build a sitetree. Yes, I know, there will be
websites that don't have a sitetree! But I try to catch the 95%.
What I am heavily against (personally) is to move Lenya in a direction
where starting a new publicarion (read: website) takes a very skilled
and trained XSLT / Java / Avalon developer who has a deep knowledge of
the internals of Lenya. I understand this is also against the goal on
the roadmap which is to lower the entry barrier.
It comes down a bit to the question: What should Lenya be and what
shouldn't it be. If you want to build a website and you don't need 3/4
of what I think Lenya is all about (acess control, metadata, workflow),
then why don't you go and use Cocoon directly? A lot of what we're
discussing here is readily available in Coocon already anyway, such as
Galleries, Bloggs, etc.
Regards,
Torsten
Andreas Hartmann schrieb:
> Torsten Schlabach wrote:
>
>>> i don't think that is a good idea. the menu is currently
>>> default-publication specific..
>>
>>
>>
>> In what respect?
>>
>> (I was making this move as a preparation to start a "core" menu which
>> will contain the minimum menus that we will always need in any
>> publication. Plugin will be able to add menu options.)
>
>
> What do you mean with "always needed"?
>
> I already developed
>
> - A gallery publication which didn't use any menu items of
> the default publication.
>
> - A course directory publication which didn't use any menu items
> of the default publication.
>
> I don't think there are any menu items which are "always needed" ...
>
>
> But more general:
>
> In my opinion, we should move away from the concept of overriding core
> components in publications, at least in certain areas. It is very difficult
> to declare contracts this way. IMO we should rather provide simple methods
> to create components using core components. This supports modularity and
> service-oriented development.
>
> To apply this to the menu concept:
>
> I don't like the idea of having a core menu. This would mean that the
> integrator is forced into a certain menu structure. Maybe she doesn't want
> a menu at all? I'd rather have the creation of menus as simple as possible
> (removing logic is one aspect), so that creating a publication menu is a
> dead-simple task.
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> 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: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Torsten Schlabach wrote:
> > The "component overriding" is a means of white-box reuse (comparable to
> > OO inheritance). This approach suffers from many drawbacks:
> >
> > - You don't access a component via its interface, but via its
> > implementation. This means you have access to internals. If the
> > original implementation changes, you'll end up with problems.
> >
> > - Collaboration between components isn't clearly visible anymore.
> >
> > In OO development, the "prefer composition to inheritance" principle
> > addresses this issue. IMO it should be applied to non-java
> > components as well.
>
> Valid points.
>
> So are you saying:
>
> - As an immediate solution, beeing possible today, have no menu in the
> core but rather use the Default Publication as a template to new ones.
> - In the medium run: Rethink and define contracts! I think a lot of
> discussions end in that.
Yes, in my opinion that should be the way to go. I agree that
creating a menu is far too difficult at the moment. But I'm
optimistic that we can further simplify it. One aspect is the
move of menu logic to usecase handlers, another aspect is the
introduction of plug-ins and automatic menu composition.
Thanks for bringing all these thoughts up, I hope we find a
reasonable roadmap to implement them :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Torsten Schlabach <ts...@apache.org>.
> The "component overriding" is a means of white-box reuse (comparable to
> OO inheritance). This approach suffers from many drawbacks:
>
> - You don't access a component via its interface, but via its
> implementation. This means you have access to internals. If the
> original implementation changes, you'll end up with problems.
>
> - Collaboration between components isn't clearly visible anymore.
>
> In OO development, the "prefer composition to inheritance" principle
> addresses this issue. IMO it should be applied to non-java
> components as well.
Valid points.
So are you saying:
- As an immediate solution, beeing possible today, have no menu in the
core but rather use the Default Publication as a template to new ones.
- In the medium run: Rethink and define contracts! I think a lot of
discussions end in that.
Torsten
Andreas Hartmann schrieb:
> Torsten Schlabach wrote:
>
>> Just one more thought:
>>
>> > In my opinion, we should move away from the concept of overriding core
>> > components in publications, at least in certain areas. It is very
>> difficult
>> > to declare contracts this way. IMO we should rather provide simple
>> methods
>> > to create components using core components. This supports
>> modularity and
>> > service-oriented development.
>>
>> How does that relate to the concept of "publication templating"? I
>> think publication templating was all about "inherit something useful
>> to start with so you don't have to re-invent the wheel but you can
>> start being productive immediately.
>
>
> Yes, but here you override a component in another publication, not
> in the core. This approach doesn't require to provide pre-defined
> and components (like menus) in the core. This would mean to limit
> flexibility. Providing pre-set components and limiting flexibility
> in a publication is welcome and even desired.
>
> IMO publication templating solves two major purposes:
>
> - Instanciate a couple of identical publications (or similar publications
> with rather small customizations) and be able to update all of them
> at the same time.
>
> - Lower the entry barrier by making it possible to customize a
> publication without modifying the original.
>
>
> The "component overriding" is a means of white-box reuse (comparable to
> OO inheritance). This approach suffers from many drawbacks:
>
> - You don't access a component via its interface, but via its
> implementation. This means you have access to internals. If the
> original implementation changes, you'll end up with problems.
>
> - Collaboration between components isn't clearly visible anymore.
>
> In OO development, the "prefer composition to inheritance" principle
> addresses this issue. IMO it should be applied to non-java
> components as well.
>
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> 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: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Torsten Schlabach wrote:
> Just one more thought:
>
> > In my opinion, we should move away from the concept of overriding core
> > components in publications, at least in certain areas. It is very
> difficult
> > to declare contracts this way. IMO we should rather provide simple
> methods
> > to create components using core components. This supports modularity and
> > service-oriented development.
>
> How does that relate to the concept of "publication templating"? I think
> publication templating was all about "inherit something useful to start
> with so you don't have to re-invent the wheel but you can start being
> productive immediately.
Yes, but here you override a component in another publication, not
in the core. This approach doesn't require to provide pre-defined
and components (like menus) in the core. This would mean to limit
flexibility. Providing pre-set components and limiting flexibility
in a publication is welcome and even desired.
IMO publication templating solves two major purposes:
- Instanciate a couple of identical publications (or similar publications
with rather small customizations) and be able to update all of them
at the same time.
- Lower the entry barrier by making it possible to customize a
publication without modifying the original.
The "component overriding" is a means of white-box reuse (comparable to
OO inheritance). This approach suffers from many drawbacks:
- You don't access a component via its interface, but via its
implementation. This means you have access to internals. If the
original implementation changes, you'll end up with problems.
- Collaboration between components isn't clearly visible anymore.
In OO development, the "prefer composition to inheritance" principle
addresses this issue. IMO it should be applied to non-java
components as well.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Torsten Schlabach <ts...@apache.org>.
Just one more thought:
> In my opinion, we should move away from the concept of overriding core
> components in publications, at least in certain areas. It is very
difficult
> to declare contracts this way. IMO we should rather provide simple
methods
> to create components using core components. This supports modularity and
> service-oriented development.
How does that relate to the concept of "publication templating"? I think
publication templating was all about "inherit something useful to
start with so you don't have to re-invent the wheel but you can start
being productive immediately.
Torsten
Andreas Hartmann schrieb:
> Torsten Schlabach wrote:
>
>>> i don't think that is a good idea. the menu is currently
>>> default-publication specific..
>>
>>
>>
>> In what respect?
>>
>> (I was making this move as a preparation to start a "core" menu which
>> will contain the minimum menus that we will always need in any
>> publication. Plugin will be able to add menu options.)
>
>
> What do you mean with "always needed"?
>
> I already developed
>
> - A gallery publication which didn't use any menu items of
> the default publication.
>
> - A course directory publication which didn't use any menu items
> of the default publication.
>
> I don't think there are any menu items which are "always needed" ...
>
>
> But more general:
>
> In my opinion, we should move away from the concept of overriding core
> components in publications, at least in certain areas. It is very difficult
> to declare contracts this way. IMO we should rather provide simple methods
> to create components using core components. This supports modularity and
> service-oriented development.
>
> To apply this to the menu concept:
>
> I don't like the idea of having a core menu. This would mean that the
> integrator is forced into a certain menu structure. Maybe she doesn't want
> a menu at all? I'd rather have the creation of menus as simple as possible
> (removing logic is one aspect), so that creating a publication menu is a
> dead-simple task.
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> 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: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Torsten Schlabach wrote:
>> i don't think that is a good idea. the menu is currently
>> default-publication specific..
>
>
> In what respect?
>
> (I was making this move as a preparation to start a "core" menu which
> will contain the minimum menus that we will always need in any
> publication. Plugin will be able to add menu options.)
What do you mean with "always needed"?
I already developed
- A gallery publication which didn't use any menu items of
the default publication.
- A course directory publication which didn't use any menu items
of the default publication.
I don't think there are any menu items which are "always needed" ...
But more general:
In my opinion, we should move away from the concept of overriding core
components in publications, at least in certain areas. It is very difficult
to declare contracts this way. IMO we should rather provide simple methods
to create components using core components. This supports modularity and
service-oriented development.
To apply this to the menu concept:
I don't like the idea of having a core menu. This would mean that the
integrator is forced into a certain menu structure. Maybe she doesn't want
a menu at all? I'd rather have the creation of menus as simple as possible
(removing logic is one aspect), so that creating a publication menu is a
dead-simple task.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Gregor J. Rothfuss wrote:
>
>>> (I was making this move as a preparation to start a "core" menu which
>>> will contain the minimum menus that we will always need in any
>>> publication. Plugin will be able to add menu options.)
>>
>>
>>
>> i see. i like that idea. for that to happen, we need to further prune
>> the logic that has crept into the menus
>
>
>
> well, the only menu items which "should" occur all the time might be
>
> Logout
> About Lenya
> Help/Documentation
Not even these. Access control should be optional, the other items too.
> But how do you want to do the overlay?
This is a good point. This will be a really complex operation, I already was
faced with the issue when I thought about menu composition based on used
plug-ins.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Torsten Schlabach <ts...@apache.org>.
> Do we want to do
> plug-in prototyping in 1.4? I guess until we have a decision regarding
> the roadmap / feature freeze, everything can be prototyped in the
> trunk.
I think we should not loose the outside-in perspective. When we will
release 1.4 we need some cool and bold features to make media report
about it. You know that CMS and "CMS" are big in the news these days.
And stuff such as Typo 3 or Magnolia gets much more coverage than Lenya,
at least from what I can see at the news stand in Germany.
Therefore I personally would like to make sure we make sure that Lenya
is a system that will be easy to use for users, not only for the people
who develop(ed) it.
It should indeed be a piece of cake to download and start Lenya, hit the
"create a new website" button, switch on the XHTML doctype and start
editing. Then switch on further editors and doctypes as you start to
understand you need them. Think of the user's learning curve!
Regards,
Torsten
Andreas Hartmann schrieb:
> Torsten Schlabach wrote:
>
>> >> But how do you want to do the overlay?
>>
>> Options
>>
>> a) XSLT
>> b) Java (custom transformer)
>>
>> Let me know what you'd prefer. But a simple XSLT should do in my view.
>> I might be able to prototype this later today.
>
>
> That will definitely be interesting. But I'd prefer to let this
> operate on a publication-specific menu.
>
>> I would try XSLT first. The idea is that if I switch on the "XHTML
>> doctype plugin" in a publication, this plugin will inject its menu
>> options such as "New XHTML document" into the menu tree. If I switch
>> on the "Kupu plugin", a menu option "Edit with Kupu" will show up in
>> the edit menu.
>
>
> Sounds good
>
> But that brings up the 1.4 roadmap discussion again. Do we want to do
> plug-in prototyping in 1.4? I guess until we have a decision regarding
> the roadmap / feature freeze, everything can be prototyped in the trunk.
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> 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: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Torsten Schlabach wrote:
> >> But how do you want to do the overlay?
>
> Options
>
> a) XSLT
> b) Java (custom transformer)
>
> Let me know what you'd prefer. But a simple XSLT should do in my view. I
> might be able to prototype this later today.
That will definitely be interesting. But I'd prefer to let this
operate on a publication-specific menu.
> I would try XSLT first. The idea is that if I switch on the "XHTML
> doctype plugin" in a publication, this plugin will inject its menu
> options such as "New XHTML document" into the menu tree. If I switch on
> the "Kupu plugin", a menu option "Edit with Kupu" will show up in the
> edit menu.
Sounds good
But that brings up the 1.4 roadmap discussion again. Do we want to do
plug-in prototyping in 1.4? I guess until we have a decision regarding
the roadmap / feature freeze, everything can be prototyped in the trunk.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Torsten Schlabach <ts...@apache.org>.
>> But how do you want to do the overlay?
Options
a) XSLT
b) Java (custom transformer)
Let me know what you'd prefer. But a simple XSLT should do in my view. I
might be able to prototype this later today.
I would try XSLT first. The idea is that if I switch on the "XHTML
doctype plugin" in a publication, this plugin will inject its menu
options such as "New XHTML document" into the menu tree. If I switch on
the "Kupu plugin", a menu option "Edit with Kupu" will show up in the
edit menu.
Torsten
Michael Wechner schrieb:
> Gregor J. Rothfuss wrote:
>
>>> (I was making this move as a preparation to start a "core" menu which
>>> will contain the minimum menus that we will always need in any
>>> publication. Plugin will be able to add menu options.)
>>
>>
>>
>> i see. i like that idea. for that to happen, we need to further prune
>> the logic that has crept into the menus
>
>
>
> well, the only menu items which "should" occur all the time might be
>
> Logout
> About Lenya
> Help/Documentation
>
> But how do you want to do the overlay?
>
> Michi
>
>>
>> ---------------------------------------------------------------------
>> 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: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
>> (I was making this move as a preparation to start a "core" menu which
>> will contain the minimum menus that we will always need in any
>> publication. Plugin will be able to add menu options.)
>
>
> i see. i like that idea. for that to happen, we need to further prune
> the logic that has crept into the menus
well, the only menu items which "should" occur all the time might be
Logout
About Lenya
Help/Documentation
But how do you want to do the overlay?
Michi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - 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: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Torsten Schlabach wrote:
>> i don't think that is a good idea. the menu is currently
>> default-publication specific..
>
>
> In what respect?
for one, the xhtml and link doctypes
> (I was making this move as a preparation to start a "core" menu which
> will contain the minimum menus that we will always need in any
> publication. Plugin will be able to add menu options.)
i see. i like that idea. for that to happen, we need to further prune
the logic that has crept into the menus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by Torsten Schlabach <ts...@apache.org>.
> i don't think that is a good idea. the menu is currently
> default-publication specific..
In what respect?
(I was making this move as a preparation to start a "core" menu which
will contain the minimum menus that we will always need in any
publication. Plugin will be able to add menu options.)
Torsten
Gregor J. Rothfuss schrieb:
> tschlabach@apache.org wrote:
>
>> Author: tschlabach
>> Date: Tue Mar 15 11:50:15 2005
>> New Revision: 157582
>>
>> URL: http://svn.apache.org/viewcvs?view=rev&rev=157582
>> Log:
>> Moved config/menus/generic.xsp from publication to core
>> lenya/cmsmenus.xsp
>
>
> i don't think that is a good idea. the menu is currently
> default-publication specific..
>
> ---------------------------------------------------------------------
> 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: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
tschlabach@apache.org wrote:
> Author: tschlabach
> Date: Tue Mar 15 11:50:15 2005
> New Revision: 157582
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=157582
> Log:
> Moved config/menus/generic.xsp from publication to core lenya/cmsmenus.xsp
i don't think that is a good idea. the menu is currently
default-publication specific..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org