[EMAIL PROTECTED] schrieb:
On 6/27/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
[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?
Each of our clients receives a ZIP of their material monthly. This
function would be much simpler if the directory structure allowed:
/myclient1/lenya/content
/myclient1/lenya/security
/myclient1/lenya/modules
/myclient1/otherstuff
/myclient2/...
I see, this certainly makes sense.
This may be "my itch"; hopefully others will find it useful. Yes,
softlinks work well on *nix systems, and our production systems are
*nix, but allowing the repository to exist anywhere means allowing the
repository to exist anywhere. The configuration would be one line:
<content type="flat" location="somewhere"/>
How about <data location="somewhere"/> for each publication, maybe with
fallback to a global setting? That would at least reduce the number of
configuration options.
[…]
My definition of a Publication is the intersection of content,
security, and code. […]
Other combinations should allow for any possible business
requirements. Does a reason exist for Publications to NOT become more
flexible?
If we can achieve this flexibility without making the configuration more
difficult, I'm much in favor of it. Actually I think that matters will
become more ovious with a clearer separation of aspects (content,
layout, access control).
Regarding layout, I think we do quite well. IMO the current concept
allows for quite a lot of flexibility:
- layout can be put in modules
- shareable across multiple publications
- customizable using publication templating
Regarding access control, the situation is not so clear. Policies should
IMO be tied to the content. Principals (users, groups) can be shared
across publications, but the GUI is still publication-specific, which is
IMO a legacy that should be overcome.
Regarding content, we still have a clear separation between
publications. IMO a global content store would be an interesting option.
The scenario you described above could be achieved by exporting and
importing the content used by a single publication. But I see some
organizational issues (content ownership etc.) if a content item isn't
assigned to a particular publication, which would have to be discussed.
- 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 watched this process. I think the design methodology caused more
issues than maintaining multiple repositories. Lenya 1.3 abstracted
the Content API and added the content: protocol BEFORE adding a new
repository type; see below.
We also introduced a repository protocol (lenya://) before adding the
repository type. A major problem was that the publication and repository
APIs weren't stable yet, which caused frequent changes to the repository
implementations. On the other hand, it was still possible to influence
the API based on the capabilities of the repository. But in the end it
was just too much work.
[…]
I feel keeping an XML file-based repository is important for two reasons:
1. Troubleshooting - Is a bug in Lenya or in the repository? Having
a Lenya XML file repository eliminates or confirms most of Lenya's
code as the source of the bug; does the bug affect the file-based
repository? If yes, the bug is in Lenya's core. If no, then the bug
is either in the JCR implementation or Lenya's JCR Content package.
Without control of one repository, this is not possible.
IMO it will be possible to locate the causes of bugs when only a single
repository is used. And I think that Lenya's JCR Content package should
be rather minimal, i.e. we should access the repository directly or use
an out-of-the-box object JCR mapping framework.
2. Low entry barrier - Anybody with a text editor can easily learn the
internal representation of Lenya's content.
IMO this shouldn't be necessary. No user should have to bother with the
internal representation of content. If this is not the case, we have to
improve the documentation of our API or make it more self-descriptive.
New potential techs have
few systems easy enough to learn and usually quickly run into a wall.
I learned programming games in BASIC poking bits into video memory;
few systems today allow the same insights into computer internals.
Lenya is completely open and could be a very good tool for new
programmers (except Java's blackboxed memory management -- great for
production systems, still a wall for learning computer internals.)
How many posts to the Lenya User ML are from people not understanding
the Web, HTML, and CSS? We WANT these people as
customers/users/potential developers; they greatly outnumber Java
programmers.
I'm not sure if I understand this correctly - do you mean that Lenya
could be used as a tool to learn about the nature and implementation of,
e.g., content management systems? I have never thought about this
aspect. If we consider this an architectural constraint, it will
certainly influence many aspects of the product. What do the others
think about this?
Lenya 1.3 also allows identifiers to be specified for documents;
"Named Resources" required about two lines of code. UUIDs are the
default, but humans prefer words. Discouraging named resources seems
petty and abusive. The identifiers must still be unique; Lenya 1.3
errors if the requested UNID already exists.
A major problem with named entities is that they are not guaranteed to
be globally unique, which prevents merging of arbitrary repositories. I
don't object to giving entities a name, but then it should also be
possible to change this name, and this would again require link
rewriting if the name is used to reference the entity.
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.
Based on reading the MLs, you (Andreas) are constantly figuring out
how to make the next function work with the current fallback system;
see the second sentence of the original post in this thread. Not
using file-based fallback has simplified many improvements.
Developers do not care whether a file is overridden in the repository,
in a Publication-specific Module, an inherited Module from another
Publication, or a Global Module, they just call the module: protocol
and let Lenya 1.3 decide what file to use.
Unfortunately I can't comment on this since I'm not familiar with the
internals of 1.3. I'm looking forward to an upcoming version - with the
last version I tried, I didn't really know where to start …
[…]
Would you please post a few examples where adding compiled Java via
Modules is useful in 2.x? I want to better understand the benefits.
IMO there are some general benefits:
- maybe most important: separation of API and implementation
- very good IDE support
- unit testing is very simple and offers good IDE integration
- make use of OO concepts like inheritance and encapsulation
Some examples are:
- sitemap components (MetaDataTransformer in the metadata module)
- services (Notifier in the notification module)
- reusable convenience classes (ResourceWrapper in the resource module)
- implementations of core services (sitetree module)
- adapter code for external services (SVNKit in the forrest module)
-- 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]
