On 12/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Or maybe get rid of the "models" cruft:
>
> /admin/myproject/blog/entry/add/
+1 for being the most readable and less cumbersome.
--
Jeroen Ruigrok van der Werven
On 15 Dec 2005, at 3:59, Adrian Holovaty wrote:
Clearly we would want to avoid that. Before importing, it could check
that the module is in INSTALLED_APPS.
By going with /admin/project/app/model/add/ stick with more normal
looking urls, you can do the checking at quite a fine-grained level
On 12/14/05, Ian Holsman <[EMAIL PROTECTED]> wrote:
> my other concern with putting the python path into the URL is would it
> allow nasty thing
> like
> admin/init.me.and.i.format.your.hard_disk/
> ?
> and other weird easter eggs which a unsuspecting admin doesn't realize
> is on his machine?
Cl
On 12/15/05, Afternoon <[EMAIL PROTECTED]> wrote:
>
>
> On 15 Dec 2005, at 3:15, Adrian Holovaty wrote:
>
> > /admin/myproject/blog/entry/add/
>
> +1, most readable, most compact, most guessable.
>
> > The problem with "/admin/myproject.blog.models.entry/", though, is I'm
> > not sure it's pos
my 2c's
add the model name as a parameter to the view so that the developer
can stick the admin screens directly into their application
ie
/forum/ calls my view
/forum/add would call the admin add view with myproject.model.forum as
a parmeter
and so on.
but to answer your specific question I wo
On 15 Dec 2005, at 3:15, Adrian Holovaty wrote:
/admin/myproject/blog/entry/add/
+1, most readable, most compact, most guessable.
The problem with "/admin/myproject.blog.models.entry/", though, is I'm
not sure it's possible to get the Python path *to* an object. For
example, given a mo
In the magic-removal branch (see
http://code.djangoproject.com/wiki/RemovingTheMagic), we're removing
the magic model modules, which means the concept of "module_name" goes
away. This creates a bunch of interesting new issues, because some
parts in Django use module_name -- namely, the admin URLs.
On Dec 14, 2005, at 8:47 PM, Tim Keating wrote:
I expected to see 1 call to function_get_iterator, or, at worst, 1
call
for every GET_ITERATOR_CHUNK_SIZE rows. Instead, I'm seeing *3* calls
to function_get_iterator for every row, which I find perplexing. I
intend to dig into this further but I
On 12/14/05, Tim Keating <[EMAIL PROTECTED]> wrote:
> for foo in foos.get_iterator():
> # Pack some of the data into a binary buffer
>
> I expected to see 1 call to function_get_iterator, or, at worst, 1 call
> for every GET_ITERATOR_CHUNK_SIZE rows. Instead, I'm seeing *3* calls
> to function_g
I have been working on a file download link, where the file is
generated dynamically in the view code and returned via the mechanisms
outlined in the help for generated PDFs or CSVs. This works fine, but
the performance is staggeringly bad. When I prototyped the file builder
in a vanilla Python sc
>
> Wait, I've got it!
>
> reporter.get_article_list()
>
> Wow! So readable, so clear!
>
> (Sorry)
So completely different semantically!
Dody Suria Wijaya wrote:
>
> hehehe,
>
> how about
>
> reporter.get_many_article()
>
> testing...
> account.get_many_type()
> poll.get_many_choice()
> city.get_many_address()
>
>
At least read a *bit* of the thread you are replying to.
On 12/14/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> I don't think class META needs to get involved at all.
>
> This seems much cleaner ( and avoids random things like "manager = "):
>
>
> class Person(models.Model):
> first_name = models.CharField(maxlength=30)
> last_name = models.Ch
hehehe,
how about
reporter.get_many_article()
testing...
account.get_many_type()
poll.get_many_choice()
city.get_many_address()
Jacob Kaplan-Moss wrote:
On Dec 14, 2005, at 10:03 AM, Jason Davies wrote:
_group
_batch
_bundle
_bunch
_clump
_cluster
_crowd
_gaggle (!)
_lot
Wait, I've
On Dec 14, 2005, at 10:03 AM, Jason Davies wrote:
_group
_batch
_bundle
_bunch
_clump
_cluster
_crowd
_gaggle (!)
_lot
Wait, I've got it!
reporter.get_article_list()
Wow! So readable, so clear!
(Sorry)
Jacob
Robert Wittams wrote:
> > You are right, _list is worse than _set.
> >
> > Would _data be a better solution?
>
> I don't think so. As a sometimes C/C++ programmer I expect things called
> data to be a void*, and come along with a length ;-)
I browsed quickly through thesaurus.com. How about:
_
> You are right, _list is worse than _set.
>
> Would _data be a better solution?
I don't think so. As a sometimes C/C++ programmer I expect things called
data to be a void*, and come along with a length ;-)
Robert,
On 12/14/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> The point is, we *won't* have set_ for setting anymore. The
> only confusion seems to be if people can't tell the difference between a
> verb and a noun. I'm afraid that we will end up with a very stilted api
> if we have to use news
Amit Upadhyay wrote:
>
> Actually I din't read the whole post, ignore my second sentence. We already
> have set_ for setting, and _set would be confusing if we
> use it for just getting the "set" as someone pointed out, so _list
> even if not totally accurate for the reasons you said.
The point
Adrian Holovaty wrote:
> Thoughts?
>
> http://code.djangoproject.com/wiki/RemovingTheMagic
>
> Please comment here rather than on the wiki.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com | chicagocrime.org
>
Hi,
Just looking over the wiki page again,
I really dislik
On 12/14/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>>> How about _list. They are python lists anyway so that would help> too.>Did you even read my post? They aren't lists. They are possibly orderedsets. To be a list, it would need to always have a meaningful order, and
it would also need to be
Amit Upadhyay wrote:
> On 12/14/05, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
>
>>On 12/14/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>>
>>[ p1.article_set.order_by('headline') ]
>>
>>
>>>Is your confusion between set the verb and set the noun ? I don't really
>>>know how to fix
On 12/14/05, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
On 12/14/05, Robert Wittams <[EMAIL PROTECTED]> wrote:[ p1.article_set.order_by('headline') ]> Is your confusion between set the verb and set the noun ? I don't really
> know how to fix that without refactoring the English langua
On 12/14/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
[ p1.article_set.order_by('headline') ]
> Is your confusion between set the verb and set the noun ? I don't really
> know how to fix that without refactoring the English language. I don't
> know what else could be done here - pluralisation i
got it. Runs well. Thanks a lot. * _ *
zagorot wrote:
> when I get rid of this below:
> -
> {% ifequal mod(forloop.counter0,4) 0 %}
>
> {% endif %}
> -
> It works fine.
> What's happened?
The end tag for {% ifequal %} is {% endifequal %}.
Kieran
p.s. the django-users list is a better place to
when I get rid of this below:
-
{% ifequal mod(forloop.counter0,4) 0 %}
{% endif %}
-
It works fine.
What's happened?
27 matches
Mail list logo
