On 3/14/08, Thorsten Scherler <[EMAIL PROTECTED]> wrote:
> we need to
> look into updating to cocoon 2.2. Further our famous 1.3 branch that
> brings some nice ideas should merge with the 2.0.x branch.
>
> Maybe we can take the chance to merge both branch in an upcoming 3.0.
> Would it make sense to have a clean cut?
>
> I meaning starting first with a requirements/architecture document and
> then develop the code around it (using as much good as we have right
> now). Do you think it would be possible?
> Thorsten Scherler thorsten.at.apache.org
That was how I developed 1.3 -- I started with what I wanted Lenya to
do. The first step was to change Usecases to use the Area part of the
URL as a patch for 1.2. That evolved into 1.3's Module system. Then
the repository became flat, with a migration-from-1.2 module and a new
protocol. The rest is recreating the functions of 1.2 to work with
the new repository using the module system.
Lenya 1.3 is still not functionally complete. I am currently working
on the structure editor ("relate" Module). I hope to finish soon, but
other obligations may delay it for 2 weeks. Security is the next task
-- another couple of weeks. Then the editor needs work. Navigation
between administration screens is missing -- 1.3 does not yet have the
comprehensive environment of 1.2 or 2.x because many of the components
have not been created. The ToDo list and other documentation is in
the "13*.txt" files at:
http://svn.apache.org/viewvc/lenya/branches/revolution/1.3.x/
1.3 is completely backwards-compatible with 1.2. Once 1.3 is usable,
tested, and all major enhancements implemented, 1.3 becomes the
migration path from 1.2. The version after 1.3 should remove 1.2
compatibility (and probably half the code for a very clean system.)
Merging with 2.x would be interesting. Both 1.3 and 2.x add similar
functions with very different implementations. Paraphrasing "What's
New in Lenya 2.0":
- Modularization: Same description, different implementation. 1.3
Modules are very simple and cannot contain Java. The module.xml
contains important information; most other constraints are due to
interaction with other Modules. (The "home" Module inherits the
"xhtml" Module overriding only "page2xhtml.xsl".)
- Improved Repository Access: Allows for new repositories by extending
the Resource Interfaces (Java).
- UNIDs for Resources: Documents are typically assigned UUIDs, but
UNIDs allow named resources -- useful for web-editable design
documents (CSS, XSL, XMAP, etc.)
- Link rewriting is still on the ToDo List.
- Everything is Treated as Resources: No distinctions.
- Improved Access Control - Still on ToDo List.
- Configurable Meta Data - Meta Data (and everything else) is defined
in Resource Modules so anything is possible.
- Module Inheritance rather than Publication Templating: All files are
inherited from multiple parent Modules. Parent Modules may be global
or belong to another Publication. New Modules only need to contain
overwritten files.
- Usecase Framework is replaced by Module system. 1.2's Usecases
still work, but should become Modules.
- No notifications (yet), mail or otherwise.
Other improvements (IMO):
- Areas are gone. Resources save all versions (of a specific
translation) to one directory. The "live" version is controlled by a
setting (in translation.xml). The Area portion of the URL is used for
the Module name.
- Only two protocols are used. The content: protocol retrieves all
Resources. The module: protocol retrieves all functional files.
Other protocols are available, but rarely needed. (see 13HELP.txt)
- Editor is Xinha -- extendible and eliminates temporary files (and
desperately needs extending to work with images and links.)
The ultimate goal is for the lenya directory to contain just /modules
and /pubs, and for
publications to contain:
- publication.xml (1.2's {pub}/config/publication.xconf)
- /modules (only needed for overriding a few files, e.g. page2xhtml,
and adding new functions.)
- /content (1.3's {pub}/content/resources, but could be external)
- /security (1.2's {pub}/ac/passwd, but could be external)
Hopefully this post and the documentation in svn explain 1.3, but
please ask about any concerns.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
