On 22/06/2010, at 4:45 AM, Ean Schuessler wrote: > Scott Gray wrote: >> Well it all really comes down to the question of who gets to define the >> structure of the content, is it OFBiz or is it the CMS? >> >> If it is OFBiz, then will other CMS' be able to consume that structure or >> will we be left trying to write our own? >> >> If it is the CMS, then in order to support more than one CMS, OFBiz would >> need some sort of mapping mechanism to provide OFBiz developers with a >> consistent structure to work with. >> >> But as I said earlier, I really don't have enough knowledge at the moment >> about any of this and will need to do more research before I can say >> anything that isn't based on guesses and hunches. It would be nice if >> others interested in this did some as well. >> > Any CMS integrated with OFBiz will need to link content items to > products, parties, workflows and so on that exist outside of the CMS > model. In that sense, OFBiz must define the content model because the > root of the content is the OFBiz datamodel and not the other way around.
Not necessarily, OFBiz need only know the location of a given piece of content and how to interact with it. So instead of entities being related to Content records, they would instead have pointers to locations in the content repository. > The question is whether the CMS model that is used to control content > related to the OFBiz data model should be the same CMS that is used to > manage blogs, forums, wikis and other useful goodies. To me, the prime > mover in these categories quickly becomes the code controlling the > content rather than the data structures because the data structures are > fairly simple. Looking at JSR-283 based solutions, one does not see > anything even close in terms of popularity to systems such as Wordpress, > Drupal or even Roller. The answer to that question is up to the individual, if OFBiz offers a blog, wiki, forum or whatever it doesn't mean that anyone is going to be forced to use it. If any of those things were to be developed it would only be because someone needed it, same as anything in else OFBiz. OFBiz has accounting functionality, but that doesn't prevent anyone from using alternative accounting systems. > With regard to the JSR-286, I think its a maze of confusion and a dead > technology. This article sort of sums it up > http://today.java.net/article/2009/01/16/jsr-286-edge-irrelevance. > Google Gadgets has as much or more these days and yet its adoption is by > no means assured. How did you just segue into JSR-286? > If we really want to switch to JSR-283 as our content interface then I > guess the first sensible step would be a JSR-283 adapter on top of the > current CMS so that new and old content apps can exist side by side. You're welcome to work on that but it certainly won't be anything I'm going to touch. To borrow from you a bit, our content application is a maze of confusion and dead code. The best I would be willing to offer is migration services for importing data from the Content model into the new repository. > Once all the existing code is migrated to use the JSR-283 interfaces we > could switch out the underlying provider. This would have the added > advantage of being able to publish OFBiz legacy content into a JSR-283 > environment. Of course, we would still have to work out how to provide > ECAs on this new technology and take care of all the other details that > the current framework gives us. Shouldn't be too difficult I imagine, some sort of listener keeping an eye on node changes in the repo and sending a notification to OFBiz via (I guess) a Node ECA mechanism. Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
