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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > >> > > >>> On 7/7/05, Sean Schofield <[EMAIL PROTECTED]> 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. > > >>> > > >>> > > >> > > > > > > > >
