Martin Busik wrote:
> Hi Darin,
>
>> This looks really interesting. What would hold me back, personally, is
>> integrating it into other methods. For example, I usually have a stock,
>> or
>> template, XML file, and then use XML::Twig to read that,
>> add/remove/modify
>> what I need to, and write it out (to a file, to stdout for apache to
>> send,
>> whatever). If I could do something like:
>> $twig->insert_decl('after',
>> twig_element "out", content {
>> #...
>> });
>
> I'm haven't used XML::Twig before, what is the meaning of
> insert_decl('after',xxx) ?
> May be, you can give me an another example?
You should look at XML::Twig. It makes XML cool - like perl. :-S
"insert_decl" is not part of XML::Twig. It's a new method that would provide
some sort of glue between your code and XML::Twig, to allow me to use
XML::Twig for parsing and finding XML nodes, while giving me the power of a
declarative syntax for adding nodes (the XML::Twig method for adding isn't
horrible, but it's not quite this clean).
$twig, in the above example, would be an object that represents an element
or node in the XML structure, containing the tag name, any attributes (and
their values, of course), embedded text and sub-elements (and their tags,
attributes, etc.). XML::Twig further has some "where" tags for inserting,
pasting, whatever, that have defined meanings. The word 'after' means to
be the element after the current one, with the same parent. e.g.,
stuff
If $twig was pointing to the node named 'bar', and I inserted a
node 'baz' "after" it, I'd get:
stuff
The rest should be obvious - I used "twig_element" instead of "element"
since I'm not sure what would be needed there. Perhaps you can get away
with just "element" - but perhaps you'd need a different method.
>> [element vs. opt_element]
>> I would suggest that $value as undef should do this, if it's "", then it
>> should insert the empty element. In fact, I'd merge your element and
>> opt_element together:
>> element "abc"; #creates the "abc" element, empty
>> element "abc", ""; # same thing
>> element "abc", undef; # no-op
>
> I have cases in my projects, where xml schema specifies that there must me
> an
> element, independent of its contents. If I'd select a null from a
> database, I had to convert it to "", if the appropriate element is
> mandatory. Therefore I like to keep the two cases distinct.
I'd find:
element "abc", $var || ''; # or, better, C<$var // ''> if using perl 5.10
to be MUCH more obvious (and perlish), personally.
> Another example may show the benefit when there are more hierarchy levels:
>
> opt_element "contact-data", content {
> opt_element "email", $email;
> opt_element "phone", $phone;
> opt_element "fax", $fax;
> opt_element "postal-address", content {
> opt_element "street", $street;
> opt_element "city", $city;
> opt_element "zip-code", $zip;
> }
> }
>
> if all of the above variables contain either undef or "", no output is
> generated
> at all. IMO this makes it more readable.
Personally, again, I'd be surprised at this behaviour if any of these
variables were "", but not if they were all undef. The fact is, undef
and "" are *different* - use them as such. If your input is treating them
as the same, the input layer (i.e., the code querying from the database)
should do the mapping, and leave this lower-level code to be complete,
concise, and clear.
>> Also, how do I put an element in the middle of the text of another
>> element?
>> Does this work?
>> element "p", "a paragraph with some ", element("b", "bold"), " text";
>> I'm guessing not. If my guess is correct, I'd suggest at least adding
>> that
>> as a limitation in the POD.
>
> Your point is good. It is possible, but there is a syntacticall
> difference: (I haven't mentioned the "text" function):
>
> element "p", content {
> text "a paragraph with some ";
> element "b", "bold";
> text " text";
> }
Interesting. A bit awkward, but that may be the best you can do to keep up
with all the other sugar you're offering :-)
> element "name", "scalar-value" is expanded to element "name", text
> "scalar-value"
>
> Do you have any idea for naming a package with that functionality?
I'd suggest one of the following:
# you can't read, I'm guessing
XML::Writer::Declarative
# if you can/will integrate into XML::Twig and/or other read/write
# XML modules, this would be better
XML::Declarative
I'm sure someone else can come up with something better :-) (You may also
try poking the monks at
www.perlmonks.org)
