David Jones wrote:
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).
I was thinking that too. I'll get a Jira issue created for it. I can't
help out with it until end of August, but it would be nice to get some
kind of task list, etc set up in the meantime.
-Adrian
