The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.
 / 
AxKit-App-TABOO-0.52
River stage zero No dependents
++
/ AxKit::App::TABOO::Provider::NewsList

NAME

AxKit::App::TABOO::Provider::NewsList - Provider for listing news stories in TABOO

SYNOPSIS

In the Apache config:

  <Location /news/>
        PerlHandler AxKit
        AxContentProvider AxKit::App::TABOO::Provider::NewsList
        PerlSetVar TABOOListDefaultRecords 20
        PerlSetVar TABOOListMaxRecords 200
  </Location>

Please note that this should go before the configuration of the AxKit::App::TABOO::Provider::NewsList Provider if you are using both.

DESCRIPTION

This is a Provider, it implements the AxKit Provider API, and therefore contains no method that anybody should use for anything. For that reason, this documentation deals with what you should expect to be returned for different URIs.

It will return lists of news stories, so it makes use of Plural Stories objects. Stories are returned sorted by timestamp, most recent story first.

This Provider will return either the story except the content field (which is unsuitable for longer lists of comments), or just title, submitter names and so on, depending on the URI.

In accordance with the TABOO philosophy, it interacts with Data objects, that are Perl objects responsible for retrieving data from a data storage, make up sensible data structures, return XML markup, etc. In contrast with the News provider, this provider mainly interacts with Plural objects to make lists of stories. Also, it doesn't deal with comments.

CONFIGURATION DIRECTIVES

TABOOListDefaultRecords

The maximum number of stories TABOO will retrieve from the data store if the user gives no other instructions in the URI (see below). It is recommended that you set this to some reasonable value.

TABOOListMaxRecords

The maximum number of stories TABOO will retrieve from the data store in any case. If the user requests more than this number, a 403 Forbidden error will be returned. It is highly recommended that you set this to a value you think your server can handle.

URI USAGE

Like the News Provider, the URI in this Provider consists of several parts that is parsed and used directly to construct the objects that contain the data we wish to send to the user.

The URIs currently begin with /news/. This should be made customizable in the future, but currently needs to be hardcoded in the httpd.conf and is hardcoded in the Provider itself.

In this provider, /news/ will return all the news stories, only limited in number by the TABOOListMaxRecords directive.

Optionally, one may then append a sectionid, to get the stories in that section.

By default, any user will see the stories they are authorized to see, so a higher privileged user will see both stories that are approved by an editor and stories that have yet to be approved. That user may then append /editor, to see only the stories that has not yet been approved, or /unpriv to see what unprivileged users see.

The default is to return all information except the content-field. With this information, one can build a page to display several stories, but with links to the whole story.

In all cases, if you rather want a simple list of titles, timestamp and submitter information, you may append /list to the URI.

At the end of the URI, you may also append an integer representing how many stories you want. This number defaults to the TABOOListDefaultRecords value, but may be both smaller and larger than that, however not larger than TABOOListMaxRecords.

To take some complete examples:

  /news/features/editor/list/5

This would, if the user is logged in and authorized as an editor return a simple list of up to 5 stories from the features section that needs to be approved. The list is suitable to get an overview.

  /news/features/30

will return up to 30 stories from the features section, where the title, minicontent, etc is included. Normal users will often want to view this and then select what they want to read more about.

TODO

Since every resource comes with a lasttimestamp, it should be relatively simple to implement mtime better than it is now, but the question is if all code updates lasttimestamp reliably enough...

The get_styles method is implemented, but just to "make it work right now". It needs to take many conditions into account, such as the mime type requested by the user. It is even possible it should be going into a parent class.

BUGS/QUIRKS

It is non-trivial is to configure both the News and NewsList providers to work and at the same time having the submit.xsp in the same directory. There is a somewhat ad hoc example in AxKit::App::TABOO now.

SEE ALSO

AxKit::App::TABOO::Data::Provider::News, AxKit::App::TABOO::Data::Plurals::Stories

FORMALITIES

See AxKit::App::TABOO.