Hi,
I figured out that generating the url_patterns wouldn't work, because
the regular expressions are compiled the first time they are accessed.
So I suppose any addition in the Node table would be ignored and the
initial set would be used.
I found another way to accomplish this. I first call the same view for
all urls: core.view.index. In this view I look up the application name
in the database, based on the first part of the url. Then I use
django.core.urlresolvers.resolve to resolve the second part of the
url.
So I have a root url conf that looks like this:
urlpatterns = patterns('',
(r'^(.*?)/-/(.*?)$', views.index),
(r'^(.*)', views.index),
)
So all request get redirected to the index view function of the core
application. That's where the trickery happens:
def index(request, node_url, application_url = ""):
node = Node.objects.get(url=node_url)
(view_function, function_args, function_kwargs) = \
resolve( \
'/%s' % (application_url), \ # the second part of the url, the
actual parameters for the application
'%s.urls' % (node.application) \ # the url conf of the
application: '<applicationname>.urls'
)
function_kwargs['node'] = node
return view_function(request, *function_args, **function_kwargs)
It works, but somehow doesn't feel right: the url resolver gets called
twice and the first time I always call the same view. Maybe there's a
hook I could use so the database lookup happens before the resolver
gets called by django?
kind regards,
Pieter
On Feb 15, 9:54 am, yuccaplant <pieter.cog...@gmail.com> wrote:
> Hi Malcolm,
>
> Thanks for your reply. I think I wasn't really clear. The problem is
> that the first part of the url is could be really anything, as it's
> user defined throgh the cms. So they are created, changed, ... from
> within the web application. As I don't know beforehand how they will
> look, I can't write url patterns for it.
>
> I have a model that maps the first part of the url to an application.
> Suppose this model is called Node, then I have a table node like this:
>
> *id* — *url* — *application name*
> 12 — /paralla/yadda/booh/ — blog
> 22 — /home/info — page
> 21 — /home/blog — blog
> 11 — /frank/blog — blog
> 33 — /frank/bio — page
> 35 — /timeline — calendar
>
> One possibility I've been thinking of, is generating the url patterns:
>
> nodes = Node.objects.all()
> for node in nodes:
> urlpatterns += patterns('',
> (r'^%s$' % node.url, include(node.application), {'id': node.id}),
> )
>
> However, if I have a big site with a lot of content, there woud be a
> lot of nodes and the urlpatterns list could become rather long. Maybe
> this would be bad for performance?
>
> thanks,
>
> kind regards,
>
> Pieter
>
> On Feb 15, 3:13 am, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
>
> > On Sat, 2009-02-14 at 10:39 -0800, yuccaplant wrote:
> > > Hi all,
>
> > > I want to develop a cms and I want my urls partially to be user-
> > > defined, for example:
>
> > > /home/info
> > > /home/blog/-/post/
> > > /frank/blog/-/articles/2003
> > > /frank/bio
>
> > > The first part (the part before '/-/' if any) would map to an
> > > application in the database and is user defined (it could be
> > > anything). That first part could also define additional information to
> > > be passed to the application, in the case of a blog-application this
> > > could be the blog-id. So:
>
> > I think you're designing the implementation a bit in what follows,
> > rather than the functionality. All this talk of database lookups in
> > URLConf isn't appropriate, unless you want to write your own URL
> > resolver.
>
> > > /home/info
> > > A lookup in the database would return the application name: 'Page' and
> > > the page-id: '23'. The url conf of application Page should be included
> > > and the page-id passed to it.
>
> > How do we know what Page and page-id correspond to here? You haven't
> > explained what this is going to do.
>
> > If /home/ is the generic base URL, you could create a pattern that goes
> > before all the user-specific ones (below) that captures it and any
> > following information and passes the processing to a view function which
> > works out that it needs to return Page and 23 and then calls a
> > subsequent function.
>
> > > /home/blog/-/post
> > > A lookup in the database would return the application name: 'Blog' and
> > > the blog-id: '54'. The url conf of application Blog should be included
> > > and the blog-id passed to it. The included url conf takes care to map
> > > the second part of the url (post) to a view.
>
> > > /frank/blog/-/articles/2003
> > > A lookup in the database would return the application name: 'Blog' and
> > > the blog-id: '22'. The url conf of application Blog should be included
> > > and the blog-id passed to it. The included url conf takes care to map
> > > the second part of the url (articles/2003) to the apropriate view.
>
> > > /frank/bio
> > > A lookup in the database would return the application name: 'Page' and
> > > the page-id: '455'. The url conf of application Page should be
> > > included and the page-id passed to it.
>
> > Again, using an initial view to further refine things will work here.
> > The URL pattern will look like
>
> > url('^(?P<user>.*?)/(?P<application>.*)$', user_app_mapping),
>
> > and the user_app_mapping view could do something like this:
>
> > def user_app_mapping(request, user, application):
> > app_name, object_id = get_data_from_inputs(user,
> > application)
> > return real_view(app_name, object_id)
>
> > > So I would to have something like:
>
> > > urlpatterns = patterns('',
> > > (r'^(.*)$', include(<application-name>, <additional-info>)),
>
> > Except that include() doesn't work like that. You would need to write
> > your own function to do that.
>
> > > )
> > > (where <application-name> and <additonal-info> are found by a database
> > > lookup of the first part of the url.)
>
> > > I can't firgure out how the database lookup would fit in and how I
> > > could pass something like a blog-id to the included application url
> > > conf.
>
> > > Any ideas how I could accomplish this?
>
> > Either use intermediate views or look into writing your own URL resolver
> > subclass. The former is easier. The latter might allow you to write
> > everything in your URL Conf file, although whether that will be clearer
> > or not remains to be seen. It will also be a lot more work (and will
> > require reading the existing code and working out how to do it).
>
> > Regards,
> > Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
