I attached the app as it stands now.  There's something wrong w/ the regex
matching in catscrape.php so only some of the images are coming through.

A bit more background info:

Someone said 'it's not that much data'.  Indeed it isn't, but that is
because I intentionally gave myself an extremely simple data set to
build/test with.  I'd anticipate more complex data sets in the future.

The .csv files are not generated automatically, we have a product called
CollectionHQ that produces reports based on monthly data dumps from our
ILS.  I was planning to create a folder that the people who run these
reports can simply save the csv files to, and then the web app would just
work without them having to think about it.

A bit of a side note, but I actually was taking the JSON approach briefly
and it was working on my MAMP but for some reason I couldn't get
json_encode() going on the server at work.  I fiddled around w/ the .ini
file a little while thinking I might need to do something there, got bored,
and decided to take a different approach.

Also: should I be sweating the fact that basically every time someone
mouses over one of these boxes they are hitting our library catalog with a
query?  It struck me that this might be unwise.  But I don't know either
way.

Thanks all.  Do with this what you will, even if that is nothing.  Just
following the conversation has been enlightening.

Nate

On Tue, Dec 6, 2011 at 7:27 AM, Erik Hatcher <[log in to unmask]> wrote:

> Again, with jrock... I was replying to the general "Ajax requests
> returning HTML is outdated" theme, not to Nate's actual application.
>
> Certainly returning objects as code or data to a component (like, say,
> SIMILE Timeline) is a reasonable use of data coming back from Ajax
> requests, and covered in my "it depends" response :)
>
> A defender of the old?  Only in as much as the old is simpler, cleaner,
> and leaner than all the new wheels being invented.  I'm pragmatic, not
> dogmatic.
>
>        Erik
>
>
> On Dec 6, 2011, at 09:34 , Godmar Back wrote:
>
> > On Tue, Dec 6, 2011 at 8:38 AM, Erik Hatcher <[log in to unmask]>
> wrote:
> >
> >> I'm with jrock on this one.   But maybe I'm a luddite that didn't get
> the
> >> memo either (but I am credited for being one of the instrumental folks
> in
> >> the Ajax world, heh - in one or more of the Ajax books out there, us old
> >> timers called it "remote scripting").
> >>
> >>
> > On the in-jest rhetorical front, I'm wondering if referring to oneself as
> > oldtimer helps in defending against insinuations that opposing
> > technological change makes one a defender of the old ;-)
> >
> > But:
> >
> >
> >> What I hate hate hate about seeing JSON being returned from a server for
> >> the browser to generate the view is stuff like:
> >>
> >>  string = "<div>" + some_data_from_JSON + "</div>";
> >>
> >> That embodies everything that is wrong about Ajax + JSON.
> >>
> >>
> > That's exactly why you use new libraries such as knockout.js, to avoid
> just
> > that. Client-side template engines with automatic data-bindings.
> >
> > Alternatively, AJAX frameworks use JSON and then interpret the returned
> > objects as code. Take a look at the client/server traffic produced by ZK,
> > for instance.
> >
> >
> >> As Jonathan said, the server is already generating dynamic HTML... why
> >> have it return
> >
> >
> > It isn't. There is no already generating anything server, it's a new app
> > Nate is writing. (Unless you count his work of the past two days). The
> > dynamic HTML he's generating is heavily tailored to his JS. There's
> > extremely tight coupling, which now exists across multiple files written
> in
> > multiple languages. Simply avoidable bad software engineering. That's not
> > even making the computational cost argument that avoiding template
> > processing on the server is cheaper. And with respect to Jonathan's
> > argument of degradation, a degraded version of his app (presumably) would
> > use <table> - or something like that, it'd look nothing like what's he
> > showed us yesterday.
> >
> > Heh - the proof of the pudding is in the eating. Why don't we create 2
> > versions of Nate's app, one with mixed server/client - like the one he's
> > completing now, and I create the client-side based one, and then we
> compare
> > side by side?  I'll work with Nate on that.
> >
> >  - Godmar
> >
> > [ I hope it's ok to snip off the rest of the email trail in my reply. ]
>



-- 
Nate Hill
[log in to unmask]
http://www.natehill.net