Needz moar ajax by bensonk. Forum: Suggestions.
administrator 328 posts 2007-12-11 04:49:40 |
I don't know how hard this would be, but it'd be pretty flippin' sweet to have the forum page check and see if it needs to add posts to a thread or whatever. Ajax ftw? |
administrator 879 posts 2007-12-11 13:59:02 |
Yes indeed. Also, in-place editing and in-place posting, like Digg has. |
user 326 posts 2007-12-11 15:44:38 |
just, don't use XML, and don't call it ajax... call it ajas (the 's' is for "Stuff") |
administrator 879 posts 2007-12-11 17:27:17 |
That's what I do. XML is nice and all, but I can't be bothered making up a standard or an API that only my scripts are going to use. Now, if it was modular or extensible, that'd be something else... |
administrator 328 posts 2007-12-11 18:18:08 |
I'm sorry, but I think at this point ajax has been redefined by popular use to mean "getting content on the fly via javascript". It bothers me too, but honestly if I said, "Needs moar Asyncrhonous Javascript" fewer people would understand what I meant. So, I go with the popular usage, because language is, after all, about communicating. Also, there's nothing wrong with XML. Personally I'd use JSON, but that's a personal decision. |
administrator 84 posts 2007-12-11 19:53:04 |
It bothers me too, but honestly if I said, "Needs moar Asyncrhonous Javascript" fewer people would understand what I meant.So say AJAS like WokTiny said. That should get the meaning across clearly enough. I don't particularly like the idea of forums auto-updating without reload. It seems very un-Web-like. Except for things that are naturally dynamic and ever-changing (clocks, for instance), and except for special views of data (like digg spy, which isn't digg's home page), I don't think Web pages should change on their own after being loaded. I also don't even want to think about what it would do to server load. Has any major forum ever done this? |
user 326 posts 2007-12-11 22:41:16 |
I've not been on one that did. you could have it be event driven, say... buttonclick... this would actually reduce bandwidth use, but might not fulfill the intent of the request, which seems like it could turn the board into a chatroom. |
administrator 84 posts 2007-12-12 02:26:42 |
Meh. The bandwidth savings over just pressing 'reload' don't really seem worth the extra maintenance effort. |
user 326 posts 2007-12-12 03:08:49 |
web1.0 ftw! actually, I don't disagree, I just thought it would be fun to say "web1.0" if we wanted an actively updating conversation, we'd get on irc.freenode.net#decorum ircftw! |
administrator 328 posts 2007-12-12 03:53:55 |
*shrug* Alright. Just a thought. |
administrator 879 posts 2007-12-13 09:40:39 |
Meh. The bandwidth savings over just pressing 'reload' don't really seem worth the extra maintenance effort. You have never experienced the pure joy of dial-up or GPRS, I can tell. |
user 326 posts 2007-12-13 13:49:50 |
You have never experienced the pure joy of dial-up or GPRS, I can tell. Ajax on a phone!? I can't figure out why my bluetooth enabled blackberry refuses to give my laptop access to its data connection. I bet it's so the phone company can sell more aircards, as though a data plan wasn't expensive enough. |
administrator 879 posts 2007-12-13 15:30:51 |
I was going to say that I have a laptop card for UMTS/GPRS (which falls back to GPRS all too often), but evidently you already know that these exist. ;) |
user 50 posts 2007-12-13 19:56:28 |
Ok, before another clueless person starts defining what Ajax (please, damnit, not AJAX) is, why not look at the article where the term was first introduced? http://blog.jjg.net/weblog/2005/02/ajax.html That's right, it's a word that's not quite 3 years old, and it's not really supposed to be an acronym. Ajax is just going beyond the usual mindset of what a website should be like. That said, an actual useful Ajax feature would be to Ajaxify the post submission. So when you click 'submit', it updates the forum without refreshing. |
administrator 879 posts 2007-12-13 20:16:41 |
Yes indeed. Also, in-place editing and in-place posting, like Digg has. |
user 326 posts 2007-12-13 21:23:57 |
Ok, before another clueless person starts defining what Ajax (please, damnit, not AJAX) is, why not look at the article where the term was first introduced? It must be frustrating to see words evolve at internet speed. Let's look at the essay that article refers to: Defining Ajax That's what it meant in Feb'05. Today, the interweb0sphere community has gotten a hold of it, and made it its own. Does this change the meaning of the term? Perhaps. Does it really matter? Maybe. Still, to me, word or acronym, AJAX is supposed to be capitalized, and used for cleaning. AJAS, is my way of picking fun at a buzz-word. |
administrator 328 posts 2007-12-13 23:10:04 |
We could argue about natural language semantics all day and get nowhere. If we're going to do that, could we please move the thread to the Debate forum where people can happily ignore it? |
user 50 posts 2007-12-14 22:16:56 |
Well, we're debating a suggestion! In a way. Also, for people who actually know how to use Ajax, it still means the same thing it meant in Feb'05. If you look carefully at it, that's still how developers do, or should do, things. Besides, many of the ideas have been around since the late 90s, where they used hidden iframes to get data from the server. |
user 326 posts 2007-12-14 22:32:02 |
I remember the iframe trick, I always thought that was clever. It's nice to have a function for it now. |
administrator 328 posts 2007-12-14 22:53:15 |
Hooray for asynchronous communication! |
user 347 posts 2007-12-16 16:10:00 |
So, your claim is that AJAX is a backronym, huh? |
user 347 posts 2007-12-16 16:11:18 |
Also, if you don't get what XML is for, you're not using it correctly. :p |
user 50 posts 2007-12-16 18:50:57 |
What do you mean "if I don't get what XML is for", I know what it's for, and it should not be for moving data asynchronously from the server to the client. |
administrator 879 posts 2007-12-18 11:20:49 |
It's a figure of speech that I don't think eitje addressed at you. Like "XML is like violence; if it doesn't work, you're not using enough." A problem with XML is that (like amazingly many technologies with "X" in their acronyms) it has received a second meaning as a marketing buzzword, which means an application becomes "cool" by using XML. Needless to say, choosing technologies based on the coolness of their names is Pointy-Haired-Boss-style. When you need to communicate data and are not sure whether or not to use XML, you should usually just ask these questions: "How many modules will need to read this data", "how many modules will generate this" and "how many different people are writing them". If you are transmitting information one-off between two very closely related programs, avoid wasting time on XML. It gets different as soon as the same data will be read by more than one module. If they use different information from it, or have to implement their own parser each, you can save time by using XML. If the design is modular, so other people will be writing their own parser modules, you should definitely use XML. It's a form of standardizing, not a technology. You only need to standardize things that will be done routinely. (This entire rant is probably redundant as everyone here knows it. And yet.) |
administrator 328 posts 2007-12-18 19:34:03 |
I agree with Arancaytar. XML is an incredibly useful thing. Here are some good examples: RSS/Atom -- Machine readable blogs! How cool is that? SOAP -- An XML-RPC style API which can be relatively easily spoken in nearly any language. This allows major interop functionality. Arbitrary Formats -- You can write your own XML schema that can be validated programatically. Then, you can publish data in a machine-readable way, and people can hack teh mad scripts that consume your data. XML is overused and too "popular" now, but it did become cool for a reason. Before it became a buzword, saying your app used XML data meant that customers could expect to be able to interact with your app's documents from their own scripts. That's a big boon to a place that employs competent programmers. |
user 50 posts 2007-12-18 20:09:26 |
Many of XML's advantages as a near ubiquitous format make it a good choice when communicating between machines and programs. However, there's not much inherent about XML itself that makes it a good choice. Since, somewhat, it was based off HTML, XML-derived languages are great for user-interface markups. However, there is a reason why other formats like YAML and JSON have gained some headway in the data format field. XML was nice for user interfaces since it was primarily people who had to write, edit, and debug the code. On the other hand, XML is mostly machine-generated today. While enclosing content and layout in tags might be nice for people, it is an unnecessary burden for computers. |
administrator 879 posts 2007-12-19 08:32:52 |
Is character comparison really that expensive? |
administrator 328 posts 2007-12-20 02:50:33 |
I will admit that XML's verbosity with tag naming is space/bandwidth expensive, but I think it gives a flexibility that is worthwhile in most cases. You don't generally find xml files that are "too big" because the tags take up too many bytes. If you get to that point, json and yaml are probably not acceptable alternatives either. You should probably consider designing your own binary file format. I could be wrong, but that's what comes to mind for me. |
user 641 posts 2007-12-20 06:10:17 |
A simple change such as using a single character to close tags would save a lot of space without reducing flexibility. For example: <foo><bar></bar><baz></baz></foo> could become <foo><bar>><baz>>> which is quite a bit shorter. |
user 641 posts 2007-12-20 06:12:16 |
Actually my example sucks, but pretend it doesn't. Like, pretend that there is actually some content inside the <bar> and <baz> tags. |
administrator 328 posts 2007-12-20 06:30:34 |
Sure, but that makes it less descriptive. </foo> is very clearly the end of foo. ">" is sort of context-sensitive. The </foo> makes it a lot easier to write a naive parser. Particularly handy if you just want to hack out a simple perl script that extracts simple bits of data from an XML file. |
administrator 879 posts 2007-12-20 08:56:09 |
Precisely. XML is a highly restrictive/redundant format in order to make it easy to read it without ambiguity. Makes sense too - as a programmer I would prefer to be stuck with fixing a generator that spewed out invalid XML, to fixing a parser that interpreted a certain variant of "Quirk XML" badly. What it's not good for is a database backend. Sadly, I've seen it used for that. |
user 326 posts 2007-12-20 14:47:36 |
For me, and my uses inside the scope of ajax, I've found that the use of XML is far more computationally expensive than JSON; so I use JSON. |
administrator 328 posts 2007-12-20 21:33:22 |
XML is terrible as a db backend. That's a classic example of XML being used for things it's not good at. As far as JSON vs XML for asynchronous data transfer in webapps, JSON makes a lot more sense. This is becuase it's JavaScript object notation. One can expect JavaScript to be able to parse it fast. It's great for serializing data for import into JavaScript. I wouldn't like to see it replace XML, because it's not as universally useful. It's harder to write a simple parser to pull specific data out of JSON than XML, and it's harder to debug a JSON problem than an XML problem. JSON also consumes less bandwidth in transit than XML. So, for async JS stuff I always go with JSON, but I don't use JSON for much else. For generic data encoding, XML is supremely useful. It's easy to write simple parsers to pull out specific bits. It's easy to understand what's going on before you've written your parser. Another useful requirement is "if it's not valid, drop it on the floor", which is built in to XML. XML really has a lot of qualities that are desirable in a universal data format. Also, XSLT is FTW. |
administrator 879 posts 2007-12-21 11:55:45 |
Can we generalize to a rule of thumb saying "if an XML file is stored in the same location for longer than the lifetime of a cache, your data structure is flawed"? Or possibly "an XML file that is read by no other module than the one that wrote it should not be an XML file"? |
administrator 328 posts 2007-12-22 07:59:23 |
I have a better rule of thumb: Don't be a fucking moron. It works for everyting! Your rule of thumb is better for people who don't know how to follow mine, though. I like your second one better -- XSLTs are xml files that describe a transform on another xml file, and they can hang around for a long time. But, they're generally created in an editor of some sort, and read by another, so the rule works. |
user 347 posts 2007-12-31 14:32:36 |
JSON is really just an example of a language-specific RPC, so you'll be using it where no other apps need access to your particular data stream. also, an XML document's size increase due to tags is inconsequential - compression handles the redundancy well. finally, depending on how complex your database is, XML will sometimes be a better way to store your data than, say, with CSVs or Access. XML is only terrible at things when it's misused. |
administrator 328 posts 2007-12-31 18:48:46 |
I agree with your first two points completely. Can you give us an example in which a single application uses the database and XML would be preferable over sqlite or some other SQL engine? |
user 326 posts 2007-12-31 22:37:33 |
This is the thread that spawned an IRC legend. I am amazed that it lives on. |
user 641 posts 2008-01-01 01:15:17 |
Well, the thread has turned into a debate about XML, and I think the debate about whether to use XML will last as long as XML itself. |
administrator 328 posts 2008-01-01 22:54:25 |
That seems likely, yes. |
