portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Date Thu, 20 May 2004 17:14:48 GMT

On May 19, 2004, at 9:28 AM, Raphaël Luta wrote:

> 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:
>>>> 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.
>> Let me preface this response by saying that my description below is 
>> how I designed the schema to handle pages and fragments a while back
>> 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 ?
Think of a folder. It has a collection of pages immediately beneath it. 
Sub pages are all direct descendants of a folder.

>> 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

>> 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.
Have you ever tried to explain how Jetspeed menus and tabs function and 
their relationship to PSML in front of a group of people?
"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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message