Arvados

Notes about the update:

• The edit button for project description is now displayed on top of textarea; uses btn-primary with pencil on left; 10 rows of display area with inline editing;

• I did not update Ok and Cancel button icons to use text. This is managed by x-editable global templates http://vitalets.github.io/x-editable/docs.html#global and is set application-wide in editable.js. I could not see how we can change these only for the inline-editable and not everywhere else and hence left it as is.

• I also could not figure out how to change the placement of the Ok and Cancel buttons to either the top or bottom of the textarea (just for this inline-textarea). Hence, I let them be on the right hand side of textarea and used 98% of page for the editable instead (css).

Reviewing 13e4bac

The new CSS will set 98% width for any inline X-Editable component. I'm concerned that this could surprise future developers who might try to use an inline editable. Is it possible to constrain this CSS further so it only applies to project description editing?

The existing code in render_editable_attribute expects htmloptions[:btnplacement] to be a symbol. The new conditional branch looks for the string 'top'. For consistency, please change this, and the call in _show_description.html.erb, to the symbol :top.

Thanks.

Thanks Brett. Yes, limiting the inline css config to description is a good idea and I made those updates.

Reviewing e146ad3. The changes address the previous issues, so thanks much for that.

The span tag is generated with all of the attributes included in htmloptions. Now that we're adding several button options to htmloptions, they're being rendered as (invalid) attributes on the span tag. For example, working on a development API server loaded with test fixtures, modifying the description for "A Project" has a span tag like this:

<span id="zzzzz-j7d0g-v955i6s2oi1cbso-description-1430770175757123" class="editable editable-textile editable-done-setup editable-pre-wrapped" [… data attributes…] btntext="Edit" btnplacement="top" btnclass="primary" tabindex="-1" style="display: inline-block;">

Is there a good way to prevent these key-value pairs from being rendered as attributes on the span tag?

Thanks again.

Brett: added a new "nonhtml_options" parameter to render_editable_attribute method definition and moved all the btn* attributes into it. Please take another look. Thanks.

Reviewing 6e10831. This seems really great. Thanks for sticking it through. Just one small thing from here: this is also a preexisting bug, but now that we have the infrastructure to clean things up, it would be good to move the tiptitle option from htmloptions to nonhtml_options (since it's not a verbatim HTML attribute either, just like the btn-related ones). There are only a couple of templates using it (_index_jobs_and_pipelines.html.erb and _show_contents_rows.html.erb in app/views/projects/), so making the switch should not be difficult. If that's a straightforward change you can go ahead and merge with it. Thanks.

Converted tiptitle to nonhtml_option.