[apology]Sorry non-coders, this is going to be a technical post, but there are major non-technical benefits so try to muddle through.[/apology]
In WebGUI 8 I'd like to pull the concept of "collateral" data out of the wobject and put it into reusable standalone or mixin objects. Right now the methods for collateral are hard-coded into wobjects. By having them as a stand alone object they would only need to be part of the asset/wobject in the case that they're needed. In addition, collateral could be used by other types of assets, or even things that aren't assets. Literally any object (user, group, version tag, workflow instance, whatever) could use the collateral methods.
In addition, I think we should build a JSON collateral system, and change most of the assets to use that instead of the SQL based one. Colin Kuskie has been working on just such an animal. This will allow us to deal with much more complex collateral data that need not be accessed via SQL. In addition, I think that most collateral data should be moved into JSON, rather than being stored in separate tables. There are a few cases were this doesn't make sense: if you don't want the data versioned; if you're going to have a lot of collateral data (more than 100 records) per asset; or if you need the features of SQL for your collateral data.
Ok, enough for the tech stuff, let's talk about what this gets the average user. If we move most of the collateral data into JSON and then store that JSON in the asset's class table then the collateral data is automatically versioned, works with prototypes, and packages. That means you can export a data form with all of it's fields, or a survey with all of it's questions as a package, or deploy it as a prototype with all that intact. Increases performance by reducing the number of database queries. It also means that as we apply various web service interfaces to assets, that all the collateral data will "just work". And like I mentioned in my previous post, one thing we could do more easily is create a site sync system that would allow the same asset to exist in multiple sites...including it's collateral data.
In WebGUI 8 I'd like to pull the concept of "collateral" data out of the wobject and put it into reusable standalone or mixin objects. Right now the methods for collateral are hard-coded into wobjects. By having them as a stand alone object they would only need to be part of the asset/wobject in the case that they're needed. In addition, collateral could be used by other types of assets, or even things that aren't assets.
This is a great idea. I've often thought about the possibility to have a 'rating object' or other objects that the designer could attach to an asset. Now you could do so with a macro. But your not talking macro's here are you? Your talking objects for programmers only, if I'm understanding correctly?
Internet for the public sector
OK, this sounds fantastic but I don't get it nor does it appear do others. Can you give us an example of what asset collateral looks like? Is it the fields that have been defined for a Data Form or is it the actual data from the form submissions?
Also, you mention that the current implementation of collateral is as methods. What's an example using the Data Form for instance? Is it methods like getFormUrl? getListUrl?
How does all the above fit into the definition? In other words, what's the difference between asset collateral and the asset definition?
PS: You can see I've not been practicing my wobject writing kung-fu.
It doesn't fit into definition (currently), that's why it's called collateral. Collateral is any data that's stored in tables other than the asset class tables. So in the data form both the list of fields and the submitted data are collateral data. However, only the list of fields is something you'd typically want versioned, so that data is what I'm talking about above.
I'm sorry if I haven't done a good job of explaining this, but I don't have time to explain it more right now.
OK, that's making sense. So instead of a wobject having a bunch of extra tables for collateral data, we'll be able to reduce that down to 1 or 2 tables (1 for the wobject instances and 1 for user input).