I totally expected this question. We've added client side filtering
to aid the user in trimming that list down which is working very well
for us speed wise. The case where a 1,000 row query comes back is not
the norm, so for us it doesn't make sense to add the complexity (UI
wise) of paging for a maybe 10% scenario.
If it becomes a problem I may need to drum up some sort of dynamic
load piece that adds more "stuff" as the user scrolls. The filtering
would then need to be server side. It wouldn't be a bad way to go,
but that would add more complexity (development wise) to this project
with the need for caching results to keep server load down and the UI
additions. The frustrating thing about it is that usability is fine
in the other browsers.
Thanks for keeping me on my toes Rich.
Josh
On Aug 8, 6:30 am, Rich Wild <[EMAIL PROTECTED]> wrote:
> Hi Josh,
>
> Not answering the question, but does your app really require 1000+
> table rows to be displayed at once? Would some pagination not be more
> appropriate? This wouldn't just help the speed of the build, but it'd
> also really help the poor person that otherwise has to scroll through
> 1000 rows.
>
> yours unhelpfully,
>
> Rich Wild.
>
> On Aug 8, 11:52 am, Josh Bush <[EMAIL PROTECTED]> wrote:
>
> > Oh, it's fine. I wasn't expecting someone to write the code for me.
> > I'm just working on a plugin and hitting a roadblock with IE here.
> > I'm going to try and whip up an example of what I'm seeing that
> > illustrates this outside of my project. It seems like the string
> > operations aren't the bottleneck. The bottleneck happens when I pass
> > a really large piece of HTML to $("") to create that object in the DOM
> > (however jQuery handles that). Once again, I'll throw together a demo
> > that has this narrowed down to see if I get any takers. It's worth
> > noting that this works fine in FF2,Opera, and Safari 3 Beta. It's
> > just IE that is giving me fits.
>
> > Josh
>
> > On Aug 7, 10:09 pm, RobG <[EMAIL PROTECTED]> wrote:
>
> > > On Aug 8, 11:56 am, Josh Bush <[EMAIL PROTECTED]> wrote:
>
> > > > Well, I feel stupid. it's not the join that's taking so long, it's
> > > > the $( "really big DOM string with 1,000 rows and 3 columns") that
> > > > takes so dang long on IE7.
>
> > > IE is notoriously slow if you are concatenating using the compound +=
> > > operator.
>
> > > > After all of this rambling, does anyone
> > > > have any options for me to try?
>
> > > You might consider returning HTML from the server rather than trying
> > > stuff on the client.
>
> > > > Sorry, for the self-dialog here.
>
> > > If you care to show your code that does the iteration and the data
> > > structure you are working with, you might get some takers.
>
> > > It seems no one is keen to write the code for you.
>
> > > Some questions that come to mind:
>
> > > - Are you trying to use innerHTML or DOM methods?
>
> > > - Is your data returned as a delimited string or JSON?
>
> > > - Are you trying to build the entire table or just add some rows?
>
> > > - Are there hanlders, classes, attributes or whatever that need to be
> > > added?
>
> > > --
> > > Rob
