--
Ticket URL: <http://trac.agavi.org/ticket/1389>
Agavi <http://www.agavi.org/>
An MVC Framework for PHP5
_______________________________________________
Agavi Tickets Mailing List
tic...@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/tickets
Comment(by david):
(In [4728]) Allow control over value literalization and whitespace
handling in parameters and settings, refs #1389
--
Ticket URL: <http://trac.agavi.org/ticket/1389#comment:1>
Comment(by david):
A small aside: the code handling this is abstracted in such a way that any
element can use {{{ae:literalize}}} and {{{xml:space}}} as long as the
schema allows it. The config handler simply needs to call
{{{AgaviXmlConfigDomElement::getLiteralValue()}}} instead of
{{{getValue()}}}, then literalization and trimming is performed (or not
performed, depending on what the attributes are).
--
Ticket URL: <http://trac.agavi.org/ticket/1389#comment:2>
* status: new => closed
* resolution: => fixed
Comment:
(In [4734]) reintegrate branches/config-1.1, closes #1385 and #1389
--
Ticket URL: <http://trac.agavi.org/ticket/1389#comment:3>
Comment(by david):
(In [4902]) tests for AgaviXmlConfigDomElement::getLiteralValue(), refs
#1389
--
Ticket URL: <http://trac.agavi.org/ticket/1389#comment:4>
Comment(by david):
(In [4903]) refine tests from [4902], refs #1389, and make them reusable
for testing AgaviXmlConfigDomElement::getAgaviParameters(), for which
we've added many other tests as well (literalization, general behavior,
overwriting in the same node and overwriting via method argument)
--
Ticket URL: <http://trac.agavi.org/ticket/1389#comment:5>
* status: closed => reopened
* resolution: fixed =>
Comment:
Reopening this as I missed something in the [http://www.w3.org/TR/REC-xml
/#sec-white-space White Space Handling section of the XML specification]:
The value "default" signals that applications' default white-space
processing modes are acceptable for this element; the value "preserve"
indicates the intent that applications preserve all the white space. This
declared intent is considered to apply to all elements within the content
of the element where it is specified, unless overridden with another
instance of the xml:space attribute. This specification does not give
meaning to any value of xml:space other than "default" and "preserve". It
is an error for other values to be specified; the XML processor may report
the error or may recover by ignoring the attribute specification or by
reporting the (erroneous) value to the application. Applications may
ignore or reject erroneous values.
We must fix this accordingly, but the question is whether or not the
{{{literalize}}} attribute should behave the same.
--
Ticket URL: <http://trac.agavi.org/ticket/1389#comment:6>
* status: reopened => closed
* resolution: => fixed
Comment:
(In [4908]) Make sure elements inherit ae:literalize and xml:space from
ancestors, closes #1389 again
--
Ticket URL: <http://trac.agavi.org/ticket/1389#comment:7>