Description of problem: If the recipe whiteboard is formatted as markdown, it is currently rendered as raw text in the job page. We'll need something sensible here, since it is a bit inconsistent with the overall support of formatting comments and whiteboards as Markdown. Version-Release number of selected component (if applicable): develop How reproducible: 100% Steps to Reproduce: 1. Edit the recipe whiteboard and format your input as markdown. Save. 2. Go back to the job whiteboard and check the whiteboard field. Actual results: Recipe whiteboard field for the job page is rendered as raw text. Expected results: Should be rendered sensibly, perhaps similar to how we render the job whiteboard?
On the job page we show the recipe whiteboard inline in each recipe row. We probably just need to call truncated_whiteboard() on it.
(In reply to Roman Joost from comment #0) > Description of problem: > > If the recipe whiteboard is formatted as markdown, it is currently rendered > as raw text in the job page. We'll need something sensible here, since it is > a bit inconsistent with the overall support of formatting comments and > whiteboards as Markdown. > > Version-Release number of selected component (if applicable): > > develop > > How reproducible: > > 100% > > Steps to Reproduce: > 1. Edit the recipe whiteboard and format your input as markdown. Save. > 2. Go back to the job whiteboard and check the whiteboard field. > > Actual results: > > Recipe whiteboard field for the job page is rendered as raw text. > > Expected results: > > Should be rendered sensibly, perhaps similar to how we render the job > whiteboard? Does this mean that the changes to the job whiteboard would be rendered differently? I edited both, the recipe and the job whiteboard and there seems to be no difference in the rendering. Is there a way to see the difference between the current recipe whiteboard rendering and the job whiteboard rendering?
(In reply to Dan Callaghan from comment #1) > On the job page we show the recipe whiteboard inline in each recipe row. We > probably just need to call truncated_whiteboard() on it. The recipe whiteboard already calls the truncated_whiteboard(). The text is truncated after 100 characters. This is quite long as it is. Should we be reducing the check from 99 to 50 maybe?
(In reply to Roman Joost from comment #0) > Steps to Reproduce: > 1. Edit the recipe whiteboard and format your input as markdown. Save. > 2. Go back to the job whiteboard and check the whiteboard field. This was a little unclear perhaps.. In step 1, include some actual Markdown formatting, like italics or multiple paragraphs. Step 2 is referring to the recipe row on the job page, where we show the recipe whiteboard inline. Right now it shows the raw value of the whiteboard, with no Markdown parsing applied. It should be using the same truncated_whiteboard() logic used in all the other places (e.g. page titles) where we need to take a whiteboard, which could contain Markdown formatting or multiple paragraphs, and show it inline.
Actually truncated_whiteboard() is probably not the right solutoin in this case, because that function also strips it down to just the text content of the elements since it's being used for page titles which are plain strings. But here we actually *can* and should show rendered markup like italics and hyperlinks, and we don't need to worry about truncating long values because we are doing that with CSS already. So I think we can just render the whiteboard as Markdown and then just ensure we aren't showing multiple block-level elements inline in this row, since that will mess it up. Maybe take the rendered Markdown and extract the content inside the first <p> (or <li> or <h1>, <h2>, <h3>, <h4>, <h5>, <h6> I guess...) and put that inline in the row?
Now I can reproduce the problem. The same problem exists on the job page as well as the recipe page. The job page also shows links and bullets (rendered as markdown on the whiteboard), as plain text on the "Jobs" page. So both need to be fixed.
(In reply to Dan Callaghan from comment #6) > Actually truncated_whiteboard() is probably not the right solutoin in this > case, because that function also strips it down to just the text content of > the elements since it's being used for page titles which are plain strings. > > But here we actually *can* and should show rendered markup like italics and > hyperlinks, and we don't need to worry about truncating long values because > we are doing that with CSS already. > > So I think we can just render the whiteboard as Markdown and then just > ensure we aren't showing multiple block-level elements inline in this row, > since that will mess it up. > > Maybe take the rendered Markdown and extract the content inside the first > <p> (or <li> or <h1>, <h2>, <h3>, <h4>, <h5>, <h6> I guess...) and put that > inline in the row? What do we do with bullets? If the bullets follow text we could just take the first line of the text and ignore the bullets.
(In reply to sratnam from comment #8) > What do we do with bullets? If the bullets follow text we could just take > the first line of the text and ignore the bullets. Realistically nobody is going to put bullets or headings or anything crazy in their whiteboard -- at most some hyperlinks. So we don't need to over-think it too much. In that case taking the content of the first <li> should be okay (which is why I was suggesting it above).
I am picturing some code like $('<div/>').html(the_rendered_markdown).find('p, li, h1, h2, h3, h4, h5, h6').first().contents().appendTo(...)
(In reply to Dan Callaghan from comment #10) > I am picturing some code like > > $('<div/>').html(the_rendered_markdown).find('p, li, h1, h2, h3, h4, h5, > h6').first().contents().appendTo(...) Marked.js allows to have direct access to the lexer and parser which will cover all the possibilities. https://github.com/chjj/marked#access-to-lexer-and-parser I guess it might be simpler to do sth like this: var whiteboard = _.find(marked.lexer(this.model.get('whiteboard')), function(token) { return token.hasOwnProperty('text'); }).text;
But we still want to show the actual renedered Markdown -- just not multiple block-level elements. I don't think finding the first token from the lexer internals will give us that. If my recipe whiteboard is: [asdf](http://asdf.com) is a *really* cool site! Don't you agree? then we want the recipe row on the job page to show: <a href="http://asdf.com"> is a <em>really</em> cool site! but not: <p><a href="http://asdf.com"> is a <em>really</em> cool site!</p> <p>Don't you agree?</p> because that will ruin the table-like row styling.
(In reply to Dan Callaghan from comment #12) > But we still want to show the actual renedered Markdown -- just not multiple > block-level elements. I don't think finding the first token from the lexer > internals will give us that. > > If my recipe whiteboard is: > > [asdf](http://asdf.com) is a *really* cool site! > > Don't you agree? > > then we want the recipe row on the job page to show: > > <a href="http://asdf.com"> is a <em>really</em> cool site! > > but not: > > <p><a href="http://asdf.com"> is a <em>really</em> cool site!</p> > <p>Don't you agree?</p> > > because that will ruin the table-like row styling. Okay, I see what we want to achieve here.
if you want to collect everything before a <br />, it would be something like $("whiteboard").html().split("<br />")[0];
https://gerrit.beaker-project.org/#/c/4994/
(In reply to sratnam from comment #15) > https://gerrit.beaker-project.org/#/c/4994/ Re-target it to 23.1 https://gerrit.beaker-project.org/#/c/5085/
Beaker 23.1 has been released.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days