Andreas Hartmann wrote:
If the reason for the configuration options is that the API required
for implementation is too complex and too hard to understand, than
I'd prefer to simplify and clean up the API.
agreed.
do you think it could ultimately be made so friendly that i can just
look at one .java file without actual java or api knowledge, discover
patterns in it recognize stuff i know from elsewhere (like object
properties having the same name as xml elements in config files etc.)
and make useful (if simple) modifications at once?
xml/xsl files and scripts are like this. if the java api can be like
this too, i'll be fine. (that is, if i can find the actual code file
behind ten thousand layers of indirection ;).
<snip>
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?
Do you mean the fact that the publication's name and description are set?
IMO this is generic enough to implement it as the default behaviour.
nothing is ever "generic enough". if a default behaviour can't be
overridden, it's a bug. ("bug" being anything that requires touching
java, as per solprovider's very useful definition.)
If you want to change it - why not override the Java class? That's
done in a few minutes, if the base class is designed for inheritance
(small methods, template methods etc.)
it's good to know that this is so easy. but in my world, you don't write
custom code. you provide patches/enhancements that are so well designed
and generic that the developers will want to include it into their tree.
this leads to lean and mean code and a user community that actually uses
the same stuff. custom setups are a maintenance nightmare, no matter how
shiny your IDE is - they will fragment your user community, make support
very hard, make bug reports very spurious and hard to reproduce.
just look at the samba-user list for a good example. no two people have
the same setup (albeit for different reasons), and more than half of the
posts go unanswered. the bugzilla is a bloody fscking mess, each bug
requires three questions from a developer to determine whether it is
even a genuine samba bug.
plus: customization via config files is always done "as intended". if i
touch java, i will have to become familiar with lenya's java slang
first, otherwise i'm likely to produce a kludgy, un-idiomatic solution.
so ++votes for clean access to publication properties via the java api
exclusively, but please please give me a config file to control it.
I'm still not quite sure - what would the config file contain?
see my initial post, ignore my syntax knockup.
and the best part is: we can ship a default instantiation.xconf that 99
out of 100 would never ever want to change :)
but they can read it and understand at a glance how instantiation works
and what possibilites for customization it has.
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 ;)
Like so often, it's about people and not about the code :)
but users will take my path by default. the first thing you see is the
gui, then you read sitemaps, then you change xslts, then you change
sitemaps. this comes natural.
otoh, trying to grok and hack on the java code means crossing a huge and
frightening barrier.
<snip>
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.
Hmmm, I don't share this opinion. We followed this strategy for a long
time, and it caused a lot of problems.
can you point me to mailing list threads where i can learn more about
these problems?
<snip>
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.
What if I implement a Publication class which stores the configuration
options (proxies, languages) in a JCR repository, so that they can be
backed-up and recovered together with the content? If other components
rely on the config file, you'll end up with trouble.
That was just an example. Components must communicate through interfaces,
everything else has no future :)
i need to get used to that java spirit, but my stomach lining tells me
to watch out. when i started with computers, "everything was a file".
looks like we have different opinions on this topic.
a little later in your post you talk about GUI customization, and how
that could never be achieved by "generic" java and config files.
agreed. only a card-punching troglodyte would consider that. for GUIs,
OO design is certainly The Way(tm), and this has to happen inside java
code.
but for other things, it's often overkill and adds complexity imho.
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.
Again, your thoughts are really appreciated :)
I hope I don't scare you away, my intention is just to learn from earlier
mistakes and share my experience.
i'm not easily scared. ;)
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
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]
