Re: svn commit: r157582 - in lenya/trunk/src/webapp/lenya: cmsmenus.xsp pubs/default/config/menus/generic.xsp pubs/default/menus.xmap

[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