today | current | recent | random ... categories | search ... who ... syndication

Movable Thoughts #18 : A Nifty Bit of Featuritis




Date: Wed, 11 Sep 2002 09:11:25 -0400 (EDT)



From: Aaron Straup Cope



To: Benjamin Trott



Subject: Re: MT - two unrelated thingies







> > I mention all of this because it seems like it would be a nifty bit of



> > featuritis for Movable Type. Actually, I mention it because it would be



> > nice to have some kind of universal glossary system and MT is rapidly



> > approaching universal status (congrats!)



>



> I agree that a glossary system would be pretty cool. Though, it's quite



> doable currently just using the MT-Macro plugin. Have you taken a look



> at that?







Ah, I see. No I hadn't. That's cool - I gather I can do something like :







<MTApplyGlossary>



 <$MTEntryBody$>



</MTApplyGlossary>







MT::Template::Context->add_container_tag(MTApplyGlossary => sub {



    my $ctx  = shift;



    my $args = shift;







    my $path = $args->{path'};







    if (! $path) {



       my $cfg = ... " # Remember how to get MT config manager here



       $path = $cfg->{GlossaryPath} ||



           return $ctx->error($ctx->errstr);



    }







    #







    my $builder = $ctx->stash('builder');



    my $tokens  = $ctx->stash('tokens');







    my $output   = "";



    my $writer   = XML::SAX::Writer->new(Output=>$output);



    my $glossary = XML::Filter::Glossary->new(Handler=>$writer);



    my $parser   = XML::SAX::ParserFactory->parser(Handler=>$glossary);







    # Would also need to $glossary->no_do_startend_document_methods();







    $glossary->set_glossary($path);







    eval { $parser->parse_string($builder->build($ctx, $tokens)); };







    if ($@) {



        return $ctx->error($ctx->errstr.": $@");



    }







    return $output;



}







Which will almost certainly break because it is very possible that the



data passed to the plugin will not be well-formed. I suppose I could just



export the code for parsing double-quoted keywords as a package function.







I'm about to add support for <my_ns:glossary id = "some keyword with



spaces" /> per a request which I'm not keen to parse with regex(p)s since



you can also do <my_ns:keyword />.







I suppose the whole thing could be hacked together using HTML::Parser to



do the parsing since it is very forgiving. Well, it's something to work



with anyway.







Question : When a plugin is called, has the FH associated with the



document already been opened or are you just building a string? If there



is a FH, is there any way that it could be passed to the plugin?







I suppose not since that would make managing nested tags/plugins



impossible. Alas.







In the unsolicited advice department, I would only mention the docs for



plugins are less than inviting. I've noticed that other people who've



written plugins have posted code which is helpful, since you can sort of



infer what 'foo' does and how to get 'bar' from them.







But, if plugins are really more exciting that just returning the value of



system calls it isn't readily apparent how.







107 ->perldoc MT::Template::Context



No documentation found for "MT::Template::Context".



refers to

meta

 
Susan Sontag : Real Battles and Empty Metaphors ←  → Philip Kennicott : Fragile Memory