Hello Shawn,
Not having unique IDs will always cause trouble. Not recommended.
> I've tried various techniques, including building a JS object structure...
> Something like $("#trigger")[0].extraData = { id: 4 }; ?
If you need data stored relative to elements, you could store
information with jQuery.data.
http://docs.jquery.com/Internals/jQuery.data
I have found it to be a very fast way to have data relative to DOM
elements.
>But breaks down when you start needing to access multiple items for a given
>action...
You can store as much data attached to an element as you need with key/
value pairs with jQuery.data.
If you need to 'trigger' reading data from a link in a different
location, you could store the ID in the link's REL (or store the ID
with jQuery.data) and then grab the data from there. With
jQuery.data, if you can find the element somehow, you can retrieve all
its data.
HTH and hope it all makes sense...
Charles
doublerebel.com
On Jan 18, 8:00 pm, Shawn <[EMAIL PROTECTED]> wrote:
> A good start, but I see a few issues here. Both from the same line of code:
>
> var id = $(this).parent().parent().attr('id).substr(1);
>
> 1) the structure has to be known for this to work. (i.e. the ancestor
> element two levels up contains the ID). This may be a non-fixable thing
> though. You're going to have to know where the information is stored
> somehow. And doing something like
> $(this)[0].extraData = $("#IDelement") leads to circular references...
>
> 2) the ID now needs to be processed. For a small number of items this
> isn't bad, but as the complexity of your page increases, you end up with
> a whole set of modifcations that have to be parsed out. For instance,
> in your sample you have id="u4". But if that same ID has to be used in
> other places, you end up with "x4", "y4", etc. Maybe it's a moot point
> though in that you are just stripping off the text that makes the ID
> unique, and then just working with the value anyways - in which case
> it'll always be .substr(1), which will always be relatively fast.
>
> 3) This deals well enough with items where you have a single piece of
> information needed (the ID in this case). But breaks down when you
> start needing to access multiple items for a given action. I have a
> specific example where I need to know the employee name (stored at the
> TR level), and the date represented by the cell clicked on. These two
> items are passed to an Ajax call for further processing. Using the date
> as an ID is a non-starter (same date used on multiple rows). But
> using it as a class is also problematic - what if you had
> class="1-Jan-2006 odd taskHeader" ?
>
> 4) Scalability. with smaller data sets, the amount of processing is
> negligible and can be safely ignored. But increase the volume of data
> and the amount of processing becomes a problem. If it takes 10
> milliseconds to process one item, what happens when you have 1000+ items?
>
> Then again, I think I mixing up different aspects of the problem -
> creating the output, and then dealing with events afterwards. Either
> way, I'm still looking for methods that would minimize performance issues.
>
> I do have a specific sample in mind, but this issue is rather generic I
> think. Thanks for the response. I think it's a good starting point. :)
>
> Shawn
>
>
>
> J Moore wrote:
>
> > A simple work around is to append a character to the id to keep them
> > unique. But also, store the ID in the parent TR.
>
> > e.g.
>
> > <tr id="u4">
> > <td class="emp">Bob Smith</td>
> > <td><div class="1-Jan-2008">link 1</div></td>
> > </tr>
>
> > Then you can get the id with
>
> > $('div.1-Jan-2008').click(function() {
> > var id = $(this).parent().parent().attr('id).substr(1);
> > alert("do something with employee id:"+id);
> > });
>
> > would that work?
>
> > On Jan 18, 7:43 pm, Shawn <[EMAIL PROTECTED]> wrote:
> >> I have a case that is going to prove to be processor intensive, so am
> >> looking for suggestions on how to make the code as responsive as
> >> possible. In addition, I'm a little stumped on how to resolve a problem
> >> with my IDs.
>
> >> I have a page that will list hundreds of people (I'm ignoring paging for
> >> now, it's just not quite suitable). For each person there will be a
> >> number of actionable items/links. Each of these links imply to do
> >> something different, but all rely on the employee ID, These links will
> >> also be embedded in sub-structures (divs/tables, etc.) So a sample of
> >> one row might look something like this:
>
> >> <tr>
> >> <td>Bob Smith</td>
> >> <td><div>link 1</div></td>
> >> <td><table><tr><td>link2</td></tr></table</td>
> >> </tr>
>
> >> (this is very contrived to help illustrate the design issues... :)
>
> >> Now the problem. If the first link (though it could be anywhere on the
> >> row) were to trigger a Cluetip with details for that employee and item,
> >> I'll need the employee ID, and supporting information (a date say, based
> >> on what column it's in). In my current code I've done this:
>
> >> <tr>
> >> <td id="4">Bob Smith</td>
> >> <td><div id="4" class="1-Jan-2008">link 1</div></td>
> >> </tr>
>
> >> Now this isn't valid HTML because the IDs are not unique. But, I need
> >> the ID to do the needed processing. I can't just ask for the first
> >> sibling's ID, because my "trigger" elements are embeded in other
> >> structures. The content is dynamic, so it may or may not have the same
> >> structure (it would be one of a small handful of possible structures)
> >> each time - so I can't embed the structure (i.e.
> >> .parents("tr").children("td:first") ). My reasoning here is that if I
> >> put the target ID as close as possible to the trigger element, there is
> >> less processing needed to get that ID - which is a large factor when
> >> dealing with hundreds of rows on the page.
>
> >> So, my question is what others are doing in this sort of situation.
> >> I've tried various techniques, including building a JS object structure
> >> with the pertinent data, but keep hitting a performance issue. Maybe I
> >> need to embed an object on each of my trigger elements that contains the
> >> needed data? Something like $("#trigger")[0].extraData = { id: 4 }; ?
> >> But won't this run into run-away memory usage when I'm dealing with
> >> potentially thousands of these triggers (multiple triggers for each
> >> employee).
>
> >> If it helps conceptually, think of a table with one employee per row,
> >> and each of the remaining columns being a day. Each day needing a
> >> trigger to show a Cluetip for what the employee is doing that day.
>
> >> I do realize my definitions are kinda simplistic, but hopefully there is
> >> enough there to get the issue across. For me to define the full picture
> >> would need a book or three... :)
>
> >> Thanks for any input.- Hide quoted text -
>
> - Show quoted text -
