[Tag Library] RailsHelpers

[Louis]

What is it?

• Attached is an adaptation of the port of RoR's JavascriptHelpers (​http://pylonshq.com/project/pylons/browser/RailsHelpers) by Ben Bangert to Django tag library.

• It also includes port of Eugene's LiveFilter(dojo) to prototype (DelayedObserver in observer.js).

Usage

{% rails function_name (arg1,arg2,kwarg1=3,...) %}

        or
    
{% rails function_name %}
arg1,arg2,
arg3,
kwarg1=value1,
kwarg2=value2,
 ...
{% endrails %}

Usage Examples

{% load railshelper %}

{% rails link_to_function ("Greeing", "alert('Hello World')") %}

{% rails link_to_remote %}
"Delete this post", 
{'update':"posts",'url':"./destroy"}
{% endrails %}

{% rails observe_form %}
"searchform",
url='?format=ahah', 
update='results',
delay=0.3,
method='get',
complete="SEL.setup('product_list');",
{% endrails %}

Issues

• Used exec to do the parameter parsing. So people may not like it, but this was the quickest way I could think of. External parameter is exec-ed only within a function argument:

  def argparser(*args, **kws):
      return args, kws
  exec("args, kws=argparser("+param+")")
  

  I could not think of any malicious thing to do in function argument but probably there are many. Please let me know.

• Easily modifiable to render passed parameter as django template.

• Tested only "link_to_remote", "observe_form" in real web browser (IE, FF, Opera).

[ian@…]

Hi.

I was just wondering why you need to have everything prefixed with 'rails'
wouldn't it make more sense to just write

{% observe_form %}
"searchform",
url='?format=ahah', 
update='results',
delay=0.3,
method='get',
complete="SEL.setup('product_list');",
{% endobserve_form %}

?

[Louis]

Changed in that way. I was lazy to get the list of all the rails helper functions. There were 62. Modified version attached

[Louis]

Changed as Ian suggested.

[hugo]

From the discussion on the list and IRC I would say that many devs would be much more comfortable with JS libs based on either Dojo or possibly MochiKit (since there now is a scrpt.aculo.us port to MochiKit, it will have widgests and stuff on par with Dojo in the next version, so it might again be an option again), then with prototype.js, which namespace-clutter and global-objects-prototype-hacking is frowned upon. And I think there is already some work on using Dojo in the Admin in magic-removal. So I think instead of porting Eugenes stuff from Dojo to prototype, porting the other stuff from prototype to Dojo would be much better and would get much better acceptance (I myself will definitely be -1 on any prototype.js usage, +1 on Mochikit and at least +0, maybe +1 on Dojo).

[akaihola <antti.kaihola@…>]

Perhaps a link to this ticket from the AJAX and Django wiki page would be appropriate?

[Louis]

Hi hugo, I put it here because there was a request for sharing the code. There is no intention of proposing this as the Django Ajax toolkit. I used this place as a Django public code sharing site, which probably was a bit of misuse. Maybe we can have a wiki page for those purposes? Anyway, I encourage you guys to discuss hard and think hard to come up with a really easy to use and lightweight ajax toolkit for Django better than RoR's. I'm looking forward to it.

I tried Qooxdoo, Dojo and read RoR book and decided that I want to try these helpers. I have to enphasize that most of the work (99% I would say) is done by Ben Bangert (and RoR + prototype guys). I only wrote a small adaptor tag. Nice thing about those helpers is that there is a whole chapter in a book explaining how to use them. Really helpful for ajax beginners like me.

Qooxdoo has the nicest set of widget but it's too heavy and doesn't seem to be geared toward ajax. Dojo is also nice but is also a bit heavy and it's a moving target. So far, Prototype had the right combination of lightness, stableness and usefulness for me. I briefly looked at MochiKit, it's nice to be pythonic but I couldn't find handy functions corresponding to Ajax.Updater, Form.Serialize, Form.TimedObserver, Form.EventObserver which are in prototype. Probably intended use is different. For data oriented communication(json) and client side dom construction, MochiKit is the best, but for HTML oriented communication(ahah) and controller only client (no model in client) prototype seems to be more suitable.

[hugo]

Best way to share code would be to put up a page in the wiki (since everybody can create new pages). Just link it to the Ajax page that's already there and attach your code to the new page (and put documentation into that page, of course). The ticket system should be kept for defect tracking and patch management.