On 1/3/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > Joern Nettingsmeier wrote: > > Andreas Hartmann wrote: > >>>as mentioned in another posting, i think the user should not be > >>>required to touch java code in order to use and tune the behaviour > >>> of templates. > >>I have to admit that I disagree. Once we followed this strategy in > >>the Lenya project, and it caused a lot more harm than benefit. > > i would fully share your objections if the feature i'm proposing were a > > central mechanism in the core of lenya. it would of course be bad style > > to implement some parts of the "business logic" with XSLT in an > > otherwise java-based framework. > > but all i'm suggesting is to provide a hook to control the behaviour of > > the ConfigurableInstantiator. in the default case, the configuration > > file boils down to a simple list of files, which is what you originally > > suggested. > I guess I see your point, and my comments where indeed of quite general > nature. But when I see script-like XML, all my alarm bells start ringing :) > At a first glance, the mechanism described in your mail could as well > be implemented using Ant with the XConfToolTask. But, the longer I think > about it, I'm rather concerned about the fact that files are copied and > patched at all. I tried to take care of this in the repo layer re-design, > whereas it's not yet finished. > > <file mode="copy" src="publication.xml"> > > <xsl:template match="lenya:name"> > > <lenya:name><xsl:value-of select="$pub_name"/></lenya:name> > > </xsl:template> > should instead be > publication.setName(...); > publication.setDescription(...); > The same should apply to policies etc. The access controller should be > configurable using the API and create configuration files whenever it > considers this appropriate. If Lenya supports instanciation of > publications during run-time, it should also allow this without copying > and patching any configuration files. > >>Patching config files using XSLTs etc. has some disadvantages which > >>can be tolerated in a limited development environment, but not in an > >> open source project of this scale: > >>- First of all, there's no IDE-based consistency ensurance. Element > >>names might change, configuration options might change. If it's Java, > >> the compiler will complain, and you can apply automatic refactoring. > >> If it's XSLT or something like that, you'll lose control. > > but: this mechanism is only used as a *customization hook*, i.e. the > > developers don't need to worry about it. if it breaks, i get to keep the > > pieces. all you need to make sure is to provide a usable default, and > > that's simple. > > the user OTOH gains a lot of control. > > i think the inheritance behaviour of a template is a property of this > > template and should thus be reflected in one of its configuration files. > > in unix speak, it's *policy* and should not be in the kernel (or the > > business logic in this case) IMHO. the kernel provides *mechanism*. > I prefer thinking in terms of separate modules which communicate through > well-defined interfaces, not configuration files. But maybe I don't > understand you correctly. > > (no matter how this is implemented in detail. the xslt stuff was just > > what came to mind first because it's already there and makes the > > mechanism very flexible and intuitive to use.) > >>- Even the fact that configurations are stored in XML files is an > >>implementation detail. No components should directly manipulate > >>configurations of other components (publication <-> instantiator). > > the instantiation of a publication is by nature a direct manipulation of > > its configuration. > Yes, it is a manipulation of the configuration, but it should happen > only using well-defined interfaces. publication.xconf and publication.xml > are implementation details, although the documentation advises to manipulate > them manually (IMO that's not a favourable situation). > > the current java code does nothing else. > Because the API doesn't offer the corresponding interfaces, due to the > fact that publication templating is quite new and not yet mature. > > i think i > > understand the spirit of your objection, but i think it does not apply > > to the creation of a new publication. in all other cases during > > run-time, i would agree. > >>- XSLTs tend to be easily understandable by the person writing them, > >> and to nobody else :) Java encourages inline documentation using > >>Javadocs, can be refactored to improve readability and > >>maintainability. > > with the lenya tree documentation effort we're thinking of, i'm going to > > demonstrate that the magic <!-- --> tag in xml can be put to other uses > > than containing the apache license :) > > of course, it's not as formalized as javadoc, but it's exactly in the > > place where the user needs it to be. > OK - it looks like other projects leverage the documentation options > of XSLT better than we do :) You're right, my point wasn't valid. > >>- Lenya is a Java-based framework. It is strongly encouraged to be > >>familiar with Java anyway if you want to start serious development of > >> a CMS using Lenya. > > i strongly disagree, and i hope this is not the position of all lenya > > developers. > Actually it certainly is the position of the minority :) > But I'll try to defend it nevertheless ... > > here's why: > > * the stuff i'm proposing is not an arcane customization, but an > > essential feature that's already there, but not quite usable. i'm sure > > every new user wants to create a publication eventually :) > > * there is a difference between *using* lenya and developing on the > > basis of lenya. i want to use lenya, and i want to use a feature that's > > already been advertised. > IMO Lenya is not a product that you just use. It could be someday in > the future, but this is a long way. We carry a quite large burden of > a lack of modularization and well-defined interfaces, lots of scripting > and patching. My major intention is to reduce that to a clean Java API > which can be used to develop applications. > > * extensive hacking of lenya's java core for more or less trivial > > functions is a problem. > It shouldn't be necessary to "hack the core". Publications should IMO be > implemented using the core (repository) API and a set of modules for > specific functionality (particular resource types etc.). > > even if i were a lot more java-capable than i > > am, i would be reluctant to do it, since it is a maintenance burden > > later on. (you might argue there's modularization and all, but still: if > > i saw the need to add or modify java code, i would try to do it in > > cooperation with the lenya devs, make it generally useful and try to get > > it accepted into the tree if at all possible.) > OK - IMO it's just the other way round. If you use Java, you're on > the safe side. Your IDE informs you when something has changed, you > have autocomplete, easy debugging and all fancy bells and whistles. > If you're dealing with XML-based configuration and patching, you're > quite on your own. But, of course, this is just my point of view :)
I think you are discussing the different attitudes between "Lenya as a Platform" and "Lenya as a Base for Development". 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. Some of the core team expects everybody to want to be a developer. As any software gains popularity, the ratio of users-to-developers increases. The popularity of software is based on usability by non-developers. For Lenya to increase in popularity, we must expect users to be productive with as few skills as possible. == Business Logic We (my company) implemented security as XSLT, because it was not "in the platform" (as of Lenya 1.2.2). Yes, I totally agree it was "bad style", but it kept the division between "configuration" and "platform", and that was more important (and much easier) than correcting the platform functionality. == Lenya users: Java vs. config Lenya should be useful without any knowledge of Java. Many of the posters to the User ML barely know HTML, and are learning XSLT specifically to configure Lenya. The attitude that any configuration requires recompiling limits the spread of Lenya. An opposing attitude is all configuration should be available from the GUI to limit the need for file access. Creating new publications from the GUI (rather than copying an existing pub using the OS) is a good step towards this goal. Think like a user. A problem with the XSLT can be fixed in the publication's configuration. A problem in Java is a bug in the Lenya platform to be worked around. == Ant I thought the Ant tasks were being moved to Java to remove a dependency, and reduce the skills required for developing Lenya. As a user, anything hidden behind Ant is part of the platform. == 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. There should be a divide between function and content, but templates' content is the sample documents already created. We may want a "Create Template from Publication": copy the function from a publication and generate the default content. Anything that does not work as expected (e.g. security using old pub's config) should be fixed to work as expected. 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. If implemented well, templates could inherit functionality from other templates. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
