Al Byers wrote: > Ean, > > Could you please give a little more information about the type of content > and merges that you see in practice, so I can see if the CMS could be built > out to handle them?
Actually, storing these things in the database is not the best way to go. It keeps people from using dreamweaver, photoshop, illustrator, flashmx, vim, emacs. The simplest explanation for what we have, it that the very old region system in ofbiz has been converted to read everything from the filesystem. We also have a unified resource type system. When a browser requests some path, we do an extension->mime type mapping. The mime type mapping then provides a set of metadata attributes. Those are combined with any attributes set directly on the resource. These attributes specify the type of file, page title, wrapper, template, etc. Resource types we currently support(not inclusive) are bsf, code, template, servlet, php, binary, multi-binary. Once any code resources are done, and an eventual template resource is called, wrapper logic is run. Then, as each subsequent template resource is called, it can have other templates applied to it. There is also section support. In almost all cases, we have put all the data and configuration options as files on disk. web.xml init parameters, servlet/filter mappings, servlet/filter configuration, error pages, welcome file lists. This was done to make it easier for non-programmers to configure. It was also done so that our filesystem overlay(kinda like COW) would work. This was done by implementing a nested servlet container. We've implemented a servlet container, that itself can be deployed inside any other servlet container.
