Flat table?

I'm in the process of creating a new all grails web site (and architecture with many grails websites providing each other services via XML http) for studentuniverse.com

I wanted to create my own custom CMS which would be specific to our business, so that editing our content would be streamlined to our business practices. But I think it would be wasteful to re-invent everything. I took another look at Weceem, and it may work for me. But I had some questions:

Did you ever consider the possibility of keeping each domain object in its own table? Right now it just adds more column to the master "content" table to cover all possible fields for all domain classes. Maybe the content table could just store the versions and types, and point to the tables (probably through the code and reflection). I'm sure there are a lot of challenges with this approach (searching content for one?), but am wondering if you tried it?

I've got a lot more questions. I'm trying to figure out how it works and how it will work with what I'm trying to do. Some of the documentation is out of date, some of it documents things not yet implemented (some tags). In general I'm looking at the source...

A lot of my questions are about best practices for introducing your own domain objects, and providing the most efficient ways to edit them. (I want a Destination content type, for example, which will allow you to pick from a dropdown of destination types, like country,state,region,theme, city). Those types are loaded at startup through a private plugin which uses XML over HTTP to get the data from a different grails app on a different server, and then creates them as objects in a memory cache. How to get something like that to populate the dropdown in the editor view would be of interest to me. Not sure how to explain the questions I have.

Also, I'd be willing to help Weceem grow if needed....

Thanks,
Dale

Dale wrote:Did you ever consider the possibility of keeping each domain object in its own table? Right now it just adds more column to the master "content" table to cover all possible fields for all domain classes. Maybe the content table could just store the versions and types, and point to the tables (probably through the code and reflection). I'm sure there are a lot of challenges with this approach (searching content for one?), but am wondering if you tried it?

Yes, we are thinking about it. The single table gets too many columns over time. The "table per class" mapping becomes problematic, because many queries get very ugly; often each sub class gets queried with an outer join (because of the reference to the parent class). So we might either put the parent reference into an independent table or we define the mapping for hibernate manually (which gives us additional mapping styles, that might be better for Weceem).

Whatever we do, this needs to be decided before 1.0 because we want the domain model to be stable by then.

Dale wrote:I've got a lot more questions. I'm trying to figure out how it works and how it will work with what I'm trying to do. Some of the documentation is out of date, some of it documents things not yet implemented (some tags). In general I'm looking at the source...

Yes, there is "room for improvement"

Dale wrote:A lot of my questions are about best practices for introducing your own domain objects, and providing the most efficient ways to edit them. (I want a Destination content type, for example, which will allow you to pick from a dropdown of destination types, like country,state,region,theme, city). Those types are loaded at startup through a private plugin which uses XML over HTTP to get the data from a different grails app on a different server, and then creates them as objects in a memory cache. How to get something like that to populate the dropdown in the editor view would be of interest to me. Not sure how to explain the questions I have.

Weceem can be used like any other Grails plugin, so you can define you own domain objects in your application or in your other plugins.

If you want your domain objects to be edited in the Weceem content editor, then you have to subclass the Weceem content class. However we currently don't have support for dropdown fields that get populated via a XML over http call. Please create a JIRA ticket (http://jira.jcatalog.com/), if you want that feature in the Weceem editor.

Dale wrote:Also, I'd be willing to help Weceem grow if needed....

That would be great. Documentation, bug reports, source code.. every help is appreciated.

Stephan

Just a note - you don't need to JIRA us to make a field that looks up data on a remote service. You can just do this by writing your own content type and one - maybe two - grails tags.

def editorFieldXXXX = { attrs ->
}

Where XXXX is the name of the field editor you used in editors mappings.

See the source for all the built in editors here:

http://fisheye.codehaus.org/browse/grails-plugins/grails-weceem/trunk/grails-app/taglib/org/weceem/tags/EditorFieldTagLib.groovy?r=56005