the current work replacing prototype.js with jQuery.

81 views
Skip to first unread message

Bryan Larsen

unread,
Nov 22, 2011, 2:44:48 PM11/22/11
to hob...@googlegroups.com
I'm currently working on replacing prototype.js in Hobo with jQuery.
It's not ready for alpha testing yet, but here is the curent state of
my CHANGES document.    I'm posting it to solicit feedback:  it's a
lot easier to make changes now than later.   For instance, the new
attribute names would be easy to change now, but harder in the future.

At this point it looks like this work will be included in Hobo 1.4,
and that Hobo 1.4 will not include support for prototype.js.    Would
this upset anybody -- are there any prototype.js fans out there?
Does anybody think that it's too big a step to convert from prototype
to jQuery, from Rails 3.0 to 3.1 and Hobo from 1.3 to 1.4
simultaneously?    Unless you have a lot of prototype code in your
app, this should be a lot smaller step than the Rails 2.3 to Rails 3.0
step.

CHANGES:


## Framework Agnosticism

jQuery support is being written in a manner that should make it easier
to support other frameworks if we ever decide to do so.   Basically
all this means is that we're annotating our HTML and the javascript is
picking up the information from the annotations rather than calling
functions or setting variables.

## Unobtrusiveness

The agnosticism is a side benefit -- really the main reason its
written this way is so that we're coding using "unobtrusive
javascript" techniques.

Hobo currently many different mechanisms to pass data to javascript:

- classdata ex class="model::story:2"
- non-HTML5-compliant element attributes: ex
hobo-blank-message="(click to edit)"
- variable assignment: ex hoboParts = ...;
- function calls: ex onclick="Hobo.ajaxRequest(url, {spinnerNextTo: 'foo'})"

hobo-jquery currently uses JSON inside of comments:

   <!-- json_annotation ({"tag":"datepicker","options":{},"events":{}}); -->

the most appropriate mechanism for 2011 is probably HTML5 data
attributes:

   <div data-rapid-options="{...}">

HTML5 data attributes are technically illegal in HTML4 but work in all
browsers (even IE6).  The illegality of them is the reason that I didn't
choose them in Hobo-jQuery, but it's now 2011 and you should be writing
HTML5 now.  The goal is to replace all of the Hobo data
mechanisms with JSON/comment or HTML5 annotations.   Hopefully HTML5
annotations unless I run out of time.

## Compatibility

Obviously compatibitlity with hobo-rapid.js is not going to be
maintained, since that's written in prototype.

However, I have also not put a strong emphasis on maintaining
compatibility with the existing hobo-jquery.js code.   Many people use
hobo-jquery's DRYML interfaces, but I don't believe that many people
use its javascript interfaces.   I'm not changing things for no
reason, but I am refactoring the code and internal interfaces as I go
along.

## Enhancements

### multiple parts

I've updated DRYML so that it emits a different DOM ID if you
re-instantiate a part.   (The first use of a part retains the DOM
ID=partname convention for backwards compatibility)  "update="
requires a DOM ID, so I've also added 2 new AJAX attributes that can
be used instead of "update=".

The first one is "updates=".  (name TBD).  Instead of a comma
separated list of DOM ID's, it takes a CSS selector.

The other one is "ajax".  (name TBD).   If used inside of a part, it
indicates that part should be updated.   If used outside of a part,
AJAX will be used but no parts will be updated.

These three Ajax attributes may be used simultaneously.

Example:

   <collection:stories>
      <div part="inner">
         <form ajax>
            <input:title/>
         </form>
      </div>
    </collection>

### allowing errors in parts

Older versions of Hobo did not render a part update if the update did
not pass validation.

This behaviour may now be overridden by using the 'errors-ok'
attribute on your form.  (or formlet or whatever other tag initiates
the Ajax call).

The 'errors-ok' attribute is processed

### AJAX file uploads

If you have malsup's form plugin installed, Ajax file uploads should
"just work".

## Editors

Editors are no longer special-cased, they now use the standard DRYML
part mechanism.

Here's the current source:

<def tag='editor' attrs="blank-message">
 <% blank_message ||= t('hobo.in_place_editor.click_to_edit',
:default => '(click to edit)') %>
 <div part="editor-part" part-locals="blank_message">
   <set my-field="&this_field"/>
   <formlet with="&this_parent" ajax errors-ok>
     <error-messages/><%# TODO: replace with something more compact,
maybe even transient %>
     <toggle-edit field="&my_field" events="&{'preview' => false}"
defaultText="&blank_message" onchange="return
hjq.formlet.submit.call(this);" />
   </formlet>
 </div>
</def>

`toggle-edit` is [the toggleEdit jQuery
plugin](http://alz.so/toggleedit/) wrapped around a standard input.

TBD: Right now editor uses `<formlet>`.   The major advantage of formlet
is that it is safe to use inside of a form.   I can't think of any
good use cases for that behaviour, but it does seem like something
people might do by accident.

The alternative is to use `<form>`.   Since this implementation of
editor starts with an input and switches to a view via Javascript,
using a form will allow reasonable javascript-disabled behaviour.

## Changes behind the scenes

### reloading of part context

[This change](https://github.com/tablatom/hobo/commit/6048925) ensures that
DRYML does not reload the part context if it is already in `this`.

### i18n

These commits will require translation updates for languages other
than English.  (Presumably this list will get larger because right now
the change is one I could do myself...)

- https://github.com/tablatom/hobo/commit/e9460d336ef85388af859e5082763bfae0ad01f5

### Hobo-jQuery incompatibilities

- annotations no longer contain an 'init' annotation.   Instead,
hobo-jquery automatically calls hjq.<tag>.init if that function
exists.

- annotations are marked with the 'rapid-annotated' class rather than
'hjq-annotated'.

- the standard `<submit>` tag now works in a formlet, there's no need
to use `<formlet-submit>`

### controller changes

Due to limitations on Ajax file uploads, multipart forms are not sent
with the proper Ajax headers.   If your controller action may receive
multipart forms, rather than using:

  respond_to do |wants|
     wants.js { hobo_ajax_response }
     wants.html {...}
  end

use

  if request.params[:render]
     hobo_ajax_response
  else
     ....
  end

for more information see http://jquery.malsup.com/form/#file-upload

## Testing

hobo-jquery is being tested using capybara & qunit.js.

# FIXME

- spinner-next-to CSS vs id?

paul

unread,
Nov 24, 2011, 5:22:59 PM11/24/11
to Hobo Dev
I wish I understood enough to comment on the detail, but I don't.
However I do think standardising on jQuery is a sensible idea.

Would this be too much for 1.3 to 1.4? I guess that depends on
- what the expected timescale is for 1.4
- how much incompatibility (and thus migration effort) will be
introduced by the other 1.3 -> 1.4 changes, as well as this?

> -https://github.com/tablatom/hobo/commit/e9460d336ef85388af859e5082763...


>
> ### Hobo-jQuery incompatibilities
>
> - annotations no longer contain an 'init' annotation.   Instead,
> hobo-jquery automatically calls hjq.<tag>.init if that function
> exists.
>
> - annotations are marked with the 'rapid-annotated' class rather than
> 'hjq-annotated'.
>
> - the standard `<submit>` tag now works in a formlet, there's no need
> to use `<formlet-submit>`
>
> ### controller changes
>
> Due to limitations on Ajax file uploads, multipart forms are not sent
> with the proper Ajax headers.   If your controller action may receive
> multipart forms, rather than using:
>
>   respond_to do |wants|
>      wants.js { hobo_ajax_response }
>      wants.html {...}
>   end
>
> use
>
>   if request.params[:render]
>      hobo_ajax_response
>   else
>      ....
>   end
>

> for more information seehttp://jquery.malsup.com/form/#file-upload

Bryan Larsen

unread,
Nov 24, 2011, 5:45:42 PM11/24/11
to hob...@googlegroups.com
To a first approximation, the amount of incompatibility this
introduces is proportional to the amount of custom prototype.js code
you have in your application. The Rails 3.1 and Hobo 1.4 changes are
comparably minor, I think.

BTW, the section I wrote about editors? It didn't work well, so
i've got another design coming. More info to come when it
stabilizes.

Bryan

> --
> You received this message because you are subscribed to the Google Groups "Hobo Dev" group.
> To post to this group, send email to hob...@googlegroups.com.
> To unsubscribe from this group, send email to hobodev+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hobodev?hl=en.
>
>

Reply all
Reply to author
Forward
0 new messages