[jQuery] Re: Design question
instead of using an array you could use a key/value object.
then you can do something like
var o = {}
o[row_position] = [row_data]
then when you remove a row you do
delete o[row_position]
you could get the row's position from the dragdrop callback I assume,
but even if thats not the case its pretty straight forward using
jquery i guess.
On Nov 24, 5:40 pm, daveyoi [EMAIL PROTECTED] wrote:
Hello Everyone,
I am new to jquery and am using it in a project to develop a PHP based
Mysql report generator. My question is not 100% jquery but more on
application design?
I have a bunch of list items that I can drag and drop (thanks to
jquery) on to a workspace - on dropping I create a TH/TH elelment
with the value of the list item and an image which has a .click()
attached with a call back to a remove(). - This all works as expected
and really demonstrates how after just a couple of hours how powerfull
jquery is.
The hard part that I just cant get my head round is I need the value
and position of each item dropped onto the page stored somehow. I have
been using a bog standard js array and just pushing the new value into
the array on the drop callback but if I remove one of the TH/TH
then my array keys become out of sync.
Any suggestions on how best to approach this - I am primarily a PHP
developer and have been thinking of using Ajax to store the data in a
temp table but this seems a little longwinded.. js gurus your ideas?
Thanks - and hope I can repay the favour some time.
Dave
[jQuery] Re: Design question
Is row_position a row number in the table? Those numbers would change when
you delete a row. Or is it a value that you increment every time you add a
row (independent of the position in the table)? That would work - but you
wouldn't have a way to loop through this object sequentially.
Dave, I think we need to know more about what you're doing with that data to
suggest a solution. But here's another idea: If the problem is your array
getting out of sync when you delete a row, simply use [].splice() to delete
the corresponding array element, e.g. if you are deleting row 'n', use
array.splice(n,1) to delete the element.
You can also use .splice() to insert elements in an array, or delete and
insert elements at the same time. It's a very handy function.
-Mike
From: Nicolas R
instead of using an array you could use a key/value object.
then you can do something like
var o = {}
o[row_position] = [row_data]
then when you remove a row you do
delete o[row_position]
you could get the row's position from the dragdrop callback
I assume, but even if thats not the case its pretty straight
forward using jquery i guess.
On Nov 24, 5:40 pm, daveyoi [EMAIL PROTECTED] wrote:
Hello Everyone,
I am new to jquery and am using it in a project to develop
a PHP based
Mysql report generator. My question is not 100% jquery but more on
application design?
I have a bunch of list items that I can drag and drop (thanks to
jquery) on to a workspace - on dropping I create a
TH/TH elelment
with the value of the list item and an image which has a .click()
attached with a call back to a remove(). - This all works
as expected
and really demonstrates how after just a couple of hours
how powerfull
jquery is.
The hard part that I just cant get my head round is I need
the value
and position of each item dropped onto the page stored
somehow. I have
been using a bog standard js array and just pushing the new
value into
the array on the drop callback but if I remove one of the TH/TH
then my array keys become out of sync.
Any suggestions on how best to approach this - I am primarily a PHP
developer and have been thinking of using Ajax to store the
data in a
temp table but this seems a little longwinded.. js gurus your ideas?
Thanks - and hope I can repay the favour some time.
Dave
[jQuery] Re: Design question.
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 = $('trtd' + 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=empBob Smith/td
tddiv class=1-Jan-2008link 1/div/td
/tr
Then you can get the id with
$('div.1-Jan-2008').click(function() {
[jQuery] Re: Design question.
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=empBob Smith/td
tddiv class=1-Jan-2008link 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
tdBob Smith/td
tddivlink 1/div/td
tdtabletrtdlink2/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=4Bob Smith/td
tddiv id=4 class=1-Jan-2008link 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
[jQuery] Re: Design question.
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=empBob Smith/td
tddiv class=1-Jan-2008link 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
tdBob Smith/td
tddivlink 1/div/td
tdtabletrtdlink2/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=4Bob Smith/td
tddiv id=4 class=1-Jan-2008link 1/div/td
/tr
Now this isn't valid HTML because the IDs are not unique. But, I need
[jQuery] Re: Design question.
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=empBob Smith/td
tddiv class=1-Jan-2008link 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
tdBob Smith/td
tddivlink 1/div/td
tdtabletrtdlink2/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=4Bob Smith/td
tddiv id=4 class=1-Jan-2008link
[jQuery] Re: Design question.
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=empBob Smith/td
tddiv class=1-Jan-2008link 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
tdBob Smith/td
tddivlink 1/div/td
tdtabletrtdlink2/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=4Bob Smith/td
tddiv id=4 class=1-Jan-2008link 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.
