On 6/25/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > at the moment, it's pretty much up to the user to configure the location of > the publication data (content, search index, access control data, ...). This > works well for directly referenced data, but causes problems with > fallback-endabled resources, like usecase-policies.xml. Apart from that, the > configuration options are scattered across several files. > > Following the convention-over-configuration principle, I could imagine that > it would be useful to have a fallback-endabled data directory with a > configurable location. > One option is to configure this globally for all publications, e.g. in > local.build.properties: > data.dir=/home/john/lenya/data > > The directory structure could look like this: > $DATA_DIR > /pub1 > /content > /access-control > /passwd > /policies > /usecase-policies.xml > /search-index > /... > /pub2 > /... > Resources in the data directory could be addressed using the fallback > protocols, e.g.: > aggregate-fallback://data/access-control/usecase-policies.xml > > I'm not quite sure yet if this makes sense and if it could be implemented > without complications. WDYT about the general idea? > -- Andreas
I want the ability to: - maintain Publications' repositories outside the formal Lenya directory structure. - maintain each Publication's repository in its own directory structure. - have multiple Publications use one repository (filtering documents using Indexes.) - have multiple repository types: Lenya XML, JCR, traditional relational database, etc.. 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 (and were replaced long ago in my prototype.) One idea for the Publication directory structure is: /pubs/mypub.xml /pubs/... where each XML file defines the content, security, and code (location of Publication-specific Modules) for one Publication. In my current implementation (not yet available in SVN), the XML content directory structure is: /design (Overridden files for Modules) /resource (Content files) If anybody was familiar with the old directories: /index - Index configuration is now in Modules. Indexes are now temporary files. /relation - The Structure (or Relation) documents are special Design documents created because an Index requests a Structure. 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? - Not changeable for each Publication? - Not editable for the development process by editing as content? 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. Just my thoughts, solprovider
