lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Calculation Summary columns selection


From: Greg Chicares
Subject: Re: [lmi] Calculation Summary columns selection
Date: Wed, 08 Nov 2006 03:58:17 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2006-11-8 2:58 UTC, Evgeniy Tarassov wrote:
> On 11/7/06, Greg Chicares <address@hidden> wrote:
>>
>> In practice, I think a customized 'configurable_settings.xml'
>> is always distributed. Any values in that file should override
>> the defaults hardcoded in C++. IOW, if the new calculation-
>> summary-column-selections entity is changed, then saving the
>> file should change only that entity.
> 
> Does this mean that any auxiliary formatting in the
> configurable_settings.xml has to be preserved?

We can ignore insignificant whitespace.

I think xmlSaveFormatFile() (called through your favorite C++
wrapper) handles whitepace well enough--we don't need to
preserve

  <crazy/>
              <misaligned/>
          <formatting/>

However....

> Like when user comments
> in some values in the xml file.
> An (insane) example of configurable_settings.xml:
> 
> <?xml version="1.0"?>
> <configurable_settings>
>  <!-- bring home some food tonight -->
>  <xslt_directory>/etc/custom/cslt/dir</xslt_directory>
>  <!-- brush cat's teeth tomorrow -->
> </configurable_settings>

I could imagine someone seriously writing this:

  <!-- All '.xs?' files belong in this directory. -->
  <xslt_directory>/etc/custom/xslt/dir</xslt_directory>
  <!-- Specify the customary extension for your spreadsheet. -->
  <spreadsheet_file_extension>.ss</spreadsheet_file_extension>

However, as it stands, this class seems to reject comment tags.
I think it rejects any tag that it doesn't explicitly recognize.
Probably it would be better if it gave a warning for elements
that it doesn't recognize, and ignored xml comment tags silently.
An unrecognized tag shouldn't be a fatal error--treating it that
way impedes backward compatibility.

What about duplicate entities? My local copy of this file has
  <skin_filename>xml_notebook_coli_boli.xrc</skin_filename>
  <skin_filename>xml_notebook.xrc</skin_filename>
Sometimes I want to switch between one and the other, and I don't
want to retype the names...so I just rearrange them, and whichever
comes last governs the behavior. I wouldn't want to lose them
because I changed some other entity--unless I had another way of
accomplishing the same thing, like

<!--
  Keep both of these possibilities here in this comment...
  <skin_filename>xml_notebook_coli_boli.xrc</skin_filename>
  <skin_filename>xml_notebook.xrc</skin_filename>
  ...and copy and paste exactly one of them outside the comment.
-->
  <skin_filename>xml_notebook.xrc</skin_filename>

> Do we have to preserve these user comments or could we just discard
> it? If we could, then life will be much easier. :)

How do other applications that edit xml files handle this, as
in the example where I want to preserve two different values
in the file so that I can easily switch between them?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]