On May 19, 2004, at 9:28 AM, Rapha�l Luta wrote:
Think of a folder. It has a collection of pages immediately beneath it. Sub pages are all direct descendants of a folder.
Le 18 mai 04, � 18:45, David Sean Taylor a �crit :
On May 18, 2004, at 8:14 AM, Scott T Weaver wrote:
On Tue, 2004-05-18 at 10:57, David Le Strat wrote:Let me preface this response by saying that my description below is how I designed the schema to handle pages and fragments a while backRoger,
I read the proposal and the proposed changes look good to me.
Quick question: I am assuming that we will be supporting nested pages, correct?Since a Page is a Fragment and a Page is collection of fragments, I would say yes.
There is no documentation, but this response and thread will be included in the document Ive started on PSML and the Profiler
There's this in CVS currently that starts to elaborate on folders/pages:
design-docs/src/aggregation/PageAggregationDesign.txt.
Not a lot though...
The phase2-schema.xml has support for SUB_PAGES.
The database PSML schema design (not completely implemented in the component) also supports the concept of FRAGMENT_REFS
Like J1 references, a fragment reference references fragments outside of the current page.
Unlike J1 references, these fragments are not associated with a page but can stand alone.
I don't really understand what SUB_PAGES are for. Can you elaborate ?
We have also considered the concept of a FOLDER, or NODE.
A folder can contain 1 or more pages.
Im still trying to weigh the pluses and minuses of any page being a folder as a opposed to having a special folder object.
I believe that this node/folder concept can be used for tabbed layouts and menu layouts of pages, which was supported in J1 only with Jetspeed links.
Here is where I disagree. A page, in my mind, is just that, a page. It cannot be a part of another page.
if its a part of another page, then its a fragment, something different.
So a page that contains references to other pages can be used for menus.
But when you navigate to that page, you leave the current page.
If you want to include re-usable PSML, use fragments.
I agree that Pages and Fragments should be different:
Fragments define the basic layout block that can be user-customized
Pages provide the context information required to display the selected fragments in the desired format.
Hence I agree with Roger proposal to move the SimpleLayout function to the Page "header" but not to directly
move the template reference inside the Page. Why ?
* Imagine you have 5000 Pages all referencing the same template and then, you want to rename it. It's going to be a major
PITA
* You want to use the same PSML page and use it with multiple client support, let's say XHTML, WML, cHTML. You need to
be able to use your Page with different layout templates without any other modification.
These 2 considerations make me think we'll be better using an additional level of indirection and reference only a "theme", "layout",
"decoration" name or whatever you want to call it and that this theme is resolved externally into template references for wrapping
the fragments.
+1 on keeping all template references out of PSML I think the top and bottom is simply a part of the page decorator
Have you ever tried to explain how Jetspeed menus and tabs function and their relationship to PSML in front of a group of people?
This leads to the last piece missing: tabs and menus like in J1.
Like in J1, tabs and layout menus should be supported with the current J2 fragment model.
Like with J1 controllers and controls, menus will be a combination of page and portlet decorators.
I will check in a document on PSML covering these issues.
Once the draft is checked, please feel free to change it to meet the design we create here
I'm not sure this is optimal actually. Sure the J1 system has proved quite versatile and flexible
in handling a variety of requirement but OTOH it's somewhat non-intuitive for new users who
apparently expect some place to configure the menu/tabs somewhere.
"Somewhat non-intuitive" is an understatement ;-)
I think it may be worthwhile to explore the benefits of actually having explicit "menu descriptors" stored in
J2. I need to think more about it...
I need to think about it too.
I'd like to also define menu options that link to other places in the portal, and even locations outside of the portal
<snip>Additionally, have you thought of the impact of the change to the navigation context. It could be nice if following that change the portal URL could locate the page to load through a simple page=pageName querystring.
The location of a page is handled by the profiler.
The profiler page location strategy is not fixed.
Create a rule to use the query parameter named 'page' to find the page.
I also need to document the new profiler
The profiler will need a portlet to aid the administrator in defining profiling rules
The profiler in J2 is completely parameterized
Nothing is hard-coded as in J1
This is just the default implementation, locating pages.
A more complex profiler could dynamically create pages and layout based on runtime information
You can actually do that in J1 if you are willing to re-implent the profiler service.
Go on then, start coding ... ;-)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
