GFM Refactoring
Created by: rspeicher
According to cane, the gfm
helper method was by far the most complex method in the entire project, so I tried to refactor it a bit.
I think the new one is a bit easier to understand and will be easier to maintain, especially for the regex pattern.
This also shows that there's still lots of room for improvement, particularly removing the duplication from dealing with html_options
and the various link classes. I'll reply to this with some ideas.
Created by: rspeicher
So as far as further improvements, there's a ton of duplication in dealing with the
html_options
for the various links. I didn't entirely understand the whole interaction betweenlink_to_gfm
andgfm
, but it seems like the actual parser (my new class) doesn't need to care about html_options at all. It should be able to just insert its own classes and titles. Or am I wrong there? In other words, is there a use case where you're inserting custom classes into a GFM-generated link to an issue? I couldn't find any.By Administrator on 2012-08-14T08:55:02 (imported from GitLab project)
Created by: riyad
@tsigo
link_to_gfm
is about dealing with gfm text that will be used in a link, thinklink_to(gfm(...), ...)
. The problem is that it will produce nested links (i.e.<a>outer text<a>gfm ref</a>more outer text</a>
). These will not be interpreted as intended. Browsers will parse something like<a>outer text</a><a>gfm ref</a>more outer text
(notice the last part is not linked any more). To correct that there islink_to_gfm
. It wraps all parts to explicitly produce the correct linking behavior (i.e.<a>outer text</a><a>gfm ref</a><a>more outer text</a>
).@randx come on, it's not that dark ;)
By Administrator on 2012-08-14T15:29:17 (imported from GitLab project)