Nicholas Van Weerdenburg
11/25/2004 8:55:00 PM
Hal,
Would this be appropriate for the YAML equivalent of DTDs?
In XML this can be handled by DTDs (and I assume schemas and Relax NG,
but I'm not familiar with those). Oddly, I don't think it's a required
part of the spec, so different parsers would or would not display the
default attributes, say when rendering to a web page. I think IE showed
them, but Mozilla didn't which bummed me out.
It was very nice for hand-editing, saving a lot of typing, but sometimes
awkward when I hadn't looked at the XML for a while, since it was hidden
in the DTD, and not explicit in the document I was looking at. An
editor that showed defaults in a ghost-like overlay would have been
helpful there. But overally, the saving of typing vastly outweighed the
lack of explicitness, since I was authoring a lot of XML by hand. Plus
the resulting common-case files were much simpler and easy to read.
If it specifically about Ruby serialization, it may make more sense to
have a ruby library that hacks yaml, like you do. I'd hate to have to
manage a dtd just for defaults- why not add it to the code? Also, then
it would possible provide a common mechanism for other persistence
mechanisms- XML, etc. (though maybe that's over generalizing). I suppose
the downside of this is that yaml is not self-documenting then, which is
an important/nice aspect, especially if you want to use the YAML in
downsteam applications (other languages, style-sheet renderings, etc.).
On the other hand, the code should be self-documenting, ideally. But a
dtd-type doc provides the documentation outside of the ruby context,
such as for handediting. I guess that's the problem with multiple
demands- it stresses the design :).
One thought...
require "yaml"
require "persistence/defaults" # hacks YAML to insert/remove defaults
class Document
default_value :author => "Anonymous Coward" # explicit initial
value doesn't easily equal a wanted default.
....
end
Nick
Hal Fulton wrote:
> _why,
>
> Just saw you post and was reminded to ask: How are we coming on a
> "good" solution to my default values problem?
>
> For those curious, what I want to do is establish defaults for
> fields in an object, such that:
>
> 1. When I dump an object, fields that still have the default
> values will be left unspecified.
> 2. When I load an object, unspecified fields will be given their
> default values.
>
> Right now I'm using an initialize_copy hack and some other stuff.
>
> Something like this can greatly compress the YAML, I've found.
> Very convenient when you read or hand-edit the file.
>
>
> Cheers,
> Hal
>
>