Bill, You are correct. Martin introduced this with his last checkin. I remembered from the svn email but there is a cool SVN feature I used to verify this called 'svn blame.' Not sure how the command line version works but if you are using Tortoise SVN you can just right click the file and then "blame."
Basically it shows every line of the file and who was responsible for adding/modifying it. As we can see mmarinschek introduced the import line in revision 209583. :-) Anyways back to problem at hand ... I'm thinking we roll back Martin's changes and add the forceId support through a tomahawk specific mechanism as you suggest. Don't know if HtmlDataTableHack is appropriate or not so I will let you make the call (but I agree 100% on your point that its not needed in api.) Once we roll back his changes we can also apply Mathia's UIData patch. What do you think? sean 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- >
