On 24/06/2010, at 12:06 PM, Ean Schuessler wrote: > Scott Gray wrote: >> 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. > Correct, from the OFBiz side. From the CMS side, the content will be a > collection of leaf nodes and the connective structure that organize them > will be invisible. That was my point. Queries across these two disparate > repositories will also be more painful.
This is why personally I would prefer it if we didn't go the route of trying to support any JSR-283 compliant CMS. I would prefer it if we selected a single CMS and then basically used it as a stand-in while we work to create tightly integrated CMS features from within OFBiz. Because hippo is Apache licensed, we can take their features and bring them into OFBiz one by one until we simply don't need their app anymore. If people want to be able to use other CMS apps then they would need to take care of mapping, mirroring, synchronizing and locking between the two repo's themselves. I really think that trying to support any CMS is just too bug of bite for us to sallow at this stage. So in short I agree with you that OFBiz should define the content model, but perhaps we should borrow from the work of others (i.e. hippo). >> 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. > My point is that JSR-283 doesn't seem to provide mech leverage in terms > of actual blog/wiki/forum code. Are you aware of any frameworks suitable for use in OFBiz that do? >> How did you just segue into JSR-286? >> > Hippo CMS is a JSR-286 provider. Ah okay sorry, I doubt that we'd actually try and use it in that manner though. >> 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. > I think we are in agreement that a JSR-283 wrapper is a difficult and > not terribly interesting thing to pursue. Yeah I'd say it might be worthwhile if the existing content stuff were in better shape but I just don't see it being worth the effort unfortunately. Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
