Serge Huber wrote:
Hi Ate,
Thanks for all this, it definitely helps clear out some definitions that
haven't been very clear in my mind. I have a few questions and remarks,
that you can find below...
At 19:58 22.06.2004, you wrote:
--
*Folder*
A Folder is an aggregate of Pages, Folders and Links. It is not
viewable or renderable but only used to group its
elements in an ordered manner. Its elements all have a parent
reference to their containing Folder.
The Folder structure and hierarchy is the basis for Page navigation,
layout, decoration and Menu rendering.
There is only one root Folder without parent. That simplifies the
definition of default Decorators and Decorations.
When you say a folder is not renderable, you mean it's content is never
shown as per say, and it doesn't have any decorator, but it does appear
in the menu right ?
I might be rendered with a different pipeline (a folder/page browser pipeline for
instance)
but not using the 'normal' portal pipeline.
In a menu its description will be displayed if, and only if it contains
elements which also must be displayed. It then represents a menu node of
the menu tree. Only Pages and Links are to be displayed as leafs.
*Folder elements*
A Folder element (Page, Folder, Link) is defined within it or may be a
reference to a element defined in another Folder
(like Unix symbolic links), which may be a reference in itself.
Deleting an element will result in references defined to become invalid.
Elements which are a reference to another Element defined in another
Folder will have as parent the Folder containing
them. For referenced Folder elements though, its elements will still
have as parent the referenced Folder itself, not
the Folder reference. This means that navigating to an element within
a referenced Folder will result in a change of the
parent hierarchy.
How would symbolic links work ? Could they survive folder moving ? (not
deleting but moving) ? One of the problems of using hierarchical
structures is maintaining integrity when using links (that are actually
artifacts to bypass the hierarchic structure). In a more general way,
could we move folders and or folder elements around ?
Depends on the implementation how easy that can be supported. With a database
implementation references probably can easily be updated. In a CMS store
probably too.
With a plain file system implementation it can only be done properly using a fancy
gui customizer (webbased).
I think any design supporting symbolic links will have the same problem though.
Not only a hierarchic model and especially filesystem based implementations.
<!-- Folder elements displayed in the menu (in the current example
in tabmenu if level < 3 or in treemenu otherwise)
in the order as defined
-->
<elements>
<page id="page1" description="Page 1"/>
<page ref="../../subfolder2/page8"/>
<page ref="/subfolder1/subfolder2/page9" description="Page 9" />
<folder id="subfolder1"/>
<folder ref="/subfolder1/subfolder3"/>
<link url="http://www.apache.org"; description="Home
Apache" target="_self"/>
<link url="http://portals.apache.org"; description="Home Apache
Portals" target="outside"/>
<!-- hidden elements -->
<page id="page2" hidden="true"/>
<folder id="subfolder2" hidden="true"/>
</elements>
</folder>
Thanks for the example, it always helps to clear things up ! One
question again : how would this be internationalized ? Are descriptions
used to be displayed ? If so, how do you specify descriptions for other
languages ?
There are a few options I think. Note: I didn't try yet to specify a complete
design. There are still issues to address like integration with the Profiler.
The Profiler could handle language and media type resolution using separate folders
like it is now in J1):
folder1
subfolder2
html
en
page1
de
page1
wml
en
page1
de
page1
Note: those 'profiler' folders can be automatically skipped (using a skip attribute on
those
type of folders) for level determination and rendering.
Besides using the Profiler one could allow for locale support in nested description
elements:
<page id="page1">
<description lang="en">Page 1</description>
<description lang="de">Seite 1</description>
</link>
Finally, localized resource bundles can be used and then resource identifiers are
specified
in the configuration instead of hard coded values. At runtime the correct, localized
description
can then be looked up.
Regards,
Serge Huber.
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
