Hey Thomas,
Always interesting to hear people's first (and subsequent) impressions.
Without disputing your observations, here are some of the reasons behind
the things you've mentioned. Some are problems, some are just
differences of opinion and cases where everybody cannot be pleased,
regardless of what we do.
On Fri, 2007-05-11 at 10:18 +0200, Thomas Guettler wrote:
> Hi,
>
> I learned django during the last days. Here are my impressions
> and some questions.
>
> Background: I develop web applications with python since 6 years.
> First with Zope, then with quixote and ZODB.
>
> I am missing a CurrencyField. It could be a subclass of FloatField
> but with a currency symbol. (100,00 *Eur*)
Within a couple of days, we'll have a DecimalField (which is really the
current FloatField that respects the precision), which is part of the
requirement for currency. There is a discussion going on on the
developers list at the moment reviving the topic of how we might allow
developers to subclass existing field types and have them appear as
proper Python instances in the model instances. So that would permit
anybody to create a CurrencyField that was stored as a string. A
currency field that was stored as an integer and another column (the
currency name) is a little trickier to do externally. Might be worth
adding to core, but might be better to see if we can make it easy to add
as a third-party option, since there are dozens of extra field types
people request.
> First I missing a way to sync the database with the model. The command
> syncdb has a bad name. It should be called initdb.
It syncs on a coarser level than you might like (the finest detail it
understands is "the model", rather than "the field"). It doesn't only
work when you initialise a database, so initdb is probably a worse name.
There's also a bit of future-proofing here: syncdb will become
finer-grained over time.
> But you can live
> without autosync: Redirect the output of sqlall to a file. Update model,
> redirect the output again, and then "diff old.sql new.sql" shows
> you what you need to execute in a sql shell (ALTER TABLE ... (ALTER|DROP|ADD)
> COLUMN ...)
>
> I am sorry, but I don't like the template language. I have no problem to
> have HTML in python code.
Maybe you mean python code in HTML, rather than the reverse? You can put
as much HTML in your python code (view functions) as you like already.
This one is "horses for courses" a bit: some people like the design
decision in the native template language, others don't. It isn't going
to change, but it's relatively simple to use external templating systems
anyway, so it shouldn't be a showstopper. We can document that a bit
better than we do at the moment, though.
> The newforms.form_for_model() and form_for_instance
> are cool. I missed a complete example for creating and modifying an object.
> Here is how I did it:
[... example snipped ...]
>
> But: This form does not look as goog as the admin interface.
> Example: A DateField does not have the Calendar Popup. I found no
> way to add this (class="vDateField").
You can add classes to any fields via the "attrs" attribute. There's
also a feature request open in Trac that you've probably found to add
back default classes on widgets. No decision's been made on that yet.
> If I understood it right, you should set null=True for FloatField and
> DateField (and not blank=True) if it is optional.
You might well need both. Blank=True is used at validation time.
Null=True is used to put a condition on the database column when the
relevant table is created.
> The newforms library
> does not handle this correct. If there is no blank=True in the model,
> it complains (ignores null=True). If I use blank=True the sql insert fails,
> since the empty string is not a valid date.
>
> Newforms: I like the as_table() output. Except: The errors should be in a
> third column: <td>...</td>.
>
> I am missing an (epydoc) API documentation. Some important methods (e.g.
> Model.save()) don't have a docstring!
We take patches. :-)
The idea is that anybody who wants to run epydoc over the code should be
able to do so.
> I use the unicode branch and there were only some minor problem, which I
> fixed
> with two small patches (added to Trac). But USE_I18N must not be set to
> true. If I do, I get errors, which I could not fix myself.
Known problem. As you'll see on the Unicode branch status page, fixing
up i18n support is last on the list. How it gets fixed is a dependent on
some earlier decisions and I wanted to make those first. I think I have
a handle on what needs to be fixed now.
> Back to templates: I might use templates, if I could make function calls with
> arguments. I just want to pass the request object to my method. I found no
> way
> to do this. Yes, I know you can create own tags, but that's too complicated.
An intentional design feature of the template language again. One way to
look at it is that if you need to pass in parameters to arbitrary
methods, you are slipping into "programming with templates" mode.
Keeping tags as the only things that take arguments eases the burden on
how much designers have to learn, too (remember you are approaching this
from the perspective of somebody who programs in Python).
I'm not sure how to address "too complicated", since creating tags that
take arguments and proxy for a function call is two lines of code with
the simple_tag shortcut. Or create one tag that takes the attribute name
and args and applies args to attribute (which is assumed to be a
method/function).
>
> TEMPLATE_STRING_IF_INVALID: The zen of python: "Errors should never pass
> silently.". I want an exception if the template can't resolve a variable.
There are also a number of cases when it's nice to have the current
behaviour: it allow heterogeneous objects to be handled more smoothly in
templates. Again, it's a conscious design decision and it's understood
that not everybody is going to agree with it, but it's also not bad by
default. There are places in the code (e.g. admin interface) that rely
on this behaviour, so it's also not particularly practical to make it
configurable (if you say all missed accesses should raise an exception,
you won't be able to use admin).
> I already ordered the django book.
>
> Model.get_FOO_display(): I think two different namespaces get together, which
> should better be seperated. Model.fields.FOO.display() would be better. Some
> fields don't have this method. This would make a loop over all fields and
> display them much easiert.
>
> Introspection: How to get all fields of a model instance? I discovered
> obj._meta.fields. Is this an offical API?
In as much as there is one. There aren't a lot of cases when you need to
do introspection like that, so the information is there (in _meta), but
not exposed any further than that.
> Admin Template (Table of all rows):
> {% for result in results %}
> <tr class="{% cycle row1,row2 %}">
> {% for item in result %}{{ item }}{% endfor %}
> </tr>
> {% endfor %}
> How can you do the same with python code?
Which part of this are you trying to emulate? There are at least three
things you could be interested in here: (1) how the cycle tag works, (2)
iterating over a queryset or (3) resolving the variable.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
