hey shawn,
this is an old thread, but i have another option for you: closures.
jquery is all about closures, but i only recently fully "got" how they
worked and how cool they can be.
In the case of a table of results, where each row has a button,
closures avoids the ugliness of parsing the dom looking for an id.
Using your original example of a list of employees, we could add an
action to each employee with a closure. The jQuery each() method makes
this easy.
<script type="text/javascript">
var employees = [
{id:13, name:'bob'},
{id:14, name:'sue'},
{id:15, name:'joe'}
];
$(document).ready(function(){
var container = $('#results');
jQuery.each(employees, function() {
var emp = this;
var row = $('<tr><td>' + emp.name + '</td></tr>');
$('<a href="#">delete</a>')
.click(function() { fire(emp); } )
.appendTo(row);
row.appendTo(container);
});
function fire(employee) {
console.log('todo: fire ' + employee.name + ' id:'+employee.id);
}
});
</script>
<table id="results"></table>
Now, each link "delete", knows which employee to delete. This seems
like the cleanest approach.
Anyone know how to make this even more succinct?
-j
On Jan 19, 7:04 pm, Shawn <[EMAIL PROTECTED]> wrote:
> 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 -
