I suspect the majority of items happen to be UI, but that's only because most of the kinds of data are used for UI. There isn't anything special about UI items, in fact all the items that are Chandler expects to be in a "new" repository will typically be populated in the repository the same way, e.g. ItemCollections, templates for ContentItems, and various housekeeping data structures for finding things easily. So I think it's a mistake to come up with two ways to populate items in the repository, one for UI and one for non-UI. I think we couldn't come up with a single, simple to use, format that works for both.
John
John
Phillip J. Eby wrote:
At 10:52 AM 5/11/2005 -0700, Lisa Dusseault wrote:
Not that there's any rush on this anyway and probably not a 0.6 priority -- I was just responding to some design implications.
But, is it possible that we don't need new namespaces anyway? It's possible to define our XML schema used in parcel definition, such that any element or attribute used in parcel definition files would come from our definition format, thus these could all appear in a single namespace. Then, we could set it up such that 3rd party parcels never defined new element or attribute names, just new data.
However, note that this is definitely a rehashing of old arguments (and a sign of my obsession over things like namespace). Morgen & I looked at this a year ago and tried to remove the need for a 3rd party parcel to define any new XML element or attribute names. It got a little awkward to clean this up -- the "hack" I perceived made the syntax simpler once you grokked the hack. It's related to another "hack" which is to use namespace prefixes inside attribute values -- another XML namespace usage no-no. Now that we're making parcel definition changes, it may be much easier to avoid using namespaces and prefixes at all when referring to stuff inside another parcel.
Possibly so; I think this will be easier to see once the existing parcel.xml files lose their schema parts. I also think it's quite likely that, except for UI items, it may become simpler for people to define any parcel-supplied items in their Python code. The import mechanism Andi created to support schema definition is not restricted to schema items only, and so far I've found it quite easy to use.
If that turns out to be the case, then it opens the door to having an XML dialect optimized for creating Chandler UI items that would be easier to learn than generic parcel.xml format. And, for simple one-offs like WakeupCaller and the like, it's possible now for a user to create them like this in the body of a module using the Schema API:
WakeupCaller(
parent=schema.parcel_for_module(__name__), name="ProcessZaoBaoFeeds",
wakeupCallClass="osaf.examples.zaobao.ZaoBaoWakeupCall.WakeupCall",
callOnStartup=True, enabled=True, repeat=True, delay="00:00:30:00"
)
Which is somewhat more compact than the parcel.xml version. This object then automatically gets added to the module's parcel under the path //parcels/osaf/examples/zaobao/ProcessZaoBaoFeeds.
So, as far as I can see, the main remaining use of parcel.xml is probably going to be for defining the UI, and we could probably create a more user-friendly XML dialect for that.
When in some future version of Chandler, non-programmers can define schema and items as a parcel, the interchange format can be the repository's "native XML" format, which isn't an especially user-friendly format, but it doesn't have to be because you'll never write it by hand anyway. (Except for its core schema, of course.)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
