I spent last weekend adding Spry to one of my web sites. I'm using
Ruby On Rails and prototype with perhaps a bit of
script.aculo.us in
this web site.
What attracted me to Spry is the region and repeat features. Lets us
a table as an example. The basic idea is the page that is sent out
has only the header and a single row. You have to put a div around
the table to define the region. And the data row in the table has a
"repeat" attribute in it. Somewhere you hook a data souce up to the
region. In my case, I went back to my Rails server with a json
request which sprewed out the selected items in a javascript array,
each element being an item.
The initial row has macros like {name} that get expanded to fields in
the items. In my particular case, while a row only has 8 elements
across, there are a lot of things in each td like hidden drop down
lists, links, etc. The work to create a json row is small compared to
the work to create the equivalent html row. What I see attractive
with Spry is it moves the work of creating the html to the browser and
offloads the server. There is just no reason for the server to be
doing that work.
My belief is that ultimately, moving the creation of the html to the
browser is the way of the future. The server serves data. The view
processing will eventually be done in the browser. There is no need
for the server to do hard labor for the view processing.
But I found Spry to be less than stellar. The main biggest issue is
when I have a page with 1800 rows, it takes my Firefox about a half a
minute of dead time to create the page and render it -- during that
time, my whole laptop is dead pretty much with the dreaded spinning
beachball. This half minute is divided into two parts I'm sure. Part
of the time is Spry running creating the 1800 rows. I'll use the term
"fill out" to refer to that process. Then there is the time for
Firefox to actually render the page.
I also found the package to not be very flexible and configurable. It
has a sort feature but it has far fewer features than the tablesort.js
file found on the net.
So, it put me back to "can I do this myself" mode.
A small side trace: I have seen the Rails cast where Ryan creates an
"endless page". My issue with that approach is that instead of one
query, he makes N queries -- one for each page. That seems like it
would add load to the server while I'm trying to take load away from
the server.
It seems like I could leverage prototypes template feature for most of
the work. The main thing I would do different is make one request
(like Spry) but I would only render the first page or two of rows.
Then as the user scrolled, more data would be filled out hopefully
before the user actually got to it.
There are lots of problems to all this. How do you make the scroll
bar act "right"? What do you do when the user does a search within
the page? How do you handle a sort? As you add rows, the width of
the columns may grow which is not expected. etc.
But the essential concept is that all the data would be held as a
javascript object and then the page filled out as it was needed.
So, the question is, has anyone done something like this starting with
Prototype? I sure don't want to recreate the wheel here. Is there
any suggestion of other work that I can look at and build from? Is
there any interest by any of the readers to help out?
Thank you,
pedz