John Anderson wrote:
I'd prefer a single format that works for all kinds of repository data, not just CPIA blocks. If I were going to optimize editing and construction of CPIA blocks, I'd much prefer a GUI builder to yet another XML format.Fair enough. Show me a GUI builder and I'll stop pushing for a declarative format for the UI. But the thing is, we've always had a single format for all kinds of repository data - you could always declare any instance in Python. pje's just made it easier. It doesn't mean there aren't more appropriate means for specific types of items, like the UI. Having a way to "compile" and "decompile" repository data would be a useful if we had a GUI builder, but it would be much more useful if the format it used was familiar -- after all look how many people took the time to understand andi's pack XML format.Woah, lets get some context here. Andi's pack format is for defining low level relationships between data types in the repository . This is a hierarchical tree of UI, which is in fact the original purpose of SGML/HTML, which is the inspiration for XML. This is a VERY common idiom in toolkits. Your argument seems to be "anything in xml is hard to learn"? Think of it this way: you can instantiate wx widgets anytime in C or Python, and yet we use the xrc format for our dialog boxes, because writing that in python is a big pain in the neck. pje's .update mechanism is obviously a vast improvement, but its still not appropriate for the UI. Finally, Python would probably load faster than XML, produce better error messages, require less maintenance, and be more flexible than yet another XML format.ok...lets break it down. Speed: we're talking milliseconds. If that's an issue, we shouldn't be using python at all. Error messages: How do you figure? Are python syntax exceptions easier to read than error messages that come from a parser that understands the purpose and context of the data it is reading? Flexibility: That isn't a goal of this format. parcel.xml is pretty darn flexible, and yet it sucks and we're moving away from it. I feel like folks are leaning towards pje's python .update mechanism as the GUT of item declaration.. and I think that's a mistake and I think its because people feel burned by parcel.xml. Its the underlying API sure, but if we never HAD parcel.xml, I can guarantee you that I wouldn't be the first one to say ".update() is really tedious for the UI - lets find a simpler way to declare this stuff.. what about xml?" Alec John |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
