Hi Maik, This is exactly the problem-area I'm trying to tackle now. My goal is to have a system that can as smoothly and transparently as possible integrate any django application that is unaware of the existence of the CMS itself.
Right now my CMS has got a notion of a content tree -- a hierarchical set of content nodes each of which corresponds to a URL on the site. Now there are 2 issues with this approach: 1) how to "mount" django apps to specific points in that node/URL hierarchy, and 2) how to add "content types" to this CMS so to be able to display other entities besides simple HTML pages in an arbitrary location in the tree. Problem 1: I don't like the define-a-dummy-url-and-override-it-in- URLconf approach you described because it is prone to breakage when the user renames a page's URL/slug in addition to the fact that I need to hardcode stuff into urls.py which is contrary to the idea of a CMS in the first place. So I've come up with a solution that lets one actually create nodes that mount to Python modules that contain a Django URLconf. So whenever a request comes in that maps to that node, the URLconf is invoked with the appropriate part of the request URL and the returned view is executed and returned. At first, this left open the question as to how to make django.core.urlresolvers.reverse() work with this layout becuase named URLs that weren't defined in the main/hardcoded URLconf couldn't be resolved. So, since the URL handling/dispatching part of Django is really not customizable at all, I simply overrode django.core.urlresolvers.reverse to select all content nodes from the database that were mapped to a URLconf and try each of those URLconfs in addition to the main/hardcoded one if the lookup failed with the main/hardcoded one. This solution still leaves open the question about how to add different content types to the CMS; that is, content nodes that aren't mapped to a URLconf but instead simply render a model object from the database to HTML. I'm not even sure if that's necessary because I think most of the time the dynamic URLconf approach works fine. Regards, Erik Allik On 15.09.2008, at 18:40, [EMAIL PROTECTED] wrote: > > Hi everybody > > As one of the contributors of django-cms, we (www.divio.ch) are using > the django-cms codebase for a lot of our projects. At the moment we > include/integrate non-textual content (galleries, contact forms, or > whatever) in the following manner: > - create a navigation node. That is a «Page» in django-cms > - (optional) create text/html content, That is a «PageContent» in > django-cms > - link to your custom django models over the Add-on functionality (to > be activated in the cms_settings.py, not yet in newforms-admin) > > This way, one can include any type of custom models on specific pages. > The pages itself are accessible over the navigation. They also - of > course - can be reordered over the navigation interface of django- > cms. > > If you have more complex pages/views that not contain any pagecontent > you would edit with django-cms, you can still create the navigation > node (Page) and i.e. set the «override url» attribute of the Page. > Than you can "catch" the overridden_url in your urls.py before the cms > url handler comes into play and do whatever you want in your custom > view. That's how we do it... > > Lots of ideas concerning the improvement of such integration are in > the pipeline. As we are a small team at the moment, we enjoy if some > proposals and contributions are made from anybody out there. > > Stay tuned... > Maik > > On 9 Sep., 21:31, "Antoni Aloy" <[EMAIL PROTECTED]> wrote: >> 2008/9/8 Thomas Steinacher <[EMAIL PROTECTED]> >> >> Hi Thomas! >> >> >> >>> @Antoni Aloy: >>> What do you mean by integration? Like integrating other applications >>> (e.g. a gallery) into the CMS? We're still looking for a good >>> solution >>> to do that (e.g. by providing an API which allows to write a CMS >>> plugin which would allow to integrate a third-party app directly >>> into >>> the CMS). >> >>> I divide CMS in applications in two groups, one are just APIs, so >>> you can >> >> create an application and the CMS just provides the content, but in >> that >> kind of applications textual content is not the goal. So, they are >> easy to >> integrate with your applications but they don't provide much >> functionallity. >> Django-cms would be that kind. >> >> The other group are CMS applications. That is, the CMS *is *the >> application. >> They are very usefull when your site is content based. Usually this >> kind of >> cms applications don't fit when creating applications that need a >> CMS. The >> user interface for the CMS and the fucntionallity are much better >> than the >> prevoious one. >> >> I don't know yet where to classify it. In fact I'll be very happy >> if I could >> have a powerfull CMS like yours being able to create applications >> using it >> as a way to manage multilanguage content. >> >> My english is not as good as I like but this is what I'd tried to >> say with >> "integration". >> >> -- >> Antoni Aloy López >> Blog:http://trespams.com >> Site:http://apsl.net > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
