On 11/23/05, Beorn <[EMAIL PROTECTED]> wrote:
> * can't generate model from database
Check this out:
http://www.djangoproject.com/documentation/legacy_databases/
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
On 11/23/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> Maybe DjangoContext should have a request property that holds the
> request object and can be accessed by custom template tags, but that
> isn't available to normal replacement variable tags in the template
> itself.
Then those template tag
James:
> I think the directories Rails creates might represent best practices
> for Rails use, but I'm not at all certain that they represent best
> practices for anything other than Rails.
Well, I don't see how Django couldn't benefit from best practices for,
e.g., staging, testing, documentatio
On 23 Nov 2005, at 22:43, Luke Plant wrote:
A third might be simply to have a convention -- a bit like the ones
proposed for standard blocks in templates -- that says the request
vars
are in the context under a certain name. Template tags look for that
name and if they can't find they can e
Luke Plant wrote:
>
>
> A third might be simply to have a convention -- a bit like the ones
> proposed for standard blocks in templates -- that says the request vars
> are in the context under a certain name. Template tags look for that
> name and if they can't find they can either carry on the
On Wed, 23 Nov 2005 17:19:20 + Robert Wittams wrote:
>
> Simon Willison wrote:
> >
> >
> > On 23 Nov 2005, at 14:59, Afternoon wrote:
> >
> >> Is there a way that the request object could be exposed to custom
> >> tag code, but not the template itself?
> >
> >
> > The aim with the templ
On 23 Nov 2005, at 17:45, Eugene Lazutkin wrote:
We have inspectdb already, which clearly can be improved. If we add
simple
template generation to show object's fields and list of objects (or
whatever
generic views support), we can cover initial prototyping of web
sites as
well.
+1 to
On Wed, 23 Nov 2005 07:30:54 -0500 James Bennett wrote:
> Now, probably the overwhelming majority
> of new developers adopting Django are not going to be integrating with
> legacy databases, and in any case they wouldn't do it by pointing at
> their production DB. So one way or another, the first
"Simon Willison" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
>
> Pluralisation is a nice idea in theory, but in practise it causes more
> problems (in terms of confusion over whether something is singular or
> plural) than it solves.
+1
Simon Willison wrote:
>
>
> On 23 Nov 2005, at 14:59, Afternoon wrote:
>
>> Is there a way that the request object could be exposed to custom tag
>> code, but not the template itself?
>
>
> The aim with the template system has always been to keep it de- coupled
> from the request/response st
I think you hit the nail on the head: there are different methodologies of
software development and tools may support different stages of software
development.
It seems to me that RoR supports earlier stages of development better:
scaffolding affords toying with your model without paying much
Yes, to have S or not have bite me couple times during my short
period of learning Django. It looks cool but I agree that practically
it helps almost nothing. So here is my +1.
On Nov 23, 2005, at 8:03 PM, Simon Willison wrote:
Here's an easy lesson we can learn from Rails: pluralisation s
On 23 Nov 2005, at 14:59, Afternoon wrote:
Is there a way that the request object could be exposed to custom
tag code, but not the template itself?
The aim with the template system has always been to keep it de-
coupled from the request/response stuff, so it can be used as a
standalone c
On 11/23/05, hugo <[EMAIL PROTECTED]> wrote:
> Actually I think that verbose_name_plural should go and instead of
> that, an class method for proper pluralization should be added:
Even better. That gets my vote.
--
"May the forces of evil become confused on the way to your house."
-- George Ca
On 23 Nov 2005, at 13:03, Simon Willison wrote:
Here's an easy lesson we can learn from Rails: pluralisation sucks.
Person -> People, Family -> Families etc is all very pretty but at
the end of the day you're constantly left asking yourself if the
bug you are facing would be fixed by adding
Simon Willison wrote:
>
>
> On 23 Nov 2005, at 13:25, Robert Wittams wrote:
>
>> Another reason that I really dislike generating a model from a database:
>> people have to learn the exact situations in which it will work and and
>> won't work. Eg what will it do with field types it doesn't kn
>Sounds good, though the verbose_name_plural and/or module_name
>attributes still ought to be kept, I think; Django shouldn't make
>assumptions about how to pluralize a model's name, but I should be
>able to tell it how to do so if I desire.
Actually I think that verbose_name_plural should go and
On 11/23/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> In defence of live introspection, Matt Biddulph made the excellent
> point at the web frameworks night earlier this week that the Rails
> method is extremely useful early on in your design process when you
> are rapidly iterating your DB des
On Nov 23, 2005, at 8:22 AM, Simon Willison wrote:
He's right too - the hoops you have to jump through changing schema
with Django do slow you down if you haven't figured out your full
data model in advance.
Wow, so developing applications without a good design up-front is
difficult? Who
On 23 Nov 2005, at 13:25, Robert Wittams wrote:
Another reason that I really dislike generating a model from a
database:
people have to learn the exact situations in which it will work and
and
won't work. Eg what will it do with field types it doesn't know about,
what if you use some nonst
James Bennett wrote:
>
> Also, consider this: your original argument was that inferring models
> from the database is useful because then you can "get an admin
> interface up-and-running just by pointing to a database". But
> regardless of whather the model is specified in Python or inferred
> fr
Simon Willison wrote:
The other one is database table names. I would argue that since these
are almost /never/ directly exposed in Django itself, they should be
left as singular as well (just the name of the model class casted to
lower case. If we wanted to be really radical we could leave
On 11/23/05, Beorn <[EMAIL PROTECTED]> wrote:
>
> I don't think scaffolding is bad just because it can't support all
> admin interface situations. It's great while you're prototyping, and
> may be perfectly fine for many applications where you just want a
> simple admin interface. Django's admin
On 11/23/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> Pluralisation is a nice idea in theory, but in practise it causes
> more problems (in terms of confusion over whether something is
> singular or plural) than it solves.
Sounds good, though the verbose_name_plural and/or module_name
attribut
Here's an easy lesson we can learn from Rails: pluralisation sucks.
Person -> People, Family -> Families etc is all very pretty but at
the end of the day you're constantly left asking yourself if the bug
you are facing would be fixed by adding or removing an S.
Under consideration at the
I don't think scaffolding is bad just because it can't support all
admin interface situations. It's great while you're prototyping, and
may be perfectly fine for many applications where you just want a
simple admin interface. Django's admin interface falls down as well if
your requirements are a
> Thoughts?
I've had such a directory for years in my webapps, although I've
always called it "assets", which I like better than static. But that's
just the bikesheds color, I guess.
This email from Beorn:
Beorn wrote:
Ruby's more extensive skeleton isn't all bad: Ruby generates a lot of
empty directories that actually "sell" the notion that this is a
framework that can grow with you and has best practices for testing,
documentation, using AJAX, logging, staging, where to
28 matches
Mail list logo
