1/ the content registry is not tied to a particular portal but
instead is the same for any site (including group/user) so it should be available on the
GateIn interface
But do we have to mirror exactly the current implementation in the api?
I might be useful in the future to have a content registry per portal
(ie if I am running many portals which are not related, should I really
have to see every portlet when I am dealing with one particular
portal?).
It might make things easier in the api if the GateIn interface is only
used to retrieve a Portal object, and then all you need is a portal
object to perform any operation.
2/ I don't get the difference between Portal (which extends Node)
and Site (which extends Navigation). A site is a container for pages and navigations. A
portal extends a site (as it provides more things).
3/ what does the Node interface describe ? I don't see a real interest in there and
it makes things more complex to understand, specially with the generics
public interface Navigation<T extends Node<T>> extends
GateInObject<Navigation>, Container<Navigation>
I think we can afford to use generics, but we cannot afford to use too many generics.
On Jun 28, 2011, at 5:42 PM, Christophe Laprun wrote:
> I've pushed the navigation changes to
http://github.com/metacosm/gatein-api
along with other changes. Please let me know what you think!
>
> On Jun 10, 2011, at 11:20 PM, Christophe Laprun wrote:
>
>> I've pushed some changes to
github.com/metacosm/gatein-api. I will re-work
completely the navigation use cases based on the recent exchanges when I come back from
vacations. I guess the current scope of the API is not as extended as I first thought so
there are lots of things that will disappear from the current design.
>>
>> On Jun 10, 2011, at 5:21 PM, Julien Viet wrote:
>>
>>> here is an updated version with the notion of site :
>>>
>>> <5806d87d.png>
>>> On Jun 10, 2011, at 4:47 PM, Christophe Laprun wrote:
>>>
>>>>
>>>> On Jun 10, 2011, at 3:33 PM, Julien Viet wrote:
>>>>
>>>>> indeed this is correct it should be done with a getPortal(String
name) / Collection<Portal> getPortals() from your entry point of the API (something
like GateIn object of Matt).
>>>>
>>>> I used to have something like that as well, except that it was used to
retrieved the PortalContainers as well, so you could navigate everything.
>>>>
>>>>> Basically what we aim to do is an API that expose this data
structure:
>>>>>
>>>>> <764a37d6.png>
>>>>
>>>> What did you use to create the diagram?
>>>>
>>>> Cordialement / Best,
>>>> Chris
>>>>
>>>> ==
>>>> Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
>>>> Follow GateIn:
http://blog.gatein.org /
http://twitter.com/gatein
>>>> Follow me:
http://metacosm.info/metacosm /
http://twitter.com/metacosm
>>>>
>>>
>>
>> Cordialement / Best,
>> Chris
>>
>> ==
>> Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
>> Follow GateIn:
http://blog.gatein.org /
http://twitter.com/gatein
>> Follow me:
http://metacosm.info/metacosm /
http://twitter.com/metacosm
>>
>>
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/gatein-dev
>
> Cordialement / Best,
> Chris
>
> ==
> Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
> Follow GateIn:
http://blog.gatein.org /
http://twitter.com/gatein
> Follow me:
http://metacosm.info/metacosm /
http://twitter.com/metacosm
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/gatein-dev
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev