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. > 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. , 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. 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? >> 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. > 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. >> 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. [...] > 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. > not in kansas anymore Well, hopefully we're not too far from it :) -- Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
