You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Bill Dudney <bd...@mac.com> on 2005/07/07 19:24:56 UTC
uidata, svn reorg and tomahawk
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-
Re: uidata, svn reorg and tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
All set,
the dependency chain should now be in order again...
regards,
Martin
On 7/7/05, Martin Marinschek <ma...@gmail.com> wrote:
> Oh my,
>
> wow, I should really start being more careful with committing, it seems to be ;)
>
> an email stack of 10 mails the same day, wow, MyFaces starts being a
> sensible project right now ;)
>
> sorry that I checked that line in, of course I didn't want to break
> dependencies, I will go change that to something useful by the minute!
>
> regards,
>
> Martin
>
> On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > Bill,
> >
> > I reverted the change (but only for UIData.) Can you reimplement
> > forceId in the way you suggested? Since part of the tomahawk changes
> > are for other things I left those in. This included a change to the
> > TLD that added the forceId attribute. So now the component is
> > declared to have a forceId attribute but has none (so we should
> > probably fix that.)
> >
> > sean
> >
> >
> > On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > > Good point. I thought about configuring different classpaths for
> > > different projects. I'm just trying to think of a slick way to do it
> > > and still keep one build file to build an indvidual subproject or all
> > > of them.
> > >
> > > Maybe we could have different classpath refs and then make the
> > > classpath in the compile target depend on what's specified in the
> > > build.properties of the specific project.
> > >
> > > Care to submit a patch for this?
> > >
> > > sean
> > >
> > > On 7/7/05, John Fallows <jo...@gmail.com> wrote:
> > > > On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > 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. :-)
> > > >
> > > > We should remove the impl classes from the classpath during tomahawk
> > > > compilation to make this kind of issue easier to catch before commit.
> > > >
> > > > Kind Regards,
> > > > John Fallows.
> > > >
> > >
> >
>
Re: uidata, svn reorg and tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
Oh my,
wow, I should really start being more careful with committing, it seems to be ;)
an email stack of 10 mails the same day, wow, MyFaces starts being a
sensible project right now ;)
sorry that I checked that line in, of course I didn't want to break
dependencies, I will go change that to something useful by the minute!
regards,
Martin
On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> Bill,
>
> I reverted the change (but only for UIData.) Can you reimplement
> forceId in the way you suggested? Since part of the tomahawk changes
> are for other things I left those in. This included a change to the
> TLD that added the forceId attribute. So now the component is
> declared to have a forceId attribute but has none (so we should
> probably fix that.)
>
> sean
>
>
> On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > Good point. I thought about configuring different classpaths for
> > different projects. I'm just trying to think of a slick way to do it
> > and still keep one build file to build an indvidual subproject or all
> > of them.
> >
> > Maybe we could have different classpath refs and then make the
> > classpath in the compile target depend on what's specified in the
> > build.properties of the specific project.
> >
> > Care to submit a patch for this?
> >
> > sean
> >
> > On 7/7/05, John Fallows <jo...@gmail.com> wrote:
> > > On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > > > 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. :-)
> > >
> > > We should remove the impl classes from the classpath during tomahawk
> > > compilation to make this kind of issue easier to catch before commit.
> > >
> > > Kind Regards,
> > > John Fallows.
> > >
> >
>
Re: uidata, svn reorg and tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
Exactly, I added support to the dataList - and this was only for the
id of the list itself. This is very useful for list based menus, as
the colon in the automatically generated id of the component screws up
the current CSS implementations completely (the colon being used as
pseudo class selector in CSS as well).
The functionality might also be interesting for the extended
dataTable, I didn't implement it though.
regards,
Martin
On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> I was mistaken about the change. Martin added the attribute to
> HtmlDataList in the TLD but implemented it in UIData. So it turns out
> there is nothing to be undone now that I took it out of UIData and he
> added the support to HtmlDataList.
>
> Now that I think about it, forceId isn't really appropriate for
> <h:dataTable> unless you want to specify the id of the table itself
> (as opposed to the elements contained within it.)
>
> sean
>
>
>
> On 7/7/05, Bill Dudney <bd...@mac.com> wrote:
> > Sean,
> >
> > I can't find the extra TLD reference to forceId, only place I'm
> > seeing that attribute is in the components in myfaces_ext.tld. Am I
> > missing something?
> >
> > The stuff that Martin just checked in fixed the dependency chain
> > stuff though (thanks Martin).
> >
> > TTFN,
> >
> > -bd-
> >
> > On Jul 7, 2005, at 12:13 PM, Sean Schofield wrote:
> >
> > > Bill,
> > >
> > > I reverted the change (but only for UIData.) Can you reimplement
> > > forceId in the way you suggested? Since part of the tomahawk changes
> > > are for other things I left those in. This included a change to the
> > > TLD that added the forceId attribute. So now the component is
> > > declared to have a forceId attribute but has none (so we should
> > > probably fix that.)
> > >
> > > sean
> > >
> > >
> > > On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > >
> > >> Good point. I thought about configuring different classpaths for
> > >> different projects. I'm just trying to think of a slick way to do it
> > >> and still keep one build file to build an indvidual subproject or all
> > >> of them.
> > >>
> > >> Maybe we could have different classpath refs and then make the
> > >> classpath in the compile target depend on what's specified in the
> > >> build.properties of the specific project.
> > >>
> > >> Care to submit a patch for this?
> > >>
> > >> sean
> > >>
> > >> On 7/7/05, John Fallows <jo...@gmail.com> wrote:
> > >>
> > >>> On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > >>>
> > >>>> 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. :-)
> > >>>>
> > >>>
> > >>> We should remove the impl classes from the classpath during tomahawk
> > >>> compilation to make this kind of issue easier to catch before
> > >>> commit.
> > >>>
> > >>> Kind Regards,
> > >>> John Fallows.
> > >>>
> > >>>
> > >>
> > >
> >
> >
>
Re: uidata, svn reorg and tomahawk
Posted by Sean Schofield <se...@gmail.com>.
I was mistaken about the change. Martin added the attribute to
HtmlDataList in the TLD but implemented it in UIData. So it turns out
there is nothing to be undone now that I took it out of UIData and he
added the support to HtmlDataList.
Now that I think about it, forceId isn't really appropriate for
<h:dataTable> unless you want to specify the id of the table itself
(as opposed to the elements contained within it.)
sean
On 7/7/05, Bill Dudney <bd...@mac.com> wrote:
> Sean,
>
> I can't find the extra TLD reference to forceId, only place I'm
> seeing that attribute is in the components in myfaces_ext.tld. Am I
> missing something?
>
> The stuff that Martin just checked in fixed the dependency chain
> stuff though (thanks Martin).
>
> TTFN,
>
> -bd-
>
> On Jul 7, 2005, at 12:13 PM, Sean Schofield wrote:
>
> > Bill,
> >
> > I reverted the change (but only for UIData.) Can you reimplement
> > forceId in the way you suggested? Since part of the tomahawk changes
> > are for other things I left those in. This included a change to the
> > TLD that added the forceId attribute. So now the component is
> > declared to have a forceId attribute but has none (so we should
> > probably fix that.)
> >
> > sean
> >
> >
> > On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> >
> >> Good point. I thought about configuring different classpaths for
> >> different projects. I'm just trying to think of a slick way to do it
> >> and still keep one build file to build an indvidual subproject or all
> >> of them.
> >>
> >> Maybe we could have different classpath refs and then make the
> >> classpath in the compile target depend on what's specified in the
> >> build.properties of the specific project.
> >>
> >> Care to submit a patch for this?
> >>
> >> sean
> >>
> >> On 7/7/05, John Fallows <jo...@gmail.com> wrote:
> >>
> >>> On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> >>>
> >>>> 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. :-)
> >>>>
> >>>
> >>> We should remove the impl classes from the classpath during tomahawk
> >>> compilation to make this kind of issue easier to catch before
> >>> commit.
> >>>
> >>> Kind Regards,
> >>> John Fallows.
> >>>
> >>>
> >>
> >
>
>
Re: uidata, svn reorg and tomahawk
Posted by Bill Dudney <bd...@mac.com>.
Sean,
I can't find the extra TLD reference to forceId, only place I'm
seeing that attribute is in the components in myfaces_ext.tld. Am I
missing something?
The stuff that Martin just checked in fixed the dependency chain
stuff though (thanks Martin).
TTFN,
-bd-
On Jul 7, 2005, at 12:13 PM, Sean Schofield wrote:
> Bill,
>
> I reverted the change (but only for UIData.) Can you reimplement
> forceId in the way you suggested? Since part of the tomahawk changes
> are for other things I left those in. This included a change to the
> TLD that added the forceId attribute. So now the component is
> declared to have a forceId attribute but has none (so we should
> probably fix that.)
>
> sean
>
>
> On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
>
>> Good point. I thought about configuring different classpaths for
>> different projects. I'm just trying to think of a slick way to do it
>> and still keep one build file to build an indvidual subproject or all
>> of them.
>>
>> Maybe we could have different classpath refs and then make the
>> classpath in the compile target depend on what's specified in the
>> build.properties of the specific project.
>>
>> Care to submit a patch for this?
>>
>> sean
>>
>> On 7/7/05, John Fallows <jo...@gmail.com> wrote:
>>
>>> On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
>>>
>>>> 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. :-)
>>>>
>>>
>>> We should remove the impl classes from the classpath during tomahawk
>>> compilation to make this kind of issue easier to catch before
>>> commit.
>>>
>>> Kind Regards,
>>> John Fallows.
>>>
>>>
>>
>
Re: uidata, svn reorg and tomahawk
Posted by Sean Schofield <se...@gmail.com>.
Bill,
I reverted the change (but only for UIData.) Can you reimplement
forceId in the way you suggested? Since part of the tomahawk changes
are for other things I left those in. This included a change to the
TLD that added the forceId attribute. So now the component is
declared to have a forceId attribute but has none (so we should
probably fix that.)
sean
On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> Good point. I thought about configuring different classpaths for
> different projects. I'm just trying to think of a slick way to do it
> and still keep one build file to build an indvidual subproject or all
> of them.
>
> Maybe we could have different classpath refs and then make the
> classpath in the compile target depend on what's specified in the
> build.properties of the specific project.
>
> Care to submit a patch for this?
>
> sean
>
> On 7/7/05, John Fallows <jo...@gmail.com> wrote:
> > On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > > 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. :-)
> >
> > We should remove the impl classes from the classpath during tomahawk
> > compilation to make this kind of issue easier to catch before commit.
> >
> > Kind Regards,
> > John Fallows.
> >
>
Re: Maven(2?) [was Re: uidata, svn reorg and tomahawk]
Posted by John Fallows <jo...@gmail.com>.
On 7/7/05, Matthias Wessendorf <mw...@gmail.com> wrote:
> On my current day job we are migrating to Maven(1)
>
> I like what I learn there. One thing I don't is that, if your project
> depends on jar (e.g. foo.jar)
> that depends itsself on another jar (bar.jar) you have to add foo.jar
> and bar.jar to your XML.
>
> But AFAIK that will be solved in Maven2
You are right Matthias, transitive dependencies are managed for you by Maven2.
> So yes, I'd like to see help on the maven stage ;)
>
> On 7/7/05, John Fallows <jo...@gmail.com> wrote:
> > On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > > Good point. I thought about configuring different classpaths for
> > > different projects. I'm just trying to think of a slick way to do it
> > > and still keep one build file to build an indvidual subproject or all
> > > of them.
> > >
> > > Maybe we could have different classpath refs and then make the
> > > classpath in the compile target depend on what's specified in the
> > > build.properties of the specific project.
> > >
> > > Care to submit a patch for this?
> >
> > I would rather help out with the Maven(2?) migration, since this kind
> > of problem is elegantly solved there.
> >
> > On that note, we have been successfully using Maven for the ADF Faces
> > project for almost 2 years, and are in the process of migrating to
> > Maven2 for enhanced configuration and extensibility features. The ADF
> > Faces Maven2 migration is expected to be complete within the next few
> > days.
> >
> > The Maven2 guys have done a really good job of supporting Ant-style
> > development by including an "ant" plugin that simply generates the
> > relevant build.xml file for the project.
> >
> > This ant build.xml file is one example of a generated artifact that
> > might make sense to checkin to source control, since it is targeted at
> > Ant-style developers who want to build the project without having
> > Maven(2) installed locally.
> >
> > Kind Regards,
> > John Fallows.
> >
>
>
> --
> Matthias Wessendorf
>
Re: Maven(2?) [was Re: uidata, svn reorg and tomahawk]
Posted by Matthias Wessendorf <mw...@gmail.com>.
On my current day job we are migrating to Maven(1)
I like what I learn there. One thing I don't is that, if your project
depends on jar (e.g. foo.jar)
that depends itsself on another jar (bar.jar) you have to add foo.jar
and bar.jar to your XML.
But AFAIK that will be solved in Maven2
So yes, I'd like to see help on the maven stage ;)
On 7/7/05, John Fallows <jo...@gmail.com> wrote:
> On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > Good point. I thought about configuring different classpaths for
> > different projects. I'm just trying to think of a slick way to do it
> > and still keep one build file to build an indvidual subproject or all
> > of them.
> >
> > Maybe we could have different classpath refs and then make the
> > classpath in the compile target depend on what's specified in the
> > build.properties of the specific project.
> >
> > Care to submit a patch for this?
>
> I would rather help out with the Maven(2?) migration, since this kind
> of problem is elegantly solved there.
>
> On that note, we have been successfully using Maven for the ADF Faces
> project for almost 2 years, and are in the process of migrating to
> Maven2 for enhanced configuration and extensibility features. The ADF
> Faces Maven2 migration is expected to be complete within the next few
> days.
>
> The Maven2 guys have done a really good job of supporting Ant-style
> development by including an "ant" plugin that simply generates the
> relevant build.xml file for the project.
>
> This ant build.xml file is one example of a generated artifact that
> might make sense to checkin to source control, since it is targeted at
> Ant-style developers who want to build the project without having
> Maven(2) installed locally.
>
> Kind Regards,
> John Fallows.
>
--
Matthias Wessendorf
Maven(2?) [was Re: uidata, svn reorg and tomahawk]
Posted by John Fallows <jo...@gmail.com>.
On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> Good point. I thought about configuring different classpaths for
> different projects. I'm just trying to think of a slick way to do it
> and still keep one build file to build an indvidual subproject or all
> of them.
>
> Maybe we could have different classpath refs and then make the
> classpath in the compile target depend on what's specified in the
> build.properties of the specific project.
>
> Care to submit a patch for this?
I would rather help out with the Maven(2?) migration, since this kind
of problem is elegantly solved there.
On that note, we have been successfully using Maven for the ADF Faces
project for almost 2 years, and are in the process of migrating to
Maven2 for enhanced configuration and extensibility features. The ADF
Faces Maven2 migration is expected to be complete within the next few
days.
The Maven2 guys have done a really good job of supporting Ant-style
development by including an "ant" plugin that simply generates the
relevant build.xml file for the project.
This ant build.xml file is one example of a generated artifact that
might make sense to checkin to source control, since it is targeted at
Ant-style developers who want to build the project without having
Maven(2) installed locally.
Kind Regards,
John Fallows.
Re: uidata, svn reorg and tomahawk
Posted by Sean Schofield <se...@gmail.com>.
Good point. I thought about configuring different classpaths for
different projects. I'm just trying to think of a slick way to do it
and still keep one build file to build an indvidual subproject or all
of them.
Maybe we could have different classpath refs and then make the
classpath in the compile target depend on what's specified in the
build.properties of the specific project.
Care to submit a patch for this?
sean
On 7/7/05, John Fallows <jo...@gmail.com> wrote:
> On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > 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. :-)
>
> We should remove the impl classes from the classpath during tomahawk
> compilation to make this kind of issue easier to catch before commit.
>
> Kind Regards,
> John Fallows.
>
Re: uidata, svn reorg and tomahawk
Posted by John Fallows <jo...@gmail.com>.
On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> 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. :-)
We should remove the impl classes from the classpath during tomahawk
compilation to make this kind of issue easier to catch before commit.
Kind Regards,
John Fallows.
Re: uidata, svn reorg and tomahawk
Posted by Sean Schofield <se...@gmail.com>.
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 <bd...@mac.com> 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-
>
Re: uidata, svn reorg and tomahawk
Posted by Sean Schofield <se...@gmail.com>.
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 <cr...@gmail.com> 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 <bd...@mac.com> 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-
> >
>
Re: uidata, svn reorg and tomahawk
Posted by Craig McClanahan <cr...@gmail.com>.
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 <bd...@mac.com> 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-
>