yet another xml generator

Hello,
there are some modules aimed to make the xml generation easy -  =

XML::Generator,
XML::Writer and XML:Writer::Simple, for example.

For my needs, these are to "verbose" and there is too much code necessar=
y
to express the structure of the resulting xml. So I wrote a piece of cod=
e
which uses a bit more declarative approach. If somebody finds it useful,=

I'd put it on CPAN - or submit it to an existing module.

Let's look at this code:

$str =3D element "outer", content {
element "inner" =3D> content {
attribute id =3D> 1;
element "abc", undef;
opt_element "def", $value;
element "ghi", "bb & cc";
}
}

provided that $value contains "dummy", $str contains the following resul=
t:

<outer>
<inner id=3D'1'>
<abc/>
<def>dummy</def>
<ghi>bb & cc</ghi>
</inner>
</outer>

provided that $value is undef or "", $str would contain:

<outer>
<inner id=3D'1'>
<abc/>
<ghi>bb & cc</ghi>
</inner>
</outer>

Another example:

$str =3D opt_element "abc", content {
opt_element "def", $value
}

provided $value is undef or "", as result, $str would contain "".
If $value would be "zzz", $str would contain:

<abc>
<def>zzz</dev>
</abc>

Any comments?

Cheers,
Martin

Martin Busik wrote:

> Hello,
> there are some modules aimed to make the xml generation easy -
> XML::Generator,
> XML::Writer and XML:Writer::Simple, for example.
>
> For my needs, these are to "verbose" and there is too much code necessary
> to express the structure of the resulting xml. So I wrote a piece of code
> which uses a bit more declarative approach. If somebody finds it useful,
> I'd put it on CPAN - or submit it to an existing module.

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 {
#...
});

that'd be really  - a huge time-saver on some of my projects.

> Let's look at this code:
>
> $str = element "outer", content {
> element "inner" => content {
> attribute id => 1;
> element "abc", undef;
> opt_element "def", $value;
> element "ghi", "bb & cc";
> }
> }
>
> provided that $value contains "dummy", $str contains the following result:
>
> <outer>
>   <inner id='1'>
>     <abc/>
>     <def>dummy</def>
>     <ghi>bb & cc</ghi>
>   </inner>
> </outer>
>
> provided that $value is undef or "", $str would contain:

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

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.

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?

> [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.

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.


> 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";
}

element "name", "scalar-value" is expanded to element "name", text
"scalar-value"

Do you have any idea for naming a package with that functionality?

Cheers,
Martin

"Martin Busik" <martin.busik@busik.de> wrote:

> if all of the above variables contain either undef or "", no output is
>  generated
> at all. IMO this makes it more readable.

I recommend to make this a setting for each, i.e.

undef -> generate empty element, or no-op, or exception
""    -> generate empty element, or no-op, or exception

--
John

Arachnids near Coyolillo - part 1
http://johnbokma.com/mexit/2006/05/...oyolillo-1.html

Martin Busik wrote:

> Hi Darin,
> 
>
> 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  - 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.,

<foo><bar>stuff</bar></foo>

If $twig was pointing to the node named 'bar', and I inserted a
node 'baz' "after" it, I'd get:

<foo><bar>stuff</bar><baz /></foo>

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.
 
>
> 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.
 
>
> 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)

On Mar 18, 2:38=A0am, "Martin Busik" <martin.bu...@busik.de> wrote:

> there are some modules aimed to make the xml generation easy - =A0
> XML::Generator, XML::Writer and XML:Writer::Simple, for example.
>
> For my needs, these are to "verbose" and there is too much code necessary
> to express the structure of the resulting xml. So I wrote a piece of code
> which uses a bit more declarative approach. If somebody finds it useful,
> I'd put it on CPAN - or submit it to an existing module.
>
> Let's look at this code:
>
> $str =3D element "outer", content {
> =A0 =A0 =A0 =A0 element "inner" =3D> content {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 attribute id =3D> 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 element "abc", undef;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opt_element "def", $value;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 element "ghi", "bb & cc";
> =A0 =A0 =A0 =A0 }
>
> }
>
> provided that $value contains "dummy", $str contains the following result:=[/color
]

>
> <outer>
> =A0 <inner id=3D'1'>
> =A0 =A0 <abc/>
> =A0 =A0 <def>dummy</def>
> =A0 =A0 <ghi>bb & cc</ghi>
> =A0 </inner>
> </outer>
>
> provided that $value is undef or "", $str would contain:
>
> <outer>
> =A0 <inner id=3D'1'>
> =A0 =A0 <abc/>
> =A0 =A0 <ghi>bb & cc</ghi>
> =A0 </inner>
> </outer>
>
> Another example:
>
> $str =3D opt_element "abc", content {
> =A0 =A0 =A0 =A0 opt_element "def", $value
>
> }
>
> provided $value is undef or "", as result, $str would contain "".
> If $value would be "zzz", $str would contain:
>
> <abc>
> =A0 <def>zzz</dev>
> </abc>
>

Have you looked at HTML::Element? It lets you create elements from a
Perl structure:

http://search.cpan.org/~petek/HTML-....pm#@elements_=
=3D_HTML::Element-%3Enew_from_lol(ARRAYREFS)

Your first example would be:

my $elt =3D HTML::Element->new_from_lol(
[ outer =3D>
[ inner =3D> { id =3D> 1 },
[ 'abc' ],
$value && [  def =3D> $value ],
[  ghi =3D> 'bb & cc' ],
]
]);

print $elt->as_XML;

XML::TreeBuilder is based on HTML::Element and can be used to process
XML.

You could add a function opt_elt to avoid repeating the $value, and
you would be quite close to your original syntax, while getting the
rest of the XML::TreeBuilder fetures for free.

--
mirod