Develop Reference

Can I make Rails' CookieStore use JSON under the hood?

I feel like it should be obvious doing this from reading the documentation, but maybe somebody can save me some time. We are using Ruby's CookieStore, and we want to share the cookie with another server that is part of our website which is using WCF. We're already b64-decoding the cookie and we are able to validate the signature (by means of sharing the secret token), all of that is great... but of course the session object is marshalled as a Ruby object, and it's not clear what is the best way to proceed. We could probably have the WCF application make a call to Ruby and have it unmarshal the object and write it out as JSON, but that seems like it will add an unnecessary layer of complexity to the WCF server.
What I'd really like to do is maybe subclass CookieStore, so that instead of just b64 encoding the session object, it writes the object to JSON and then b64's it. (And does the reverse on the way back in, of course) That way, the session token is completely portable, I don't have to worry about Ruby version mismatches, etc. But I'm having trouble figuring out where to do that. I thought it would be obvious if I pulled up the source for cookie_store.rb, but it's not (at least not to me). Anybody want to point me in the right direction?
(Anticipating a related objection: Why the hell do we have two separate servers that need to be so intimately coordinated that they share the session cookie? The short answer: Deadlines.)
Update: So from reading the code, I found that when the MessageVerifier class gets initialized, it looks to see if there is an option for :serializer, and if not it uses Marshal by default. There is already a class called JSON that fulfills the same contract, so if I could just pass that in, I'd be golden.
Unfortunately, the initialize function for CookieStore very specifically only grabs the :digest option to pass along as the options to MessageVerifier. I don't see an easy way around this... If I could get it to just pass along that :serializer option to the verifier_for call, then achieving what I want would literally be as simple as adding :serializer => JSON to my session_store.rb.
Update 2: A co-worker found this, which appears to be exactly what I want. I haven't gotten it to work yet, though... getting a (bah-dump) stack overflow. Will update once again if I find anything worthy of note, but I think that link solves my problem.

Why use CakePHP's JsHelper?

I'm just starting with CakePHP and was wondering if someone could explain the true benefit of using its JsHelper over coding regular static jQuery and JS. So far, I don't really see how the helper would make creating scripts easier or faster.

for the same reason I wrote my GoogleMaps Helper ;)
the basic idea is that you can use the same language (php in this case) as the rest of the application and you can pass in any php option arrays and arrays holding data values and the helper is supposed to cake care of it.
it is similar to cakephp as a wrapper for php. it wraps your code and can help keep it dry.
don't get my wrong - i never ever used the js/ajax helper myself.
but I can understand why some want to chose it over writing JS themselves.
in some cases the output can even be more "correct" (if you don't know about the potential problems). for example the IE bug:
if you output {} options yourself and forget to remove the last , it will not run in IE6 etc. that can't happen with the helpers as wrapper - at least it shoudnt ;)
so with the helper it either doesnt run at all or runs as a team of skilled developers designed it to work.
especially for not so skilled developers this is usually a win-win situation: fast and more reliable. you can always start to switch to manual stuff later on (if you see the actual JS output and start to understand it).
also - when any of the js methods need to change for some reason your way of using the helper usually doesn't. if you don't use the abstraction you might find yourself in the need to manually adjust all occurrences.

As like any Helper, the JsHelper is a way to parse stuff into your view in a simplified way. But putting in "raw" JS/jQuery code into your view would work just fine by using $this->Html->scriptBlock for example.
There is not a real benefit I could think of other than if jQuery would ever change the syntax of a specific function, you wouldn't need to adjust your code when using the JsHelper, since the core then needs that update to be implemented, rather than you having to change all your "raw" JS code throughout all of your views.

JsHelper is like scaffolding: comes very handy if you need just the basic stuff, and only the basic stuff. That is, ajaxify a pagination or some elements.
But beyond that, it is better to write your own code, because you will need things as you need them, and not how the helper is aligned by default.
As everything else in a framework: it is a tool. Check your requirements and use the best tools available.

jQuery: Templating data

I have a unique situation where I'm building a site that will call data via AJAX and load it into "containers" (basically just divs styled and arranged according to elements retrieved from the AJAX callback).
I'm not sure how many of these unique container types will be created (styled and rendered) when all is said and done, so I'm looking for a solution that will allow me to store containers in a separate file(s), load them dynamically as they are needed, populate the content, and rendered them on page.
I'm not sure if I should write my own loading/template solution or use an existing JavaScript template engine (e.g.: Pure).
The reason I'm hesitant to use an existing JavaScript template solution is they all seem focused on binding and looping on existing page elements, whereas I'm more concerned with the ability to load-up and binding to dynamic content.

You might want to give jQote a try, it's the most powerful jQuery templating engine as it let's you use scripting inside your templates.
Go check it out, it'll suit your needs, I promise.
http://aefxx.com/jquery-plugins/jqote

After starting with JST, we moved to EJS:
http://embeddedjs.com/
It's more powerful, syntactically simpler, and you can put your templates in different files.
The website is pretty nice too.

I found http://code.google.com/p/trimpath/wiki/JavaScriptTemplates pretty useful for this.

I am planning to use jTemplates for a future project that will need to do something like this, it is very fast and has a nice jQuery plugin

Generate JavaScript objects out of Django Models

I am performing a lot of JavaScript work in the browser and would like to have some of that backend functionality in the front-end. Specifically, it would be nice to have the functions get(), save(), all() and count() available to the client. Additionally, it would be great to have the field list of the model already available in the generated JavaScript object.
Whether the current user can read or write the records is a separate issue I will deal with using Django's authentication. For the time being, retrieval would be a start.
In short, is there code that would generate a JavaScript model from a Django model?
Thanks.

It sounds like you're looking for a complete JavaScript interface to the model and queryset APIs. I can't imagine that this would have ever been done or even be a simple task. Not only would you need to somehow generate JavaScript instances of models (much more than JSON serialisation provides, since you also want the methods) but you'd need to expose a web service that can handle every kind of DB-API call. I can't even begin to imagine where to start and the security issues may be too numerous to easily overcome.
The alternative (and much simpler) approach would be to use one of the various Django REST modules and JSON serialization. You could perform an AJAX GET request on a resource, which can be identified by a series of query parameters that would be equivalent to chained queryset filters. This would return the JSON representation of the model's values. You can then modify the JavaScript object and use an overloaded AJAX POST request to persist the changes back to the server. You wouldn't have access to the model's methods, so that functionality would have to be reimplemented but making any changes to a model should be straightforward enough - This is basically the JavaScript equivalent of using an HTML form to modify data.

You need a data serializer. You can do it with django built in serializers. It is documented on official django site. djangoproject_topics-serialization

I've started a project that I think does exactly what you're looking for. You can find it at
github_bumby_jslib. It currently only supports get(), but I'm hoping to extend this soon. Feel free to contribute patches :)
jslib is a Django application aiming to simplify AJAX integration with your Django projects.

It sounds like you want to JSON encode your object data. See JSON.org for more on the data format.

So it's been a while since I posted the original question and since then there has been a number of developments in Djangoland. Not least of which is a great little library called Django REST Framework. I will be using it on a new project and it's looking pretty kewl.
http://www.django-rest-framework.org

XmlHttpRequest return values

I'm looking for (arguably) the correct way to return data from a XmlHttpRequest. Options I see are:
Plain HTML. Let the request format the data and return it in a usable format.
Advantage: easy to consume by the calling page.Disadvantage: Very rigid, stuck with a fixed layout.
XML. Let the request return XML, format it using XSLT on the calling page.Advantage: the requested service is easily consumed by other sources.Disadvantage: Is browser support for XSLT good enough?
JSON. Let the request return JSON, consume it using javascript, render HTML accordingly.Advantage: easier to 'OO-ify' the javascript making the request. Disadvantage: Probably not as easy to use as the previous two options.
I've also thought about going for option one while abstracting the view logic in the called service in such a way that switching in and out different layouts would be trivial. Personally I think this option is the best out of three, for compatibility reasons.
While typing this, I got another insight. Would it be a good idea to allow all three response formats, based on a parameter added to the request?

If you're looking for a quick solution that should work with most available frameworks, I'd go for JSON. It's easy to start with and works.
If you're trying to build a larger application that you're going to extend (in terms of size or maybe your own API for 3rd party extensions) I'd go for XML. You could write a proxy to provide the information in JSON or HTML too, but having XML as the main source is definitly worth the time and effort while building the app.
Like #John Topley said: it depends.

I'd agree with John Topley - it depends on the application. There's a good article on quirksmode that discusses the advantages and disadvantages of each format that you might want to read: http://www.quirksmode.org/blog/archives/2005/12/the_ajax_respon.html

I think this sort of depends on the level of "ajaxyness" your app is going to have. If your front end is a "rich client", al'a gmail, I'd go with the JSON solution, as you'd have to solve the problem of having client side view generation anyway. If you're using ajax sparingly, to provide simple messages to the user, update a few fields now and then, etc, then I'd go with option 1, since most of your view logic is already on the server.

I think trying to use XmlHttpRequest will be a huge headache, unless its the type of headache you don't mind - to do it properly you're almost reinventing the wheel. Then again, people like to reinvent wheels in their spare time, just to say, "Hey, I did it". Not me...
I would get a framework like prototype or Extjs, that has alot of data loading functions built in for XML and JSON, plus you'll get more predictable results, as the frameworks have event handlers to make sure your XmlHttpRequest succeeded or failed. Plus you get support for all the various browsers.

Different response format shouldn't be difficult to produce.
JSON works best for me, i like to keep OO in js, and don't know how to parse XML well :)