> 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.
>
> Alex
Because it's the URL system which is making those models available on
the web, not
Just like james has pointed out, the way urls are assembled when asked
directly to models can be made relatively independent from the models
themselves. I do so personally by using the "permalink" decorator and
returning just a name for the right view to be matched, using the
built-in named view m
Oh, and trying to make the url resolving mechanism look in the
database is really a bad idea because it would trigger a bunch of
database queries every time a request is processed by your
application, which would really slow things down.
mathieu
On 16 sep, 10:11, matehat wrote:
> Hi,
>
> If the
Hi,
If the url only depends on the object's id (which I suppose don't
change with time), you should not have it put in the database at
first, because the object's id alone takes care of its persistence.
Then, plugging it into Django's url resolving mechanism becomes really
easy with the well-docu
On Wed, Sep 16, 2009 at 9:11 AM, Vladimir Prudnikov wrote:
> Hello,The default behaviour for saving object is very hard for big models,
> especially if it contain TextField. For example if I change one small field
> in a model and that run save() method it will generate UPDATE query for all
> of t
Hello,The default behaviour for saving object is very hard for big models,
especially if it contain TextField. For example if I change one small field
in a model and that run save() method it will generate UPDATE query for all
of the fields which is very slow.
Instead of that I do it like that:
p
Hello,
I am having little difficulties with django url system and I hope
someone can clear it up. Here's what I want to achieve: we're going to
have a tree-based catalog in our app and we'd like to index it like
this: name1/name2/name3/... I've created a database lookup table url <-
> id with urls
On Wednesday 16 September 2009 12:21:54 Tom Evans wrote:
> On Wed, 2009-09-16 at 04:09 -0700, Aljosa Mohorovic wrote:
> > could somebody check ticket #10436?
> > is there some reason why patch for ticket #10436 is not in trunk?
> >
> > Aljosa Mohorovic
>
> It was committed 6 months ago?
>
> http
On Wed, 2009-09-16 at 04:09 -0700, Aljosa Mohorovic wrote:
> could somebody check ticket #10436?
> is there some reason why patch for ticket #10436 is not in trunk?
>
> Aljosa Mohorovic
It was committed 6 months ago?
http://code.djangoproject.com/changeset/10030
Check your sources are up to
could somebody check ticket #10436?
is there some reason why patch for ticket #10436 is not in trunk?
Aljosa Mohorovic
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group,
> Interestingly, if the first title isn't the first line, then this
> works fine... i.e. if you do:
Yes, I discovered this. I don't know why.
> You'll get the expected result... how often does your ReST content
> start with a heading?
Very often. Look at any ReST document and you will find sever
On 16 Sep 03:56, Max Battcher wrote:
> On 9/16/2009 2:34, Exe wrote:
>>
>>> What isn't working with section headers? They seem to be working fine
>>> in the cases that I use them...
>>>
>>> Can you give an ReST example that is failing to render correctly?
>>
>> Shure. Test program to reproduce pro
On 16 Sep 10:34, Exe wrote:
> > What isn't working with section headers? They seem to be working fine
> > in the cases that I use them...
> >
> > Can you give an ReST example that is failing to render correctly?
>
> Shure. Test program to reproduce problem:
>
> #
On 9/16/2009 2:34, Exe wrote:
>
>> What isn't working with section headers? They seem to be working fine
>> in the cases that I use them...
>>
>> Can you give an ReST example that is failing to render correctly?
>
> Shure. Test program to reproduce problem:
>
>
14 matches
Mail list logo
