On Jul 4, 2011, at 3:16 PM, Julien Viet wrote:
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
As Matt pointed out, I think it makes more sense to be able to only see what's
available for a given Portal instead of everything (even though that's not currently
the case).
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
I want to keep Navigations separate from the "actual" objects. Nodes (which
should probably be renamed to something more meaningful, though I'm not quite sure
what at the moment) represent the actual objects which are pointed to by Navigations.
I personally find the navigation concept as it stands in GateIn rather complex and I fail
to see which problem it addresses (i.e. I don't really see the point of having aliases
to the same page at different spots but maybe I'm just not seeing the whole picture of
user needs). I would much rather have only one structure (i.e. only what I call Nodes
which are organized and which can be navigated) instead of having the objects and then an
artificial layer of Navigations on top of it that will, in most instances, perfectly match
the organization of the underlying Nodes. If you recall, I didn't have Navigations
previously. For me a Site is just a collection of Navigations, just like a Portal is a
collection of Pages.
I guess part of the difficulty for me to come up with an API for GateIn is that I am not
really in touch with the users' needs, having never really touched other parts of the
project. So I'm trying to guess between what you say and how I would like to use
GateIn as a user what might be useful. This doesn't make for a very satisfying
experience… :(
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.
I agree. I'd like to simplify things as well (and I've already done so somewhat).
Some of the generics complexity is there to help have clean API usage. As a user you
don't really care about the declaration of the objects you use, rather about how you
use them, which is what we should focus on first. The point s to have clean use cases,
which is what I'd like people to comment on rather than on the interfaces (at least at
this stage).
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