Alec Flett wrote:
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.
Based on the amount of time we spent on parcel XML, I suspect that if
the amount of work to build/maintain yet another XML format is not much
different from the amount of work to build a simple GUI builder, and I
think the GUI builder has a bigger payoff.
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"?
Actually, it's not that XML is hard to learn, it's learning the
concepts you need to encode in XML (e.g. CPIA) and how they map to XML.
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.
Almost nobody uses xrc directly, it's the format that is edited by the
GUI tools.
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?
Regarding errors, I've spent much more time trying to figure out Parcel
XML errors than I ever spend figuring out python errors. Usually this
is due to the limitations of parsing XML with tools we use -- they just
don't give you the same granularity as the Python compiler. I can't
tell you the number of times I've gotten the parcel XML message that
say nothing useful, or the number of times I've had to comment out the
parcel XML exception handler to figure out where the error really
occurred.
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
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
|
