mirror of
https://github.com/ezyang/htmlpurifier.git
synced 2025-08-07 06:36:44 +02:00
Update documentation.
git-svn-id: http://htmlpurifier.org/svnroot/htmlpurifier/trunk@418 48356398-32a2-884e-a903-53898d9a118a
This commit is contained in:
@@ -17,18 +17,9 @@ are passed. These classes are: HTMLPurifier::*, Generator::generateFromTokens
|
||||
and Lexer::tokenizeHTML. However, whenever a valid configuration object
|
||||
is defined, that object should be used.
|
||||
|
||||
-- the following is projected changes to the configuration system --
|
||||
|
||||
In relation to HTMLDefinition and CSSDefinition, there are going to be some
|
||||
major structural changes to enable the easy configuration of these objects.
|
||||
Due to the intricacy of these objects, it's not feasible to ask an average
|
||||
user to twiddle around with an element and its 20 other dependencies. However,
|
||||
these objects are the only possible point where change could occur in the
|
||||
context of configuration.
|
||||
|
||||
The solution is to introduce a special class of directives that influence the
|
||||
*construction* of the Definition object. A standard call pattern would look
|
||||
like:
|
||||
In relation to HTMLDefinition and CSSDefinition, there is a special class
|
||||
of directives that influence the *construction* of the Definition object.
|
||||
A standard call pattern would look like:
|
||||
|
||||
1. Client calls Config->getHTMLDefinition()
|
||||
2. Config calls HTMLDefinition->createNew(this)
|
||||
|
Reference in New Issue
Block a user