Craig, You are correct but this happened by mistake. Its definitely not our intention to make the Tomahawk stuff depend on anything in API.
sean On 7/7/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > I confess to forgetting the abbreviation taxonomy, but does "impl" > below refer to the JSF container implementation? If so, I would > suggest that you do *not* want Tomahawk or the examples to have direct > dependencies on those classes -- because that locks them in to only > the MyFaces implementation (a current example of this being the way > that Tiles is integrated with MyFaces). Thus (again, if my > interpretation is correct), you'd want the following as your direct > dependency chains: > > api <- share > > api, share <- impl > > api, share <- tomahawk > > api, share <- sandbox (perhaps depend on tomahawk or impl also for > some use cases) > > api, share, tomahawk <- examples > > Right? > > Craig > > On 7/7/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > > Hi All, > > > > I'm playing around with the reorg and trying to get started on > > building tests and I've run into the following snag; > > > > The UIData has a dependency on > > > > org.apache.myfaces.component.html.util.HtmlComponentUtils > > > > which is currently in the tomahawk project. This causes a dependency > > on tomahawk from api (a circular dependency). > > > > My understanding of the dependency tree is as follows > > > > api <- share <- impl > > > > api, share, impl <- tomahawk > > > > api, share, impl <- sandbox > > > > api, share, impl, tomahawk <- examples > > > > Since the only (apparent to me anyway) additional functionality of > > HtmlComponentUtils.getClientID is to consider 'forceId' shouldn't > > this call be in a myfaces specific subclass in tomahawk instead of up > > in api? Users can't use 'forceId' unless they are using the x: tags > > anyway correct? > > > > HtmlDataTableHack appears to be the best place currently to put this > > functionality. > > > > Thoughts? > > > > -bd- > > >
