I've just uploaded WebGUI::Crud into subversion. It is by no means a production worthy piece of code. It has no tests, in fact, it hasn't even ever been executed. However, it is in a complete enough state to ask for feedback from those of you who develop for WebGUI and wish there was an easier way to deal with database backed objects.

WebGUI::Crud is a base class for you to create your own database backed objects in WebGUI. It could be (and probably will eventually be) used as the base class for most of the WebGUI::Shop objects, WebGUI::Group, WebGUI::User and more. But probably more importantly for you, it is an easy way to build asset collateral. You simply fill out the crud_definition() data structure with your own, and WebGUI::Crud does the rest. 

We may also build WebGUI::Crud::AssetCollateral on top of this which would give you some things needed to use it under collateral. It would add an assetId field and make it the sequence key. And it would probably have some methods for allowing you to include your WebGUI::Crud objects in an asset package, so the data can be imported/exported with asset packages.

This is not the basis for all objects. It's only a great starting point for objects that need to persist their data to a database table. You can even create several subclasses of WebGUI::Crud that work together and therefore allow you to access multiple tables.

WebGUI::Crud could not work as a base to WebGUI::Asset, for many reasons, but the least of which is that WebGUI::Asset composites its data over multiple tables. It also wouldn't be useful if you don't need to persist your data to a table, or if you persist your data to something else like LDAP or a file.

To give you a real world example of where this would be useful, let's talk about WebGUI::Asset::Sku::Product better known as the Product asset. Products have lots of collateral, including accessories, specifications, related products, features, benefits, which are all stored as JSON, but could be persisted to a table. But more specifically, the product does have the productVariants table which could be made to be accessible via a WebGUI::Crud object. One advantage would be that there would be a clean easy API for variants rather than sticking those methods into the Product asset. Another advantage would be that since each variant was it's own object, it could be worked on by the workflow engine, as the workflow engine works on object types.

So please, if this sort of thing is interesting to you, then please have a look at the new module. Tell me what you think. I'll use your feedback to improve it before it goes into WebGUI 7.6.