Re: preformatters and entry parsers

On Fri, 20 Aug 2004, David Ascher wrote:
>
> 1. It looks to me like only the default txt (plain) entry parser calls
> the cb_preformat and cb_postformat callbacks.  Shouldn't all entry
> parsers call them?

They don't have to if they don't want to.  Beyond that, I have no
experiecne with other dataparsers except the .txt one and one I wrote for
.tips for my own blog.


> 2. Also, I'm once again stumbling on an 'order of data collection'
> problem.  Here's the scenario.
>
> I was thinking that I could implement a version of the 'extended entry'
> concept by supporting the following markup:
>
> >>>>
> Title of the entry
>
> Summary:
>    This is the summary of the entry that shows
>    up in the index
>
> This is the body of the entry, in other words the 'extended' entry.
> >>>>
>
> Something like this _would_ have worked:
>
> def cb_preformat(args):
>     lines = args['story']
>     entry = []
>     summary = []
>     target = entry
>     for line in lines:
>         if line.startswith("Summary:"):
>             target = summary
>             continue
>         if not line.startswith(' ') and target == summary:
>             target = entry
>             continue
>         target.append(line)
>     request = args["request"]
>     config = request.getConfiguration()
>     renderer = args['renderer']
>     if len(renderer.getContent()) == 1:
>         return ''.join(entry)
>     else:
>         return ''.join(summary)
>
>
> except that args['renderer'] (which I saw the comments plugin using to
> figure out whether a single entry was being shown or not) isn't
> available at the time that cb_preformat is called.
>
> I want this concept to work with all entry parsers, hence my idea of
> putting it in the preformat as a 'filter'.

That should be a postformatter.  postformatters can add additional
properties to the entry.  You don't want to be dropping information in the
entryparser/preformatter stage depending on whether the request is for an
index or not.  That'll screw up caching further down the road since the
results of entry parsing, preformatting, and postformatting are cached.

What you want to do is change the name of the above function to
cb_postformat and then adjust the code like this:

def cb_preformat(args):
    data = args['entry_data']
    lines = data["story"]

    # note: i can't remember if lines is a string or a list of
    # strings here

    entry = []
    summary = []
    target = entry
    for line in lines:
        if line.startswith("Summary:"):
            target = summary
            continue
        if not line.startswith(' ') and target == summary:
            target = entry
            continue
        target.append(line)

    data["story"] = ''.join(entry)
    data["summary"] = ''.join(summary)


(I'm sort of assuming your parsing was ok before--I didn't check that
out.)  Then in your index templates, use $summary instead of $body.


> Are there other ways of finding out if we're looking at a single entry
> or an index?

Mmm...  Actually, I think there is, but I forget what it might be.
Someone had problems with the single entry case a month or two ago, but I
can't remember the specifics or what the solution was (or whether there
was a solution).

Your best bet is to download my cutsie debug mode plugin, create the two
situations in your blog datadir, and then go to those urls adding
"?debug=yes" to the end of the url.  That'll let you see all the data in
the request object.  The thing to look at is the Request.getData() dict
section.

Incidentally, that's an awesome tool for figuring out what's going on and
what information is where.

/will


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285