Great question: you could look at it either as an important first step in that direction, or a big problem in moving in that direction!
"A good first step": if we move skinning into a general support package, we've got to figure out which APIs should be considered the public API of that support package, which would make Tomahawk's life much easier for uptake - a smaller API, and less worries about that API breaking. "A big problem": my goal is to let people write third-party renderers without worrying about which APIs might come-and-go and break - but if we're gonna move the packages later, then that's gonna break some users... A good compromise, I think, is to go forward with this and while working on it, explicitly try to identify those packages that should be part of a shared rendering API, and keep those at least somewhat separate and explicitly identify them as candidates for moving in a future shared API, so users can now that their packages are subject to change. -- Adam 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
