> I couldn't get json_encode() going on the server at work.
This usually means your server is running an older version of PHP. If it's OS is RHEL 5, then you've likely got PHP 5.1.6 installed.
http://php.net/manual/en/function.json-encode.php
json_encode
PHP 5 >= 5.2.0
--Dave
-----------------
David Walker
Library Web Services Manager
California State University
-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Nate Hill
Sent: Tuesday, December 06, 2011 8:18 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] jQuery Ajax request to update a PHP variable
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
|
