On May 31, 2011, at 10:47 AM, Julien Viet wrote:
I spent a bit of time reviewing this and the immediate feedback I can
do is:
1/ I see improvement in Chris work about the ID part and I think the Id<T> is quite
good with the factory method that make them intuitive to create.
However on the stylistic view my opinion is that it would make sense to avoid the
"get" style like getUserId and simply have "userId" because static
import allows to write:
User root = Users.get(userId("root"));
instead of:
Id<User> id = Ids.getUserId("root");
User root = Users.get(id);
Done.
2/ There are two parts which are out of scope of the current API that
we should remove which are the portal container and the UI component.
The current API should not mention the portal container and every work should be scoped
to the current portal container. This notion exist for isolating deployments (for instance
one portal container per customer). I think Matt has this right so far but not Chris API
that mentions it.
OK. I took the point of view that the API needed to be able to create portal containers
and portals and I indeed didn't scope the objects to the current portal. I will change
that.
The UI component part is not part of the scope of the current API and
we should leave it aside and address it later. However we still need the Page notion but
as a way to find pages (not create them because we don't address for now the UI
component part). Mostly pages will be associated with navigations programmatically.
I'm not too sure what you mean here.
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