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 Raphaël Luta <ra...@apache.org> on 2005/03/03 14:56:38 UTC

Folder semantics issue

We've been playing around the Profiler and Folder stuff to implement our
portal navigation and we came across this oddity:

If I put this code in my page decorator velocity template

Parent Folder
$parentFolder

Parent Folder Children
#foreach($obj in $site.parentFolder.Folders(true).iterator())
$obj
#end

Siblings
#foreach($obj in $site.siblingFolders.iterator())
$obj
#end


I get the following results, as guest, default profiler settings:

In default page:

Parent Folder
$parentFolder

Parent Folder Children

Siblings
/folder1
/folder2
/folder3

In default page of folder1:

Parent Folder
/

Parent Folder Children
/folder1
/folder2
/folder3
/_user
/_role

Siblings

That means that contrary to my expectations,
$site.parentFoler.Folders is not equal to $site.siblingFolders

or said differently the children folders of my parent folder are
not my sibling folders !

I guess this is mostly a semantic issue but I believe the API
should make it clearer what we are calling parentFolder and
siblingFolders.

My understanding is that :
$site.parentFolder = the parent folder of the current *folder*
$site.siblingFolders = the siblings folders of the current *page*

I believe we should stick to having the same reference point, either
current page or current folder.
What do you think ?

-- 
Raphael 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: Folder semantics issue

Posted by Randy Watler <wa...@wispertel.net>.
Raphael,

BTW, getFolders(), getPages(), etc. have the same problems as 
getParent*() since these too attempt to navigate the logical profiled 
view by following physical file system relationships.... :(

Randy

Randy Watler wrote:

> Raphael,
>
> The reason all of this is so confusing is due to the use of the 
> Profiler by the PageManager. Because the getParent*() methods are 
> coming from the physical folder/page nodes and various collections in 
> the $site object are presenting a logical view, there is often 
> disagreement. The easiest way to stay sane is to never use the 
> getParent*() methods... :-(
>
> However, everyone wants to navigate the $site folder hierarchies to 
> generate menus. I am proposing that this be fixed in the latest Portal 
> Navigations proposal that has been discussed lately on another thread. 
> The idea is to build a proxy site definition that mostly delegates to 
> the underlying physical files and folders, but hides the real file 
> system getParent*() methods. For now, you can employ nested document 
> sets to generate hierarchical menus. However, as noted by others, it 
> is not intuitive to do so.
>
> If you need to create some complex portal navigations using M1 and 
> cannot wait for the M2 refactoring, let me know and I can give you a 
> hand.
>
> Randy
>
> Raphaël Luta wrote:
>
>> We've been playing around the Profiler and Folder stuff to implement our
>> portal navigation and we came across this oddity:
>>
>> If I put this code in my page decorator velocity template
>>
>> Parent Folder
>> $parentFolder
>>
>> Parent Folder Children
>> #foreach($obj in $site.parentFolder.Folders(true).iterator())
>> $obj
>> #end
>>
>> Siblings
>> #foreach($obj in $site.siblingFolders.iterator())
>> $obj
>> #end
>>
>>
>> I get the following results, as guest, default profiler settings:
>>
>> In default page:
>>
>> Parent Folder
>> $parentFolder
>>
>> Parent Folder Children
>>
>> Siblings
>> /folder1
>> /folder2
>> /folder3
>>
>> In default page of folder1:
>>
>> Parent Folder
>> /
>>
>> Parent Folder Children
>> /folder1
>> /folder2
>> /folder3
>> /_user
>> /_role
>>
>> Siblings
>>
>> That means that contrary to my expectations,
>> $site.parentFoler.Folders is not equal to $site.siblingFolders
>>
>> or said differently the children folders of my parent folder are
>> not my sibling folders !
>>
>> I guess this is mostly a semantic issue but I believe the API
>> should make it clearer what we are calling parentFolder and
>> siblingFolders.
>>
>> My understanding is that :
>> $site.parentFolder = the parent folder of the current *folder*
>> $site.siblingFolders = the siblings folders of the current *page*
>>
>> I believe we should stick to having the same reference point, either
>> current page or current folder.
>> What do you think ?
>>
>
>
> ---------------------------------------------------------------------
> 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: Folder semantics issue

Posted by Raphaël Luta <ra...@apache.org>.
Randy Watler wrote:
> Raphael,
> 
> The reason all of this is so confusing is due to the use of the Profiler 
> by the PageManager. Because the getParent*() methods are coming from the 
> physical folder/page nodes and various collections in the $site object 
> are presenting a logical view, there is often disagreement. The easiest 
> way to stay sane is to never use the getParent*() methods... :-(
> 
> However, everyone wants to navigate the $site folder hierarchies to 
> generate menus. I am proposing that this be fixed in the latest Portal 
> Navigations proposal that has been discussed lately on another thread. 
> The idea is to build a proxy site definition that mostly delegates to 
> the underlying physical files and folders, but hides the real file 
> system getParent*() methods. For now, you can employ nested document 
> sets to generate hierarchical menus. However, as noted by others, it is 
> not intuitive to do so.
> 
> If you need to create some complex portal navigations using M1 and 
> cannot wait for the M2 refactoring, let me know and I can give you a hand.
> 

I hqve no urgent need to qddress, I can wait the refqctoring. It's just 
that I noticed something thqt simply feels like a semantic issue that
makes using J2 more complex that it needs to be.

If you already have a fix in the works, I'll wait for it.

-- 
Raphaël Luta - raphael@apache.org
Apache Portals - 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: Folder semantics issue

Posted by Randy Watler <wa...@wispertel.net>.
Raphael,

The reason all of this is so confusing is due to the use of the Profiler 
by the PageManager. Because the getParent*() methods are coming from the 
physical folder/page nodes and various collections in the $site object 
are presenting a logical view, there is often disagreement. The easiest 
way to stay sane is to never use the getParent*() methods... :-(

However, everyone wants to navigate the $site folder hierarchies to 
generate menus. I am proposing that this be fixed in the latest Portal 
Navigations proposal that has been discussed lately on another thread. 
The idea is to build a proxy site definition that mostly delegates to 
the underlying physical files and folders, but hides the real file 
system getParent*() methods. For now, you can employ nested document 
sets to generate hierarchical menus. However, as noted by others, it is 
not intuitive to do so.

If you need to create some complex portal navigations using M1 and 
cannot wait for the M2 refactoring, let me know and I can give you a hand.

Randy

Raphaël Luta wrote:

> We've been playing around the Profiler and Folder stuff to implement our
> portal navigation and we came across this oddity:
>
> If I put this code in my page decorator velocity template
>
> Parent Folder
> $parentFolder
>
> Parent Folder Children
> #foreach($obj in $site.parentFolder.Folders(true).iterator())
> $obj
> #end
>
> Siblings
> #foreach($obj in $site.siblingFolders.iterator())
> $obj
> #end
>
>
> I get the following results, as guest, default profiler settings:
>
> In default page:
>
> Parent Folder
> $parentFolder
>
> Parent Folder Children
>
> Siblings
> /folder1
> /folder2
> /folder3
>
> In default page of folder1:
>
> Parent Folder
> /
>
> Parent Folder Children
> /folder1
> /folder2
> /folder3
> /_user
> /_role
>
> Siblings
>
> That means that contrary to my expectations,
> $site.parentFoler.Folders is not equal to $site.siblingFolders
>
> or said differently the children folders of my parent folder are
> not my sibling folders !
>
> I guess this is mostly a semantic issue but I believe the API
> should make it clearer what we are calling parentFolder and
> siblingFolders.
>
> My understanding is that :
> $site.parentFolder = the parent folder of the current *folder*
> $site.siblingFolders = the siblings folders of the current *page*
>
> I believe we should stick to having the same reference point, either
> current page or current folder.
> What do you think ?
>


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