On Wed, 30 Jul 2008 10:43:42 -0700, Adrian Crum <[EMAIL PROTECTED]> wrote: > David Jones wrote: >> On Wed, 30 Jul 2008 10:26:56 -0700, Adrian Crum <[EMAIL PROTECTED]> > wrote: >>> David Jones wrote: >>>> What is it that you are trying to implement Jacques? In other words > what >>> sort of requirement do you have or feature are you trying to support? >>>> Or are you just trying to clean up the Content Manager? There is a lot >>> of stuff in the Content Manager that either doesn't work, or that is > for >>> an unclear purpose, and personally I'd like to see a redesign of most > of >>> it and eliminate a lot of what is there, possibly including the > ListLayout >>> and related pages... >>> >>> Has anyone ever considered integrating OFBiz with an Open Source CMS? > If >>> there was a way to do it, we could eliminate a good sized chunk of code >>> and the work required to maintain it. >> >> The problem is that most CMS systems are really pretty limited in scope > and capabilities, and are often meant for pretty specific purposes. A lot > of people use them and work around these limitations with CMS > supplementation, like like a lot of companies work around ERP systems and > end up writing a lot of ERP augmentation stuff. There are a number of nice > content and document management pieces that have been built on the OFBiz > content stuff, with the CompDoc stuff that is in the Content Manager being > just a hint at some of the possibilities (like Survey integrations, > document combining, revision control, approvals, and so on). >> >> If we did go with an external content management system, even for simple > things like ProductContent, a lot more effort would go into the indirect > integration and getting them to work together. >> >> IMO what we really need is a decent UI for managing content, and if even > if we started out by borrowing designs from one of the existing open source > ones for web content management it would be great. Most of the efforts so > far have been, well, half-assed and never finished. > > Maybe we could start out by moving some of the more framework-oriented > stuff out of the content component and into the framework. That would > help reduce the size of the component and make the "code cleanup" target > smaller and easier to work with. > > The other day I was working on fixing an email service bug and was > surprised to find email services are kept in the content component. IMO, > those should be kept in the framework - since many other components use > them.
Yeah, that would be good to do regardless. The common component is probably a better place for some of that stuff. In a way, BTW, we may want to consider moving the whole content component to the framework as it is more often a tool used to enable business processes than something that actually automates processes (which is what the applications and most specialpurpose components are about). -David
