If you check out the FormData class that was made public, it has a much smaller API. Much of the stuff that should be kept private has been moved down to a CoreFormData subclass. Same approach for PartialPageContext.
-- Adam On 9/26/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote:
do we need to make FormData public? That class has a lot of stuff in it that shouldn't be public. --arjuna On 9/26/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > hard to say. > > context makes sense, I think > > -M > > On 9/26/06, Simon Lessard <[EMAIL PROTECTED]> wrote: > > Hello Adam, > > > > I think I prefer the .context option. I believe it's a bit more > intuitive > > when looking for the class. > > > > > > Regards, > > > > ~ Simon > > > > On 9/26/06, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > > Any comments, anyone? I'm getting close to implementing > > > this... > > > > > > -- Adam > > > > > > > > > On 9/22/06, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > > > > I've checked in the first big part of getting ready for public > rendering > > > > APIs. > > > > The goal is to move APIs out of trinidad-impl and into trinidad-api, > but > > > > a number of the desired APIs pulled in a lot of code that really > > > shouldn't > > > > > > > > be made public. So, a bunch of refactoring was called for, > introducing > > > > some pure abstract base classes with reduced functionality, or > sometimes > > > > just eliminating dependencies altogether. > > > > > > > > My planned next step is to move the following APIs over, with > > > > proposed package names (all under org.apache.myfaces.trinidad, > > > > of course) > > > > > > > > * render.RenderingContext > > > > * render.PartialPageContext > > > > * render.LocaleContext > > > > * render.FormData > > > > * skin.Skin > > > > * skin.Icon > > > > > > > > Option 2 I can think of is to use context.RenderingContext instead > > > > of render.RenderingContext (and likewise for all the first four). > > > > > > > > After that, the only classes I'm itching to make public are > CoreRenderer > > > > and RenderUtils, both of which would go into o.a.m.t.render . After > > > > that, I can think of a bunch of candidates, like some of the output > > > > utility functions in core.xhtml, maybe RenderKitDecorator, etc., > > > > but we can take those on more slowly. > > > > > > > > Comments? > > > > > > > > -- Adam > > > > > > > > > > > > > > > > > > > > > -- > Matthias Wessendorf > http://tinyurl.com/fmywh > > further stuff: > blog: http://jroller.com/page/mwessendorf > mail: mwessendorf-at-gmail-dot-com >
