On 11/24/05, David Ascher <[EMAIL PROTECTED]> wrote:
> Speaking of searchability, I find that Google searches don't give much
> insight into the Django website pages.
>
> e.g. a search for schema site:djangoproject.org
>
> fails to find any reference to "schema" on the site, but a search from the
Speaking of searchability, I find that Google searches don't give much insight into the Django website pages. e.g. a search for schema site:djangoproject.orgfails to find any reference to "schema" on the site, but a search from the wiki certainly finds a few hits (23).
Is Google being inadvertently
On Thu, 24 Nov 2005 10:39:42 + Simon Willison wrote:
> At the moment we don't really promote the fact that there's a wiki
> on the Django site
Putting 'Wiki' as a link at the *beginning* of the list item for it on
http://www.djangoproject.com/community/ would help - something like:
"Wiki - c
On 11/24/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> There's a list of user-contributed documentation on the front page of
> the wiki which you are welcome to add things to:
OK. I'd seen that, but at first glance I didn't catch the link to
Ian's presentation and so it seemed like they were al
On 24 Nov 2005, at 12:03, James Bennett wrote:
For example, I'm finishing up Django/lighttpd instructions for
TextDrive which will be published on their Hieraki installation, and
as I develop a couple projects I'll be adding useful bits of code to
their "snippets" site, both of which I'd like
On 11/24/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> The way we are using it at the moment (listing sites powered by
> Django, detailing backwards incompatible changes etc) is great. I
> think we should expand our promotion of it to encourage more user-
> generated documentation. Just a few mo
On 24 Nov 2005, at 10:19, Sune Kirkeby wrote:
There is a wiki on http://code.djangoproject.com/wiki/ and the
documentation
itself supports commenting, do we need more than that? Should we have
a wiki somewhere other than code.d.c, for user-level wiki-pages?
I'm a huge fan of the Trac wiki
On 11/24/05, patrick k <[EMAIL PROTECTED]> wrote:
> - a wiki-like documentation (see RoR) would be a good thing, i think (eg to
> promote "best practices" or "howtos")
There is a wiki on http://code.djangoproject.com/wiki/ and the documentation
itself supports commenting, do we need more than tha
i´ve tested a lot of different frameworks and django has probably been the
easiest to get started with (besides helma).
still, some comments from my point of view:
- you should be able to search the documentation (sometimes it´s really hard
to find things)
- a wiki-like documentation (see RoR) wo
> * ease of finishing
> * lack of best practices
http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters
It's up to us users to make that document more complete if there really
is stuff missing.
Django uses a good middle-level approach currently: it adds many basic
stuff to the pro
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
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 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
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
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
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
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
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
On 11/22/05, Beorn <[EMAIL PROTECTED]> wrote:
> There are two parts to "ease of learning". One is how easy it is to
> get started, the other is how easy it is to keep going. Ruby does
> pretty well on both fronts.
One of the things that bothers me about Rails is that you get the
"instant gratif
There are two parts to "ease of learning". One is how easy it is to
get started, the other is how easy it is to keep going. Ruby does
pretty well on both fronts.
Ruby's more extensive skeleton isn't all bad: Ruby generates a lot of
empty directories that actually "sell" the notion that this is
Why not make two screencasts (or more)? For example:
1) Blog+RSS+flatpages with nice post editor: Admin + RichEdit (either ours
or 3rd party like TinyMCE).
2) Adding comments + secure e-mail form to the blog from 1st screencasts
with Markdown/Textile/Whatever (or restricted RichEdit, if we have
Simon, you named one good metric. I.e. how long is the screencast to
create an application pattern (weblog in this case) :)
Another
Radek
On 11/21/05, Simon Willison <[EMAIL PROTECTED]> wrote:
>
>
> On 21 Nov 2005, at 09:45, James Bennett wrote:
>
> > 2. Django doesn't have one of those nifty "u
I think everybody involved agrees that screencasts are almost
guaranteed to generate LOTS of interst. And it's not for lack of
understanding that (or lack of effort) on the part of the developers
that Django doesn't have any official ones. I know everyone's impatient
to see Django take over the wo
On 21 Nov 2005, at 09:45, James Bennett wrote:
2. Django doesn't have one of those nifty "useful application in
twenty minutes" tutorials/screencasts. Again, I'm partial to a weblog
as the sample app because it's stupidly easy to do in Django and shows
off a lot of the nice built-in stuff, and
On 11/20/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> I see it as an indicator of good architectural design rather than
> something people should regularly use.
In that case I'm even more suspicious of it; it smells a little of
TMTOWTDI, and it raises the question of why we'd provide a "good
a
Just a quick comparison, since I'm working on learning Rails at the moment...
With the proposed changes to models and views, starting a Django
project and adding an application creates this structure:
project/
apps/
appname/
models.py
views.py
settings.py
On 20 Nov 2005, at 19:47, James Bennett wrote:
I particularly like this example code for a Django app contained in a
single file:
I don't like this at all, mostly because I don't think it can scale;
the "single-file app" organization might work well for very simple
applications, especially i
+1. I think that Simon and David (and aaronsw in Trac) raised
valid points about first experience. It does count. The appreciation of innards
comes later. For example I switched from RoR to then new Django because of
superficial things mentioned by David: Django web site cleanliness projecte
On 11/20/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> I just saw http://code.djangoproject.com/ticket/853 , which advocates
> simplifying Django's first-time user experience as much as possible.
> I think this is an admirable goal, and one that would dramatically
> improve the number of people
>I've got to say I don't see much of a point in this. It seems to just
>mean that people making "simple" apps will be doing something different
>than people making "real" apps. Code churn results when an app
>graduates. I can't see that many people being turned off by using
>urls.py and views.py.
Simon Willison wrote:
>
> I just saw http://code.djangoproject.com/ticket/853 , which advocates
> simplifying Django's first-time user experience as much as possible. I
> think this is an admirable goal, and one that would dramatically
> improve the number of people using the framework. First
On 11/20/05, Simon Willison <[EMAIL PROTECTED]> wrote:
I just saw http://code.djangoproject.com/ticket/853 , which advocatessimplifying Django's first-time user experience as much as possible.I think this is an admirable goal, and one that would dramatically
improve the number of people using the f
I just saw http://code.djangoproject.com/ticket/853 , which advocates
simplifying Django's first-time user experience as much as possible.
I think this is an admirable goal, and one that would dramatically
improve the number of people using the framework. First impressions
count!
I part
37 matches
Mail list logo
