Opened 3 years ago

Last modified 3 years ago

#768 new enhancement

BibFormat: support non-HTML output modes easier (a simple tag?)

Reported by: jblayloc Owned by:
Priority: major Milestone:
Component: BibFormat Version:
Keywords: Cc:

Description

It would be really nice if there were an obvious way to produce non-HTML output in BFTs, for, e.g., production of raw LaTeX or csv. I guess what I'm imagining is being able to have a BFT like:

<bft:setnohtml>
<name>my cool format</name>
<description>it formats things coolly</description>
% and now everything we put in that isn't explicitly a <name>, a <description>
% or a <bfe_foo> gets passed to the browser uninterpreted.
% this is not really different from how it works now, except that the bft: tag
% above says to not wrap the output in any of the normal page template
% boilerplate
This is a valid, though boring, \latex document.
<BFE_PRODUCE_SOME_INTERESTING_STUFF arg1=val1 arg2=val2 arg3=val3>

As far as I can tell, if this flag existed and were used liberally, a lot of the output special casing in search_engine could be simplified, and it might even be possible to implement things like atom feeds as BFTs.

I like the bibformat system so I think this would be a pretty big win.

Change History (2)

comment:1 Changed 3 years ago by jblayloc

Two additional thoughts:

  1. Alternately (and aesthetically preferable to me (though a more radical departure from previous usage (and consequently probably impractical))) there could be a bft tag that gets interpreted to mean "wrap this page in the standard template infrastructure", so that all BFT output would be produced as raw text by default and you would say like <bfe_invenio_page> at the top of most of your BFTs.
  1. I forgot about content types. If your format is producing latex or json it should say so, like so:
    <bft:setnohtml content_type="text/json">
    ...
    

with the understanding that if no content_type is set it defaults to something reasonable like "text/plain".

comment:2 Changed 3 years ago by jcaffaro

Some quick comments that I don't have time to develop too much:

  1. BibFormat is agnostic to the way its output is used: in an HTML page, as raw text, XML, etc. It is already up to the format maintainer to specify if the output should be HTML-escaped or not for example. So you could add the proposed tags, but it would be other modules calling BibFormat (for eg. WebSearch) to make use of this tag, depending on the context.
  1. Note that currently the role of specifying the content-type is left to the output format (.bfo) instead of the format template (.bft). It seemed to make more sense to have it here, since a BibTeX output would remain text/plain whenever it deals with a foo (foo.bft) or a bar (bar.bft).
  1. BibFormat configuration files are designed to deal with individual records, not group of records (one .bft formats one record). One template represents the output of a single record (this really easier when creating template than when you have to think about a list of records, as with XSL). This is probably a bigger issue than what you described above to adopt .bft for atom feeds for example. Note also that having per-record formatting enables the following when searching: WebSearch retrieves list of records, and ask BibFormat to format the first one, write to the page (and send back to user), ask BibFormat to format second one, write to the page (and send back to user), ask BibFormat to format third one, etc. Still what seems to really miss in this case is the ability to specify a prefix, a suffix and a separator for each output format: these are currently hard-coded in WebSearch, while the output formats could know about it. Each output format would link to a prefix.bft, suffix.bft and separator.bft in addition to the contents.bft files. Still it might be that in some cases the prefix must have access to some context that would potentially not be available from the BibFormat environment.
  1. Note that .bft can already be used for atom feed. We use an .xsl by default but a .bft would do.
  1. Note that there are some developments possibly going into the direction of this ticket in ticket:720
Note: See TracTickets for help on using tickets.