On Dec 8, 3:23 am, Rick Yazwinski wrote:
> I think that this may be too simplified:
> protocol = getattr(settings, "PROTOCOL", "http")
> domain = Site.objects.get_current().domain
> port = getattr(settings, "PORT", "")
>
> Many sites put load
Mike Malone wrote:
> In my opinion, using the Site module and settings files is damn
> annoying.
My point is that we better fix these annoyances than leave this way of
doing things altogether.
> I never use the Site module
This is by itself is not the reason why it might be annoying. Django
Michael Richardson wrote:
> With these cases (the former more so than the latter) you are creating
> URLs for an entirely separate project, not your own, essentially.
Not "entirely separate". These are projects sharing much of the
codebase, just having different SITE_ID in settings.
Anyway
On Wed, Dec 16, 2009 at 4:51 PM, SmileyChris wrote:
>
>
> On Dec 17, 8:57 am, Alex Gaynor wrote:
>> On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote:
>> > How's that different than the current situation, where we return an
>> >
On Dec 17, 8:57 am, Alex Gaynor wrote:
> On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote:
> > How's that different than the current situation, where we return an
> > absolute URL reference that can be converted into an absolute URL
> > using
On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote:
> On Wed, Dec 16, 2009 at 11:10 AM, Alex Gaynor wrote:
>> On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone wrote:
The way i see it (which may be wrong), this is not a proposal to
On Wed, Dec 16, 2009 at 11:10 AM, Alex Gaynor wrote:
> On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone wrote:
>>> The way i see it (which may be wrong), this is not a proposal to make
>>> the request object global or replace/refactor the contrib.site app.
On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone wrote:
>> The way i see it (which may be wrong), this is not a proposal to make
>> the request object global or replace/refactor the contrib.site app. In
>> fact, some of the use cases mentioned strike me as things that would
>>
> The way i see it (which may be wrong), this is not a proposal to make
> the request object global or replace/refactor the contrib.site app. In
> fact, some of the use cases mentioned strike me as things that would
> require overriding the default get_absolute_url method anyway. It
> seems to me
On Tue, Dec 15, 2009 at 3:23 PM, Michael Richardson
wrote:
>
>
> On Dec 15, 4:35 am, Ivan Sagalaev wrote:
>> Mike Malone wrote:
>> > Well, not really. It's making a way to generate a URL based on the
>> > request object global. I agree
On Dec 15, 4:35 am, Ivan Sagalaev wrote:
> Mike Malone wrote:
> > Well, not really. It's making a way to generate a URL based on the
> > request object global. I agree that it's not ideal, but it's not the
> > same as just making the request object global.
>
> My
Mike Malone wrote:
> Well, not really. It's making a way to generate a URL based on the
> request object global. I agree that it's not ideal, but it's not the
> same as just making the request object global.
My main gripe is not globalness of a request object itself (I agree with
"not ideal"
On Sat, Dec 12, 2009 at 3:58 PM, Ivan Sagalaev
wrote:
> Mike Malone wrote:
>> On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee
>> wrote:
>>> 4. I share Mike's concern about using settings.SITE_ID to determine
>>> the current host, but I'm
Mike Malone wrote:
> On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee
> wrote:
>> 4. I share Mike's concern about using settings.SITE_ID to determine
>> the current host, but I'm not sure I have any suggestions on how we
>> could practically use request, short of
+1 to get_url
--
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
On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee
wrote:
> 4. I share Mike's concern about using settings.SITE_ID to determine
> the current host, but I'm not sure I have any suggestions on how we
> could practically use request, short of encouraging the use of a
>
On Tue, Dec 8, 2009 at 6:43 AM, Simon Willison wrote:
> This made it to the 1.2 feature list:
>
> http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
>
> If we want this in 1.2, it could be as simple as merging the get_url /
> get_url_path methods in to the base
I'd much rather have this information come from the current request
vs. coming from settings. Relying on the Site is particularly
annoying. I like the implementation of build_absolute_uri() in
django.http.HttpRequest. The hard part is getting the request object
to a place where it's usable by
I brought this up during the 1.1 dev schedule and if I remember correctly
the response was "let's have it painted red" and it seemed like it wasn't
considered a practical problem.
The reason I think this is an issue is the same reason that I get frustrated
whenever I see a pull-style handle on a
BTW, generally I like this idea... :)
On Mon, Dec 7, 2009 at 10:23 PM, Rick Yazwinski
wrote:
> I think that this may be too simplified:
> protocol = getattr(settings, "PROTOCOL", "http")
> domain = Site.objects.get_current().domain
> port =
I think that this may be too simplified:
protocol = getattr(settings, "PROTOCOL", "http")
domain = Site.objects.get_current().domain
port = getattr(settings, "PORT", "")
Many sites put load balancers and https hardward acceleration in front
of their web interfaces. This
This made it to the 1.2 feature list:
http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
If we want this in 1.2, it could be as simple as merging the get_url /
get_url_path methods in to the base Model class, rolling a few unit
tests and writing some documentation. It feels like we
22 matches
Mail list logo