On 4/28/2010 8:03 PM, Justin J Stark wrote:
There are two types of filters: input and output. When you publish a
post, the input filters are applied, and the raw content as well as
the filtered content is saved in the db. The input filters will put
the content in a neutral state such that output filters can convert it
to whatever format is required.
Upon thinking about this further, it could be a requirement that every
filter is a codec that both encodes and decodes between its native
format and the intermediate state. This would ensure that every format
had a way to render between its native format and the intermediate format.
But what would be $post->foo_filtered? How do we know which filters
to apply. Depending on my type of post I may want different filters
applied (hence why drupal does what it does).
Themes should ultimately decide what output format they require. If the
theme is XHTML, then it should demand XHTML output, and requires
(http://wiki.habariproject.org/en/pluggable#requires) a plugin that
provides XHTML filtering.
In every case in the theme output, the request should be for whatever
produces XHTML output.
eg. $post->foo_xhtml
I imagine a process that is more like the following:
1. User enters content in a format designated in advance as appropriate
for the field in question.
2. Input filters convert sections of the content that may be specially
marked into specific intermediate bundles. (Useful for things like
converting LaTeX to images.)
3. Remaining content is converted from the native format to the
intermediate format using the input codec.
4. Input filters are applied (pre-save) to the intermediate format.
(Useful for things like inserting links from product names to Amazon
Associate ID Links, where the link is already identified in the
intermediate format.)
5. The intermediate format and original content input are both stored in
the database.
6. Upon request by a visitor, the intermediate format for a post is
recalled from the database.
7. Output filters are applied (post-save) to the intermediate format.
(Useful for things like inserting weather maps and other things that may
change after the post is saved.)
8. The filtered intermediate format is converted to the necessary output
format using the appropriate codec.
Step 2 allows for plugins to pull identifiable sub-content into
intermediate format prior to being otherwise mutilated by the default
filtering codec.
Some logic between steps 6 and 8 could determine if a post would be
altered enough to affect client-side caching.
It is my opinion that we should do as much as possible to avoid
complicating an install by putting the filter configuration/selection
process in front of the user.
For most users, a one-time selection of a default for the format of
their input is enough for the life of their blogs. By enabling and
disabling plugins, it would be possible to change the defaults.
A page similar to this one in Drupal could be useful for users with more
complicated needs, but it should not be displayed by default:
http://demo.opensourcecms.com/drupal/?q=admin/settings/filters
U/P: admin/demo123
In my opinion, Drupal's default configuration for input formats is terrible.
It might be worthwhile to have Habari's default be very basic, and
anything more complicated require an additional plugin. Habari's
default would allow you to select between any formats that were
initially installed
So, if you wanted to have the ability to select different input formats
as defaults for different content types, to manually re-order the
priorities of filters, or to select input formats per-field as you were
entering content, then you would need to enable some Advanced Formatting
plugin. This plugin could ship with Habari, but would not be enabled by
default, and would allow you to manage filters and formats in more detail.
Owen
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/habari-dev
