lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Calculation Summary columns selection


From: Evgeniy Tarassov
Subject: Re: [lmi] Calculation Summary columns selection
Date: Thu, 9 Nov 2006 01:29:47 +0100

On 11/8/06, Greg Chicares <address@hidden> wrote:
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>

I have committed a change which, i think, satisfies all the cases you
have mentioned so far. The algorithm writes back the settings into the
xml file as such:
- open the existing configuration_settings.xml
- for each class member:
- - find the last corresponding xml node (with the needed name)
- - if no such a node and the value is not a default one, then create a new node
- - if there is a node, then replace its content with the new value
- endfor

This ensures that we only modify nodes that contain the values we are
working with and it does not strip no formatting, no comments and no
other data, since we do not recreate the file, we only modify it.

> 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?

I guess they mostly overwrite the file content. IMHO the reason for
that could the fact that human logic is really clumsy and could not be
easilly expressed in formal language. :) What if someone adds comments
_inside_ the node, like so:
<xslt_directory>
  <!-- this is a link in my home directory, but the real path would
be /home/eta/xslt -->
  /public/lmi/xslt
</xslt_directory>

And it would be really difficult to try to expand our program's logic
to support such comments, since we will really need to couple the code
dealing with nodes content and the algorithm for importing/exporting
the data from/to the xml. The calculation summary column selection
node could even allow comments to be inserted between column names,
and it should work, since the code reading values, automatically
strips comments inside values.

Oh, i think it could be a potential bug. I have not tested it, but i
think the following example should make the application work
incorrectly:

<?xml version="1.0"?>
<configurable_settings>
   <calculation_summary_colums>
       <!-- first column -->Outlay<!-- second column -->AcctVal_Guaranteed
   </calculation_summary_colums>
</configurable_settings>

Note that there is no space between comment and values. ASAICS
xml_lmi::get_content method used to read values would return the
following for the column list:
"#LF        OutlayAcctVal_Guaranteed#LF    "
Since it silently discards the comment nodes, which makes the text
originally separated to be concatenated.




reply via email to

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