On 1/22/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> I'd like to start moving my stuff over to the magic removal branch and
> was wondering if the API is stable enough to start doing so.
>
> I'm not after something bugfree, just something where the ground is
> stable enough so I don't have to rewr
On 1/23/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
I'd like to start moving my stuff over to the magic removal branch andwas wondering if the API is stable enough to start doing so.I would say probably not. There is still one big change to come - the use of descriptors on database objects. This wil
Hi.
I'd like to start moving my stuff over to the magic removal branch and
was wondering if the API is stable enough to start doing so.
I'm not after something bugfree, just something where the ground is
stable enough so I don't have to rewrite huge portions of my code
every week.
regards
Ian
I've found solution(by hacking code):
choices.get_list(order_by=['poll_polls.pub_date'],
select_related=True)
This works fine.
Thanks
I don't have any time to do anything about this, but I can't really see
how this is going to work. Eg, edit inline. Is your plan now to totally
destroy edit inline for non-ajax uses? Also, the whole problem that the
follow argument to manipulators solves arises again ( how to deal with
partially u
Adrian Holovaty wrote:
p = Poll(pub_date=request.POST.get('pub_date'),
question=request.POST.get('question'),
num_votes=request.POST.get('num_votes'))
Some automation is needed for this. Currently automatic manipulators can
deal with copy of POST dict themselves.
On 1/22/06, hugo <[EMAIL PROTECTED]> wrote:
> Make that a defined Exception instead of an attribute and I might like
> it. Something along these lines:
>
> try:
>p = Poll()
> except ValidationErrors, e:
>print e.errors
>
> So the ValidationErrors would be an exception that collects all
[EMAIL PROTECTED] myproject]$ python manage.py shell
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.models.polls import *
>>> polls.get_list()
[Wha
akaihola wrote:
> I don't see why you couldn't use compile_string (from
> django.core.template) or your own parser to resolve variables in your
> template tag. A custom parser might be faster, but then again with
> compile_string you get more features.
Using compile_strings
{{a}} = 'c'
{{d}} = '
># a.errors is a property that returns a dictionary
># of field names to lists of errors. Maybe this could
># be named something else, so as not to clash with the
># field namespace -- perhaps "_errors" with a leading
># underscore.
Make that a defined Exception instead of an attr
>default manager works fine for the simple case, but how do propose to
>choose the 'correct' manager if there are multiple managers involved?
The objects do have some meta data - just plug a "source" meta data in
there that points back to the manager from where the object was loaded?
Or maybe jus
I don't see why you couldn't use compile_string (from
django.core.template) or your own parser to resolve variables in your
template tag. A custom parser might be faster, but then again with
compile_string you get more features.
On 1/22/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> I've been messing with manipulator code in magic-removal, and it
> struck me that we could avoid a lot of the boilerplate, cruft and
> newbie confusion by making models validation-aware.
+1; this would even be useful in non-standard scena
13 matches
Mail list logo
