On 6/22/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Now, I don't like to put the whole burden into the input validation,
And nobody's really suggesting that we should; we already provide a
template filter for sanitizing on output, and a block tag for doing
the same seems like a decent idea.
On 6/22/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Now, come on, that's a completely different thing than auto-escaping
> of variables in the template. I had no idea php is/was *that* brain-
> dead (*shiver*)
The problem of suddenly having to figure out ways to tell whether
you're dealing
On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
> Oh - I haven't heard of the magic_quotes fiasco. Do you have any
> links or more information about this? If it blew up for the PHP
> folks, I think I'd be prone to changing my position on the issue.
The magic_quotes setting in PHP is a
On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
> This is my preferred choice, as well, but I'm not well-versed enough
> in the internals of Django to know if allowing empty models can
> create other problems outside of the admin interface. If anyone could
> point me to the relevant areas of
The more I think about it, the more I find I have two objections to
the auto-escaping stuff.
1. A philosophical objection. One thing Django does, and does pretty
well IMHO, is encourage best practices. Pretty much every aspect of
Django, from the overall architecture of the framework to the
On 6/20/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I haven't used the magical versions of Django, but I regard the magic that
> has magically imported models a different thing. In every framework things
> happen automatically, and just calling it "bad magic" is something that
> might result
On 6/20/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I've gotta say, I don't like the concept of auto-escaping on by
> default. I'd rather not have the framework automatically munging my
> data behind my back: it'd be a case of the same type of magic that we
> removed in the magic-removal
On 6/19/06, Jay Parlar <[EMAIL PROTECTED]> wrote:
> It felt like a db error, because of *where* it was breaking, but I've
> not yet looked into the ORM layer, and didn't have time to start
> digging.
This feels like a reawakening of some old bugs that had to do with
matching dates in SQLite; I
On 6/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> then nobody got it - because *that* is not a framework - it is an
> application server, which is a totally different kettle of fish
Yeah. I was thinking "Booby on Whales".
Some things have a learning curve. Zope has a learning
On 6/19/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> Will the Summer of Code project include some kind of fall-back for
> when a proper full-text indexing system isn't available? (Something
> trivial based on LIKE queries). For small sites the .search() method
> would be very useful.
Jacob's
On 6/19/06, Matias Hermarud Fjeld <[EMAIL PROTECTED]> wrote:
> I have submitted a patch to ticket#2197[0]. Any comments? Does anyone
> else think this is useful to have in django?
It's a useful thing, but...
We've got a Summer of Code project working on a true
search-engine-like system to
On 6/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> yes - we are all ears
Meh. The book-buying is a giveaway.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~-~--~~~---~--~~
You received this message because
On 6/16/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> To reiterate: templates shouldn't need to care about escaping. Django
> *in particular* uses an intentionally dumbed down template system
> that is supposed to be easy for non-programmers, which includes the
> notion that little mistakes
I've had some thoughts bouncing around in my head for a while about
Django's documentation, and I think it's time to finally commit them
to tangible form, so here goes:
Compared to either the standard open-source project or the standard
piece of web software, Django's documentation is good.
In response to a comment I got the other day on my blog, I've written
a first draft of a document detailing, from start to finish, how
Django processes a request. I'd love to get feedback, suggestions and
corrections on this so I can refine it into a really useful write-up,
so if you have a few
On 6/2/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> One issue would be what to name this
> more-critical-than-CriticalValidationError validation error.
FatalValidationError.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
On 6/1/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> So, why not create an option for "startproject", to keep everyone (you,
> me, the unexperienced, the experienced) happy? Flexibility and freedom
> of choice is a nice thing:
OK, now I have to start questioning credibility. "Accomodate
On 6/1/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> So, is it possible to have an overview of the _active_ "core developers"
> and "other contributors"?
There is no such list or overview.
Again, I think that maintaining such lists is a level of bureaucracy
which would not provide the
On 6/1/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> Is is possible to have an overview of the currently _active_ team,
> including roles? e.g. on a page on the project wiki?
The Django project defines pretty much two roles: "core developers"
and "everybody else". Again, with the exception of
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> Is such a document available, which lists e.g.
>
> * committers
Not that I'm aware of.
> * subsystem leads (or component leads)
Except for the i18n system, there really aren't "component leads" for Django.
> * code level
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> Please feel free to send me any concrete criticism about my website via
> private email (your comments are very welcome).
I seem to have screwed that up by forgetting that replies go to the
list by default. My apologies for the mistake.
On 5/25/06, lazaridis_com <[EMAIL PROTECTED]> wrote:
> * Replace command "django-admin.py" by "django-admin" or "django"
Naming it 'django' would likely cause confusion, leading users to
believe that it runs an entire Django-powered site. There is a web
server built in to it, but this web server
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> The term 'Audit' explained here:
>
> http://case.lazaridis.com/multi/wiki/ProjectOverview
That page is a lot of marketing speak along with a note that open
source projects can order your services at a "reduced rate". So now
you sound like
On 5/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 1) a commandline util only (via manage.py)
This would maintain consistency with the rest of Django's management
options; I'd always figured that at least part of the schema evolution
interface would involve manage.py.
--
"May the
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> Additionally: The fact that I have _not_ the full domain knowledge (=
> background information) enables me to make those "sweeping suggestions"
> from a newcomers point of view (who cares not much about project details
> and internals, but
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote:
> Now that you've mentioned it, first_name and last_name should not even
> be in User. They should be in profile. Profile is for
> personalization, not for user specific login criteria like (is_active,
> is_staff, is_superuser, IS_APPROVED).
My
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote:
> I need their email to be verified at sign up and when they change it in
> their profile. I don't understand how this system would verifiy
> someone changing their email address.
Honestly, now that I've read through this more thoroughly, I think
On 5/29/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> The "Add Field" functionality is nearly ready.
You are aware that a full implementation of schema evolution for
Django was accepted as a Google Summer of Code project, right?
--
"May the forces of evil become confused on the way to your
On 5/15/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> In the very beginning, I often made trivial errors in some functions
> used by the methods. Sometimes this resulted in exceptions that were
> ignored and resulted in missing data. This is then hard to spot since
> you don't get a hint what
On 5/14/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Django documentation page titles are like: "Django | Documentation | Model
> Reference", "Django | Documentation | Template Guide", "Django | Code |
> RemovingTheMagic". If you have multiple tabs open with these pages, all you
> get to see is
On 5/12/06, arthur debert <[EMAIL PROTECTED]> wrote:
> I have an app that uploads a 4mb file and is taking a ton of memory.
> >From tickets 1484/1569 they are set as fixed, but I cannot find them on
> django's source code. Are these patches active in trunk? If not,
> anyones knows if they're
> On 05/11/06 17:02, [EMAIL PROTECTED] wrote:
> (myself included -- I am not about to put my production db
> password into a subversion repository that everyone in the company can
> read).
On 5/11/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
> For putting the dsn in the env I'm -1 as it may
On 5/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> But I need this for an ugly existing database (tm) that I cannot
> touch. And, of course, it's a ManyToManyField in very open disguise,
> but it has additional attributes. Unfortunately, a ManyToManyField is
> based on an association table
On 5/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I need to be able to use models like this:
>
> class Xlwzl(models.Model):
> xl = IntegerField(primary_key=True)
> wzl = IntegerField(primary_key=True)
You'll probably want to read this and save yourself some time:
On 5/9/06, Bryan <[EMAIL PROTECTED]> wrote:
> I understand that this is not a priority for Django, but I would like
> to know if anyone is working on Ajax support in Django. I read through
> the proposals and was wondering if I could do anything to help with one
> of the layers (preferably with
On 4/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> A definite -1 on this from me, because it's out of Django's scope.
Agreed.
Also, for the as-yet-undetermined future when we have Dojo integration
merged, people who want WYSIWYG will be able to hang the Dojo
rich-text widget on any text
On 4/25/06, Petar Mariæ <[EMAIL PROTECTED]> wrote:
> So, a free global licence for a buffed-up version to one of best
> WYSIWYG XHTML editors today in exchange for a link to xhtml.com? I'm
> so +1 on this :D
I'm so -1 on this that words fail me. WYSIWYG HTML editors should be
the concern of
On 4/21/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Which patch there is the "one true patch"(tm) ;) comments.3.diff?
Looks like it; it seems to match pretty closely with the patches I'd
submitted on #1659, which cover parts of the comments app as well (and
on that ticket, the most recent
On 4/21/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> so i have two problems.. the first is:
> - is there some dispatch thing I can connect to so that this function
> gets called at the right time
To clarify a bit after some late-night IRC chatting about this:
What Ian's trying to do,
On 4/14/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> I would sooner blame your setup or software for not properly
> supporting such links.
The thing is, this *is* "proper support". The URL is still accessed
correctly, and the page is displayed correctly. But the URL string
On 4/13/06, Viktor <[EMAIL PROTECTED]> wrote:
> Of course, every requested url must be URLencoded, but that is browsers
> job, and they all do it quite well.
Except that that runs contrary to the purpose of the slug. See below.
> Yes, they are (more and more every day)... (for example Wikipedia
On 4/13/06, olive <[EMAIL PROTECTED]> wrote:
> Note: the fact that I have to rename this is still relevant:
> ManyToOne by ForeignKey
> ManyToMany by ManyToManyField
In what files and locations are you having to do this?
--
"May the forces of evil become confused on the way to your house."
--
On 4/13/06, olive <[EMAIL PROTECTED]> wrote:
> Now just a silly question: what is the value added by Dojo ?
A few things.
The one that most people have been clamoring for is easy AJAX
functionality; Dojo's libraries for that are really simple to use.
But the big deal for me is the packaging
On 4/13/06, olive <[EMAIL PROTECTED]> wrote:
> What I see is a simple multiselection list, so I suspect that the
> related Dojo is not loaded.
Does your browser report any JavaScript errors?
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
On 4/13/06, olive <[EMAIL PROTECTED]> wrote:
> How do I specify the use of Dojo rich-text editing widget in my model ?
You'll want to take a look at Dojo's documentation at
http://dojotoolkit.org/docs/
> I don't know why M2M does not render properly, here is an excerpt of
> the displayed page
On 4/13/06, olive <[EMAIL PROTECTED]> wrote:
> to make it work I had to replace in your views all occurences of:
> ManyToOne by ForeignKey
> ManyToMany by ManyToManyField
The patch was extracted from a modified copy of magic-removal which
I'd been running for a while, there should have been no
A good question was just raised by a friend of mine who's trying out
Django: we encourage the use of a URLConf for each application to
ensure pluggability, but manage.py doesn't create one when you start a
new app.
How would people feel about changing that so that 'manage.py startapp'
creates a
On 4/8/06, Petar Mariæ <[EMAIL PROTECTED]> wrote:
> I suggest we change urlify.js in a way that will not block out
> non-English chars. Instead it should translate them into their English
> feel-a-like, as suggested in #1602.
If we decide to go the sound-alike route, a good resource to start
from
On 4/7/06, Rudolph <[EMAIL PROTECTED]> wrote:
> It could be solved by putting the django-admin stuff inside a tag with
> a django-admin class. Then ".django-admin p" or ".django-admin
> #content" will format only the admin stuff and not your site.
It could be, but I think I'm with Wilson in
On 4/7/06, Rudolph <[EMAIL PROTECTED]> wrote:
> Put this line:
> {{ app.name }}
> above the for loop instead of inside it.
Weird... I submitted the patch that added the captions, and that's how
it is on my working copy, but somehow in generating the diff that line
got moved. Best solution for
On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> I just realized that both the calendar and clock widgets were within a
> fieldset with 'classes': 'collapse'
http://files.shtuff.us/admin-dojo.tgz
Fixed now :)
--
"May the forces of evil become confused on the way to your house."
-- George
On 4/4/06, James Bennett <[EMAIL PROTECTED]> wrote:
> On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> > I just realized that both the calendar and clock widgets were within a
> > fieldset with 'classes': 'collapse'
OK, now I'm able to replicate it, and I've foun
On 4/4/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Have you read through the proposal? I don't tie the URL structure to the
> internals of of the application's code. Quite to the opposite.
Then why did the original email say that it would "tie the urls to the
field names in the model"?
--
On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> I just realized that both the calendar and clock widgets were within a
> fieldset with 'classes': 'collapse'
I've got a test app running with date/time fields inside a collapsed
fieldset, and it's rendering just fine in all the browsers I can
On 4/4/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I feared this might turn out a problem. I haven't so much experience
> with different projecs, can you explain a litte about the problems with
> this?
Tying the URL structure to the internals of the application's code,
which is what you
On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> I just realized that both the calendar and clock widgets were within a
> fieldset with 'classes': 'collapse'
Hmm. I'll try that tomorrow and see if I can replicate it and find out
what causes it.
--
"May the forces of evil become confused on
On 4/4/06, limodou <[EMAIL PROTECTED]> wrote:
> And there are many people except me consider that: django need a good
> urls system:
You've taken this completely out of context; as I understand it, Jacob
and Adrian were not saying that the *entire* URL system should be
replaced, only that the
On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> Tested on Debian Sarge (Firefox from backports.org) and Windows XP.
That's extremely weird... I just set up a fresh copy and tested on FF
1.5 on Ubuntu, and it looks fine. It also was fine on FF 1.5 on a Mac
at work. Could you completely clear
One more thing I forgot: though the Dojo "Event + I/O editon" dojo.js
provides all the Dojo modules the admin needs at the moment, the
package includes a full Dojo source tree, so if you want to start
playing with this and improving it or experimenting with things you've
wanted to do once
On 4/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Is there any mecanism of database connection pooling in django ?
Not at the moment, but some of the changes in the magic-removal branch
seem like they'd make this much easier to implement in the future.
--
"May the forces of evil become
On 3/28/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> If possible I would like to see dojo *not* included in django's SVN repo.
> just a pointer to where DOJO is installed on your docroot should be
> sufficent for most things, and remove the need to figure out what
> things should/shoiuldn't be
On 3/28/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> From the top of my head we need dojo.io, but I assume it is included
> indirectly by other packages.
Ack. Yeah, I just forgot that one when I compiled my list.
--
"May the forces of evil become confused on the way to your house."
--
Quick update: I now have a magic-removal install with all of the admin
JS ported to Dojo packages. There are some crufty bits that still need
to be cleaned up, but it works!
Next step: I need to know what sort of Dojo functionality people are
going to rely on, because we're going to have to do a
On 3/21/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Actually, the availability of connection splitting/pooling tools for
> various backends makes me less inclined to want to add it to Django,
> but that's all academic now :)
I like multiple-backend support for the express purpose of doing
On 3/19/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I think good documentation is the best way to solve this one.
...snip...
> Assuming the URLconf is in a file "urls.py" and the models are in a
> file "models.py" in the same directory, you can just do this:
>
> from models import
On 3/19/06, gismo <[EMAIL PROTECTED]> wrote:
> I know I can change the extension. But there is a lot of editors,
> people write some extension for them, and only way to handle file type
> is the extensions.
On some operating systems, that's true, but not all.
> Everytime template act like html
Last night in #django a couple of good points were brought up by
someone who was just starting to explore Django and had decided to
learn from magic-removal rather than trunk; both of them, I think, are
worthy of discussion, so here goes:
1. The new example of usage for a generic view is
On 3/14/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> This is based on a simplistic assumption that everytime we are talking about
> validation in django context we are talking about model based validation.
No, it's based on an assumption that the facilities for doing custom
validation that
On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> In most cases we do not do anything alone use model, but always there
> is a ui layer, such as gui or web. They have to do any such thing.
There should be the ability to generate an HTML form for
creating/changing an instance of a model, yes, but
Someone in the IRC channel tonight was asking why the built-in User
model, when rendered by formfields, doesn't render the password field
as an input of type "password", and it struck me that this is a good
question, because there are plenty of use cases where you'd want that
behavior to happen.
On 3/6/06, Kevin <[EMAIL PROTECTED]> wrote:
> The generic views use RequestContext (was DjangoContext) and that
> requires request.user be set.
>
> I'd be nice if that middleware dependency could be removed since my
> site never needs authentication and so the extra middleware is
> redundant.
On 3/1/06, xamdam <[EMAIL PROTECTED]> wrote:
> Using no-magic branch from about a couple of weeks ago.
If possible, update your copy of magic-removal to the latest revision;
there's been a HUGE amount of work done on it recently, and if this is
a bug it may already have been fixed. If you still
On 2/10/06, limodou <[EMAIL PROTECTED]> wrote:
> Maybe you consider that it's nothing, so I think you also don't want a
> tool to do that for you automatically. But I want, and I think maybe
> someone else want also.
What, exactly, is it about Python files which make it, in your view,
On 1/14/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> Basically, you define your own inner class called "Manager" if you want
> to add custom methods to Person.objects (or modify the behaviour of
> existing methods). If you don't define this inner class the default
> Manager will be used.
I
On 1/12/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> Thinking about this further, it could result in a security hole. If a
> filter that removes dangerous markup failed silently and that markup
> was spewed on to a page it could lead to an XSS vulnerability.
I would hope that the author of
In the IRC channel tonight there was some discussion (mostly motivated
by ticket #1204) about template tags and filters failing silently,
particularly those in the markup app. Since it was kind of late and
people were popping in and out it sputtered, but I think it's an
interesting topic to bring
On 12/14/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Or maybe get rid of the "models" cruft:
>
> /admin/myproject/blog/entry/add/
+1
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
On 12/12/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I think all in all it's a good idea, but I do have one big objection:
> one of the things that's always bugged me about ORMs is that they
> shield you from knowing when you're hitting the database. This sucks
> when it comes time to
On 12/12/05, oggie rob <[EMAIL PROTECTED]> wrote:
> The "len" idea is not great anyway - it is much more costly to get and
> len 10,000 rows than to use SQL count, as get_article_count does.
I would hope that the __len__ method would be implemented as something
that does an SQL count.
--
"May
On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:
> the issue is, how do you define the pluralization. just adding s at the end
> works only in some cases and does not usually work in other languages. (eg.
> in Czech: class Anketa - plural is ankety not anketas)
Currently, with
On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:
> so I think it should be either:
> 1.
>reporter.article.add(...)
>article.reporter.id
>
> or:
> 2.
>reporter.articles.add(...)
>articles.reporter.id
>
To me, the pluralization makes sense; a reporter has many articles, so
On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:
> very nice proposal. but please avoid pluralization. it is very odd in other
> languages than English.
I think pluralization is something to be dealt with elsewhere; so long
as this takes advantage of module_name, verbose_name and/or
On 12/11/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Its pretty orthogonal to most of the other suggestions.
Yeah, but as proposed lookup syntaxes go, this one is by far the best.
And implementing special methods like __len__ would make it just about
perfect, IMHO; the closer we can get to
On 12/7/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Thoughts?
Models: +1, hooray for properties.
DB connections: +1
Object creation/model import: +1
Table-level functions: -0, there may be good underlying reasons for
it, but it strikes me as needless cluttering of the syntax.
On 12/6/05, Maniac <[EMAIL PROTECTED]> wrote:
> But still you have to blindly copy strings from code to decorator
> parameters.
Any way of implementing this is going to require you to specify
*somewhere* which GET parameters are relevant to caching a particular
view, and it'd be hard to
On 12/6/05, Maniac <[EMAIL PROTECTED]> wrote:
> So when the view's code change during development one should alsways
> remember to update this invalidators list. Not very DRY :-(
Except it's a decorator, so it's right there with your view code.
--
"May the forces of evil become confused on the
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
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
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
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
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
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
On 11/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Yes, it's a very useful snippet indeed. :) It's on the documentation
> to-do list; I'd like to get it out of the way this week.
Huzzah!
Thanks, Adrian.
--
"May the forces of evil become confused on the way to your house."
-- George
On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> Now I am confused. AJAX stands for Asynchronous JavaScript And XML. But
> "AJAX effects" == visual effects?
Many so-called "AJAX libraries" are as heavy on the "visual DHTML
effects for use with AJAX" as on the actual meat of "AJAX"
On 11/15/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> We're looking for a volunteer to update and maintain Django's FAQ
> (http://www.djangoproject.com/documentation/faq/). It's pretty
> unhelpful at the moment, unfortunately. We'd love it if someone
> could become the FAQ maintainer and
On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> What are these mysterious "AJAX effects" you talking about in your posts? Is
> it the same as "AJAX in the core" or different beast?
As I mentioned in an earlier message, many "AJAX libraries" provide a
large stable of DHTML components
I've been poking around through the bundled comments app, trying to
work out exactly what it can do and how to use it (also looking
through the djangoproject.com code for hints), and it looks to be
incredibly robust and useful; is there any ETA for documentation for
it? Just basic tips on
On 11/14/05, hugo <[EMAIL PROTECTED]> wrote:
> Actually the only thing I can think of that would be good if django had
> it, would be a REST style API to access model stuff that automatically
> will be returned in JSON format. That would allow JavaScript code to do
> easy database queries without
On 11/14/05, limodou <[EMAIL PROTECTED]> wrote:
> I want to know if there is easy way to create form?
You might want to look over this:
http://www.djangoproject.com/documentation/forms/
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
On 11/14/05, Stephen Rainey <[EMAIL PROTECTED]> wrote:
> I agree with you that it's pure marketing fluff and I guess you see that
> was my point. It just got me to thinking when I was reading about
> developer adoption. I do like your lightweight ideas. It might be good
> to do something rather
801 - 900 of 901 matches
Mail list logo
