On 4/6/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote: > > Lachlan Cannon wrote: > > > > We have urls.py already, which maps urls -> views. Most of the proposals so > > far > > for getting urls back seem to have revolved around getting a url for a > > model -- > > I think this is looking at the situation the wrong way. We're not > > redirecting > > people to an object. We're redirecting people to a view of an object. > > That was my point in the ticket #672. > > > My proposal for url mapping is that we can specify a specific view we want > > to > > redirect people to, and provide the right arguments to fill that url out. > > Sounds good but the devil is in the details of implementation.
I described my proposal in : http://groups.google.com/group/django-developers/browse_thread/thread/884a837856023d42/8eb4e3227ed3cd62?lnk=st&q=Think+about+urlconf+again&rnum=1#8eb4e3227ed3cd62 > > > We could import a urlresolver module (maybe? haven't thought about this bit > > much) and tell it we want to send the user to the > > taravar.apps.newsletters.views.subscrie view, with slug=newsletter.slug > > > > Maybe in code it'd be > > > > import urlresolver > > > > url = urlresolver.url('taravar.apps.newsletters.views.subscribe', > > slug=newsletter.slug) > > > > Thoughts? Criticisms? I've had this idea bouncing around for a while but > > have > > yet to flesh it out. > > Is it going to be imported in a view or in a model? I am more inclined > to include this kind of functionality in a view. In this case we have > two problems, which should be resolved somehow: > > 1) It looks like the view should know the name of your project (e.g., > 'taravar'), and the name of your app (e.g., 'newsletters'). What if I > use this app in different project? What if I renamed it for some > reasons? Obviously it can be addressed by some introspective variables, > or by configuration parameters, or a request variable can carry this > information derived during url processing. I think view indeed needs to know the name of the project or the app, but the name should be just a name, but not concerned with url. And if we define a relationship between such names and urls, so the first step is ok. Next we should resolve, how to define it easily, and hwo to convert they easily. So in my proposal, I just define a dict to map name and url, just like: MAP_RULES = ( ('name1', 'url1'), ('name2', 'url2'), ) This one in not very same like my original proposal. And you can ealily convert it to a dict, it just like settings.py format. Or directly define it as a dict, that's ok. So there are four places we should think about: 1. urls.py 2. view 3. template 4. model And we also need to decide how to define a mapping rule easily. And I think we can also use the common way we just do in out codes: string format, and we also can provide some helper function to do that. How to define a mapping rule in string? I think out some formats: '$name/page' #using '$' as the prefix, but these one may be conflict with regx '$' '<name>/page' '{name}/page' '{!name!}/page' and many formats we can think out. Also we can provide some helper function: get_mapping_rule('name') + '/page' So we have many appoaches in different places. And I think using string format is the easiest way: in urls.py, we can : (r'^{!blog!}/(?P<user_name>.*?)/', include('apps.woodlog.urls')), in views, we can: HttpResponseRedirect('/{!blog!}/username/feb') in template, we can: <a href="{!blog!}/page">{{ title }}</a> and in model, we can do it just like in views: def get_relative_url(self): return str(object.id) def get_absolute_url(self): return '{!blog!}/%s' % self_get_relative_url() > > 2) If we are not going to have get_absolute_url(), we have to provide a > default view. It appears to be useful in some special situations, like > in the Admin. How to do it? One way is to follow "convention over > configuration" path requiring a default name (or url) to be available > for that. > > If you want to put this functionality in the model, you have even more > problems. > > Additionally the solution should be simple, non-taxing in typical cases, > and useful for reusable applications. > > Thanks, > > Eugene > -- I like python! My Blog: http://www.donews.net/limodou My Django Site: http://www.djangocn.org NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
