Thorsten Scherler wrote: > On Fri, 2008-01-11 at 17:34 +0100, Jörn Nettingsmeier wrote: > ... >> but a lesson could be learnt from this nonetheless: we should try to tie >> into apache (and other projects we re-use) more than we currently do, > > Can you define tie in?
well, show up at apachecons and cocoon gts, be more visible, join other asf projects like most of us do with cocoon (i really need to get on jetty-dev, for example). > See the Jboss workflow engine that is getting used in e.g. Daisy and > Alfresco and compare it with ours. Much more powerful, tools > support, ... Our own JCR implementation is just another bullet point in > a big list. > > ...and yes we need jcr, now! A CMS without JCR support is doomed. hmmm. i don't buy this. i agree that a cms that tries to maintain its own repo system is likely doomed, yes. but it's not like there aren't any alternatives to JCR. i'd like to discuss this further, learn about the pros and cons of JCR vs. an RDBMS vs. SVN vs. eXist vs. younameit and then arrive at a decision and maybe a repo abstraction that makes switching repo engines really easy (which might mean to leave some of the cleverness in lenya and not use mechanisms that might be available on one backend but not on another). > ...but what do you mean with: expose and handle more stuff through > sitemaps and pipelines than it currently does. can you give an example? when i started with lenya, i was quite frustrated how things that should be really easy (like asking "who published this document last and what is their email address?") were all but impossible in lenya or required passing way too many paramters between sitemaps, components and xslts. with 2.0, most of the clever things i want to do are quite easy. but that is not because of particularly brilliant design. it's because andreas has tirelessly answered every tantrum i threw on the list with yet another input module :) it would be great if users could peak at lenya-internal information in way that devs haven't anticipated and provided a hook for. when a new user starts doing clever things with lenya, the first thing s/he sees is sitemaps and xslts. this should be our primary api for getting at data. i don't like how we are using a gazillion input modules and passing way too many params to our xslts. i'd prefer to get at lenya-internal data in big xml chunks which i then aggregate with the content and match in xslts. for instance, i'd like to be able to say "give me this file's revision history for the last n revs" and "give me a map of user ids vs. their emails", and then i can implement the "last edited by user <[EMAIL PROTECTED]>" stuff in my xsl, where it's easy to see and understand. same for usecases: i think it might make things easier if some of the more trivial logic (and most of our usecase logic is trivial) was visible in xslts. before anyone cries wolf: i'm talking about read-only access at this point, so there will be no locking issues between the java api and the xml side. i must confess that when i ripped out the broken naive caching we had in the default pub, i had mixed emotions - it clearly could not work, but it was nice to have such a rather advanced mechanism happen in a sitemap, using core cocoon components mostly. if we somehow exported an xml view of our repository, i'm sure many users could think of very clever things to do with their content and metadata. there are coupling issues to think of, and performance, and it might require a lot of thinking, and the whole idea might turn out to be crap. but i'd like to re-iterate: the reason i like lenya is the sitemap/xslt side, not its java api. it's waaaay too crufty in many areas, and avalon is very limiting nowadays (think of how it prohibits effective server-side state in cocoon flow, requiring such abysmal constructs like a UsecaseProxy...) > Yes, we need all the help we can, but slimming down our core and > outsource components as dependencies such as JCR and workflow and ... > will reduce the workload. agreed. as to workflow, is there a good third-party implementation that a) allows meaning to be attached to states and transitions and b) can provide perfectly understandable error messages for every illegal state transition? if it can't do that, it's just a dumb state machine that can easily be implemented in a few lines of code (like the one we have now). if there is, we should take a look at it. -- Jörn Nettingsmeier "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
