On Thu, Dec 8, 2011 at 9:11 AM, Godmar Back wrote:
If we tell newbies (no offense meant by that term) that AJAX means
"send a request and then insert a chunk of HTML in your DOM," we're
short-changing their view of the type of Rich Internet Application
(RIA) AJAX today is equated with.
sure, f
On 12/8/2011 11:19 AM, Robert Sanderson wrote:
If you blindly include whatever you get back directly into the page,
it might include either badly performing, out of date, or potentially
malicious
For the last year or two, we have done apps that return HTML.
I don't have the energy to jump into this, and although I think that
the HTML method is more efficient (at least in our case) and possibly
more flexible, I don't have hard data to back that up.
Cary
On Thu, Dec 8, 2011 at 9:24 AM, Bri
I definitely don't think one pattern is going to cover every possible scenario.
And I agree that we shouldn't be dogmatically telling people that one practice
is always good and another is always bad.
But in my experience, writing code to do the same task in two different places
(in two diff
On Thu, Dec 8, 2011 at 12:24 PM, Brian Tingle
wrote:
> most sense for what you are trying to do. And for things that work that
> way now, I don't see a need to rush and change it all to JSONP callbacks
> because of some vague security concern.
My comment wasn't security-related. Also, I wasn't t
On Thu, Dec 8, 2011 at 9:11 AM, Godmar Back wrote:
>
> Let me give you an example for why returning HTML is a difficult
> approach, to say the least, when it comes to rich AJAX applications. I
> had in my argument referred to a trend, connected to increasing
> richness and interactivity in AJAX a
On Thu, Dec 8, 2011 at 11:14 AM, BRIAN TINGLE
wrote:
> returning JSONP is the the cool hipster way to go (well, not hipster cool
> anymore, but the hipsters were doing it before it went mainstream), but I'm
> not convinced it is inherently a problem to return HTML for use in "AJAX"
> type devel
Maybe I fully misunderstood this conversation; but I was assuming a scenario
where the developer has full control of the script and the server.
> If you blindly include whatever you get back directly into the page,
> it might include either badly performing, out of date, or potentially
> maliciou
On Thu, Dec 8, 2011 at 9:14 AM, BRIAN TINGLE
wrote:
> On Dec 7, 2011, at 2:19 PM, Robert Sanderson wrote:
>> * Lax Security -- It's easier to get into trouble when you're simply
>> inlining HTML received, compared to building the elements. Getting
>> into the same bad habits as SQL injection. It
returning JSONP is the the cool hipster way to go (well, not hipster cool
anymore, but the hipsters were doing it before it went mainstream), but I'm not
convinced it is inherently a problem to return HTML for use in "AJAX" type
development in a non--ironic-retro way.
On Dec 7, 2011, at 2:19
On 12/8/2011 9:27 AM, Bill Dueber wrote:
To these I would add:
* Reuse. The call you're making may be providing data that would be useful
in other contexts as well. If you're generating application-specific html,
that can't happen.
Well, if the other contexts are Javascript, and your HTML is n
wick, NJ 08901
http://rucore.libraries.rutgers.edu/
- Original Message -
From: "Esme Cowles"
To: CODE4LIB@LISTSERV.ND.EDU
Sent: Thursday, December 8, 2011 8:57:28 AM
Subject: Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was:
jQuery Ajax request to update a PHP variable)
I'
To these I would add:
* Reuse. The call you're making may be providing data that would be useful
in other contexts as well. If you're generating application-specific html,
that can't happen.
But really, separation of concerns is the biggest one. Having to dig
through both template and code to mak
On Wed, Dec 7, 2011 at 5:02 PM, Nate Vack wrote:
> OK. So we have a fair number of very smart people saying, in essence,
> "it's better to build your HTML in javascript than send it via ajax
> and insert it."
X in AJAX means XML, so if you send XHTML, you're good. :-)
-
From: "Esme Cowles"
To: CODE4LIB@LISTSERV.ND.EDU
Sent: Thursday, December 8, 2011 8:57:28 AM
Subject: Re: [CODE4LIB] Sending html via ajax -vs- building html in js (was:
jQuery Ajax request to update a PHP variable)
I've been following this thread very closely, and find myself t
I've been following this thread very closely, and find myself torn. Doing all
the HTML generation server-side seems like the easiest way to have a single set
of template code that's shared between JS and non-JS paths, reducing complexity
of the overall app, and making graceful degradation easie
> Also, I've thought of a good reason myself: performance. If I'm adding
> an item to a list, it's a better user experience to update the display
> immediately rather than waiting for the server to send back a 200 OK,
> and handle the error or timeout case specially.
While in general I tend toward
Nate,
>From what I hear, these are increasingly common questions.
When the main stack is javascript, it just heightens the questions.
With the resurgence of javascript being used server-side with tools
like Node.js, client-side javascript MVC frameworks, and single-page
applications, lots of diffe
On Wed, Dec 7, 2011 at 4:19 PM, Robert Sanderson wrote:
> * Separation of concerns...
>
> * Lax Security...
>
> * Obfuscation...
Let's say I'm planning to first build a completely functional app with
no javascript at al(*)l, and then use javascript for progressive
enhancement.
In other words, i
Here's some off the top of my head:
* Separation of concerns -- You can keep your server side data
transfer and change the front end easily by working with the
javascript, rather than reworking both.
* Lax Security -- It's easier to get into trouble when you're simply
inlining HTML received, comp
A fair number? Anyone but Godmar?
On 12/7/2011 5:02 PM, Nate Vack wrote:
OK. So we have a fair number of very smart people saying, in essence,
"it's better to build your HTML in javascript than send it via ajax
and insert it."
So, I'm wondering: Why? Is it an issue of data transfer size? Is the
OK. So we have a fair number of very smart people saying, in essence,
"it's better to build your HTML in javascript than send it via ajax
and insert it."
So, I'm wondering: Why? Is it an issue of data transfer size? Is there
a security issue lurking? Is it tedious to bind events to the new /
updat
22 matches
Mail list logo
