On Apr 19, 1:36 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Since this is actually a good idea, we should give credit where it's
> due: the whole theory behind this (and most of the details) is Simon
> Willison's creation. I just wrote the code and polished off some of the
> less smooth
Justin Bronn wrote:
> >From GEOSGeometry it is simple to retrieve WKT and HEX, e.g., 'g.wkt'
> or 'g.hex'. However, KML is implemented by PostGIS and can only be
> retrieved if you do "SELECT AsKML(the_geom)" on the database end.
> Further, GML (ancestor to KML, another OGC standard) and SVG can
> How do you handle data input of GIS types? What format is used during
> assignment?
During assignment, PostGIS returns in a format called HEXEWKB
(hereinafter "HEX"), one of its 'canonical forms'. Essentially it's a
hexadecimal string of the binary format (WKB, an OGC standard). For
input
On Wed, 2007-04-18 at 08:58 +, SmileyChris wrote:
[...]
> I actually like Malcom's proposal. Can't say I'd be thrilled if it was
> on by default though.
Since this is actually a good idea, we should give credit where it's
due: the whole theory behind this (and most of the details) is Simon
On 4/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Would you consider adding a thumbnail capability to Django? I know
> there are contributions out there that do it and the dependency on PIL
> might be a negative but I believe this is a very common use case. How
> many apps have an
Just a question out to the developers-
Would you consider adding a thumbnail capability to Django? I know
there are contributions out there that do it and the dependency on PIL
might be a negative but I believe this is a very common use case. How
many apps have an image field and don't use
Russell Keith-Magee wrote:
> On 4/19/07, jbronn <[EMAIL PROTECTED]> wrote:
>
>> The GIS branch (GeoDjango) is interested in type coercion.
>> Specifically, PostGIS returns geometries as hex strings to the client
>> -- it would be preferable to have this come into the model as either a
>>
On 4/18/07, Brian Harring <[EMAIL PROTECTED]> wrote:
> What exactly was the issue you were having? Ofhand, a ShellCommand
> with haltOnFailure=True ought to suffice- last I looked, y'alls test
> runner properly set the exit code if a failure was detected, thus you
> should be able to rely on
On 4/18/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> The script [1] I'm using for the Django pybots [2] is very simple. The
> only thing I'd like to get going is testing against different
> backends. Do you have a problem with running it on pybots, except for
> the fact it isn't testing
On 4/19/07, jbronn <[EMAIL PROTECTED]> wrote:
>
> The GIS branch (GeoDjango) is interested in type coercion.
> Specifically, PostGIS returns geometries as hex strings to the client
> -- it would be preferable to have this come into the model as either a
> different type of string like WKT
On 4/19/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 4/18/07, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> > Do you have a resident buildbot? That could be used to run the
> > regression tests on (all pythons) x (all databases). It would still
> > take time, of course, but it
On 4/18/07, Gulopine <[EMAIL PROTECTED]> wrote:
>
> On Apr 17, 9:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
> I don't know what
> other field types there might be in the future, but it seems like a
> stretch to think that it's unnecessary just because I can't anticipate
> other
On Wed, Apr 18, 2007 at 11:16:56AM -0500, Jacob Kaplan-Moss wrote:
>
> On 4/18/07, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> > Do you have a resident buildbot? That could be used to run the
> > regression tests on (all pythons) x (all databases). It would still
> > take time, of course,
Thinking about it more, I wouldn't actually be against Malcom's
autoescaping solution being on by default - I do see the importance of
solid XSS protection!
I can also see a solution which would maintain backwards compatibility
for old sites:
TEMPLATE_AUTOESCAPE=False in conf.global_settings
Matt,
That's a good point you brought up: if there's a ForeignKey to a model
with a geographic field, then the model with the ForeignKey requires
GeoManager to construct geographic queries on related objects (even if
the model itself does not have geographic fields).
The GeoManager overrides
> Coercion of the type you describe is not required for any field
> currently supported. I would be hesitant to include coercion as a core
> part of the framework unless there is a generic need to coerce
> database values into Python values in some way other than that
> performed by the database
I'm not sure this is really adding that much. Why can't you just use
reverse as it stands? It doesn't seem hard to do:
>>> some_id = 1
>>> reverse(some_view, kwargs=dict(id=some_id))
'/event/1/'
or:
>>> reverse(some_view, args=[some_id])
'/event/1/'
On 4/18/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 4/18/07, Daniel Brandt <[EMAIL PROTECTED]> wrote:
> > Something has been bugging me for a while..
>
> This type of complaint seems to come up every few months. I'm always tempted
> to
> ignore it because I have a hard time
Matt Riggott wrote:
> from django.core.urlresolvers import reverse
>
> def absolute_url(viewname, *args, **kwargs):
> return reverse(viewname, args=args or [], kwargs=kwargs or {})
As far as I can tell you don't need 'or []' and 'or {}' since they will
be [] and {} already when
Hoi,
Another small notice. Pylons and other frameworks thought about
implementing "__html__" for objects that return an html representation
of the object. If there is none it's converted to unicode and escaped.
Adding something like "__html__ = lambda s: s" to the escaped string
base classes
A little more research shows that I could also accomplish what I'm
looking for by tying into the pre_init or post_init signal, but then
I'd need a customized function for each field that needs processing,
on each model. This could be done, of course, and it would certainly
keep this coercion out
Hi folks,
Something I find myself writing for each new Django project is a small
wrapper for the django.core.urlresolvers.reverse function. It usually
looks something like this:
from django.core.urlresolvers import reverse
def absolute_url(viewname, *args, **kwargs):
return
On 4/18/07, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> Do you have a resident buildbot? That could be used to run the
> regression tests on (all pythons) x (all databases). It would still
> take time, of course, but it could at least be automated[1][2].
I've spent some time in the past
On Wed, Apr 18, Jonathan Daugherty wrote:
>
> # 7. Run the regression tests against every supported version of Python
> #with every database backend available.
>
> Do you have a resident buildbot? That could be used to run the
> regression tests on (all pythons) x (all databases).
Jacob Kaplan-Moss wrote:
> I've filed tickets and bugs against many other projects, and as you
> might expect the results run the gamut from "fuck you"[1] to being
> checked in instantly.
> ...
> [1] No prizes for guessing which project this was.
I'll have a shot anyway: RoR? ;-}
Hi
Ok, sorry about that Jacob!
Thanks for pointing me at right place!
Best Regards,
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
# 7. Run the regression tests against every supported version of Python
#with every database backend available.
Do you have a resident buildbot? That could be used to run the
regression tests on (all pythons) x (all databases). It would still
take time, of course, but it could at
On Wed, Apr 18, Daniel Brandt wrote:
>
> Something has been bugging me for a while..
>
> Check out http://code.djangoproject.com/ticket/3012 for a pretty
> critical patch to the locmem cache backend. The patch is accepted and
> ready for checkin, and more than two weeks have passed since. The
On Apr 17, 9:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Coercion of the type you describe is not required for any field
> currently supported. I would be hesitant to include coercion as a core
> part of the framework unless there is a generic need to coerce
> database values into
Hi Chris,
On Wed, Apr 18, SmileyChris wrote:
>
> On Apr 18, 3:48 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > In the past threads, we basically had consensus anyway, I'm not sure
> > that revisiting everything again is worth the hassle.
>
> Without trying to rock the boat...
On Apr 18, 3:48 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Unfortunately, the AutoEscapingAlternative page uses strawmen to try and
> make its arguments.
Ok, it's less "controversial" now.
--~--~-~--~~~---~--~~
You received this message because you are
Hi
Malcolm Tredinnick wrote:
> What I don't think is the right answer is to suddenly start making
> gettext() behave as if it were ugettext() -- using the wrong name for
> something will lead to confusion for people who use Django as a tool,
> not as a lifestyle choice.
Certainly. Think about
32 matches
Mail list logo
