cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From leo leonid <...@leonid.de>
Subject Re: DO NOT REPLY [Bug 27600] - syntax for unique rows in repeater binding
Date Wed, 17 Mar 2004 18:28:56 GMT

On Mar 17, 2004, at 7:11 PM, Bruno Dumon wrote:

> On Mon, 2004-03-15 at 20:51, Joerg Heinicke wrote:
>> On 15.03.2004 17:57, bugzilla@apache.org wrote:
>>
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=27600
>>>
>>> syntax for unique rows in repeater binding
>>>
>>> ------- Additional Comments From tek@leonid.de  2004-03-15 16:57 
>>> -------
>>> More and more I doubt that this might be the way to go, chasing any 
>>> kind of
>>> xml-file though the XSLT processor  to update some minor syntax 
>>> changes in
>>> repeater binding. I bet there only few users need do update only a 
>>> few files. I
>>> think it's not worth the risk. I'm quite sure there are still more 
>>> uncoverd
>>> issues in connection to the XSLT processing of unpredictable user 
>>> files. While
>>> we don't have a solution, I think we should disable the automatic 
>>> update feature.
>>
>> Ok, asking the list: in which way shall we handle the update in the
>> repeater syntax? The problem is that through an XSLT process the 
>> DOCTYPE
>> must get lost, no chance to save it. I don't find it that problematic 
>> as
>> no Woody file does have a DTD, but of course users can have added 
>> their
>> own ones.
>>
>> a) Ignore the problems (removal of DOCTYPE).
>>
>> b) Point out the possible problem before asking the user for the
>> src.dir. The user will probably have to start the update process
>> multiple times for specifying deeper directory hierarchies to avoid
>> touching unrelated files (or we provide a loop).
>>
>> c) Let him specify a binding.dir or patternset explicitely (binding
>> files are the only files that must be processed by an XSLT at the 
>> moment).
>>
>> d) Do not handle the syntax change automatically at all.
>
> e) Use a text-based search and replace. This preserves the layout of 
> the
> XML (which I consider to be rather important since these files are
> mostly hand-edited).

+1 for e) With this approach whitespace can be preserved, too. (<tag/> 
!= <tag />)


Mime
View raw message