App-Changelog2x
view release on metacpan or search on metacpan
bin/changelog2x view on Meta::CPAN
is processed and all others are ignored.
=item verStr[,verStr[,verStr]...]
Generally, the value is assumed to be a comma-separated list of versions as
defined by the C<version> attribute of the C<< <release> >> tag. As each
release block is considered, if the version is present in the user-provided
list then the release block is processed. There is (currently) no sort of
wildcarding or regular-expression matching provided for the list.
=back
Any string that is I<not> C<first> or C<all> is assumed to be a list of
versions. If it badly-formed, it will likely not match any of the release
blocks, and none will be processed.
=item --order STRING [ div, dl, html, text, ul ]
This parameter should be a string whose value is one of C<ascending> or
C<descending>. It controls the order in which the release blocks are sorted
by their C<date> attributes. The default is C<descending>, which places the
newest version at the top of the resulting document.
Date-sorting is used as proper sorting of version strings is usually
problematic. Dates expressed in ISO 8601 will sort correctly when sorted as
text. The only caveat is that two releases close to each other in different
timezone-offsets could sort incorrectly, since the sorting would key off of
the hours portion before taking the offsets into consideration. This is a
limitation of XSL's sorting capabilities.
=item --class STRING [ htmlnewest, htmlversion ]
For the C<htmlnewest> and C<htmlversion> output templates, the overall XHTML
content is much smaller than the other XHTML-oriented stylesheets. To this
end, this option allows the user to specify an explicit CSS style-name to give
to the containing elements that are generated. In the case of the
C<htmlnewest> stylesheet, this is a C<< <div> >>. In the case of
C<htmlversion>, it is a C<< <span> >>. See the documentation below
(L</"Template Option Values">) for the default class names for each of the
templates.
=item --css URL [ html ]
Specifies a URL to be used as the basic CSS stylesheet when rendering a
complete XHTML document. If given, a C<< <link> >> element is created in the
document's C<< <head> >> section with the C<rel> attribute set to
C<stylesheet>, the C<type> attribute set to C<text/css> and the C<href>
attribute set to the value of this parameter. No checking is done on the URL,
and no constraints are applied. The URL may be absolute, relative, etc.
The only distinction between this parameter and the next one, is that this one
will occur first in the C<< <head> >> block, and thus be first in the CSS
cascade model.
=item --color URL [ html ]
As above, but this parameter is used to allow a second URL to be specified,
one that will follow the previous one in the CSS cascade order. This allows
the user to have a "main" stylesheet with font, spacing, etc. declarations
while also using this option to select between color schemes for text,
backgrounds, etc. (hence the choice of C<color> as the option name).
=item --javascript URL [ html ]
Like the two CSS-related options above, this allows the specification of a URL
to be included in the document head-section. Unlike the previous, this URL is
assumed to refer to a Javascript resource. As such, it triggers the generation
of a C<< <script> >> element with a C<type> attribute set to C<text/javascript>
and a C<href> attribute set to the value of this parameter.
This element occurs I<after> any content specified in the C<headcontent> (or
appliction option C<headcontentfile>) is included in the output. Thus, it can
safely refer to any functions, etc. defined in that content.
=item --headcontent STRING [ html ]
=item --bodycontent STRING [ html ]
These options allow for the user to provide arbitrary content for the C<<
<head> >> and/or C<< <body> >> sections of the XHTML document, when rendering
a full document with the C<html> template.
Realizing that the generalized stylesheets provided by this package won't fit
every user's needs, these options are a sort of "wildcard" pass to include
anything that can't be achieved by the existing stylesheet-targeted
parameters. Note that as command-line arguments, they are limited as to how
complex the values can be. Hence the C<headcontentfile> and C<bodycontentfile>
options, which are handled by the application before processing is handed off
to B<XML::LibXSLT>. Also note that the file-oriented options to the
application will override any values passed in via either of these options.
=item --xsltparam NAME=VALUE
Allow for the user to pass additional parameters to the XSLT processing phase
beyond those defined here. If you have written your own XSLT stylesheets to
use with the C<template> and/or C<templateroot> options, you may also have
need for your own XSLT parameters. You may provide as many of these as you
wish with this option. Each occurrence should have a value of the form,
C<name=value>, where C<name> is the name the parameter will have when passed
to the XSLT processor, and C<value> will be the content of the parameter.
=back
=head2 Template Option Values
This application installs with (at present) nine pre-defined stylesheets
available for use. These are the potential values of the C<template> option
to the application (the default being C<html>). The stylesheets fall into
two groups: XHTML and plain-text.
=head3 XHTML templates
These templates produce content that is either complete, valid XHTML, or
snippets that are conformant and should be easily included in larger
documents:
=over 4
=item html
This is the default stylesheet, which generates a complete XHTML document.
( run in 0.496 second using v1.01-cache-2.11-cpan-85f18b9d64f )