We need to remembert that we're also building a framework, not just
Chandler the application. It's important for some applications you might
build out of the framework (or even for some Chandler parcels) to easily
create any schema and instances, not just U/I centric schemas and
instances, even though Chandler's schema is currently dominated by
schema U/I. Besides, the best way to create instances in U/I isn't with
parcel XML or even a custom U/I centric XML, it's through direct
maniplation in the application itself.
So, I think it's a big mistake to make creation of instances and schema
tied to any one particular domain, U/I or something else. We can
certainly come up with a reasonable syntax that's not domain specific --
after all programming languages have been doing that for years. Then
let's concentrate on putting U/I instance creation in the application,
like Interface Builder and all the other GUI builders.
John
Phillip J. Eby wrote:
At 01:20 PM 6/27/2005 -0700, Ted Leung wrote:
If we are seriously considering going to a domain specific XML for
0.7, then I don't think its worthwhile to spend a lot ot time
patching parcel.xml.
I'm fairly sure I've spent more time discussing the change than I will
on implementing it. For that matter, I will probably spend more time
running the tests afterward. ;)
Also, there are no specific proposals outstanding for a hypothetical
domain-specific format.
Currently, almost 6000 of Chandler's 10000 lines of parcel.xml reside
in osaf.framework.certstore.data, and almost half of the remaining
4000 lines are in osaf.views.main. There are less than 40 parcel.xml
files, with a median size of about 24 lines. Only 7 parcel.xml files
have more than 100 lines of XML in them. I think that this is a
pretty good indication that the schema API has displaced most
everything but UI and certain specialized data.
For specialized data like the certstore, I don't see that the
parcel.xml format buys anything, since it's just an intermediate
conversion format. One might as well just directly import such data
to the repository. If I added my previously-proposed "create_parcel"
hook, then certstore.data.__init__ could read something like this:
def __create_parcel__(parcel):
for filename in certificate_filenames:
# ... read the file for info
# create a certificate object w/parcel as the parent
Certificate(name, parcel, type="root", trust=3, ...)
And then we could just dump the original certificate files into the
certstore/data directory, rather than having to paste them into a
parcel.xml file. In other words, if the data source is already
available in some computer-readable form, one might as well let it be
loaded by code at parcel creation time.
(In fact, I anticipate that at some point the loading of parcel.xml
files themselves will be done in similar fashion, albeit automatically
rather than by defining a __create_parcel__ function.)
Anyway, this pretty much leaves the GUI use cases, and there could be
a custom XML format for that, but so far I've only seen discussion of
"something XUL-like" without getting much more specific.
I suspect, however, that there are some tweaks possible to the
parcel.xml format that would alleviate its current issues for GUI
definition. These would be changes both to the parser (e.g. to allow
nesting items as references), and to the actual schema (e.g.
redefining many block types to separate interface from behavior, ala
Eclipse UI delegates). I would also like to establish some guidelines
to clean up some of the naming conflict messes (where there are items
with the same name as the class) and eliminate the need to use
itemClass altogether.
But, these would be evolutionary changes rather than revolutionary, at
least with respect to the parcel loader. Honestly, unless somebody
just puts together some really smashing idea for a GUI-specific XML
syntax (and soon!), I think that minor improvements to the loader and
the schema will be fine for getting us through 0.7 at the very least.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
