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/...
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"/>
I cannot imagine a reason for discouraging this.
> > - 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.
Lenya 1.2 defaulted to each Publication having separate content,
sharing security (accidental because the default Publication hardcoded
the security folder to itself and the easiest method to create a new
Publication was to copy the default Publication, but often changed to
Publication-specific), some code shared (GUI), and some code separate
(page2xhtml.xsl).
My definition of a Publication is the intersection of content,
security, and code. If two Publications only differ with:
- Content: Same security, same functionality and display, just
different documents -- probably two areas of the same website
maintained separately for better organization and possible future
changes to security.
- Security: Same content and functionality; just different readers and
authors -- the classic public and editable websites.
- Code: Same content and security, just different display useful for
multiple branding of the same information. This is also useful for
ADA (Americans with Disabilities Act) compliance. One aspect of ADA
requires all information to be easily accessible using screen readers
i.e. navigation menus after content, text replacing images, no
structural images or tables. Lenya is quite suitable for this market
since the changes required for ADA can be implemented with alternate
XSLTs. This could be implemented by having an "ADA" Module replace
the "live" Module, but implementation may be easier/cleaner by
creating an alternate "ADA" Publication. This is only possible if
both Publications use the same repository. (The law states all
information must be available to all visitors; having separate
repositories is viewed as allowing potential violations.)
Other combinations should allow for any possible business
requirements. Does a reason exist for Publications to NOT become more
flexible?
> > - 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.
> 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.
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.
2. Low entry barrier - Anybody with a text editor can easily learn the
internal representation of Lenya's content. 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.
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.
> > 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.
The new protocols should also simplify adding repositories like JCR.
Adding JCR repositories to 1.3 should be trivial. (Some of the code
in the content.flat package belongs in the content package, but needed
to be kept away from the content.hierarchical package. The code can
be refactored once the content.hierarchical package disappears.) If
everything uses the content: protocol to access repositories, then the
JCR Content package just needs to implement a few classes. My hope is
adding content.jcr1 and content.jcr2 packages will allow using any JCR
without any additional implementation-specific work by the Lenya
Project.
> > 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.
This may be a philosophical difference. Modules define actions;
actions require Roles so Roles must be defined in the Modules.
Publications define security: people and groups. People and groups
are assigned to the Roles of a Publication -- the list of all Roles
defined by the Modules included in the Publication.
A similar system is already being used for Indexes and Structures.
Some Modules require Indexes. Some Indexes require Structures. The
"edit" Module displays the list of required Structures. Clicking a
Structure opens it for editing with the "relate" Module. A future
enhancement will allow specifying one Structure is an alias for
another. This will allow Publication administrators to decide when
Structures should be identical rather than forcing Module developers
to standardize Structure names This is not yet an issue since the
default Publication only uses one Structure ("live"). Editing uses
the special "ALL" Index which does not use a Structure (and ignores
whether Translations exist for the current language.)
I am defining an "admin" Role to override all security; this is formal
recognition that someone with access to the file system cannot be
prevented from changing everything. All other Roles will derive from
the Modules. My expectation is that many of these Roles will be
assigned to very few Groups, then people are added to those Groups.
I do not know how or why 2.x distinguishes between Modules and
Usecases. 1.3's Modules are a mature version of 1.2's Usecases:
standard directory, better URL syntax, and the module: protocol to
handle finding files through inheritance and document overrides. I
know 2.x's Modules allow compiled Java classes.
I believe needing to write Java should be viewed as a hole in the
platform. Many uses of XSP and Javascript (JS) Flow can be eliminated
by using Lenya 1.3's new XMAP components. The migration Module
contains much JS and could now probably be rewritten without any JS,
but rewriting it is pointless since the Module will disappear quickly.
"post.xsp" was created before I learned about the RequestGenerator.
Modules using post.xsp should be rewritten, but improving working code
can wait until the platform is completed.
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.
> > - Not changeable for each Publication?
> What do you mean? The file is publication-specific.
Sorry. My mistake.
> > - 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?
In Lenya 1.3, once a file is edited with the GUI (which is not yet
possible since the text-editing Modules are incomplete), the file in
the repository will override the file in the file system for any
Module inheriting from the Publication Module that was edited with the
GUI. Global Modules cannot be changed by the GUI since the GUI-edited
file must be saved to a Publication's repository i.e. the file becomes
Publication-specific upon saving. I am uncertain this matters to
Lenya; see below.
> 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).
> ...
> -- Andreas
That sounds reasonable. With multiple inheritance and any Module
storing versions in the repository, a "create complete Module"
function pulling all the current files used by a Module could be very
useful. The "Module Designer" will display the current location of
each file. Developers can save Design Resources to the current
Publication or a parent Publication (if they have write access to the
parent Publications.)
The Lenya project mostly avoids this issue by including the "default"
Publication. The default Publication is both a repository and in SVN.
A Design Resource could belong to the "default" Publication and be
developed with versions in the repository. At some point, the code is
declared complete and copied to a Global Module. (The Module version
system will need improvement to support this. The hooks for this
functionality are included, but having only one version of each Module
for the first release allowed me to skip writing the code.)
solprovider
