6:39 a.m.
What I'll want to represent is what is in the drawing I attach and I
think we are pretty close. I think the notion that pages can be shared
between sites is actually missing from Julien's UML diagram and may
motivate the notion of Portal and site (multiple sites per portal)
EPP instance and Portal contexts are managed by deployment.
Sites, Navigation Nodes, Pages and Application Registry is what we want
to manipulate by the API.
The part that we don't cover in that step are the links from pages to
the applications of the application registry.
The end result should be simple.
See in-line
On 07/04/2011 05:09 PM, Christophe Laprun wrote:
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).
Yes we can prepare for the future but let's not prepare for things
that
won't get done soon.
Let's target what's possible now (if there is very little cost in
complexity we can offer to target what's may be next).
In the future if things change we'll make things more generic, it
doesn't prevent from keeping the less generic API in place except for
major changes (but then it will have to be carefully thought and may
require deprecation.
Let's not make this API complex "just in 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).
Me neither. From
my diagram we have a Site which contains navigation
nodes, those nodes point to pages (here we can indeed be a bit more
generic as pointing to something like a URL is right to the corner, I
would rather be happy to make it possible so that the abstraction in the
API makes sense for new comers).
If Portal = Portal Context, then it shouldn't be a Node (and a Page
shouldn't be a node neither).
> 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.
A NavigationNode is a PageNode (extends NavigationNode) or a URLNode
(extends NavigationNode)
Am I oversimplifying ?
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).
It is what it addresses.
Same page in different contexts. Imagine you create 1 page for
registration and x sites, all the sites can share the same page (with
different header and footer (site template) and different skin.
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 was also wondering if we should "merge"
the 2, but now I'm rather
going for mapping what's in the UI now (so flat set of pages and
navigation nodes pointing to the 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).
I'm already lost with those generics.
But I like the use cases much better now.
Not sure about:
getKnownManagedContentIds
We are pretty close I think, let's nail it down ASAP.
Thomas
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
