[Mediacloth-devel] Back on track (and on link handling)

[Gregory Murphy]

Thiago,

I think splitting the link handler method into two, link_for() and 
link_for_resource(), is a great idea. This seems to be a big division in 
Mediawiki, in that page links all fall into two simple categories (links 
to pages that do exist, and links to pages that do not exist), 
distinguished by URL. Resource links on the other hand are a Pandora's 
box. Some resources, like categories, are not even treated as links. So 
most applications will probably need to completely customize the output 
of resource links.

I'm not so sure about the need to break out the functionality of 
link_for() into special attributes and options handlers. Is this too 
much engineering?

Another approach might be to make it easier to override link_for(), by 
providing a class method that formats XML elements. Then the link_for 
default impl would be as simple as

      def link_for(page, text)
          element(:a, :href=>url_for(page), text)
      end

Something like that would be much easier to customize, and it would keep 
the LinkHandler simpler.

// Gregory

Thiago Arrais wrote:
> I have been too busy (or lazy) to spend some time on Mediacloth for the
> past four or five weeks, but I finally found some spare time since
> yesterday and got back to the link handling stuff. I thought about
> answering directly to Gregory's message but it's been so long that it feels
> like it's time for a new thread.
>
> The old code had something that I was not very comfortable with. A
> single LinkHandler method (url_for) was responsible for generating a
> page's URL and also custom link tag attributes. That wasn't very nice
> and I have been experimenting with some options inside my branch,
> but I can't say I am 100% comfortable with the new approach.
>
> Anyway, the url_for method has been broken into two: url_for (for URL
> generation) and options_for (for the custom tag options/attributes).
> But the real new thing is the link_attributes_for method that combines
> both. The referenced address can be returned together with the other
> tag attributes inside a hash, clients just need to remember to index it
> by an :href key (examples, as expected, are inside the tests at revision
> 89).
>
> The other major addition is the thing that Gregory wisely remembered
> some time ago: some people may need to fully customize the link
> generation code (maybe not even rendering a link tag at all). The
> link_for method (at revision 90) accomplishes that. The original version
> uses all of the other methods to build a link tag, but it can be overridden
> by clients to fully replace the default behaviour.
>
> The next idea is to provide an easier way to provide an options_for
> method using Ruby code blocks. Instead of having to subclass and override
> some method, clients could pass a code block to a constructor, like
>
>     generator = MediaWikiHTMLGenerator.new
>     generator.link_handler = MediaWikiLinkHandler.new do |page|
>         h = { :href => "http://www.myhost.com/wiki/#{page}" }
>         h[:class] = 'empty' unless exists(page)
>         h
>     end
>
> I don't know if it feels right for other people, though. For me it makes sense
> because it is what my (client) code needs, but I would like to know how other
> feel about it. I may have a prototype for this in my branch some time today
> (it may even already be there when people read this message, if we're lucky).
>
> Cheers,
>
> Thiago Arrais
>