I agree with all of Bryan's comments.
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. 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.
Finally, Python would probably load faster than XML, produce better
error messages, require less maintenance, and be more flexible than yet
another XML format.
John
Bryan Stearns wrote:
I don't see why this is necessary:
- It's another syntax to learn, but who'll learn it? Most parcel
developers who are adding item types will mostly just be writing
detail-view trees of blocks; I'm looking forward to rewriting the
detail view's parcel.xml as Python, so the ready examples that
developers will have will be Python. Few non-Python developers will be
customizing other parts of the UI, at least in the next year or so.
- The syntax isn't better: while it might be familiar to HTML
programmers just
because it's XML, it isn't simpler or terser than the equivalent Python
code given in the example.
(and what's with the "<ref:
22d5dbf0-0921-11da-ab3d-00054e47c157>"?)
...Bryan
Alec Flett wrote:
Here's a very quick overview of my XmlForCpia proposal. I have already
implemented the parser that does all of these things, as well as a tool
that dumps the current block structure from a currently-running
chandler into XmlForCpia format (in fact that's where the same code
comes from)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
