Andreas Hartmann wrote:
> Joern Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>
>>
<snip>
>> 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 :)
and for a reason. the thing is: i tried to be constructive, i can't find
my way around the java code (yet), so i cobbled together something from
the stuff i'm good at. i could not care less if there's xsl in the
config file, but i do want all this to be configurable without having to
touch java.
my idea was that the xsl file would be parsed by the instantiator
anyway, not just by an external xalan process - i was not suggesting to
circumvent the java "business logic" at all. ultimate control of what
happens to the new publication should remain with the instantiator.
> 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.
>
> IMO
>
>> <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(...);
that is convincing.
but it should be configurable in an xml file, not hardcoded in java.
do you agree?
so ++votes for clean access to publication properties via the java api
exclusively, but please please give me a config file to control it.
> 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.
agreed.
i guess the main difference is that, being new to lenya and java
servlets, i'm working from the configuration files downwards, and you
start from your java IDE upwards, so naturally our opinions about what
is easiest and most elegant would differ ;)
>> 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.
imho the servlet should provide all necessary functions (the
"mechanism"), but it should not second-guess the user's needs and
implement one particular behaviour ("policy").
the instantiator needs to be so general that most lenya users never need
to touch it. all its power must be accessible through the config file.
and to become really usable, instantiation needs those features i
described in my initial post, namely a detailed description of which
properties should be copied from the template and which ones referenced,
and if copied, which alterations must be made.
<snip>
>> 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).
why not? they document themselves, it is evident what they do, i can
modify them by just looking at them and grokking the general idea.
>> 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.
do you and the other developers consider this very important for the 1.4
release, or are there more pressing issues atm? if somebody could direct
some of their time towards polishing this, i'll gladly offer my help and
smart-ass remarks, but i can't pull it off myself.
>>> - 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.
understandable.
but all the basic gui stuff is there, lenya is very usable already. i
just don't see why common tasks should require custom java code by design.
since it seems that gui programming is the hardest, may i suggest the
following priority:
* get the java core api completed and polished
* make all the implemented features accessible through config files
* eventually extend the gui to allow access to those new features, if
feasible
for me the third point is not really important. i need the gui for my
users, who have to work on the *content*. i'm content with tweaking
config files.
>> * 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 :)
different worlds. i do unix administration, you do java development. me
tarzan, you jane. or maybe the other way round. :-D
still, users should feel comfortable with lenya even if they don't boot
their machine directly into eclipse ;)
i'll shut up now and look forward to your comments.
jörn
--
"Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga."
"Without new works, without the present the past will cease to be of
interest."
- Ásmundur Sveinsson (1893-1982)
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
