[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 drag&drop 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
> 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
> > 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
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 drag&drop 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 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
> 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.
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 = $('' + emp.name + '
[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.
>>>
>>> Bob Smith
>>> link 1
>>>
>>> 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:
Bob Smith
link 1
link2
(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 s
[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.
>
> >
> > Bob Smith
> > link 1
> >
>
> > 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:
>
> >>
> >> Bob Smith
> >> link 1
> >> link2
> >>
>
> >> (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:
>
> >>
> >> Bob Smith
> >> link 1
> >>
>
> >> Now this isn't valid HTML because the I
[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.
>
>
> Bob Smith
> link 1
>
>
> 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:
>>
>>
>> Bob Smith
>> link 1
>> link2
>>
>>
>> (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:
>>
>>
>> Bob Smith
>> link 1
>>
>>
>> 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 tri
[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.
Bob Smith
link 1
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:
>
>
> Bob Smith
> link 1
> link2
>
>
> (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:
>
>
> Bob Smith
> link 1
>
>
> 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.
