RoR Ajax helpers port to Django tags?

[Louis]

Hi,

Has anybody ported RoR's JavascriptHelper functions to Django's tag
library? Just want to make sure before I begin.

Thanks.

[ToddG]

For a head start take a look here:

http://pylonshq.com/project/pylons/browser/RailsHelpers

Pylons being an in-development python "mega" framework (not a fan of
that term!). I don't know anything of licensing or credit issues, but
they're ported from Rails, so... maybe ask Ben over there, he did the
work I believe.

You'd need to Django-ize them but it should still be a big help...

[Louis]

Thanks! It helped a lot. I only had to write small bridging Django tag
to use his Rails Helpers. It saved a lot of time.

-Louis

[the....@gmail.com]

can you share your code? i'd like to take a peek. :P

[Louis]

It's in http://code.djangoproject.com/ticket/1262
.

[Ben Bangert]

For those concerned about the fact that these helpers use ProtoType and
Scriptaculous, it should be noted that Mochikit 1.3 will include
equivalent functionality. This should make it seamless to use Mochikit
instead with no or minimal changes to the helper functions.

There's several people now working on the RailsHelpers package to keep
it up with the Rails version, as well as the unit tests. The one big
thing this package does not include is the Javascript Generator object
used for the very very new Rails feature (only in svn I think) called
Rails Javascript Scripts (or something like that, RJS). Here's an
example:

page.insert_html :bottom, 'list',
content_tag("li", "Fox")
page.visual_effect :highlight, 'list', :duration => 3
page.replace_html 'header',
'RJS Template Test Complete!'

As one can see, it makes AJAX so trivial, you can do a ton of stuff not
knowing Javascript at all. These functions just generate some
Javascript that does the work for you. I would like to have something
similar for use in Python, anyone else interested in helping out on
this?

Since this is just generating Javascript from a function, I see nothing
particularly framework specific in it, so we should all be able to work
together on it. :)

[Ian Holsman]

That sounds like a great idea (working together), and personally I'm
not too hung up about which AJAX library I use, as long as it can do
the job (which most seem too for my simple things)

I like the idea of having one way of doing this across frameworks, it
makes them all simpler to learn and increases the adoption of all of
them.

my only question is how are you planning on setting this up. are you
thinking that each framework should just reference your module, or are
you planning that you put the API glue into your SVN repo as well?
(alongside a turbogears & myghty version I'm guessing)

Louis has already started integrating django with it, and I'm most
concerned that his hard work doesn't get lost.

--I

--
I...@Holsman.net -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909

If everything seems under control, you're not going fast enough. -
Mario Andretti

[Ben Bangert]

I'd think the most reasonable approach would be to have the frameworks
reference the module.

Myghty doesn't require an API, as the names are just imported and
attached to a template global helper object, ie, <%
h.observe_field(.....) %>. TurboGears may likely require a bunch of
API's for the various template languages Buffet support, I don't know
offhand.

For those cases, I'd have no problem including the API glue in the
RailsHelpers repository since it makes little sense to have yet another
package that just contains that API glue.

[Eugene Lazutkin]

Ben Bangert wrote:
> For those concerned about the fact that these helpers use ProtoType and
> Scriptaculous, it should be noted that Mochikit 1.3 will include
> equivalent functionality. This should make it seamless to use Mochikit
> instead with no or minimal changes to the helper functions.

(What I wrote below is not directly related to what you guys were doing
with RoR's Ajax helpers. Thank you for the job well done.)

My only problem with RoR's approach in general regardless of underlying
library is it is very low level. Essentially it is a way to propagate
some events to the server. I am not sure I like the idea of callbacks
for every sneeze. David (of RoR) really dislikes programming client
side, so he moved everything he could server-side. Do we really want to
replicate RoR? I prefer to see more widget-oriented approach.

Saying that I don't see any problem using this approach to augment
legacy apps. It makes perfect sense to do it server-side way:

1) Do something without Ajax.
2) Incrementally add Ajax to different places.

While it reminds me of extending command line utility with GUI dialog
boxes in some places, it works. We have to support this style of Ajax.
But it would be better if we offer something more original and more useful.

Thanks,

Eugene

PS: Just take a look at local apps. While you can draw pixels, track
mouse pointer, and catch keyboard keys, usually it is better to use
stock widgets. This way you can concentrate on core logic of your
application instead of doing somebody else's work.

[Ben Bangert]

Eugene Lazutkin wrote:
> My only problem with RoR's approach in general regardless of underlying
> library is it is very low level. Essentially it is a way to propagate
> some events to the server. I am not sure I like the idea of callbacks
> for every sneeze. David (of RoR) really dislikes programming client
> side, so he moved everything he could server-side. Do we really want to
> replicate RoR? I prefer to see more widget-oriented approach.

I think its actually rather high level, in that you don't really need
to know any Javascript what-so-ever. Obviously not knowing any
Javascript will be a limitation to exactly what you can do, but the
helpers and RJS meet a lot of people's needs with a very minimal amount
of additional learning required to utilize it.

The stuff done with it also is mainly geared towards stuff that
requires server participation to an extent. If you know Javascript
well, you can reduce the traffic in the AJAX request, but you still
need some data.

Take as example, a button that when clicked, adds something to your
shopping cart, swaps in the cart element HTML, and fades it in or
something snazzy. You will need to do an AJAX request to attempt to add
it, and receive acknowledgment.

If you know Javascript, you could just keep everything client-side, and
toggle behavior based on a very simple Success/Failed response on the
cart add.

If you don't know Javascript, but use Rails style helpers, you'd
instead just update the cart element with the reply from the server,
etc.

So you send slightly more data over the line, but very little knowledge
of Javascript is needed.

However, if you're building a "real" interactive AJAX application, you
will no doubt need to know Javascript. The RoR helpers won't help you
as they hit a very specific range of use-cases common in many webapps.

> While it reminds me of extending command line utility with GUI dialog
> boxes in some places, it works. We have to support this style of Ajax.
> But it would be better if we offer something more original and more useful.

I agree entirely, though usually once you get too far past the basic
cases the RoR helpers account for the "genericness" starts to break
down. The common problem with widgets is that you'll spend as much time
customizing them for your need, as you would writing one that solves
your need from scratch.

If the widget itself can be broken down into the generic portions, then
you'd be able to quickly build custom widgets that do exactly what you
want. That'd be ideal I think, though I'm not sure what these generic
portions would look like...

- Ben

[Eugene Lazutkin]

Ben Bangert wrote:
>
> I think its actually rather high level, in that you don't really need
> to know any Javascript what-so-ever. Obviously not knowing any
> Javascript will be a limitation to exactly what you can do, but the
> helpers and RJS meet a lot of people's needs with a very minimal amount
> of additional learning required to utilize it.

A lot of people who use list boxes, radio buttons, and other widgets
don't know X11/Win32 graphics APIs and event systems. My point is there
are many ways to minimize exposure to js.

Of course it is debatable that the absence of knowledge is The Good
Thing (tm). ;-) In many cases it is used to dumb down the programming
tools for dumb down programmers to create dumb down applications.
Personally I prefer to learn the proper way using proper tools. :-)

> If you don't know Javascript, but use Rails style helpers, you'd
> instead just update the cart element with the reply from the server,
> etc.

"If your only tool is a hammer, all your problems will look like nails."
This is what I call "a low-level approach" --- using a crutch instead of
building a proper web application.

Thanks,

Eugene

[Ben Bangert]

Eugene Lazutkin wrote:
> A lot of people who use list boxes, radio buttons, and other widgets
> don't know X11/Win32 graphics APIs and event systems. My point is there
> are many ways to minimize exposure to js.

Agreed, I have yet to see anyone come up with clear cases for widgets
within web programming. Zope has some, and they're pretty decent I
believe, but there's a bit of a learning curve as usual.

AJAX web widgets is a bit different than just putting list boxes and
radio buttons up, its a whole infrastructure thing with backend
responses, etc. Minor deviations in customization of the web widget can
easily involve modifying server-side code to handle the interaction,
etc.

It seems like AJAX web widgets is very different from X11/Win32 graphic
API's as far as I can tell.

The real question is, are Django people happy to wait while some new,
super-neat, powerful, widget system is developed using AJAX; or would
Django coders like to use something as soon as possible?

I'd suggest taking both approaches, RailsHelpers and something like RJS
now; new thing when its ready. The amount of effort required for
something like RJS is pretty minimal, for an AJAX widget system there
will likely be extensive planning, meetings, etc. As I plan on doing
something like the RJS stuff anyways, Django need only have a single
person who implements it for Django (like Louis did for the
RailsHelpers)

> Of course it is debatable that the absence of knowledge is The Good
> Thing (tm). ;-) In many cases it is used to dumb down the programming
> tools for dumb down programmers to create dumb down applications.
> Personally I prefer to learn the proper way using proper tools. :-)

Sure, it goes both ways. In the case of RJS and RailsHelpers, I think
the philosophy is, if you just want to use AJAX to swap some elements
or something, that in itself is not enough reason to invest hours into
being a Javascript programmer. There's a lot of tools up and down the
toolchain of web programming, I seriously doubt any of us are
completely proficient at each and every level of it.

> "If your only tool is a hammer, all your problems will look like nails."
> This is what I call "a low-level approach" --- using a crutch instead of
> building a proper web application.

Alternatively, I think RailsHelpers is meant purely for hitting nails.
You can get creative and smash in some screws without much harm, but
obviously you'll need a better tool if your needs are larger.

Anyways, the RailsHelpers are mostly done. The RJS/Javascript Generator
won't take me more than an hour or two to port, then its a matter of
figuring out good practices for using it since our setup is rather
different than Rails. Anyone interested in taking a look at this, and
figuring out how to slot it into Django, feel free to contact me.

Cheers,
Ben

[Eugene Lazutkin]

Ben Bangert wrote:
> Eugene Lazutkin wrote:
>> A lot of people who use list boxes, radio buttons, and other widgets
>> don't know X11/Win32 graphics APIs and event systems. My point is there
>> are many ways to minimize exposure to js.
>
> Agreed, I have yet to see anyone come up with clear cases for widgets
> within web programming. Zope has some, and they're pretty decent I
> believe, but there's a bit of a learning curve as usual.

Look at Dojo. I did a small how-to on creating widgets here:
http://lazutkin.com/blog/2005/dec/24/live-filtering/. Some people, who
read it, missed my point: it was not about Ajax functionality (you can
do it with any library), it was about creation of self-contained generic
widgets, which don't pollute your html code with unnecessary garbage.
You can download LiveFilter.js (link in the tutorial) and use it
literally without modifications with practically any form in your
project to make it "live". All you have to do is to implement a
relatively simple view to support it on Django's side (example
included). No JavaScript knowledge is involved in actual use. But if you
want to be fancy, you can create your own widgets, and reuse them across
projects. Additional bonus (useful for medium-to-large projects): such
widgets provide a clean separation between client-side programmers,
server-side programmers, and (most importantly) designers --- everybody
is doing stuff they are familiar with.

As soon as I deal with never-ending stuff on my plate (sigh), I plan to
bundle some widgets and corresponding generic views to make it super
simple to use for simple projects.

> I'd suggest taking both approaches, RailsHelpers and something like RJS
> now; new thing when its ready. The amount of effort required for
> something like RJS is pretty minimal, for an AJAX widget system there
> will likely be extensive planning, meetings, etc. As I plan on doing
> something like the RJS stuff anyways, Django need only have a single
> person who implements it for Django (like Louis did for the
> RailsHelpers)

Agreed. "Let 1000 flowers bloom" (c) Chairman Mao. Like I said before
you did fantastic work porting this stuff over to Django.

Thanks,

Eugene

[Ben Bangert]

Louis that made the Django adaptation stuff, I just ported it from
Ruby. :)

The RJS style stuff is going to take some thinking about the best style
of usage within Django, any volunteers? I'll be happy to go over the
details.

- Ben

[Eugene Lazutkin]

Ben Bangert wrote:
> Louis that made the Django adaptation stuff, I just ported it from
> Ruby. :)

In this case I want to see the packaging.

Thanks,

Eugene

[Max Battcher]

Eugene Lazutkin wrote:
> Look at Dojo. I did a small how-to on creating widgets here:
> http://lazutkin.com/blog/2005/dec/24/live-filtering/. Some people, who
> read it, missed my point: it was not about Ajax functionality (you can
> do it with any library), it was about creation of self-contained generic
> widgets, which don't pollute your html code with unnecessary garbage.
> You can download LiveFilter.js (link in the tutorial) and use it
> literally without modifications with practically any form in your
> project to make it "live". All you have to do is to implement a
> relatively simple view to support it on Django's side (example
> included). No JavaScript knowledge is involved in actual use. But if you
> want to be fancy, you can create your own widgets, and reuse them across
> projects. Additional bonus (useful for medium-to-large projects): such
> widgets provide a clean separation between client-side programmers,
> server-side programmers, and (most importantly) designers --- everybody
> is doing stuff they are familiar with.

Nice example. I think it points towards the basic direction that a
Django AJAX framework should take. Client-side code should be in
template-vars (ContextProcessor if needed) and template-tags connected
to client-side "views" in .js files. Server-side code should consist of
simple RESTful views (there are several existing generic views that
could easily be used for that task, and there are probably some good
ideas out there for other good AJAX-friendly generic views).

I think it points to another idea I think would be nice to see in
Django: "smart views" (actually, it would really just be a smart
template loader and a single additional piece of information needed to
pass to the generic views, in order to pass to the template loader).
There are several cases where you might have the same view (all of the X
objects, details of the X object with id=somenumber, ...), but different
output formats based on circumstance. You could let the template loader
handle the format... I would use the file extension. For example, you
could have your HTML templates as myobject_list.html and your RSS
template for the same object as myobject_list.rss. Then you could just
add the proper format setting to your info_dict for the generic
object_list view and let it choose the proper one. (Assuming for
whatever reason you don't want to use the existing RSS Framework, which
works well, but this is just the first example to come to mind.)
Another example would then be the "simple" views for use in AJAX/REST
projects (using .ajax or .rest or .js or .raw.xml depending on the
content type, perhaps).

You could even design your URLs to take advantage of the format context
*if you wanted*. Something like (using an object_detail-style example
this time):

``r'^mysite/coolthings/(?P<object_id>\d+)(?P<output_format>\.\w+)?/?'``

That would match things like:
/mysite/coolthings/1/ (The typical HTML view for a Django site)
/mysite/coolthings/1.xml

Overall it would be subtle "opt-in" and shouldn't affect the current
behavior (ie, if the generic view+template loader doesn't know the
expected output format, default gracefully to the default in settings.py).

Anyone else see it as useful?

--
--Max Battcher--
http://www.worldmaker.net/
"History bleeds for tomorrow / for us to realize and never more follow
blind" --Machinae Supremacy, Deus Ex Machinae, Title Track

[Louis]

Hi,

I just noticed there's a lot of postings on this thread.

Ian: I only spent half an hour or so to make a bridge between Django
and Ben's RailHelpers. Thanks for the concern, but don't worry about
it. My code is public domain and anybody can use and modify if they
like.

I did a bit more of Ajax programming and begin to use MochiKit. It's
really usefull when doing client side dom creation. I'm now using both
MochiKit and Prototype, but it would be nice if MochiKit can
incorporate Prototype functionality. Ben, do you know when MochiKit1.3
will be released?

Ben, Eugene: I think one of the difference between "helper" approach
and "widget" (especially dojo.widget) approach is whether you want to
specify "parameters or behaviors" of elements in the page using
(proprietary) DOM attributes or using parameters to helper tags. So
dojo.widget is probably more designer friendly, but since Django
template system already has tags, helper approach is as suitable for
Django. Another difference is whether you have inline javascript or
not. Sometimes inline javascript is handy (like when you're sending
back element with behaviors because you don't have to trigger setup
code after the element is inserted). As long as we're doing AHAH, I
feel both approaches may not be so different, but once models and
logics are dealt in client widget approach seems to be more suitable to
me.

Btw, both approaches have to provide tags/atributes/parameters in the
template. I'm now thinking of combining helper or widget approach with
Ben Nolan's approach which mimics CSS's way of separating document
structure and design.(http://bennolan.com/behaviour/ ,
http://www.schuerig.de/michael/javascript/). Basically just using
helper or widget inside Behavior's rule definition file. This way if
you have many templates which use same helper or widget, you only have
to assign class and don't have to repeat/scatter code across many
templates. It's also a snap to swap behavior across many templates.

Ben: RJS sounds interesting. How does it work different from other
helpers?

Eugene: Your article is excellent. I like it a lot.

-Louis

[Eugene Lazutkin]

Louis wrote:
>
> Ben, Eugene: I think one of the difference between "helper" approach
> and "widget" (especially dojo.widget) approach is whether you want to
> specify "parameters or behaviors" of elements in the page using
> (proprietary) DOM attributes or using parameters to helper tags. So

Widgets accept parameters and it may make sense to have helper tags as
well. The real difference is in how (and where) to handle presentation
logic, user's interaction, and back store. AFAIR RoR's helpers define
callbacks for primitive operations (like "drop" in drag-n-drop
operation), which introduce unnecessary overhead and invite spaghettis
code on client and server sides to handle a presentation logic. By
substituting client side code with helpers we may even have the "X over
Internet" scenario: everything is driven from server, while helpers
dispatch events from client's objects to server, and dispatch AHAH from
server to client's objects. This design opens a can of worms: overloaded
servers, clients will hit bandwidth bottlenecks all the way from our
servers to their ISPs, to their pipes. Sometimes you have to design this
way, but in many cases it can be (and should be) avoided.

Thanks,

Eugene