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: [jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Date Tue, 01 Mar 2005 22:53:59 GMT
Randy Watler (JIRA) wrote:
> [
> http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59846
> ]
> 
> Randy Watler commented on JS2-69: ---------------------------------
> 
> Team,
> 
> After devoting some time to this issue over the week I think I have
> come up with the heart of a proposal. I plan on commiting it to an
> official design document in all of its glory soon, but I would like
> some feedback first.
> 
Randy,

Im going to try to summarize your proposal so that I can better
understand it. Lets try to stay out of too many implementation issues
for now...

* There will be a new session context object: Site
* The profiled page context object will no longer be used directly
   Instead Site should be used in all navigation templates

If this is correct, then with your upcoming official document, could I
request to see a public API (interfaces) for the new Site interface and
high level examples for several use cases


> 3. Basic utilities will be implemented by the site session context
> object that mimic the existing PageManager/Profiler features. These
> will minimally include: getPage(), getFolder(), getSiblingFolders(),
> getSiblingPages(), and getRootLinks(). The new getRootFolder(),
> getRootPages(), and getRootFolders() access will also implemented to
> facilitate ad-hoc access to the root of the profiled site.
>
Is this for backward compatibility?
I have existing systems usuing the page context 'api'...


> 4. Document sets will be deprecated and replaced with named menu
> definitions that will appear in the folder.metadata files. In the

+1
In you design doc, could you provide examples of menu definitions

> 5. The implementation of the functionality behind the site session
> context object and its proxy hierarchies will be encapsulated in a
> separate component I am referring to as the PortalNavigations
> component. I am also considering the implementation of another
> compatible component that simply returns underlying Folders, Pages,
> and other documents from the PageManager without employing the
> Profiler or Security; this would also eliminate the need for proxies
> and delegation.

There is a Site session object used internally
Then a PortletNavigations component...

Perhaps some UML (sorry XPers) or even circles and lines would help
about now (components, pipeline context interfaces, interfaces provided 
to template developers). I need to start at a higher, design level 
before getting into all of the implementation details

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


Mime
View raw message