David Sean Taylor wrote:
On May 18, 2004, at 8:14 AM, Scott T Weaver 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 backOn Tue, 2004-05-18 at 10:57, David Le Strat wrote:
Roger,
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
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.
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 on that. A page should only include fragments and not other pages. It would be easier to design pages. It could get complicated and confusing if the sub-page would include different page decorators.
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.
The current proposal doesn't include the menu handling. I'll add a section that explains the basic concepts and refers to the PSML document.
A PageManager component is on the to-do list. We should have a component that finds pages, fragments once the PSML is stored in the database.
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 think only fragments should be referenced, except for the special case of a node (folder).There is one thing we need to clear up. If we have a page, within a page, how do we handle the embedded page's decoration?
But again, this is open to discussion
Do we:
1. ignore the embedded page's decoration and just show its fragment markup. 2. Show the root pages decoration around it and then any of its sub-pages also show there decoration. 3. Allow a sub-pages decoration to override and become the root pages decoration. 4. Any of the previous 3 controlled by settings in the psml.
I am +1 on 4, that way you could get as fancy as you want.
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
-- David Sean Taylor
Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- 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]
