You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/03/16 09:35:52 UTC
Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp
pubs/default/config/menus/generic.xsp pubs/default/menus.xmap
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>.
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