On Mon, Sep 14, 2009 at 7:10 PM, Patrick J McNerthney
wrote:
> The objective is not to completely separate the two. URLs are roughly
> the "Controller" in the MVC world, and need to know about both the
> models and the views. It is the "glue" that binds the two together.
> URLs already do know
> I can't see the problem in that article.
> Also, the datetime objects have changed since then, taking a timezone
> as optional parameter:
> http://docs.python.org/library/datetime.html#datetime-objects
>
> I mean we are using date/time already with our pre-save way of doing
> things, why should
>
> If the objective is to seperate the two systems why is having the URL
> system know about Models more acceptable than having the Model system
> know about URLs? This is most certainly a bike shed IMO.
>
The objective is not to completely separate the two. URLs are roughly
the "Controller
On Sep 15, 3:25 am, Mike Malone wrote:
> > I just checked in change to Tornado that enables you to run any WSGI-
> > compatible framework on Tornado's HTTP server so that Django apps
> > could run on top of Tornado's HTTP server and benefit from some of the
> > performance work we have done. (I
On Mon, Sep 14, 2009 at 6:58 PM, Patrick J McNerthney
wrote:
>
> We are not (at least not now), endless discussing the color to paint the
> bike shed, we are discussing the fact that the bike shed is being built
> in entirely the wrong location. IMO, the proper place to build this
> particular b
We are not (at least not now), endless discussing the color to paint the
bike shed, we are discussing the fact that the bike shed is being built
in entirely the wrong location. IMO, the proper place to build this
particular bike shed is in the urlresolvers section of the city, not in
the mode
When using related table based approach for the translations, django
could use pivoting to fetch all the translations with just one normal
join.
Some pseudo sql, skipping constrains and indexes...
create table a (
id integer pkey
);
create table b (
id integer pkey,
a_id integer references
This is kind of incorrect question by itself.
It's MVC pattern you're trying to overcome with this sort of question.
Model is not living anywhere on site!
Admin app instance ("View" and "Controller") is one that allows you to
manage specific model instances ("Model") and make guesses what's the
m
Le 12 sept. 2009 à 15:20, Jacob Kaplan-Moss a écrit :
>
> On Sat, Sep 12, 2009 at 8:42 AM, Thomas K. Adamcik
> wrote:
>> In essence we could add only one new method to the API that returns a
>> URL-object that provides access to the data:
>
> I like this idea a lot. It solves most of the prob
On Mon, Sep 14, 2009 at 1:54 PM, Joseph Kocherhans
wrote:
>
>
> On Mon, Sep 14, 2009 at 12:16 PM, Alex Gaynor wrote:
>>
>> FWIW, Russ, Joseph Kocherhans, and I discussed this at the DjangoCon
>> sprints and our conclusion was to have syncdb only sync a single table
>> at a time, and to take a --
On Mon, Sep 14, 2009 at 12:45 PM, Patrick J McNerthney
wrote:
> I am new to Django and am deep in the middle of my first major project
> using Django. When I encountered get_absolute_url, my reaction was,
> "What were they thinking!". Why does the model have any knowledge about
> it's presentat
Yuri,
I am with you.
I am new to Django and am deep in the middle of my first major project
using Django. When I encountered get_absolute_url, my reaction was,
"What were they thinking!". Why does the model have any knowledge about
it's presentation? What if that very same model object is
Hey,
As per Russ's request, I'm pinging this thread. Does my proposal seem
feasible to people more familiar with Django's guts than I?
Cheers,
Alex
On Sep 8, 9:38 am, Russell Keith-Magee wrote:
> On Tue, Sep 8, 2009 at 12:35 PM, vegas wrote:
>
> > Okay, so I've looked at the previous discuss
On Mon, Sep 14, 2009 at 12:16 PM, Alex Gaynor wrote:
>
> FWIW, Russ, Joseph Kocherhans, and I discussed this at the DjangoCon
> sprints and our conclusion was to have syncdb only sync a single table
> at a time, and to take a --exclude flag (or was it --include?) to
> specify what models should b
> I just checked in change to Tornado that enables you to run any WSGI-
> compatible framework on Tornado's HTTP server so that Django apps
> could run on top of Tornado's HTTP server and benefit from some of the
> performance work we have done. (I just sent a message to django-users@
> with getti
On Mon, Sep 14, 2009 at 12:49 PM, JL wrote:
>
> Russell Said:
>
> "I'm yet to be convinced that `Meta: using` is actually a good thing.
> IMHO, it's the very model of a setting that makes it impossible to
> re-use your application. The setting will probably survive into the
> final version, but I
Hi Jacob,
how about my kind of patch -- deprecation and removal of the feature? :)
On Mon, Sep 14, 2009 at 8:24 PM, Jacob Kaplan-Moss wrote:
>
> Hi guys --
>
> Ya know, this conversation is going in circles, and arguing over
> increasingly trivial details. As always, our policy is that the pers
Russell Said:
"I'm yet to be convinced that `Meta: using` is actually a good thing.
IMHO, it's the very model of a setting that makes it impossible to
re-use your application. The setting will probably survive into the
final version, but I suspect we need a much better mechanism than
`Meta: using
Hi guys --
Ya know, this conversation is going in circles, and arguing over
increasingly trivial details. As always, our policy is that the person
who builds the bikeshed gets to decide which color it is, so I'd
suggest we all stop writing email and start writing Python now. Work
up a patch, and
On Monday 31 August 2009 15:26:42 Russell Keith-Magee wrote:
> 3. CSRF is currently a contrib app. Why? CSRF control is the very
> model of a feature that shouldn't be decoupled from the base
> framework. If we're aiming to make CSRF support like XSS support,
> surely it should be baked into the
On Mon, Sep 14, 2009 at 6:30 PM, drozzy wrote:
>
> get_absolute_url is just a shortcut for one stupid thing: Get some url
> returned by the model.
> It does not have to be about the object. It can be: google.com.
> Whatever!
So you tell get_absolute_url does some random stuff, and no contract imp
I can't see the problem in that article.
Also, the datetime objects have changed since then, taking a timezone
as optional parameter:
http://docs.python.org/library/datetime.html#datetime-objects
I mean we are using date/time already with our pre-save way of doing
things, why should auto_add act
get_absolute_url is just a shortcut for one stupid thing: Get some url
returned by the model.
It does not have to be about the object. It can be: google.com.
Whatever!
All the things you are concerned with can be created using urls+views
so you shouldn't even need to worry about get_absolute_url
Hi all,
I'm very much concerned about using get_absolute_url and its substitutes at all.
This approach makes harder to keep apps modular, extensible and
reusable of apps.
1) You make a hypothesis that each object instance has a single point
of reverse and a default output format, giving you onl
24 matches
Mail list logo
