 |
 |
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