Categories
JavaScript

Ajaxy comments

I’ve incorporated editing into the site–both traditional, link-based, and Ajax. I still need to tweak, and I imagine as people use the comments, things will break.

Both types of edits are available for each item, using the philosophy that a person may want to use a traditional edit page over an Ajax editing approach. The hypertext link for editing takes you to the full edit page, where you can also delete the comment. The Ajax approach is accessible through a ‘button’ added to the post using script.

I had planned on pulling my simple custom library for the background functionality, and either using JQuery, or Dean Edwards Base.dom on which to build. However, I’m concerned about the Safari problem with Dean’s library, and I’m not sure that JQuery fits all my needs. What I may end up doing is pulling in Edwards’ library, and creating my own custom intermediate library.

All I’ve done for now is create a singleton where before I had several global functions. The original approach doesn’t impact on performance or cross-browser compatibility, but lots of global variables can cause problems with merged libraries. I’ve also made some attempts at eliminating IE memory links related to removeChild used with elements with assigned event handlers, but this still needs work.

I have one polling operation that checks to see if there are new comments after the page is loaded, and then pulls these in if found. The new comment(s) are added to the end of the list of comments in the page, with a yellow ‘fade’ to signal the addition. I’ve also added an Ajax preview, but not a non-scripted preview. Lots of real issues doing the latter with WordPress. Mayhap someone else has a plugin for it.

Finally, I didn’t incorporate OpenID. I thought about doing this, and had incorporated OpenID for comments via an existing plug-in at one point. However, OpenID is identity, not necessarily trust or ownership. My main interest is identifying the person who just made a comment and perhaps wants to edit typos–that’s it. For now, I’m using a combination of cookies and IP address. It’s not perfect, but it should be relatively safe, and relatively open.

If I had used OpenID, those people who did not want to get one of these, or who write anonymously wouldn’t have been able to edit their comments. Contrary to popular criticism, anonymous comments do have value, at least in this space.

One big problem I ran into, and perhaps I don’t understand XHTML, is that when I created the URL to edit a comment, which uses a traditional GET with two parameters, ala ?action=editcomment&comment=3333, I received a mal-formed XML error with Firefox. The page validated, and also pulled up in every other browser. Did I miss something related to XHTML with this one?

I have a lot more to do with the site, and the underlying libraries, but I’m starting the book this next week, and will have to finish the bits off as I can. I still have my graphics and photo library, and some meta/RDF stuff I want to incorporate. Once the work I’ve published here gets a chance to be decently tested, I’ll look at packaging for other use. It’s not going to be a simple plug-in, but should be able to be packaged.

update

I had forgotten to encode the ampersand in the URL for the link. The validator did not pick it up, because I also forgot that the link wouldn’t show unless the application accessed it with my logged in cookie.

Yes, it was a particularly stupid error on my part. That’s what’s nice about XHTML: it doesn’t hesitate to let you know when you’ve been stupid. Same as anonymous commenters. <smiley />

Categories
JavaScript

Ajax is dead. Not it’s not.

I love how the marketing folks put a spin on things every time there’s an announcement from one of the Players. This time it’s Java’s turn for the RIA space with the introduction of JavaFX. Immediately people are talking about ‘Ajax killer’. It’s no more an Ajax killer than Flash was (actually, Ajax and Flash are quite compatible), or Silverlight.

This one cracked me up:

The advantage Java-connected scripting language has over others, such as Ruby, PHP or Python, is that Java programmers can easily transfer their skills and knowledge. Moving from Java to another language like JavaScript, which is often used for Ajax applications, “is like moving to another foreign land,” Monson-Haefel said.

I used to program in Java before Sun et al bloated it out of recognition. I had no problem working with JavaScript. I guess today’s crop of Java developers isn’t very versatile.

Sun has also said it will open source JavaFX. What does that mean? Microsoft and Adobe are also talking about ‘open sourcing’ select pieces of their infrastructures. Seems to me there’s as many variations of ‘open source’ in this market as there is ice cream flavors at Baskin’s & Robbins.

JavaFX does seem to have a head start into the mobile market, but it’s behind the other players, which are at least on the street. However, it also has a built-in audience, as there is a lot of Java developers. Of course, same could be said about Silverlight and Adobe’s Flex.

I’ve not found, though, that companies that use Java for their applications are the most forward looking and ‘on the edge’ development environments. In my opinion (note I said, ‘in my opinion’), Java is the most conservative web development environment. Web Sphere, nuff said.

One thing for sure: RIA is the hot market this year. Adjust your resumes accordingly.

Categories
JavaScript

Ajax security: FUD or fact?

from_future_import has a post stating that Fortify’s recent Ajax alarm is more FUD than fact. Money quote in this one:

And MOST importantly the exploit is only applicable to JSON that also happens to be valid JavaScript code.

Was it FUD or fact? A bit of both. The benefit of the paper is the fact that unlike other discussions on these issues, it was written in plain English, diagrammed, and not meant to be understood only by insiders. Perhaps if more Ajax developers would adopt the same approach to documenting issues, concerns, and examples, documents such as that given out by Fortify wouldn’t get the audience.

Or we could all use XML, only (she says as she ducks and runs…)

While I was in the neighborhood, I picked up a couple of other links in comments:

Practical CSRF and JSON Security
An ArsTechnica post on the original article.

(Thanks to Michael Bernstein for link)

Categories
JavaScript

Ajax vulnerability

Ajax developers should check out a report on Ajax vulnerabilities in several Ajax libraries, and download the extensive advisory. The advisory details the vulnerabilities, and how to protect against.

It’s always a bit risky to put out such details, but I, as a developer, really appreciate such because it allows me to better understand how to protect against security risks. Much of the discussion of the vulnerabilities in this advisory isn’t necessarily new, but it does cover newer issues, vulnerabilities in popular libraries, as well as overall issues.

Money quote:

An application can be mashup-friendly or it can be secure, but it cannot be both.

Categories
JavaScript

Baseline library

I’ve only downloaded it and started playing, but I like the idea of a JavaScript library based purely on implementing standards. Small and lightweight, Dean Edwards’ base2.DOM provides a good baseline for development without worrying about interesting proprietary extensions and recalcitrant browsers.

Not that I’m naming names.

Edwards’ library does provide support for the older 5.x versions of IE. Those are browsers I won’t support anymore. I realize there are people using version 9 of the Mac OS or other equipment still loaded with the 5.x versions, and that not supporting old browsers limits their access to applications. However, as long as any JavaScript-enabled application has a non-script enabled alternative that provides the same functionality, I’d rather just turn off any script effects for such instead of adding enormous amounts of code to deal with the idiosyncrasies. Thank goodness for the concept of progressive enhancement…and nice, small footprint JS libraries.

As for the Edwards’ self-deprecating reference to base2.DOM not being a documented library, JavaScript libraries don’t have to be documented when they’re small, use meaningful naming standards, and are easy to read. Note to Dojo: this doesn’t mean you.