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.
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.
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. :)
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, 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). The advantage of your solution (as opposed to mine,
which has a Nodes classes to query all nodes across all portal containers / portals) 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.
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. :)
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