More details, roadmap, convince me

Probably best starting off by saying my experience with CMS's is with Drupal. I've got heavy experience in Drupal, custom module development, themes, and a large portfolio of large Drupal sites with a bit more going on than a vanilla Drupal install. Although I think Drupal is good at what it is, it isn't ever going to be as nice to develop with as developing in Grails (not a fan of php).

Spaces
Ok now coming from Drupal the first question I have, Spaces. I don't have a proper understanding of spaces but think they are common in Enterprise CMS apps. From what I can gather they are nothing more than grouping of content to allow easy management? In Drupal content is managed by content type, where as with a 'Space' the content can be off any type and with the current implementation a piece of content can virtually exist in more than one space? The current implementation of spaces is also used for url mappings (SEO?) so you can map content to seo friendly urls such as 'http://..../blogs/' or http://..../forums/' .

Can anyone further expand on spaces, although it's useful to do why would you need virtual references of content between multiple spaces? Coming from Drupal I can see they could be useful but maybe over engineered without having some user cases of grouping content by space rather than content type?

Guess spaces are the biggest thing I need to get my head around so any details would be useful

Templates
It's clever that everything is content with Weceem but again got a feeling this may be over engineered. I'd think it would be beneficial if templates could be stored in the codebase rather than having them as content. I only have one reason for this, templates on the filesystem can be put into version control so changes can be tracked and also end users cannot edit templates. The end user problem could be solved with permissions but again that's probably adding complexity's.

I see Scott Burch of the Simple CMS grails plugin is migrating his work to Weceem and some of his taglibs + having templates on the filesystem would be a huge plus.

Widgets
Again I think it would be good to have these on the filesystem. These are a bit more complex than templates in that they require some logic than render a response so some sort of system like how controllers render views. Ie we have a folder 'grails-app/widgets', any classes in here need to end in 'Widget', they contain closures which pass the response to the relevant template under 'views/blocks/[widget-name]/[closure-name].gsp'

other
Url aliases, it's good how you can manualy specify a url but again coming from drupal I like the idea of all urls being in the form 'node/[id]' and then using a Filter to catch the request and redirect to the clean url. This should make it easier keeping track of urls and providing things such as tokens so for specific content types the urls follow a set structure automaticaly such as 'blog/[YYYY]/[MM]/[DD]/[title]' .

Scripts, at the minute the create content forms are rendered based on the domain properties. This makes it easy creating new content types etc, it would be nice if the plugin provided scripts so we could override the default create/edit form for a specific content type eg 'grails weceem-create-editor-view Page' which would then pretty much work the same as 'grails create-view Page' .

Provide hooks into the content edit form. It'd be useful if a developer could add things to a Content class without editing a content class. I dunno if a class implements 'ContentAPI' it has 'load,save,view,delete' hooks which can push extra info into the domain object or view. Guess the actual implementation needs thinking about but it'd be quite powerful for adding meta tags without touching the domain or other useful things.

Taxonmy: Allow categorization of content, tagging etc

User interface: Very clear developed by Developers not designers and still in early stages. Adding some plugin scripts to generate the views and allow them to be overridden would be a plus.

Guess their is quite a lot their, but they would be some of the basics I need before considering using Weceem in a production environment.

So whats the official long term roadmap / feature set for Weceem? If any of my ideas are of interest maybe we should chat in more detail as I'd be more than happy getting a killer Grails powered CMS out their instead of creating my own spin off when there's 2 grails cms's out there already and it looks like the Simple CMS plugin is moving to Weceem.

For me the key blockers at the minute are:

Templates not on filesystem

Widgets not on filesystem

Ability to automatically assign templates based on content type

Unsure of roadmap, is it worth my while getting involved?

Hello ajevans85,

first of all, thanks for taking the time to check out Weceem and writing up a detailled analysis. Weceem is still in the early stages (we are talking 0.2), so any feedback is helpful and appreciated.

ajevans85 wrote:
Although I think Drupal is good at what it is, it isn't ever going to be as nice to develop with as developing in Grails (not a fan of php).

I have also some experience with Drupal and also with other PHP and Java based CMS. In my experience, some of the PHP based solutions were hard to maintain and the Java based solution very often very heavy-weight and not easy to extend. And yes, Grails is a great foundation for a CMS.

ajevans85 wrote:
Spaces
I don't have a proper understanding of spaces but think they are common in Enterprise CMS apps. From what I can gather they are nothing more than grouping of content to allow easy management? In Drupal content is managed by content type, where as with a 'Space' the content can be off any type and with the current implementation a piece of content can virtually exist in more than one space? The current implementation of spaces is also used for url mappings (SEO?) so you can map content to seo friendly urls such as 'http://..../blogs/' or http://..../forums/'.

Can anyone further expand on spaces, although it's useful to do why would you need virtual references of content between multiple spaces?

Spaces or Workspaces can be seen as completely independent repositories. Simplest Examples: multiple spaces represent independent websites, stored in one repository. Permissions on Spaces still haven't been implement. Again, many other system (eg. JCR, Atlassian Confluence) have the same concepts. Also, we plan to support the mapping of domains to spaces.

Virtual references allow to reuse the same content in multiple places of the content hierarchy.

Content is not grouped by type; we had this in 0.1, but did not find it intuitive. So you can have HTML pages, that have wiki children, Blogs that have comments as children etc.

ajevans85 wrote:
Templates
It's clever that everything is content with Weceem but again got a feeling this may be over engineered. I'd think it would be beneficial if templates could be stored in the codebase rather than having them as content. I only have one reason for this, templates on the filesystem can be put into version control so changes can be tracked and also end users cannot edit templates. The end user problem could be solved with permissions but again that's probably adding complexity's.

There are a couple of reasons why we have Templates as content (as well as Widgets). We have versioning for content (partially implemented in 0.2), so you don't need an external system like subversion to go back to a previous version of a template. Next we have adapted some ideas of the Java Content Repository (JCR), where everything is content, too. And as you guessed correctly, we are planning to control the access to content types via permissions.

ajevans85 wrote:
I see Scott Burch of the Simple CMS grails plugin is migrating his work to Weceem and some of his taglibs + having templates on the filesystem would be a huge plus.

Yes, Scott Burch is merging the functionality of Simple CMS into Weceem and we are jointly working to make this happen. However this will be based on templates and widgets that are stored in the DB.

ajevans85 wrote:
Widgets
Again I think it would be good to have these on the filesystem.

see Templates

ajevans85 wrote:
other
Url aliases, it's good how you can manually specify a url but again coming from drupal I like the idea of all urls being in the form 'node/[id]' and then using a Filter to catch the request and redirect to the clean url. This should make it easier keeping track of urls and providing things such as tokens so for specific content types the urls follow a set structure automaticaly such as 'blog/[YYYY]/[MM]/[DD]/[title]' .

Generally, Weceem constructs URL based on the content hierarchy and the titles of the content. For SEO and the migration of old content (keep old URLs, because other sites deep link into your site), we provide URL aliases.

We see blog entries sorted by date (eg. all blog entries for a specific month) as an independent widget, not as a specific content (you could also use a different template), because it shows multiple content elements in parallel.

ajevans85 wrote:
Scripts, at the minute the create content forms are rendered based on the domain properties. This makes it easy creating new content types etc, it would be nice if the plugin provided scripts so we could override the default create/edit form for a specific content type eg 'grails weceem-create-editor-view Page' which would then pretty much work the same as 'grails create-view Page' .

You can customize the editor using some static properties eg. for grouping of attributes (needs to be documented...). However, I think it's a good idea to create exit points and additional customization capabilities.

ajevans85 wrote:
Provide hooks into the content edit form. It'd be useful if a developer could add things to a Content class without editing a content class. I dunno if a class implements 'ContentAPI' it has 'load,save,view,delete' hooks which can push extra info into the domain object or view. Guess the actual implementation needs thinking about but it'd be quite powerful for adding meta tags without touching the domain or other useful things.

Good idea. Certainly we have to provide hooks especially for "exotic" content types.

ajevans85 wrote:
Taxonmy: Allow categorization of content, tagging etc

We might do this later. However, we already allow arranging the content in a hierarchy. Additionally, you can use Virtual content to reference the same content in multiple hierarchies.

ajevans85 wrote:
User interface: Very clear developed by Developers not designers and still in early stages. Adding some plugin scripts to generate the views and allow them to be overridden would be a plus.

Yes, the UI is a little rough. We will have several improvements in the next version and we had a designer looking at the UI, so expect a nicer L&F.

ajevans85 wrote:
So whats the official long term roadmap / feature set for Weceem? If any of my ideas are of interest maybe we should chat in more detail as I'd be more than happy getting a killer Grails powered CMS out their instead of creating my own spin off when there's 2 grails cms's out there already and it looks like the Simple CMS plugin is moving to Weceem.

Our current roadmap is not very detailled (look under Documentation/Roadmap), but it gives you a first idea about what we want to achieve. Improved UI, searching, Blogs and Wikis are next (UI/Searching done; Blogs currently being developed).

And yes: I would love to talk about more details with you, because we believe Weceem can be a "killer CMS" for Grails and every helping hand is needed.

One more note about the Grails CMS plugins. There are currently three plugins: Simple CMS, contentmanager and Weceem and we already have agreed to join forces! I think that this is exiting news for the Grails community and we will announce this officially pretty soon.

ajevans85 wrote:
For me the key blockers at the minute are:

Templates not on filesystem

Widgets not on filesystem

Ability to automatically assign templates based on content type

Unsure of roadmap, is it worth my while getting involved?

Sorry, but Templates and Widgets will stay in the database.

We don't assign templates based upon the content type, because you might have multiple templates even for the same type. However we have the concept of "template inheritance": if a content element does not have it's own template, then it looks for the template of the father (..grandfather..). This is probably more powerful and still easy to understand.

I hope I gave you a better idea about the roadmap, too.

Was that enough to "convince you"? I would love to see you coming on board!

Hope that helps to understand better where we are heading and why we are putting a lot of effort in Weceem.

Best Regards,
Stephan Albers

Thank you for the detailed reply.

The issues with templates / widgets is still a big one for me.

Templates, in practical terms if you have a team of developers working on a project they would need a individual user account on the CMS for versioning of templates to be trackable. These are not really users which should have accounts etc as they are not users but developers, thats not really a big issue but I'd much prefer to handle revisioning for templates (which is essentially backend functionality code) to be in the main code base file repository as a preference.

The big issue I see in practical terms in regards to templates in the DB is deploying from development sandbox to production. If the template was on the file system I'd just re-deploy the app , as the templates are in the database it gets a bit more complicated moving changes made on the development build to production, we simply can't re-store the dev database on production as we would need to synchronize content. We could manually alter the templates within the CMS on the live site but this brings in user error, it happens and it's probably everyones biggest headache, merging database record changes.

Drupal lets you store templates in the database using the ContentTemplate module. After 3 years experience working on many Drupal sites with teams of 1-6 people per project I quickly reached the conclusion in practical terms templates in the database became to much of a management headache and the problems can be avoided altogether by storing the templates on the filesystem. This also allows for people to work on a site on their own sandbox database etc but still have correct template files and not worry about them being out of sync.

Guess a good compromise would be templates on the filesystem which are scanned on deploy time and either insert / update existing templates in the database. As I say, the problem I see is manageability from practical experience working in teams on a cms, I actually quite like how you engineered the system I just think it won't work well in practical terms within a team environment each making regular changes and deploying from dev to live.

The same really applies for widgets. I can easily create widgets in the database within Drupal, and it works. When you then have multiple databases around as different people work on various sections of a site it then becomes counter productive as people start to make errors merging database changes. Therefore I stress any blocks ('widgets') that we make need to be done on the filesystem, always. It makes management easy, and deployment easy. As widgets are on the filesystem they then become more re-useable, all I need to do is drag the module across into a new project to re-use it, I don't have to mess about re-creating it in a database. On Drupal blocks any which are on the filesystem can also provide their own configuration options to help make them re-useable.

Having a team of 20 people producing several CMS based websites of various sizes each month we also use Redmine for issue tracking. A lot of companies / projects use issue tracking and most of them integrate with SVN / CVS / Git etc. With this keeping track of template changes, widget changes becomes really easy for anyone who has to oversee 20 developers working on several projects. I know when, what was changed, and appropriate feedback from Client / Testers.

Taxonomy i'd now also consider basic functionality of a CMS. Yes I can create hierarchal content in WeCeem but to do the below (which should be quite simple) would be a useability / management nightmare:

Usercase:
I have a content type called Car, this content class has a image, add title and description.

I now want to search for cars on:
Fuel type
Colour
Make
Model

I could add these properties to the domain but Drupal allows me to create these as taxonomy, the domain doesn't know about these new categories the node belongs to but I can then filter on them. I'd also probably structure make and model into a tree structure. When I create a new Car type, depending on the taxonmy configuration on the node form I'd get checkboxes, select list, radio buttons etc to set the correct categories the car belongs to. Currently I do not see no easy way of doing this in WeCeem? Also as a requirement i's say 90% of the sites we produced have used taxonomy from very basic categorization to some very complex ones.

For now I can get around this by adding colour, fuel, make etc to the domain. It makes sense to make this more generic though, and as in drupal externalizing this from the node implementation should make it easy to implement faceted search using Solr (another interest of mine).

I am trying to work on a Grails Taxonomy plugin which hopefully should let me add Taxonomy for any grails domain class. Hopefully when I get a move on with it, it should be pretty trivial to add to WeCeem.

I am keen to keep a eye on WeCeem but I'd need a way to work around the template / widget issue, scanning a folder at deploy time and updating the db looks like my best option for now and I'll have to look into this.

ajevans85 wrote:The big issue I see in practical terms in regards to templates in the DB is deploying from development sandbox to production. If the template was on the file system I'd just re-deploy the app , as the templates are in the database it gets a bit more complicated moving changes made on the development build to production, we simply can't re-store the dev database on production as we would need to synchronize content. We could manually alter the templates within the CMS on the live site but this brings in user error, it happens and it's probably everyones biggest headache, merging database record changes.

You have the same problem with new/altered content, that you want to put into the live system at a certain point in time. Putting the content/templates/widgets as files into the file system is one way to solve it. The alternatives we have been thinking about are:
- using jobs (scheduling) that move/rename content at a predefined point in time
- use multiple spaces for current/new content, synchronize between the spaces and switch between the spaces (staging to live)

ajevans85 wrote:Guess a good compromise would be templates on the filesystem which are scanned on deploy time and either insert / update existing templates in the database.

That sounds like a reasonable solution, however do not expect this to happen in the next two or three releases as we still have a lot functionality that needs to be developed before.

ajevans85 wrote: The same really applies for widgets.

Yes.

ajevans85 wrote: Having a team of 20 people producing several CMS based websites of various sizes each month we also use Redmine for issue tracking. A lot of companies / projects use issue tracking and most of them integrate with SVN / CVS / Git etc. With this keeping track of template changes, widget changes becomes really easy for anyone who has to oversee 20 developers working on several projects. I know when, what was changed, and appropriate feedback from Client / Testers.

I certainly see the need for tracking systems. Again, the problem with templates are the same as with content. You also have content changes that you want to track and if you want to be consistent, then all the content should be stored in files.

Also, I don't see Weceem competing with "the big guys" in the next couple of months. It will take some time to reach that level, so while I like the idea to scan the file system and sync with the DB, it certainly will take some time before we would implement that.

ajevans85 wrote: Taxonomy i'd now also consider basic functionality of a CMS. Yes I can create hierarchal content in WeCeem but to do the below (which should be quite simple) would be a useability / management nightmare:

Usercase:
I have a content type called Car, this content class has a image, add title and description.

I now want to search for cars on:
Fuel type
Colour
Make
Model

If you want to use taxonomies as classifications, you could create them as an additional hierarchy and link the hierarchy to your existing content using VirtualContent.

For specific content types (like car), you can create a new domain class. That is very easy to do and fits into the Grails concept. The content editor gets generated automatically, so you start to create content immediately. Also, this content can be structured hierarchically. The database table is also accessible with other tools. This fits also well into the JCR concept and could allow to store the complete content as an alternative in a JCR repository (which I would like to see in the future).

ajevans85 wrote: I could add these properties to the domain but Drupal allows me to create these as taxonomy, the domain doesn't know about these new categories the node belongs to but I can then filter on them. I'd also probably structure make and model into a tree structure.

We would not add the fields, but create an additional content type for that. The only thing we cannot do with that approach is multiple inheritance (see Java, Groovy..).

ajevans85 wrote: When I create a new Car type, depending on the taxonmy configuration on the node form I'd get checkboxes, select list, radio buttons etc to set the correct categories the car belongs to. Currently I do not see no easy way of doing this in Weceem? Also as a requirement i's say 90% of the sites we produced have used taxonomy from very basic categorization to some very complex ones.

As mentioned before, Weceem creates the content editor for your content type automatically. You can define/overwrite which editor should be used for each attribute, attributes can be grouped, so there is enough flexibility to create a good user experience.

And certainly, you could create a plugin for Weceem or Grails to support taxonomies.

ajevans85 wrote: For now I can get around this by adding colour, fuel, make etc to the domain. It makes sense to make this more generic though, and as in drupal externalizing this from the node implementation should make it easy to implement faceted search using Solr (another interest of mine).

Yes, faceted searches are helpful and Solr is great for that. Also, we expect users to use their own (existing) domain classes, so they could implement their own searches, content editors etc. and just use the Weceem Plugin for presentation purposes.

ajevans85 wrote: I am trying to work on a Grails Taxonomy plugin which hopefully should let me add Taxonomy for any grails domain class. Hopefully when I get a move on with it, it should be pretty trivial to add to WeCeem.

This would be nice for Grails as well as for Weceem.

ajevans85 wrote: I am keen to keep a eye on Weceem but I'd need a way to work around the template / widget issue, scanning a folder at deploy time and updating the db looks like my best option for now and I'll have to look into this.

As I said, I like the idea, but we would not get that started, before we have implemented all our core features. However any code submission, patches and enhancements are welcome.

Best Regards,
Stephan

There's another possible solution for the future. We already have pretty good import/export support.

If there was a way to select only certain nodes for export, and tell it on import to OVERWRITE nodes rather than replace the whole space, then you could export your new templates into a single file, and import them into the live system "merging" with the existing space and replacing nodes at the same place in the hierarchy.

I think this would be a rather neat solution as you could replace entire sub-graphs of the content tree in a controlled manner.