On 1/4/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > Maybe there are users who want to use it > "out of the box" without customization, but I doubt that Lenya is the > right tool for this job (except you're so lucky that the default publication > is just what you were looking for). > > Most users treat it as a Platform. Just configure and use (and many > > will skip step #1.) If there is a bug, complain and hope it is fixed > > in the next release. > > Users who change the Java become developers. > I don't think so. I'd rather compare Lenya to Cocoon - if you're implementing > a generator or a transformer, you're still a Cocoon user. The same should > apply to Lenya. Implementing an instantiator is just using the framework.
(Writing from extremely limited knowledge about Cocoon) Cocoon is a development tool. Does it include any applications that might be useful "out of the box"? Lenya is a CMS. The default publication includes enough to be useful "out of the box". From the comments on the User ML, it seems many people use it with cosmetic changes, and some do not even change the look. I thought our goal was to make the default publication so good that everybody will be "so lucky that the default publication is just what [they] were looking for". > OK, but I, personally, would rather limit the range of application > to heavily customized enterprise level CMS than make any compromises > regarding the above quality aspects. But I still think that both > ways are possible. The Lenya core should provide a solid repository > implementation, funcionality should be added using configurable > modules. At the moment we don't have these modules, so implementing > functionality using Java is necessary. (Writing as someone with much experience in enterprise software) Large companies are using Lotus Notes/Domino (over a decade of proven usefulness for content management with versioning and many features other software can only dream about) or Oracle (because they have great salespeople). Some companies are trying to build CMS using Microsoft software (because they do not know better.) Add Documentum and other smaller players, and the few enterprises using Lenya are those committed to OSS. I expect Lenya to be used by small businesses looking for an inexpensive solution. That is how I sold it. We quickly changed the look. Then I worked around the broken security (in 1.2.2), fixed Search, and added Register/Login, Contact Us, Sitemap, and Newsletter functionality. The only thing that took more than a day was the Newsletter, because it required complex programming, and I used Flow so it could be integrated easily. (I had trouble because I never figured out how to use Flow to modify the XML being passed back to the XMAP.) I was able to meet our requirements without changing the core. I do not understand how adding configuration options reduces quality. I usually add configuration options so the code can be cleaner, and meeting customer's always-changing requirements does not require touching the code. (If you don't touch it, you won't break it.) > > A problem in Java is a bug in the Lenya > > platform to be worked around. > Why that? If it's a core XSLT, the problem has to be fixed in the > core. You can override the XSLT in your publication, but you should > be able to override the Java component as well. I have much experience working around bugs in proprietary software. I love that I can override anything in Lenya, but I still treat the core as untouchable to reduce maintenance headaches. (That will change if my login starts working so I can help with the JCR migration.) Many times I read the code so I knew exactly what was happening, then created a workaround at the configuration level. (A Cocoon bug/design flaw was very annoying.) > > == ConfigurableInstantiator > > I have not read the code yet, but no list of files should be needed. > > The copy (new pub) should contain the entire "template". "Templates" > > should mostly use fallback to functionality in global elements (or > > other templates), so there is little custom code in new publications. > > If someone has 99 pubs based on a template, a change (such as a bug > > fix) to a function should change all the pubs based on that template. > I agree. Publications should use functionality provided by modules. > Upon instantiation, a custom configuration of the functionality could > be generated which applies to the new publication. > > A different approach is for Fallback to check the current pub, then > > the templates, then global. Creating a new pub would be recording the > > name of the desired template (and other base information such as the > > Publication Name), and creating a new datastore for content. Until > > functionality is added to the publication, it defaults to the > > template's functionality. > This is how it's done now. But this concept should rather apply to > presentation options like XSLTs and CSS. I think fallback becomes quite > complex for functionality like usecases etc. Here I could imagine > configuration options or polymorphism towards the module providing the > functionality. Imagine creating a new Publication by checking a list of functionality, choosing a layout, and attaching a few graphics (e.g. corporate logo), all handled using the GUI. That requires a good list of included modules. Is that a good ultimate long range goal for Lenya? Editing XSLT and CSS using the GUI is not difficult. That will probably be finished soon after creating new doctypes becomes easy. Which will happen shortly after creating modules becomes easy. Which should happen about the time 1.4 is released. It will be good when a module uses the publication's files if they exist, then the template's files, then the parent template's files, continuing until it must use the global files. That could become a maintenance nightmare, but adding the ability to gather all the files used for the current functionality into a new template will solve that. That would remove the ability to apply bug fixes at the various levels, but most likely it would be used to locate the bug, then applied to the correct file in the hierarchy. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
