Another day, another filter plan

Posted by Scott Laird Wed, 17 Aug 2005 15:13:38 GMT

I’ve spent a bit of time playing with moving my Typo filter patch to use controller instances for filtering, and it doesn’t look too hideous on the filter side, but I’m going to need a lot of infrastructure changes before I can deploy it.

Unfortunately, the main user of filters right now is Article#set_defaults, which is called whenever an Article is saved. If I make filtering a controller issue, then I’ll have to rip out the filtering in Article (also Comment and Page) and move it to ArticleController. This won’t be a big performance hit, because I can use fragment caching, but it’s very invasive.

So, before I go any further down this road, I need to decide if this is really cleaner then just caching a base URL and using it to manually generate URLs. I was originally against this, but a thread on the Typo mailing list reminded me that we’re going to need a base URL if we want to support multiple blogs in a single Typo install anyway.

Ugh.

Posted in  | Tags ,  | 8 comments

Comments

  1. Tom Moertel said about 3 hours later:

    What are the input and output domains for filters? Could you augment the output domain to support “URI specifications” that a final rendering pass could convert into URLs? Then filters could emit context-free URI specifications and leave the context-specific translation to the final pass, which would have knowledge of the action/controller/application/… environment.

    For example, a filter could emit the following:

    Later, the context-aware final pass could convert the src-spec attribute into a src attribute that has been customized for the current application, blog, controller, action, etc.

    One advantage of this approach is that you get to define and document the semantics of the output domain, precisely controlling what contextual information filters can make use of. It also encapsulates context-specific logic in one place: the final-pass renderer.

    Cheers. —Tom

  2. Tom Moertel said about 3 hours later:

    For my previous comment I guessed Markdown, but as you can see, I guessed incorrectly.

    Cheers. —Tom

  3. Scott Laird said about 4 hours later:

    It’s markdown, but <> are turned into < and > before Markdown gets its hands on it. That does weird things to pre-formatted blocks of HTML.

  4. Geoff said about 12 hours later:

    Scott, you’re the energizer bunny. Most people would take a break, but you keep delivering Good Stuff(TM)

  5. Bob Aman said 1 day later:

    I’m not really sure exactly what filters do yet, but would it be possible to write a filter so that you could write:

    <pre syntax=”ruby”> (Frink::Gromzalot = Class::new).class_eval { define_method(:zork) { puts “Zogmorfo” } } </pre>

    And have it syntax highlight it?

    Also, Typo really needs something along the lines of the “fancy stuff” link that _why has going in order to explain Textile/Markdown formatting to people. Not to mention to let commenters know which formatter is in use.

    For example, I have no idea what’s going to happen with my snippet above. :-)

  6. Scott Laird said 2 days later:

    Syntax highlighting is good; it should be easy to add that once I get the core filter stuff out. I suspect that might be better--I think that's what Jon Udall decided on for his blog a year or so ago, but I'll need to check back. I'm not completely convinced that I like this syntax-- might be better, even though the code doesn't currently support text.

    By "fancy stuff", I assume that you mean some sort of syntax help text? That's absolutely on my list. The problem is that it's not really static text, because it depends on which filters are enabled, but that's not really that big of a hurdle.

  7. Scott Laird said 2 days later:

    Did I say “Jon Udall”? I ment Udell. Anyway, it looks like he ended up with 

    


    His goals are a bit different, though--IIRC he wanted to be able to have valid XHTML that he could run through an XML-aware search tool.  We're more interested in the transform itself.
    


    I suspect that 
    , , or  would be better.
    
  
    8. 

  8. 
  
  
  
  Bob Aman  said 2 days later:
    
  
    Well, the main reason I suggested <pre> instead of <code> is that <pre> is normally a block tag and <code> is usually an inline tag.  Seems to me that syntax highlighted code makes most sense as a block, and well… principle of least surprise and all.  I chose the “syntax” attribute because I wanted to avoid confusion with the use of “lang” attributes elsewhere when referring to natural languages, for example, “xml:lang”.  (Yeah, I know it’s in another namespace, but still.  I’d just assume be careful.)
    
  
    9. 

  
  





  
  RSS feed for this post
  



  
Comments are disabled