After a recent demo of scripting, Mitch asked, "Could you use this to write a parcel?" Here is a proposal to answer that question with a definitive "Yes!" Under this proposal, a user interface would be provided to allow non-programmers to define their own kinds of data objects, and then create, view, and manage those objects. Python programmers would be able to use our python scripting to extend those objects by adding behavior. In essence, we'll be providing a very simple UI to allow users to create simple parcels.

What would it take to provide Chandler users with a set of tools to let them write their own parcels? What kind of parcels would users want to write? What are the difficult things about parcel writing, and is there a way we can make those things easier? Here's my opinion on one way to answer these questions.

Users want to put their information into the computer. Different users not only have their own individual data, they often have different ways of organizing or thinking about their data. They may also have different things that they want to do with the data. My friend who runs a health food store provides a good example - he has a huge amount of data that he'd like to put into the computer, but the way it's organized and displayed probably needs to be customized to his needs.

I think there are several key things people want to be able to do:

1. Define their data, and how it should be organized
2. Decide how they would like that data displayed
3. Choose different ways to manage and search their data
4. Extend the behavior of their data objects
5. Connect to other programs to facilitate importing and exporting their data with other systems or applications
6. Build interfaces to allow them to interact with their data in a convenient ways

I propose we start by providing a UI to make it easy to do some of the things on this list, and defer the rest. I think the key requirements are the ability to create your own Kind, decide how it should be displayed, and have a way to add behavior through python programming. Then a python-capable user can do the import and export functionality themselves. As for managing and searching for their data, I hope that Chandler's Collection features will cover the basic needs, and we can look at enhancing those features later.

For the initial implementation of the Kind Builder UI, I propose we build something really simple: The Summary View of the Builder would show a table of all the attributes in your Kind. The Detail View would let you edit each attribute - its name, type, a doc string, and how it should be displayed. As you edit the details of your attribute, the note body in the detail view will show you the code that will be generated for that attribute. All the code for all the attributes you define get wrapped up into a script that defines the schema for that Kind, and the information needed by the Detail View and Summary View to display items of that kind. Since the code generated is a Script, it can later be viewed and edited by the user if they want to enhance the behavior of their Kind, or rewrite it into a real parcel, etc.

Here are the details on how the UI would work. You start by selecting "Build a new Kind" in the Test menu. This brings up a dialog to let you choose the Kind to build. The dialog lets you type in the name of the Kind you want to create, and an OK and Cancel button. If the Kind you name does not exist, it creates a new Script by that name, and makes a new untitled attribute. If the Kind you name already exists it opens up that existing Script, and lists all the attributes you defined earlier. At this point, you can see all the attributes of you Kind listed in the Summary View, and can select one and edit it in the Detail View. The Summary View has columns that show the attribute's name, type, a comment, and something about how it is displayed. The Detail View of an attribute shows the following:

• the attribute's name
• the attribute's displayName
• the attributes type
  • this is done with a choice box that has all the main types listed
  • an additional choice is "property" which allows you to enter a piece of python code to compute the value, and/or code to set the value
• a cardinality choice popup
• a comment to describe the attribute
• check boxes to allow you to make this attribute redirected to by one of the normal content item redirects
• a check box to allow the item to be displayed in its summary view
• the kind of block to use to display the attribute

Once you create your Kind, there is a script that has all the code generated to implement that Kind. That script is executed each time you make a change to one of your kind's attributes, so changes immediately affect the repository. The generated script includes code that provides a simple UI to give you access to your kind; it adds a collection of your Kind of items to the sidebar, and adds a menu item to the "File/New Item" menu so you can create new items of your Kind.

Future Enhancements

Kinds created by this system would be mixins for Notes, along the lines of our current Content Items (and suitable stamping should we decide to support that later). We could allow the Kind Builder to be used to subclass existing Kinds, and Kinds build with the Kind Builder. I think these features could cause problems, so I think they should be deferred until later. There's obviously a lot that will need to be done to the UI to make it more usable if we decide we really want to make this an end-user feature.

Issues

Updating the schema for Kinds immediately as the Kind's attributes are edited my turn out to be problematic for a variety of reasons. But I think we should try it, and see if we can make it work. It will make is super easy to test some of our upcoming schema migration work, because we'll be able to easily add and remove attributes from Kinds that have instantiated items in the repository.

There are still a lot of implementation issues that I have not decided upon yet. For instance, how does the code get generated when you edit an attribute in the Detail View? And when you bring in an existing Kind, how do the various settings of each attribute get re-internalized for display and editing? Maybe I'll end up creating items that store this information.

The scripts produced by the Kind Builder are essentially python modules. Will they be usable from other python code? How will they be imported? Remember these things are items, not files, so the normal import won't work on them, but I think we can install them in sys.modules anyway, and that will make them available via import from other python modules.

Philippe's Comments

Pretty cool idea though I'm a little concerned by the amount of work this represents. The good thing is that it will allow Python litterate scripters to get something in Chandler without having to mess with CPIA and wx in a parcel. The bad thing is that they're likely to start bumping into limitations and willing to create a "real" parcel pretty fast...

I also think we shouldn't start working on this before we get some documentation and tutorial for the existing scripting capabilites.