Re: making URL resolving/reversing gradually more flexible
Hi Sam,
what's the problem with regexp = '^newitems'+SUFFIX+'$' where
SUFFIX='(/|\.xml|\.json)' ?
And if you need more shortcuts, there are surlex (
http://codysoyland.com/2009/sep/6/introduction-surlex/ ) and
alternatives.
On Fri, Nov 12, 2010 at 11:25 AM, Sam Lai wrote:
> [First timer participating in the Django dev process, so apologies if
> I have missed some protocol etc.]
>
> First up, this is not about adding an alternate URL
> resolution/reversal method to the core; I've noticed a fair bit of
> resistance to that.
>
> PROBLEM:
> I want to make my website available via an API with URLs like this -
> http://example.com/newitems/ => returns HTML
> http://example.com/newitems.xml => returns XML
> http://example.com/newitems.json => returns JSON.
>
> To represent this in urls.py, I have to either:
> a) write a separate url entry for each one
> b) write 2 url entries, one for newitems/ and another for
> newitems\.(?P\w+). This is the better option, but still
> annoying. Plus it forces my view to validate whether or not the format
> value is acceptable (e.g. is either xml or json).
>
> I have to do this for every URL I wish to make available via an API,
> bloating out my urls.py file. (I'm aware I can use the HTTP-ACCEPT
> header instead, but there is a need to be able to force the response
> format in the URL for certain uses.)
>
> MY DESIRED SOLUTION:
> Subclass RegexURLPattern, and override the resolve method so that it
> will replace a placeholder, e.g. (?#format), with the appropriate
> regexps (/|\.xml|\.json). Effectively it will perform something
> similar to this regexp instead -
> ^newitems(/|(?P(\.xml|\.json))) where the list of accepted
> formats will be defined in settings. This subclass will be returned
> using an alternate url(...) call, e.g. murl(...).
>
> So my urls.py will look like -
> urlpatterns = patterns('project.app.views',
> murl(r'^/(?P\d+)(?#format)$', AppView.as_view(),
> name='app_view1'),
> )
>
> (For completeness, the view is a CBV, and uses the format arg to
> determine which template to render, and using what MIME type to
> respond.)
>
> This is a proven way of extending the URL system, as demonstrated by
> the various projects out there for alternative URL specification
> syntaxes, e.g. django-easyurls.
>
> ROADBLOCK:
> The issue with this solution is that while resolving will work fine,
> reversing will not. The list of possible URLs for a particular view is
> determined by _populate in RegexURLResolver, and is based on the
> regexp pattern alone. Django doesn't support | in regexps
> (understandably), and there is no way to supplant this with additional
> regexps or possibilities at the moment, even though the infrastructure
> is there during reversal.
>
> RESOLUTION - PHASE 1:
> Because of the friction and work required to fully revamp the URL
> resolution system, this phase is a short, simple fix that will suffice
> for most cases where people want to extend the URL resolution system.
>
> Refactor out line 218 (in trunk) in django/core/urlresolvers.py:
>
> bits = normalize(p_pattern)
>
> ... into a separate method in RegexURLPattern:
>
> def get_possibilities(self):
> return normalize(self.regex.pattern)
>
> ... and replace line 218 in django/core/urlresolvers.py with:
>
> bits = pattern.get_possibilities()
>
> That's it. I'll create a patch for this later if the consensus is
> positive. The above change allows subclassed RegexURLPattern classes
> to alter what is returned as possible URLs from that pattern. I'm
> hoping this simple change can be made in Django 1.3.
>
> Of course, the possibilities returned still have to be regexps, which
> leads to phase 2...
>
> RESOLUTION - PHASE 2:
> The ultimate goal should be a URL resolution system that allows
> alternate URL spec syntaxes to be first-class citizens, allowing
> regexp based URL specs and say, URI Template specs to exist
> side-by-side.
>
> My plan would be to create an abstract base class for all URLPatterns,
> which RegexURLPattern will extend. The existing behaviour will mostly
> stay, except the get_possibilities from phase 1 will be deprecated in
> favour of a new reverse method. The reverse method will be called by
> the new universal URLResolver class for matches when reversing URLs,
> and if a match exists, that will be returned. During _populate(), the
> new universal URLResolver class will group URLPattern objects by view
> callback and name, instead of the output of
> get_possibilities/normalize.
>
> This approach requires no changes to existing urls.py; in fact, from a
> dev perspective, they would only notice the difference if they choose
> to use alternate URL spec syntaxes. The existing regexp system will
> work as it has always worked. And it makes sense that the URLPattern
> object is responsible for resolving and reversing itself, and not the
> resolver.
>
> Until this phase is reached, the API should be considered private so
> devs are on notice that things will change and may break
making URL resolving/reversing gradually more flexible
[First timer participating in the Django dev process, so apologies if
I have missed some protocol etc.]
First up, this is not about adding an alternate URL
resolution/reversal method to the core; I've noticed a fair bit of
resistance to that.
PROBLEM:
I want to make my website available via an API with URLs like this -
http://example.com/newitems/ => returns HTML
http://example.com/newitems.xml => returns XML
http://example.com/newitems.json => returns JSON.
To represent this in urls.py, I have to either:
a) write a separate url entry for each one
b) write 2 url entries, one for newitems/ and another for
newitems\.(?P\w+). This is the better option, but still
annoying. Plus it forces my view to validate whether or not the format
value is acceptable (e.g. is either xml or json).
I have to do this for every URL I wish to make available via an API,
bloating out my urls.py file. (I'm aware I can use the HTTP-ACCEPT
header instead, but there is a need to be able to force the response
format in the URL for certain uses.)
MY DESIRED SOLUTION:
Subclass RegexURLPattern, and override the resolve method so that it
will replace a placeholder, e.g. (?#format), with the appropriate
regexps (/|\.xml|\.json). Effectively it will perform something
similar to this regexp instead -
^newitems(/|(?P(\.xml|\.json))) where the list of accepted
formats will be defined in settings. This subclass will be returned
using an alternate url(...) call, e.g. murl(...).
So my urls.py will look like -
urlpatterns = patterns('project.app.views',
murl(r'^/(?P\d+)(?#format)$', AppView.as_view(),
name='app_view1'),
)
(For completeness, the view is a CBV, and uses the format arg to
determine which template to render, and using what MIME type to
respond.)
This is a proven way of extending the URL system, as demonstrated by
the various projects out there for alternative URL specification
syntaxes, e.g. django-easyurls.
ROADBLOCK:
The issue with this solution is that while resolving will work fine,
reversing will not. The list of possible URLs for a particular view is
determined by _populate in RegexURLResolver, and is based on the
regexp pattern alone. Django doesn't support | in regexps
(understandably), and there is no way to supplant this with additional
regexps or possibilities at the moment, even though the infrastructure
is there during reversal.
RESOLUTION - PHASE 1:
Because of the friction and work required to fully revamp the URL
resolution system, this phase is a short, simple fix that will suffice
for most cases where people want to extend the URL resolution system.
Refactor out line 218 (in trunk) in django/core/urlresolvers.py:
bits = normalize(p_pattern)
... into a separate method in RegexURLPattern:
def get_possibilities(self):
return normalize(self.regex.pattern)
... and replace line 218 in django/core/urlresolvers.py with:
bits = pattern.get_possibilities()
That's it. I'll create a patch for this later if the consensus is
positive. The above change allows subclassed RegexURLPattern classes
to alter what is returned as possible URLs from that pattern. I'm
hoping this simple change can be made in Django 1.3.
Of course, the possibilities returned still have to be regexps, which
leads to phase 2...
RESOLUTION - PHASE 2:
The ultimate goal should be a URL resolution system that allows
alternate URL spec syntaxes to be first-class citizens, allowing
regexp based URL specs and say, URI Template specs to exist
side-by-side.
My plan would be to create an abstract base class for all URLPatterns,
which RegexURLPattern will extend. The existing behaviour will mostly
stay, except the get_possibilities from phase 1 will be deprecated in
favour of a new reverse method. The reverse method will be called by
the new universal URLResolver class for matches when reversing URLs,
and if a match exists, that will be returned. During _populate(), the
new universal URLResolver class will group URLPattern objects by view
callback and name, instead of the output of
get_possibilities/normalize.
This approach requires no changes to existing urls.py; in fact, from a
dev perspective, they would only notice the difference if they choose
to use alternate URL spec syntaxes. The existing regexp system will
work as it has always worked. And it makes sense that the URLPattern
object is responsible for resolving and reversing itself, and not the
resolver.
Until this phase is reached, the API should be considered private so
devs are on notice that things will change and may break existing
custom URL resolution code.
Again, I'm happy to have a crack at making this work if the consensus
is positive.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/dja
Re: Receipt for mail to security@ ?
On Fri, Nov 12, 2010 at 3:38 AM, Paul McMillan wrote: >> I'd argue that an autoresponder is almost exactly what we *don't* >> need. An autoreponder can give the illusion of that a message has been >> received when it's really just a robot going through the motions. The >> worst possible situation would be an autoreponse message that says >> "We're looking into it" when the message has actually fallen into the >> bit bucket. > > That makes sense. I was thinking an autoresponder along the lines of > "Your message got to our servers and wasn't marked as spam, but a real > person hasn't looked at it yet. We try to respond to all messages with > X days, if you haven't heard from us by then, please do Y." > > Something like that would bridge the gap between "we got your message" > and "we've been able to replicate the issue and have some idea for a > fix". Sounds like a reasonable idea. I'll raise the idea with the rest of the core team. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Django developer required
Hello My company is looking for a Django developer based in Somerset in the UK. If anyone is interested please see http://www.joinerysoft.com/en/company/job-vacancies/ Many Thanks Tom -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DDN: Localize anything with _(this_syntax) ?
On Thu, Nov 11, 2010 at 4:39 PM, Stephen Kelly wrote:
> I have a patch to allow localizing localizable values like {{ _(foo) }},
> which I think is more convenient. It sort of mixes up the meaning of _() to
> be both for translatable strings and localizable dates and numbers, so I
> thought I'd ask before finishing the patch and filing a ticket whether that
> is something people want/think is ok.
I'm -1 on this. _ has a very well-established meaning -- "translate"
-- and I can't see a good reason for Django to be "special" here.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
DDN: Localize anything with _(this_syntax) ?
Hi,
Currently strings in templates can be translated with {{ _("foo") }} syntax.
Localizing values can be done with a filter {{ foo|localize }}.
I have a patch to allow localizing localizable values like {{ _(foo) }},
which I think is more convenient. It sort of mixes up the meaning of _() to
be both for translatable strings and localizable dates and numbers, so I
thought I'd ask before finishing the patch and filing a ticket whether that
is something people want/think is ok.
In [1]: from django.template import Template, Context
In [2]: import datetime
In [3]: t = Template("{{ _(foo) }} -- {{ _(bar) }} -- {{ _(100.001) }}")
In [4]: c = Context({ "foo" : 11, "bar" : datetime.date.today() })
In [5]: t.render(c)
Out[5]: u'100,001 -- Nov. 11, 2010 -- 100.001'
(Locale is en_US)
All the best,
Steve.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Disqus API 3.0
I think you accidentally sent this to the wrong list. This is django- developers, a mailing list for discussion about the development of Django itself. Thanks, Eric Florenzano -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Disqus API 3.0
We have been working on a new version of the API these past couple of months, and we're nearing a public release. I wanted to take this opportunity to see if any of the heavy API users (specific needs, etc) would like to chime in with what they want to see, and possible give our docs/api testing tools a whirl. Just throw your feedback here, and if you're interested in testing out the new API before it goes public, toss me an email (da...@disqus) with what your current application use and we'll go from there. Thanks! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Receipt for mail to security@ ?
> I'd argue that an autoresponder is almost exactly what we *don't* > need. An autoreponder can give the illusion of that a message has been > received when it's really just a robot going through the motions. The > worst possible situation would be an autoreponse message that says > "We're looking into it" when the message has actually fallen into the > bit bucket. That makes sense. I was thinking an autoresponder along the lines of "Your message got to our servers and wasn't marked as spam, but a real person hasn't looked at it yet. We try to respond to all messages with X days, if you haven't heard from us by then, please do Y." Something like that would bridge the gap between "we got your message" and "we've been able to replicate the issue and have some idea for a fix". -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: custom function for autoescape
Hi Luke,
> First, you depend only on the name of the function - so one that shadows
> a builtin filter won't be treated correctly (as you noted on the
> ticket).
This is true, I really hated this bit. The only thing that might work
is "libraryname.filtername" if it's possible to identify exactly which
filter was meant at runtime (the libraryname would be the same as that
used in {% load %} ). Even then it's functionality could depend on
the installed apps, which is just wrong.
> Second, when you are defining an autoescape function you have to know
> all the filters it will ever be used with. This is just as ugly a
> constraint as the problem it is trying to fix.
Not quite. The 'proper' way to do this is to have the filter define a
matching "autoescape context". The whitelist is only really there for
convenience, to let you use filters from other contexts (ie the
default django ones, external ones), without writing new ones.
If you wrote the filter, you can define the "autoescape context". If
you only wrote the escape function, you can define the whitelist. If
you wrote neither and they are for different "autoescape contexts",
you can use the "|safe" filter in the template.
> Third, although we can fix the filters in your 'group 2', you can't fix
> 3rd party filters like this. If we don't fix them, we still have caveats
> that we have to add to the docs - "Be aware that any filters/tag not
> bundled with Django may be broken with respect to autoescape" etc.
This is true, I don't see any way around this.
> Overall, with this addition, the whole thing actually gets harder to
> understand and document, and just feels like a hack. That kind of thing
> is acceptable to fix existing bugs, but not for new features IMO.
Agreed. I'll leave the ticket be for now, I don't really want to
distract anyone from 1.3 work. If I can think of a cleaner way of
doing this, I'll have another look at it after 1.3 is out.
Cheers and thanks for your time,
Will
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: custom function for autoescape
On Wed, 2010-11-10 at 13:04 +0100, Will Hardy wrote: > > Reading over the discussion, I'm in the same camp as Luke. I can see > > the use case, but I see a bunch of sharp edges that will end up biting > > the user in unexpected ways. > > Thanks for dropping by :-) I think I've managed to remove the sharp edges. The proposed solution isn't compelling IMO. Specifying a set of filters as a whitelist (or as a blacklist) is a very brittle mechanism. First, you depend only on the name of the function - so one that shadows a builtin filter won't be treated correctly (as you noted on the ticket). Second, when you are defining an autoescape function you have to know all the filters it will ever be used with. This is just as ugly a constraint as the problem it is trying to fix. Third, although we can fix the filters in your 'group 2', you can't fix 3rd party filters like this. If we don't fix them, we still have caveats that we have to add to the docs - "Be aware that any filters/tag not bundled with Django may be broken with respect to autoescape" etc. Overall, with this addition, the whole thing actually gets harder to understand and document, and just feels like a hack. That kind of thing is acceptable to fix existing bugs, but not for new features IMO. Luke -- I never hated a man enough to give him his diamonds back. (Zsa Zsa Gabor) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Charfields and Admin and None, oh my.
On 11/11/10 01:40, Karen Tracey wrote: > > There is a way, it just requires some admin customization. See: > > http://stackoverflow.com/questions/454436/unique-fields-that-allow-nulls-in-django/1400046#1400046 Right, and you can also register a pre_save hook to fix this, but it's just ugly. > > I don't think we can do anything now that would suddenly, when people > installed a new level of Django, start storing nulls in cases where > previously empty strings had been stored. Wouldn't we then likely be > creating a situation where a table column winds up with some "empty" > values equal to empty strings an others nulls? Having just one "empty" > value is the reason empty strings are forced for null values, > according to the doc. Personally I may wish null had been chosen as > the empty value but I'm not sure we can safely make that change at > this point. (I am tired, though, so maybe I am missing something in > how this would not be a backwards-incompatible change?) Yes, my main problem with this is backwards-compatability - as you say, whenever people started saving forms again, things would suddenly become None, which is never a Good Thing. We could do it only when the field is unique=True null=True (since if you have that chances are you _really didn't_ want an empty string), but that also presents the additional weirdness of it changing only when very specific field options are turned on. The other options are to improve the error message a bit (but doing so while keeping it end-user friendly is tricky) or to add an option to ModelAdmin (because what that class needs is more options...) But yes, the main issue here is the underlying issue that Django has been using "" for empty strings since the start, which can be a divisive issue amongst the developers I know. Something to chalk up for the fabled Django 2, perhaps. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
