On Wed, 2011-05-25 at 15:56 +0200, Christophe Laprun wrote:
Some comments on Matt's work in no particular order.
The use cases developed in the test cases are pretty simple so it's difficult to get
a good feel for the API when trying to accomplish things that are more complex.
yes, my idea was to keep the test cases as simple as possible for now.
More complex tests can come later when we get some better ideas down.
GateIn.getPortal() won't quite work as there can be several portal containers and
each of these can in turn contain several portals so we need to be able to identify which
Portal we want to work with precisely.
agreed, we need to look into that and see where we want to draw the line
for what belongs to individual portals or portal containers and what
belongs to gatein as a whole.
I would like to keep things to individual portals as much as possible
even if in the current implementation they are shared.
ie maybe applications later on can be restricted to particular portals.
I'm not too sure about GadgetRepository and PortletRepository. I see why you have
them but I'd rather have only one repository for all possible content first if
possible. It is true that I somewhat neglected the Gadget case so I will do that now. :)
We need two separate ones since they do separate things. The
portletRepository is mostly read only and only fetches the available
portlets, while the gadget one can create and add remote gadgets.
I think it's best to return Iterable instead of Iterator for
collections. I use a subclass of Iterable that augment the base
interface with size and contains methods as both methods could be
implemented without needing to load the entire collection in memory.
Even without the additional methods, Iterable is better because it
allows to write code such as:
Iterable<Item> items;
for(Item item : items) { // actual code }
As discussed in a previous email, the fact that you use the same class
to represent "original" content (i.e. one that comes directly from
your repositories and which should be as read-only as possible) and
what I call managed (or customized for Thomas) content (i.e. one that
has been added to a category) can create a confusion for users as to
which version is which and why some Applications can be modified and
other not. I initially chose to implement this the same way you did
before deciding to make it more explicit.
Of course, I don't like
nodeManager.getNode("/home/testA/testB/testC") :) Apart from the fact
that it hardcodes the internals of node naming in the client code,
I guess something like getNode(String... node) might be better.
Then you could call getNode("home");
or getNode("home", "page1", "subpageA");
I will change this.
it also means that you cannot retrieve a node without first
retrieving its parent portal, then its NodeManager, etc. I'm still
wondering if it's a good thing or not :) Why not put the node methods
directly on Portal instead of having a separate NodeManager? The same
actually goes for PageManager since they need a parent portal to work
correctly i.e. what they return is scoped only to the parent Portal
(since "/home/testA/testB/testC" is not a valid node id over the whole
set of existing nodes for a complete GateIn install)
hmm, yeah, I guess I can remove the Manager classes and move the methods
to the portal class.
. The advantage of your solution (as opposed to mine, which has a
Nodes classes to query all nodes across all portal containers /
portals)
I don't think being able to query across all portals is a use case that
will be brought up too often. I think it will be better to force the
developer to loop over the available portals if they want to do
something like this.
is that it is easier to get away with using Strings to identify
nodes
as opposed to having to deal with complex ids like
"portal#classic:/web/NavigationPortlet"…
On Query, I prefer to use my version that is built fluently (which
seems to be the predominant idiom for such use case at the moment in
APIs, see
http://relation.to/Bloggers/ATypesafeCriteriaQueryAPIForJPA
for example) and is a little more typesafe but I guess that's a
matter of preference.
Right now the query object I have is probably something I want to remove
since its only used for getting pages.
I don't know if we want to have a robust query option for the first
implementation though. I think its something that we do need later on
though.
That's it for now, I would really like to see more fleshed out
use
cases to be able to get a better feel for the API. :)
Any suggestions on what exactly you want to see in the tests? more real
life use cases which use multiple components?
On May 25, 2011, at 5:08 AM, Matt Wringe wrote:
> There have been some discussion on creating an api package to create a
> simple way for people to interact and manipulate a gatein portal.
>
> Example situations would be things like creating a gadget, adding an
> application to a category, creating a page and adding it to a node,
> adding applications to a page, managing users, etc...
>
> Two different solutions have been created, both are a bit different in
> approach. These are preliminary and are not meant to be complete, it is
> more meant to start of a discussion:
>
>
https://github.com/metacosm/gatein-api
>
https://github.com/mwringe/gatein-api
>
> Lets start a discussion on the above apis and what you would expect to
> come from an api like this.
>
> _______________________________________________
> 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