portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Ruttimann <roger...@apache.org>
Subject Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Date Wed, 19 May 2004 17:05:38 GMT
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...

David started a new document under design-docs/src/psml that describes 
the structures better. It's not complete but it describes the PSM structure.

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

Just for clarification. Do you propose another layer of abstraction 
called theme that defines the layout and decorators? Would the page only 
reference a theme that will be resolved by the aggregator. This way 
fragments could reference different themes inside the page.


>> 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.
>
> 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...
>
>>> <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.
>
> -- 
> Raphaël Luta - raphael@apache.org
> Apache Jetspeed - Enterprise Portal in Java
> http://portals.apache.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message