Thanks for your advice and the link. We appreciated any contribution from community. Unfortunately we do not have well documented discussion about this. We answer your question below; we are open
for discussion and changes/improvements in the future.
We have seen many field implementations which do looks very flexible. Below is the reason why we chosen schema instead of field approach.
We would like to design a system with minimum leaning cost for new developers. Our goal is that a developer will be able to read an instruction for half an hour and then start building his own sites in Kooboo.
In order to do this, we need to design a system with similar as what ASP.NET developers already get used to. For example, Schema similar as a database table, layout template similar as master page, Content template similar as user control, and developing
kooboo modules is just like developing a standard MVC site.
When we gave a system with schema and a system with fields to developers, it seems that normal developers can understand a schema concept instantly but find it hard to understand fields immediately. The same reason for XSLT support, we did not offer XSLT
in current release now because that has much higher learning cost than regular CSS. We do, will offer that some ways in the future.
Also when it comes the time, a developer wants to “hack” the data storage, when he opens the database behind, schema approach is much easier for him to find the information he is looking for. For Schema, we directly map a schema to a database
table, when you create a schema, you will find a table created as well. We are storing information in a structure way. We thought developers will love this approach.
By the way, we were also developing a content repository without SQL database, but we find it too much work, so we use SQL database for content storage for now.
>> 1. Loading less information.
I am not sure fields approach will load less information; it seems like more complicate to load information for editing form and also for front site data query. For SQL database storage, you may need to have a separated table for field property values and
this need to be a many to many relation to main content table. For data query, this will not be simple SQL query. The performance might be an issue in this case. We have heard too many complaints about the performance of DNN. We need simple and fast system.
>> Permissions per field.
Good point, thanks.
Sorry, it is not possible by current Kooboo schema design right now. Currently, CMS only control permission per page by default. For modules, it is possible to control permission per controller action.
We understand this need, but simplicity wins flexibility again in our decision.
>> No title field requirement
The title field is used to show list of content in the CMS content list page. Otherwise we do not know which field to show there. Also it is common to have a title for any content, so we make it fixed there.
>> Sharing fields across content types
Right, we also thought of this. This might be useful when system is really big. Again open for discussion.
We make it open source which means we would like contribution and opinion from community, when there are enough people asking for some features, we will implement. You can also submit a patch to codeplex when you modify something useful.