[Dev] XML for CPIA

[Alec Flett]

Phillip J. Eby wrote:
> I would imagine that if we were using Python to create items in the 
> first place, the evolutionary pressure would've been towards providing 
> simpler constructors or utility functions as part of the CPIA API, 
> because those could be done by just writing new methods or functions, 
> not by needing to change an XML format.
>
now we're getting somewhere. I'd like to hear some suggestions about how 
this could be done though. I mean is there a smarter way to use 
.update() by fixing up the constructors? I thought .update() worked by 
constructing the object, and then assigning attributes - but maybe what 
you're saying is the arguments to .update() go directly to the 
constructor? If that's the case then yeah, this does get a little 
simpler.... but honestly, I'm still skeptical.

The things that are rubbing me the wrong way with .update() and CPIA are:
1) childrenBlocks & hierarchy - I want a system where the hierarchy is 
implied
1a) A "nice to have" would be making the repository child relationship 
match the childrenBlocks hierarchy - this is extraordinarily painful 
with python at the moment and requires lots of temporaries.
2) itsName vs. blockName - I should not have to declare them seperately.
3) anonymous block names/itsname/etc - for instance menu separators 
don't need itsName but .update() requires them to be consistently 
findable with the same name.
4) Having to repeatedly pass in 'parcel' as the first parameter of every 
single update() call.

You can fix ALL of these problems with a declarative syntax and a 
processor for that syntax.
(2) could be solved by CPIA eliminating blockName and falling back to 
the repository name - but I think we'd have to stop copying blocks to 
//userdata to solve that problem.

An alternative that I was debating was some sort of big hierarchical 
list/dict system directly in python like:

[Menu, { blockName='FileMenu', title=_('File') },
  [NewMenu, { blockName='NewMenu', title=_('New...'), ...},
    [MenuItem, {blockName="NewMessageItem", ..}],
    [MenuItem, {blockName="NewNoteItem", ...}]
  ]
]

But this is basically xml-translated-into-lists-and-dicts and seemed a 
little silly - I mean when writing it its harder to figure out the 
correct syntax, brace balancing, and so forth.. furthermore you'd STILL 
have to write some sort of processor for this datastructure. Since there 
are tools to do this for you with XML (emacs, eclipse, you name it) it 
just makes more sense to me to do this in XML

If you have another specific suggestion for improving cpia's API to make 
this cleaner, I'm all ears.

Alec

> In other words, I'm suggesting that the verbosity of defining blocks 
> in Python comes from CPIA-defined features, not from Python.  The 
> simplest way to improve this would be to enhance the CPIA API -- and 
> not to define another data format.  (Which doesn't make anything you 
> still have to do in Python any easier.)
>

> Also, certain features of CPIA (such as blockName vs. itsName) might 
> be able to go away if we're not copying items -- or the constructors 
> might be changed to set blockName=itsName.  There are lots of 
> possibilities for simplifying object creation and reducing redundancy 
> that are available in Python, as Bryan has also pointed out.
>