You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Adam Winer <aw...@gmail.com> on 2006/09/18 22:35:08 UTC
Making rendering API public
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
Re: Making rendering API public
Posted by Simon Lessard <si...@gmail.com>.
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 <ma...@gmail.com> 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 <aw...@gmail.com> 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
>
Re: Making rendering API public
Posted by Adam Winer <aw...@gmail.com>.
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 <ma...@gmail.com> 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 <aw...@gmail.com> 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
>
Re: Making rendering API public
Posted by Martin Marinschek <ma...@gmail.com>.
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 <aw...@gmail.com> 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