Arvados

Note that for Projects this disrupts the way that Projects are displayed on the home page. If Textile is used for a longer description then it may not render as expected in the list of Projects there.

Offering a suggestion in the form of commit 41f3658 on this branch:

• 3354: Redirect link#show to "show named object". This way, if you put a text link like "foo":{uuid-of-name-link} in a textile description field, it leads to the named object rather than the generic "show attributes" page for the link object.

• Depending on the shape of the rendered description (e.g., long first line followed by a few short lines of text) the "edit" pencil icon ends up in a slightly unnatural place. I wonder if it would count as an improvement to put a <br/> before it, so it's in a more predictable place?
• The textile source is shown instead of the textile-rendered version if the attribute is non-editable (e.g., current user does not have write access on the project being viewed).

Other than that, this looks pretty good.

I worry slightly that attrvalue in the helper could end up being nil -- we used to .to_s it for content_tag but don't any more. I wasn't able to make this blow up on any page, and all tests pass, so maybe the .to_s was superfluous?

Regarding the front page, see #3339, but it might still be interesting to find the perfect way to render the first line/paragraph in the home page: what if the first line has an h1 on it? That might be kind of ugly. But it would be nice to render font effects there instead of *ascii art*...

• Edit icon: in fact I'd added an inline-block so that it would not appear on the next line, which I thought looked worse. In any case, on your suggestion, I've removed that bit of CSS, and now the pencil will always appears below the edited text, even if it's only a single phrase (because Textile adds <p>). In fact I don't think either solution is really all that great, but the only ideas I can come up with would, for the sake of consistency, require changing the way these edit icons appear everywhere in Workbench. (e.g. Put the edit icon on the left! Or remove the edit icon and alter the appearance of editables such that the user will come to know that hovering over one will reveal that a click will allow editing, etc.)

• Read-only not rendered as textile: fixed

• attrvalue NPE: shouldn't be a problem - I had feared the same thing and decided not to to_s until the last possible moment, here in ApplicationHelper#render_content_from_database, and I have a nil-detected clause in there. If attrvalue is nil, nil will also end up being returned.

• front page: not sure what to do here; seems like it could get overcomplicated pretty quickly trying to work out what to do when there's markup of some kind, and all for something that might be ill-conceived anyway... Lo-tech suggestion: a new attribute called "short description"?

Phil Hodgson wrote:

• Edit icon: in fact I'd added an inline-block so that it would not appear on the next line, which I thought looked worse. In any case, on your suggestion, I've removed that bit of CSS, and now the pencil will always appears below the edited text, even if it's only a single phrase (because Textile adds <p>). In fact I don't think either solution is really all that great, but the only ideas I can come up with would, for the sake of consistency, require changing the way these edit icons appear everywhere in Workbench. (e.g. Put the edit icon on the left! Or remove the edit icon and alter the appearance of editables such that the user will come to know that hovering over one will reveal that a click will allow editing, etc.)

OK. You're right, it does look even uglier there than I expected. I think we should probably just do one thing or the other for now and seek professional help. (i.e., from Tom O'Keefe. We already have some ideas at Workbench UI images about changing the "edit button" approach throughout, which might be helpful.)

• Read-only not rendered as textile: fixed

Looks great

• attrvalue NPE: shouldn't be a problem - I had feared the same thing and decided not to to_s until the last possible moment, here in ApplicationHelper#render_content_from_database, and I have a nil-detected clause in there. If attrvalue is nil, nil will also end up being returned.

I see... but if attrvalue is nil and attr isn't textile-able, don't we end up passing a nil rendervalue to content_tag (where we would have sent nil.to_s before)? Of course, I don't have any particular evidence that content_tag can't handle nil, other than that we used to have .to_s there...

• front page: not sure what to do here; seems like it could get overcomplicated pretty quickly trying to work out what to do when there's markup of some kind, and all for something that might be ill-conceived anyway... Lo-tech suggestion: a new attribute called "short description"?

I'd say let's start with the easiest thing (cut off after first newline, and display it without rendering it as textile). Revisit when we've seen what happens in the wild?

Oh... and it's probably a good idea to write a test -- maybe just a basic functional test, just to make sure we have non-zero coverage on the RedCloth code path.

Thanks!

I will settle on putting the edit icon back to the right then.

content_tag handles nil without complaint, and indeed defaults the content attribute to nil... I tested in console:

2.1.1 :001 > helper.content_tag('hello')
 => "<hello></hello>" 
2.1.1 :002 > helper.content_tag('hello', nil)
 => "<hello></hello>" 

For the display of first line only on home page, should I just take over #3339 from Radhik by re-assigning it to myself?

I will work on writing a couple of functional tests for this textile sutff. I confess that I have not gotten any tests to run yet in my environment successfully, and I was trying to make progress without losing the time to getting them running, which no doubt is short-sighted.

Just noticed the regular hyperlink style doesn't seem to work. Is this caused by the Arvados UUID link feature, or something else?

• Running a pipeline tutorial from "Arvados documentation":qr1hi-j7d0g-w07c2rkhy5nouy3
  

• Running a pipeline tutorial from "Arvados documentation":http://doc.arvados.org
  

Radhika also pointed out that we should provide some hint to the user that it's possible to use Textile here. Perhaps in the title bar of the popup, or below the textarea?

"You can use textile here. {More info...} (opens in a new window)"

http://redcloth.org/hobix.com/textile/ (or something?)

I believe I've fixed the bug you identified Tom, and pushed the changes but, frustratingly, I am having trouble getting all my moving parts to fit together today and haven't been able to test it yet outside of the console (where it works peachily).

A few of my observations as I experimented with this branch (in preparation to address Tom's request to add a test or two):

• Once I enter a description, the pencil icon moves to the bottom of the description. (I see some of the discussion about this above). This is rather confusing and not quite intuitive. I think we should move the pencil icon to left of the text (for project title and description), if displaying it inline on the right is not doable.

• I entered some textile description to my project. And, it was displayed correctly (formatted) while in the project. However, once I went back to dashboard, I saw the description text as entered, not formatted, for my project. This I think is pretty bad. We should display the formatted descriptions in "My projects" and "Shared with me" panels. Otherwise, not show the description at all.

• Out of curiosity, I entered plain html in description field and as expected it was rendered correctly. I think it might be desirable that we say that the description can be textile or html formatted. Agree, textile is converted into xhtml but I am thinking a lot more people might know html formatting and might be able to connect right away. Just a suggestion.

Added a few integration tests to test the textile description for projects.