On 3/18/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> There's one critical issue in 2.0 which bothers me: The size of
> continuations. In the docu publication, an instance of the sitetree
> occupies about 10 MB of heap space. Since it is duplicated as soon as it
> is requested by a modifiable session (i.e., in a usecase which is about
> to be executed), the continuations grow very large. When you click
> "Publish" for 20 documents in a row in the MultiWorkflow usecase, quite
> a lot of RAM is allocated.
>
> There are multiple ways to approach this problem:
> 1. Break the sitetree up in local collections/indexes (I think this is
> what solprovider implemented in 1.3, and I like the idea a lot).
> 2. Don't duplicate the whole sitetree, but only the affected fragments,
> and merge them back into the tree when the session is committed (nice
> idea, but probably very complicated when it comes to implementation).
> 3. Get rid of the live sitetree, move sitetree features to meta data.
>
> In case 3, the sitetree would only be a skeleton to declare the
> parent-child relations of documents. The navigation title and visibility
> would be stored in the document's meta data. This way, publishing and
> deactivating wouldn't affect the sitetree at all. The sitetree would
> only have to be checked out during operations which directly manipulate
> the document hierarchy: Adding/deleting documents and cut/copy/paste.
>
> Another positive side effect would be that there can't be any
> checked-out live sitetrees anymore (see bug 44563, thanks to Richard for
> the check-in workaround).
>
> Additionally, it would be possible to change the document hierarchy
> (cut/copy/paste, move up, move down) without deactivating the
> corresponding documents. Of course, the changes would be live
> immediately, but maybe the users could live with that. Deactivating a
> document before moving it around in the sitetree also affects the public
> site.
>
> I hope we can collect some fresh ideas to improve the site structure
> implementation.
>
> solprovider, I would be very interested in a short overview on your site
> structure / index ideas. Sorry if you have already posted this - if you
> remember the title, would you mind giving a pointer to the archive?
> Thanks a lot in advance!
> -- Andreas
Thanks for making obvious that no documentation exists about how
Lenya-1.3's navigation system works. OTOH, I am currently working on
the Structure editor and will be changing the location of the
configuration files so any existing documentation would become
obsolete in the next few weeks.
Lenya-1.3 has several paradigm changes that are difficult to describe
in Lenya1.2/2.x terms. I just finished programming the interface for
the relations editor for Structures. The editor is completely DHTML.
Current actions are "Add Resource", "Move Resource and all
descendants", and "Remove Resource and all descendants". "Copy
Resource and all descendants" is easy to program, but I did not create
an easy interface distinguishing between move and copy actions.
Making everything extremely easy is one of my priorities.
The data sent to the browser includes the UNID, ID, and Type of each
Resource, the language of each Translation, and the Title of "live"
Translations. The browser submits a String of UNIDs with <> characters
marking parent-child relationships.
- Concerns about continuations are eliminated as no continuations are used.
- Concerns about Publishing are eliminated. Publishing is handled by
setting the Revision ID in the Translation.
Lenya-1.3 is most similar to Case 3. Structures currently contain the
UNID, ID, and FullPath of each Resource. (The data could be optimized
to contain only the UNID and let the Indexers do more work. I chose
to waste some drive space to save processing by the frequently run
Indexers.) I expect most Indexes will use the "live" Structure, but
Module developers have the freedom to request a new Structure, and
administrators can have as many Structures as they are willing to
maintain. With Module Inheritance, a new Module could use all the
code from an existing Module while specifying a different Structure.
Here is how the completed system will work:
1. A Navigation Module defines Index configurations. Configuration
includes the Revision name (currently "live" or "edit", but will allow
the Module developer to create more) and filters (e.g.limit to certain
Types). Hierarchical Indexes also require a Structure. Index
configuration files are currently stored in {pub}/content/index, but
will move to Modules.
NOTE: This could be used to create a many-Structure Case #1. A large
Publication could have several local Modules inheriting from the
global "nav" Module with each using a different Index/Structure. That
might require only one file in one new directory for each new Module.
Then teach the aggregation to use different Modules based on the
current page (again implemented by overriding only one file.)
2. Lenya-1.3 will notice Module Indexes that need Structures and add
the Structure names to an administration menu.
3. Administrators edit the Structure Resources. (Structures are
currently stored in {pub}/content/relation, but will become Design
Resources.)
4. The Indexer creates/updates the Index using the specified
Structure. The result is similar to a Sitetree file. Indexes are
language-specific and add the Title from the specified
Translation/Revision to the information in the Structure. (Indexes
are currently stored in {pub}/content/index, but should be moved to a
temp directory as they are completely and frequently generated so
permanent storage is unnecessary and unwise.)
---
5. Something (usually a Type Module which received the user request
from the Live Module) requests a menu from the Navigation Module. (The
"nav" Module handles menus for Flat datastores.)
6. The Module calls the SitetreeGenerator with the name of the Index.
The SitetreeGenerator sends the correct file and will filter based on
security (so people cannot see what they cannot get.)
7. The Module transforms the Index into XHTML and returns the
information to the requesting Module.
Lenya-1.3 does not use checkout/locking/checkin for anything. Every
Revision is saved to a new file. Structures will probably become
Design Resources when I write the "Save Structure" function next week.
As Resources, Structures will have the same controls as all
Resources, i.e. you will be able to choose which revision is "live".
The Structure editor also includes Undo/Redo functionality -- very
useful when a misclick removes an entire section. (I worried about
memory so I did some math. With my current default of 5 undos,
browsers should use 1 MB per 2000 Resources. The Page Down key will
break before memory becomes an issue.)
I will be checking in the "relate" Module/Structure editor interface
without the Save action because the interface is almost complete and I
will be unavailable from Friday to Monday. Please try it after my
next commit.
I believe Lenya-1.3 will solve every complaint/issue/request. I think
in Lenya-1.3 terms so please ask me about any concepts and terms
needing further explanation.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
