hmmm... jQuery.data looks promising. I'll check it out. Thanks for the
tip.
Shawn
polyrhythmic wrote:
> 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 -
