Hi,
On 21.08.2010 18:28, Jason Tackaberry wrote:
> Having implicit conversion between dashes and underscores makes the API
> cleaner, since you can reference XML attributes the same way you
> reference python attributes and you can pass attributes as kwargs.
That was the basic idea. The use-case for xmlutils is config files and
stuff like that. I wrote it for kaa.xmpp and it can handle simple stuff
but not complex xml trees withe elements and text inside one element.
But we don't need this. That gives us the following possible structure:
<a>
<b c="attr"/>
<d e="attr">
<f>Text</f>
</d>
<a>
> That is:
>
> >>> node.add_child('url', 'http://foo', mplayer_options='-demuxer
> lavf')
> >>> print node.mplayer_options
That was the plan. a.d.f.e == 'attr' and a.d.f.content == 'Text'
> Versus:
>
> >>> node.add_child('url', 'http://foo')
> >>> node['mplayer-options'] = '-demuxer lavf'
> >>> print node['mplayer-options']
How do you want to handle sub-elements?
> The former is more magical, but perhaps more intuitive. But it has the
> (I think fatal) flaw of conflicting with the Node class namespace, so
> you could never have an attribute called, for example, 'save'. And it
> is, as you say, not zen-compatible.
And you are not allowed to use an attribute or sub-element called content.
> Instead of accepting kwargs for add_child, I'd prefer explicitly
> accepting a dict, and always using __getitem__/__setitem__ to avoid the
> collision problem with python attributes.
>
> >>> node.add_child('url', 'http://foo', {'mplayer-options': '-demuxer
> lavf'})
> >>> print node['mplayer-options']
Always? Also for children?
a['d']['f']['e'].content? This does not look as nice as the other style. :)
> dischi, can we deprecate __getattr__ and the kwarg support in add_child?
> (I'll implement it.)
It is not only about implementing the stuff in xmlutils, it is about
changing everything that uses it: kaa.config (IIRC we use it for
parsing), FXD parser, kaa.xmpp (well, it is only used in my PhD thesis
and there is not connection between kaa.xmpp and Freevo in SVN, only on
my HD), the Freevo 2.0 GUI code and maybe other stuff. First we need an
idea how it should look like for
a. Node attributes
b. Children
c. Text content
Dischi
--
Anything labeled "NEW" and/or "IMPROVED" isn't. The label means the
price went up. The label "ALL NEW", "COMPLETELY NEW", or "GREAT NEW"
means the price went way up.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
