On Mon, 2007-04-30 at 10:13 +0200, Andreas Hartmann wrote: > Jörn Nettingsmeier schrieb: > > Thorsten Scherler wrote: > >>> Convention over Configuration > >>> ----------------------------- > >>> I used to prefer configuration for a long time for reasons of > >>> flexibility, but I kind-of changed my mind. We have to make > >>> flexibility trade-offs to accelerate development. The past showed > >>> that many configuration options are apparently not important > >>> enough to be worth providing. > >> > >> > >> Actually this and all following points depend on which way lenya is > >> going. I guess 1.6 would be build on cocoon 2.2, right. > > > > important point. > > > > <snip> > >> IMO 1.6 should have a clean (cocoon independent!) core which should not > >> contain a web client. > > > > interesting. i have a totally different view of lenya. for me, lenya > > should be almost exclusively glue, the thinner, the better. > > I agree, and IMO this doesn't contradict Thorsten's view.
Exactly, lenya should provide thin glue. The more re-usable the better. > > existing frontends (editors), existing backend (cocoon) > > In the sense of multi-tier applications, Cocoon is not a back-end > but rather a framework for building the view and controller layers > of web applications. Where Lenya as well should provide a tier dedicated for controlling content. This tier (if having a clear interface) can be 100% java. We will provide the glue (cocoon specific components to call our default java implementations) so Lenya is seamless usable in cocoon but as well in any other java based environment (e.g. junit). > > , existing > > repository (svn, EJB, eXist, rdbms, whatnot). > > lenya brings them together under a nice api, and provides our quite good > > web gui as the default mode of interaction. > > in my dreams, lenya has no significant "features" of its own. it just > > passes through the features of those existing components and unifies > > their apis. > > Exactly - with any other approach, we'd die from exhaustion. > This shouldn't be a dream, but one of our most fundamental principles. > Unless the project is backed up by a strong base of professional > developers, we have to take advantage of the work of others. Yeah, that is the point. It should not matter that the content is stored in a DB, file system or whatever, the way we call it should be the same for all java based apps. If we can get some steam and make the core components independent from cocoon we may interest the ruby-on-rails community. We need every help we can get! > > Take the repository layer: > AFAIK the JCR spec and reference implementation (now known as > Jackrabbit) cost Day 30 man-years. Not to mention the man-millenia > spent on RDBMS and ORM technologies. How could we possibly > build something similarly powerful? Yeah, we need a layer to call it the same way. We have down the first steps introducing protocols to call the content now we need to make them re-usable for in a java environment where lenya is just a "jar" providing the cms functionality. > > > > >> The web client should be a module and we would > >> provide a cocoon implementation to show how to connect to the core and > >> make arbitrary operations. > > > > it looks like we mean basically the same, but i'm surprised about > > "cocoon independent". my preference would be to only have a very thin > > layer above cocoon, getting rid of a lot of custom stuff and using > > cocoon mechanisms wherever possible (caching comes to mind especially). > > Well, I'd suggest to use Cocoon caching only in the view layer. > IIUC it is not designed for repository-layer caching. That is the point cocoon is beautiful for views but that's it. Why stress using it for more then views and presentational logic? All our implementations should be testable with junit, meaning a custom java implementation and not depend on cocoon. > > > > cocoon is what got me hooked to lenya: powerful xml workflows. i'd hate > > to see that put on the back burner. otherwise, i think i agree. > > Yes, but this is again a view layer aspect. Exactly, I do not negate cocoon as view layer but logic should be 100% java (testable with junit). > > > >> Regarding repository yeah, we need to support different approaches and > >> show a db backend out of the box. > > > > i'd say we should aim for a nice abstraction, but not necessary > > implement too many different backends - leads to maintenance issues. > > Yes, I agree - one repository is sufficient. Adding a different > repository is something for a six- or seven-figure project. And if > this amount of money is spent, they just pick the things from Lenya > they like and throw away the rest. > Very simple approach is having a DAO way of calling objects. The mapping can be everything and the interface always the same. The implementations are just providing a way to connect a concrete backend (being EJB, DB, whats however). > [...] > > > every part of a publication should be stored in a repository and be > > editable in a browser (if only with oneform) and hot-deployable, css, > > xslts, heck, even sitemaps with a fallback feature to a backup in case > > the new version explodes. > > Big +1. I had a quick look (for now) in Daisy and was impressed about the editor and rep. You can use it to aggregate content (in the editor!) based on a sql like way of selecting content. Impressive, IMO we can learn from it. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
