On 1/9/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > Adam Winer wrote: > > @Matthias, I'd rather not have any wrappers - the plan here > > is to repackage in line with MyFaces rules. I would, however, > > strongly like to keep the high-level concept of separating our > > public APIs - like component classes - from private internal > > implementation details - like renderers and tag classes. We > > do this now with an "oracle.adf" package for public stuff > > and "oracle.adfinternal" for private stuff, much like Sun puts > > public APIs in "javax.*" and private in "com.sun.*". > > > > What would others think about repackaging org.apache.myfaces.custom > > to separate the renderers, tags, and components? org.apache.myfaces > > already does this for the "ext" stuff. Or, more generally, separating > > further the "things that are used internally in MyFaces" from "things > > we expect developers outside of MyFaces to rely on"? > > > > +1 on putting components and renderers/tags into separate packages in > tomahawk, just like myfaces does for api/impl. > > I don't believe it's as important as for the spec stuff, but it still > helps to make it clear what is a change that affects *users* of tomahawk > components, vs changes that break only *customisers* of tomahawk > components (a much smaller community).
Yes, exactly. It can't be quite as essential as it is for the spec, because MyFaces doesn't have an explicit spec, and a TCK, and lots of JCP rules, and multiple implementors of the same API, etc., etc., but it's very helpful to architect everything as if we *did* have such rules, and it's immensely helpful to point out the difference between the public contract exposed by any library - which users can largely rely on from release to release - and the private implementation details, which users shouldn't care about and can change as needed. > It's a moderate amount of work, but not huge. And it can be done > incrementally... Indeed. It's also worth considering a general repackaging of the components themselves - instead of one package per component, more functional groupings (and I'm guessing it won't shock you if I point out the packaging of the components in the ADF code as an example? :) This sort of thing, I'd be happy to take a crack at - I think much of the work is actually in coming up with a proposal. -- Adam
