[EMAIL PROTECTED] schrieb:
[…]
I want the ability to:
- maintain Publications' repositories outside the formal Lenya
directory structure.
- maintain each Publication's repository in its own directory structure.
Would you mind elaborating a bit about the reasons for these
requirements? TIA!
- have multiple Publications use one repository (filtering documents
using Indexes.)
What does "use" mean in this context? IMO referencing documents across
publications (read-only) is an important feature (access control has to
be considered, though). But I'm not sure if we also should allow to
write documents in a different publication. Wouldn't that render the
whole publication concept (in a sense of self-contained content buckets)
obsolete? Which might be worth a thought …
- have multiple repository types: Lenya XML, JCR, traditional
relational database, etc..
We once started with this approach. It had almost destroyed the project,
if we hadn't pulled the handbrake in time. The maintenance costs for one
repository implementation are high, for multiple repository
implementations they are not bearable by a small community like ours.
I still think that we shouldn't maintain a repository at all, but use
JCR instead. Maintaining repositories should be outside the scope of
Lenya. I'd rather like to focus on providing end-user functionality.
When it comes to marketing, you can't score with a repository anymore.
Each CMS is supposed to have a robust, performant, etc. back-end. But
you can dismissed during the early stages of an evaluation if you're not
able to store your content in a JCR repository.
Adding a global data directory (internal or external to the Lenya
build directory) cannot lead to a solution meeting these goals. The
fallback protocols used by Lenya 1.2 and 2.x also cause problems with
distributed content and design
Would you mind elaborating? I didn't notice any problems by now …
[…]
On 6/25/08, Jürgen Ragaller <[EMAIL PROTECTED]> wrote:
What I think is problematic generally are single files that are editable
via the gui (usecase-policies.xml) and need to be edited in the development
process as well - if a new module is added, the changes dev/build have to be
merged.
Jürgen
The prototype allows any and every design file to be overridden by
files in the repository. OTOH, no integrated GUI exists yet (because
the security system will not enter the programming phase until next
week, which is why I am currently very interested in 2.x's
implementation -- what is necessary for compatibility and any
potential code reuse?) Why are
"single files that are editable via the gui (usecase-policies.xml) and
need to be edited in the development process as well"
- Not in Modules?
usecase-policies.xml is publication-specific. It declares roles for
usecases. Roles are defined in the publication, so it's not possible to
put the usecase policies in modules. IMO we should keep this strict
separation - functionality in modules, access control settings in
publications. Otherwise we'd have to ship a standardized set of roles.
- Not changeable for each Publication?
What do you mean? The file is publication-specific …
- Not editable for the development process by editing as content?
That would be an option, but it doesn't solve the problem mentioned by
Jürgen. Some people like to have the files in the SVN repository,
versioned together with the source code, others want to edit them via
the GUI. Should we require people to choose one of these options?
BTW, the Sling project faces a comparable issue, which they consider
quite controversial. The general approach seems to be to put the files
(in their case mostly scripts) in the content repository during
prototyping, and when they become mature, move them to the source code
repository (SVN).
The last point could become a problem. If a Publication overrides a
design file in a Module, then parent Module changes the file, the
Publication will not receive the change. Module developers can keep
often-customized information separate from rarely-customized code
(like navigation menu element creation/selection is away from
presentation.) Nothing distinguishes between static and
expected-to-be-customized elements beyond the Module
description/instructions -- a Publication could override an entire
Module while claiming inheritance. The current solution for changing
customizable elements is to use versions of Modules -- the Publication
needs to upgrade manually to the next version of the Module and verify
any overridden files are still correct. Instructions for upgrading
and a "diff" function showing what changed would help.
There are some concepts in this paragraph that aren't applicable to
2.0.*, so it's a bit difficult to comment on it …
Thanks for sharing your ideas!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
