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?
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
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.
>
>