Personal tools
You are here: Home Members tseaver Software userschema userschema Issues Extending userschema's XML story
Issue 10 of userschema Issues [userschema]
Title: Extending userschema's XML story
Status: Accepted Security related: No
Description: Martin Aspeli wrote: I'm currently working on a prototype to try an support full-blown through-the-web and from-an-XML-file content types in Plone. P...
From: tseaver on: Feb 6, 08 15:15
tseaver Last update: Feb 6, 08 15:41
Topic/class: API/feature Importance: medium
Version info:
Assigned: tseaver
Issue 10 Transcript
2 entries
= Edit - Entry #2 by tseaver on Feb 6, 2008 3:41 pm

 Changes: submitter email, edited transcript, revised description
________________________________________
= Request - Entry #1 by tseaver on Feb 6, 2008 3:15 pm

 Supporters added: tseaver

Martin Aspeli wrote:

I'm currently working on a prototype to try an support full-blown
through-the-web and from-an-XML-file content types in Plone. Paul and I
have spoken about this before, a bit.

The XML file needs to contain a few things - FTI information, some view
definitions, and of course a schema. For the latter, userschema (I'm
looking at 0.8.1 right now) seems to provide nearly all that I need,
although there may be a few deviations:

   1. The XML file needs to contain other, non-schema information. From a
quick glance, I think the userschema.etree parser should be able to
support this, but I'm not 100% sure.

   2. I'd like a little more generality. In particular, Field properties
not in _ELEMENT_CONVERTERS that don't happen to be convertible using the
value_converter for that field type will not be settable. I think it
should be possible to inspect the field class (or rather, its interface)
and extrapolate the underlying type for most, if not all properties.
I've got code that does this in plone.app.portlets already that could
probably be re-purposed.

   3. My configuration needs are different. I can't use the userschema
ZCML directive, and I have no need for CSV or
HTML schema definition (at least not right now).

Now, depending on the userschema egg shouldn't be a problem. In fact,
this opens the door to support CSV-based or HTML-based schemata as
options in the future. For the main XML parsing, I could create some
wrapper APIs and just use userschema.etree.

However, I'd like to address points 1 and 2 above, generalising the XML
handlers a bit to support additional (and preferably an open-ended
number of) field properties, and making sure that the parser was able to
deal with an XML file that contains other sibling elements to the
<schema /> element.

What do you think is the best course of action? If userschema is in a
public repository, I could contribute directly to (a branch of) that.
Alternatively, I could just borrow the bits of etree.py that I need and
put them in my own code if that's less trouble/risk for you - with your
permission of course.


Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: