incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: [PORTAL] Changes and API review?
Date Thu, 14 Dec 2006 22:23:23 GMT
Scott,

My big concern is with the sheer quantity of new public APIs
(that is, public classes in trinidad-api).  We should be avoiding making
anything public unless it is absolutely, critically necessary.

Configurator APIs: I'm not completely sold on the name, but anyway,
I think we should:
 - Make Configurator an abstract class, not an interface.  Make most
   of the methods empty, not abstract.
 - Add getGlobalConfigurator() to the Configurator API
 - Eliminate GlobalConfigurator and GenericConfigurator classes

TrinidadListener:
 - *Definitely* should be in impl, not in api.  Register it automatically
   by including it in tr.tld.

All of the classes in webapp/wrappers and context/external:
 - Why aren't these in impl?
 - I don't understand at all why we could or should be implementing
   ServletExternalContext...  that's provided by the impl.  And
   PortletExternalContext should be provided by the bridge,
   or the impl as well if it supports portlets.  What am I missing?
   I suspect these come from adding TrinidadFacesContext, so...
 - TrinidadFacesContext:  why can't you just use the regular
   FacesContextFactory, as we're doing today?  Almost any
   solution is better than duplicating large amounts of impl code.

ExternalContextUtils:
-  To what extent does this really need to be in API?
-  In particular, I'd rather not expose any of the methods
  that are getting added to ExternalContext in 1.2:
    - getRequestCharacterEncoding()
    - getRequestContentType()
  ... but in general, I'd rather not expose anything here
  as a public API unless absolutely necessary.
- A Coding surprise:  you may not call
   request.getClass().getMethod().  Doesn't work, sadly, because
   the defining class might be package-private.  You have to
   get the API directly from ServletRequest.class, PortletRequest.class,
   etc.





On 12/14/06, Scott O'Bryan <darkarena@gmail.com> wrote:
> Hey everyone,
>
> As some of you know I have been working on a bunch of enhancements in
> order to get Trinidad prepared to work on a portal environment.  While
> there is still some myfaces bridge work which needs to be done in order
> to call this a complete success, I would like to get the work I have
> done merged into the trunk in order to prevent conflicts and to get
> everyone working with the new API's.  You can find the portal code into
> the jwaldman-portal branch which has a combination of the following
> patches as well as some of the work she is working on for skinning.  I
> am going to talk about the Patches corresponding to: ADFFACES-231,
> ADFFACES-232, ADFFACES-234, and ADFFACES-235.
>
> Most importantly, I would like your input on several public API's that
> were added as a result of this project in order to get approval from the
> community.
>
> Also, as an FYI, I am on the JSR-301 Expert Group and have tried to
> incorporate a design which will allow us to use that spec once it's
> finished.  The design is still in the preliminary stages, so there is no
> official support just yet, but I hope to have that support soon after
> the release of the final draft.
>
> Thanks,
>   Scott O'Bryan
>

Mime
View raw message