On 1/4/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > No, but IMO Lenya doesn't include [applications that might be > useful "out of the box"] either. Like Cocoon, it provides > samples what the included components are capable of. But we make the > mistake of announcing the samples as complete applications. > > 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. > That's why I dislike the default publication. It gives the impression > that it provides everything Lenya is capable of.
(Partially agreeing with you) When I started with Lenya, I was surprised that "blog" was a separate publication. Why couldn't we have a website/publication that includes company-controlled documents, blogs, and blogs on the company-controlled documents? We could if I did much work, but this functionality felt like it should have been included, and I felt cheated that the pieces were there, but not usable. With doctype modules, I expect publications to have choices of "document", "document with authenticated visitor comments", "document with anonymous visitor comments", "personal blog" (page for one user), "personal blog with visitor comments", and whatever other variations people can imagine. OTOH, Lenya provided enough (online editing of website content) that I was willing to fill the few holes. > > 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". > IMO this is the wrong way. The example publications should be moved > from the webapp directory to a top-level directory (like modules) to > emphasize their purpose as basic examples. In the end, modules could > ship with sample publications presenting their functionality. (Disagreeing with you) I hope people start using Lenya because it does most of what they want. The list of modules is in their face, so they know Lenya can do much. Then they realize it can be easily extended to do that other thing they were dreaming about. I learned Lenya because I had an immediate need that it mostly solved out of the box. - I know how to use Cocoon within Lenya. I have no idea how to use Cocoon by itself; there is no starting point that captures my interest. - I just learned Jackrabbit. It caught my attention because it is becoming part of Lenya. It is not useful out of the box. It only became an obsession because it is the platform for which I have been waiting 6 years to use as a base for a personal project. I do not expect any non-developer to have the slightest interest in Jackrabbit. I recently had the experience of introducing someone to computers that did not know how to play Solitaire (Klondike). To most people, a computer is immediately useful as a game machine because they already know how to play Solitaire using cards. To this person, the computer was not as useful (or fun) because they did not know the "basics". If someone finds Lenya, and it solves an immediate need, then we have a new customer. If they have to struggle before it becomes useful, they will not bother. > [Having many configuration options] does not necessarily reduce quality, > but I have the impression that > it suggests people that configuration is the only option for > customization. Give them all the options they can stand. If they really need more, they may figure it out. Or they will complain to the User ML, and we will have the opportunity to tell them that Lenya is extensible. Most people do not dream; if a function is not provided, they will assume it cannot exist. Not providing configuration options means losing the customer before they are invested in Lenya. > Tasks in Lenya 1.2 are such an example - you can > configure them in tasks.xconf and in targets.xml, but you reach the > limits quite soon. You need a separate copy of targets.xml for each > publication, which is terrible. Agreed. So use fallback. If the target is not in the current publication's files, Lenya checks the template, and so on until global. A publication only needs to define tasks specific to the publication, and they should be moved to a template ASAP. (I expect all functionality to be in modules called by templates called by publications.) > > 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? > It would be absolutely great to have something like that. But: > - With respect to the limited size of our community, it is IMO quite far > away. > - Lenya shouldn't be limited to that. It must provide an API to implement > custom functionality. I did say "ultimate long range". I do not expect it soon. The module API must be stable so we do not lose all the modules from previous releases. (Today I listened to complaints from a customer who recently upgraded Firefox and needed to reinstall most of the extensions, but some of the extensions were not available for the new release yet.) I did not say "The GUI will be the only method of adding functionality to a Publication." A good API for custom functionality is the only path to getting enough modules to make the GUI configuration viable. Besides, good design is better programming. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
