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 <[EMAIL PROTECTED]> 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
