Hello all,

+1 on making most of those API public, even if it means to redo some
architectural work to reduce coupling. I would be +1 to place that kind of
library in a completely different JAR as well to allow other libraries like
Tomahawk to use the feature without having a dependency toward Trinidad.


Regards,

~ Simon

p.s. I'm still alive, I'm just assigned full time on a project and a full
time semester at University.

On 9/18/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:

Hi Adam,

how does this fit into the plan of refactoring out skinning and some
of the other stuff to a general support package that might be used by
tomahawk as well?

regards,

Martin

On 9/19/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> Trinidad has a whole bunch of APIs for writing Renderers - lots in
> org.apache.myfaces.trinidadinternal.renderkit,and elsewhere -
> which are, by virtue of their packaging, off-limits as far as
> general third-party development goes.   So, no one can rely
> on their stability, which is something that we'll need to solve
> going forward.
>
> I'd like to start moving some of these out of "trinidadinternal"
> and the trinidad-impl JAR, and into the main, stable
> trinidad-api JAR so that developers can start writing renderers,
> skins, etc., without fear that we'll keep breaking the APIs.
>
> On a first pass, this would ideally involve at the
> following APIs:
>
> - RenderingContext
> - FormData
> - Skin, SkinFactory, SkinExtension
> - Icon (and everything in the icon package)
> - PartialPageContext
> - CoreRenderer
> - TrinidadAgent and related APIs
> - AccessKeyUtils
> - OutputUtils
> - XhtmlUtils
> - SelectItemSupport
>
> Unfortunately, there's some issues with moving over all of these.  For
> example,
> Jeanne Waldman has some proposed Icon API changes;  and Skin currently
> has hard dependencies on things like StyleSheetDocument, etc., which I
> really
> don't think we want in our public API.  So, I think this'll have to be a
> combination
> of some refactoring to get the private details moved down lower, and a
> go-slow
> with some of these classes that need changes.
>
> but maybe not
> - XhtmlRenderer
> - XhtmlConstants
> - SkinSelectors
>
> and definitely not at this time
> - any of our concrete renderer classes
>
> Comments?
>
> -- Adam
>
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Reply via email to