You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Roger Ruttimann <ro...@earthlink.net> on 2004/05/18 01:29:06 UTC
[J2} Proposal for Layout, pages & Decorator handling in J2
I have checked-in a design proposal for how layouts, pages and decorators should be handled in J2.
The first part of the document describes the current state and the last chapter proposes a list of changes in order to enhance the current implementation.
The document can be found under /design-docs/src/decorations/j2 layout and decorator handling.pdf
Please review the doc and use the dev list for any discussion. My current goal is to implement the proposed changes by Friday.
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by Roger Ruttimann <ro...@apache.org>.
David Sean Taylor wrote:
>
> 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
>
> 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.
>
> 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
>
>> 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?
>>
> I think only fragments should be referenced, except for the special
> case of a node (folder).
> 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
>
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.
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> [office] +01 707 773-4646
> [mobile] +01 707 529 9194
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by Roger Ruttimann <ro...@apache.org>.
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
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by David Sean Taylor <da...@bluesunrise.com>.
On May 21, 2004, at 5:08 AM, Raphaël Luta wrote:
> Le 20 mai 04, à 19:14, David Sean Taylor a écrit :
>>>> 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.
>>
>
> What's the benefit of this structure compared to simply having a menu
> descriptor ?
>
Its orthogonal to menu structures.
Im working on a proposal/design doc for CMS support built into Jetspeed.
The profiler currently supports PSML pages.
Im proposing supporting a typical file system-like hierarchy (CMS) of
folders, sub-folders, documents.
PSML is simply one kind of document.
This means that we can uniformly address all documents, PSML included,
in a common namespace.
With CMS integration, PSML could also be versioned.
Regarding menus in PSML, lets begin a discussion here. Im thinking of a
separate section in the PSML:
<menus>
<!-- traditional J1 type menu built off a fragment collection -->
<menu name='TabOuterMenu' fragment='OuterPortlets'/>
<!-- mixed menu, external links, pages, page/fragment, local fragment
-->
<menu name='Example'>
<!-- link to another page -->
<menu-item name='AnotherPage' page='/employees/benefits/401K' />
<!-- link to another page,fragment -->
<menu-item name='AnotherFrag'
page='/employee/benefits/401K,CalculatorPortlet'/>
<!-- link to an 'outside' url -->
<menu-item name='Outside' url='http://www.apache.org'/>
</menus>
<fragments name='OuterPortlets' >
....
>>> 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
>>
>
> +1 but the relationship between profiler and such a menu based portal
> structure is nn-trivial.
> Things to consider:
> - if we keep a request pipleine like
> request -> capability -> profile -> page
> How do we know where this page is in the menu ?
The link still needs to go thru the profiler somehow or a similar
process.
In J1 you see that JetspeedLink creates links with media type built in,
for example
> The mapping function between the menu and the available pages
> is certainly not injective (several menu items may point to the same
> page) nor surjective (some pages may not be
> referenced at all).
Yes, and pages can be deleted and the menu references will be left
hanging
However if the PSML is normalized as in the J2 DB PSML DDL, we can put
in referential constraints
> - if you have loaded a page with a "menu" component displayed on it
> and you click on link provided by this menu, is this
> link considered "dumb", ie the portal will provide the request Page
> ID without any profiling or "smart" where you allow the
> profiler to modify the target based on its logic ?
I think it should be smart
In J1 it was made smart at the time the link was generated (Im speaking
of JetspeedLink, which is also the basis for J1 forwards)
I
> If you chose "smart", how will this link be constructed to provide
> hints for the profiler ?
> In, J2 PSML Pages are *always* user-independant.
>
Well they also worked with groups and roles, but yes, a jslink was user
dependent
I have to give that some thought...
> These questions are just scratching the surface of the implications of
> using a dual profiler + menu driven portal.
> The challenge is not to make such a setup "non-intuitive" :)
>
Well I think menus are intuitive, thats a starting point
Now we have to make the links both smart and intuitive...
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by Raphaël Luta <ra...@apache.org>.
Le 20 mai 04, à 19:14, David Sean Taylor a écrit :
>>> 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.
>
What's the benefit of this structure compared to simply having a menu
descriptor ?
>>> <snip>
>>> 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 ;-)
>
LOL :) Yes I know how it feels... but then I often get these kind of
confused looks from people when I try to explain
how everything works. ;P
>> 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
>
+1 but the relationship between profiler and such a menu based portal
structure is nn-trivial.
Things to consider:
- if we keep a request pipleine like
request -> capability -> profile -> page
How do we know where this page is in the menu ? The mapping function
between the menu and the available pages
is certainly not injective (several menu items may point to the same
page) nor surjective (some pages may not be
referenced at all).
- if you have loaded a page with a "menu" component displayed on it and
you click on link provided by this menu, is this
link considered "dumb", ie the portal will provide the request Page
ID without any profiling or "smart" where you allow the
profiler to modify the target based on its logic ?
If you chose "smart", how will this link be constructed to provide
hints for the profiler ?
In, J2 PSML Pages are *always* user-independant.
These questions are just scratching the surface of the implications of
using a dual profiler + menu driven portal.
The challenge is not to make such a setup "non-intuitive" :)
>>
>>>> <snip>
>>>
>>> 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 ... ;-)
>
I wrote 2 implementations of it for some internal projects 2 year ago
(esp. because I needed a client IP driven user
profiling). Very easy when you don't try to provide a "generic"
solution like the default profiler does.
--
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
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by Raphaël Luta <ra...@apache.org>.
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 ?
> 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.
> 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
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
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.
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
> 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?
>
I think only fragments should be referenced, except for the special
case of a node (folder).
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
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by David Le Strat <dl...@yahoo.com>.
+1 on 4 as well.
Another question:
I am assuming that the page decorator will provide
menu support, correct?
If you want
Tab 1 - Tab 2 - Tab 3
For Tab 1
Sub Tab 1 - Sub Tab 2 - Sub Tab 3
where tab 1 -> page1
and sub tab 1 -> page 1.1 (page 1.1 is nested in page
1)
etc.
What mechanisms are we planning to provide to allow to
automatically generate a tab menu / control over how
the menu should behave (menu on the top, on the left,
etc).
Regards,
David.
--- Scott T Weaver
<sc...@binary-designs.net> 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.
>
> 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?
>
> 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.
> >
> > Regards,
> >
> > David.
> > --- Roger Ruttimann
> <ro...@earthlink.net>
> > wrote:
> > > I have checked-in a design proposal for how
> layouts,
> > > pages and decorators should be handled in J2.
> > >
> > > The first part of the document describes the
> current
> > > state and the last chapter proposes a list of
> > > changes in order to enhance the current
> > > implementation.
> > >
> > > The document can be found under
> > > /design-docs/src/decorations/j2 layout and
> decorator
> > > handling.pdf
> > >
> > > Please review the doc and use the dev list for
> any
> > > discussion. My current goal is to implement the
> > > proposed changes by Friday.
> > >
> > > Roger
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > jetspeed-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > jetspeed-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! - Internet access at a great low price.
> > http://promo.yahoo.com/sbc/
> >
> >
>
---------------------------------------------------------------------
> > 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
>
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by Scott T Weaver <sc...@binary-designs.net>.
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.
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?
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.
>
> Regards,
>
> David.
> --- Roger Ruttimann <ro...@earthlink.net>
> wrote:
> > I have checked-in a design proposal for how layouts,
> > pages and decorators should be handled in J2.
> >
> > The first part of the document describes the current
> > state and the last chapter proposes a list of
> > changes in order to enhance the current
> > implementation.
> >
> > The document can be found under
> > /design-docs/src/decorations/j2 layout and decorator
> > handling.pdf
> >
> > Please review the doc and use the dev list for any
> > discussion. My current goal is to implement the
> > proposed changes by Friday.
> >
> > Roger
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > jetspeed-dev-help@jakarta.apache.org
> >
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! - Internet access at a great low price.
> http://promo.yahoo.com/sbc/
>
> ---------------------------------------------------------------------
> 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
Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Posted by David Le Strat <dl...@yahoo.com>.
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?
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.
Regards,
David.
--- Roger Ruttimann <ro...@earthlink.net>
wrote:
> I have checked-in a design proposal for how layouts,
> pages and decorators should be handled in J2.
>
> The first part of the document describes the current
> state and the last chapter proposes a list of
> changes in order to enhance the current
> implementation.
>
> The document can be found under
> /design-docs/src/decorations/j2 layout and decorator
> handling.pdf
>
> Please review the doc and use the dev list for any
> discussion. My current goal is to implement the
> proposed changes by Friday.
>
> Roger
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org