Thorsten Scherler wrote:
Convention over Configuration
-----------------------------
I used to prefer configuration for a long time for reasons of
flexibility, but I kind-of changed my mind. We have to make
flexibility trade-offs to accelerate development. The past showed
that many configuration options are apparently not important
enough to be worth providing.
Actually this and all following points depend on which way lenya is
going. I guess 1.6 would be build on cocoon 2.2, right.
important point.
<snip>
IMO 1.6 should have a clean (cocoon independent!) core which should not
contain a web client.
interesting. i have a totally different view of lenya. for me, lenya
should be almost exclusively glue, the thinner, the better.
existing frontends (editors), existing backend (cocoon), existing
repository (svn, EJB, eXist, rdbms, whatnot).
lenya brings them together under a nice api, and provides our quite good
web gui as the default mode of interaction.
in my dreams, lenya has no significant "features" of its own. it just
passes through the features of those existing components and unifies
their apis.
The web client should be a module and we would
provide a cocoon implementation to show how to connect to the core and
make arbitrary operations.
it looks like we mean basically the same, but i'm surprised about
"cocoon independent". my preference would be to only have a very thin
layer above cocoon, getting rid of a lot of custom stuff and using
cocoon mechanisms wherever possible (caching comes to mind especially).
cocoon is what got me hooked to lenya: powerful xml workflows. i'd hate
to see that put on the back burner. otherwise, i think i agree.
Regarding repository yeah, we need to support different approaches and
show a db backend out of the box.
i'd say we should aim for a nice abstraction, but not necessary
implement too many different backends - leads to maintenance issues.
the sorry state of our editors is a similar symptom. our community is
too small to maintain several backends. we should concentrate on one
core implementation and keep it ship-shape always, and leave custom
backends (and their maintenance) to third parties until we have
conquered a more significant fraction of the world.
*.*
while we're talking grand plans: i would like to see XHTML2 used
exclusively for all of lenya's internal GUI and documents (rendered to
XHTML1 of course), up-to-date, table-free layout and the move to an
XSLT2-capable transformation engine (saxon-8) - which does not mean that
core should rely on xsl2 features too much, only that users can use them.
why xhtml2? you are obliged to separate content and design, you can nest
structures in a sane fashion, it's harder to write ugly stuff in xhtml2.
it's nice to use.
why xsl2? because often the xsl layer is the most convenient way to get
things done quickly for users without having to dig too deep and having
to spread a needed feature over too many places (as happens with java
stuff: data needs to be exported to the sitemap again, which leads to an
inflation of ad-hoc interfaces that add up to a huge legacy). xsl2 means
that users can do very clever stuff in xslts which remain readable and
maintanable thanks to functions and the promotion of variables to
first-class citizens....
*.*
every part of a publication should be stored in a repository and be
editable in a browser (if only with oneform) and hot-deployable, css,
xslts, heck, even sitemaps with a fallback feature to a backup in case
the new version explodes.
not in kansas anymore,
jörn
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
