Php frameworks and Django

[Shankar Dhanasekaran]

Hi all,
A newbie question! Please can anyone answer or direct me to a good resource 
that detials the advantage of Django over other frameworks that are in php? PHP 
is all over and seems to be more popular than Python in web development. Though 
popularity doesn’t always mean it's the best, it would be easy for me to 
explain to my Director why switching over to Sactmo or Django framework would 
be a good move, if any of you explain me the features and benefits (also where 
php wins over python).

Typically I expect the following questions from my Director:

1. Php is all over and very popular, why choose a language which is less 
popular.
2. Will python deliver speedy pages as php, or will django deliver speedy pages 
as any php framwork, say cakephp?
3. what will be the future of python websites and django framework?

I installed django framework and found its amazing power. But am no expert in 
answering the above questions. Documentation is Django is excellent!!! Special 
Thanks to the documentation team. It's the clear and detailed documentation 
which gave a good confidence on the framework as such for me. Also I like the 
green theme!

Thanks all,
Shakthi


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Php frameworks and Django

[Russell Keith-Magee]

On Mon, Jun 16, 2008 at 3:21 PM, Shankar Dhanasekaran
<[EMAIL PROTECTED]> wrote:
>
> Hi all,
> A newbie question!

Hi Shankar,

Two quick comments:

1) Cross posting between mailing lists is quite bad form. Find the
mailing list that is appropriate for your purpose, and post your
question once.

2) Django-developers is not the right forum for this question.
Django-developers is for discussing changes to Django itself, not for
general user queries.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[Marc Fargas]

El lun, 16-06-2008 a las 11:28 +0800, Russell Keith-Magee escribió:
> A bug/feature keyword won't
> give you anywhere as much attention, but it will help us filter out
> features from the list of work we need to focus on.

I took the other way around, I'm adding the keyword "post10" for tickets
that can wait until 1.0 so a negative filter would give you "pre10" and
"yet-to-be-marked-tickets".  Hope that makes life a bit easier (but I've
only marked about 5 tickets).

Regards,
Marc
-- 
http://www.marcfargas.com -- will be finished some day.


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Context support for simple_tag #7462

[Julien Phalip]

Hi all,

I have just added a patch that allows a simple_tag to receive the
context as first argument, like inclusion_tag already does. It is
backward compatible.

I'd like to get some feedback on the code, so feel free to check it
out [1].

That issue has been raised at several occasions both on the users and
developers lists. There are some nice workaround like [2], and I
recall Malcolm agreed that it should be in django core one day [3].

The change was not trivial as simple_tag currently only takes one
argument (the decorated function) while inclusion_tag has its own set
of arguments like 'takes_context'. I got around that issue in the
patch while remaining backward compatible. The management of context
is inspired from the one in inclusion_tag.

You can still do:

@register.simple_tag
def my_tag(bla):

You can now also do:

@register.simple_tag(takes_context=True)
def my_tag(context, bla):

Note that the following (with brackets but without arguments) will be
accepted and work the same as the current code (without brackets):

@register.simple_tag()
def my_tag(bla):

Let me know what you think, and if you find it useful I could then add
a note in the doc as well.

Thanks!

Julien

[1] http://code.djangoproject.com/ticket/7462
[2] http://www.chipx86.com/blog/?p=245
[3] 
http://groups.google.com/group/django-users/browse_thread/thread/b3b3d7894f48b609/cf74b962aa68085e
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[Russell Keith-Magee]

On Mon, Jun 16, 2008 at 3:46 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> El lun, 16-06-2008 a las 11:28 +0800, Russell Keith-Magee escribió:
>> A bug/feature keyword won't
>> give you anywhere as much attention, but it will help us filter out
>> features from the list of work we need to focus on.
>
> I took the other way around, I'm adding the keyword "post10" for tickets
> that can wait until 1.0 so a negative filter would give you "pre10" and
> "yet-to-be-marked-tickets".  Hope that makes life a bit easier (but I've
> only marked about 5 tickets).

Marking everything that _wont_ be in v1.0 will be a lot more work than
making sure we can find everything that _will_ be v1.0.

We would like to aspire to having Zero Bugs (or, at least, Zarro
Boogs) for v1.0. Therefore, all we need to be able to do is eliminate
any feature proposal (whether accepted, DDR or someday/maybe) from a
'todo list' search.

There are already 26 tickets marked 'feature'; IMHO, the best tagging
approach would be to continue this trend. Tag any feature specifically
included for v1.0 with a v1 keyword, any feature without the v1
keyword will be ignored, and assume everything else is a bug, and
needs to be addressed for v1.0.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

django evolution not working

[Vishal Gupta]

Hi all,

the command
Unknown command: 'evolve'
Type 'manage.py help' for usage.
shows the error :
Unknown command: 'evolve'
Type 'manage.py help' for usage.

 i tried moving the django evolution directory out of the projects
directory and set it path to PYTHONPATH and PYTHON_PATH but to no
avail but it shows the same error.

i am using
django developer edition 0.97 pre
python 2.5.2
windows xp

can somebody please help me to run the evolve commands ??
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Context support for simple_tag #7462

[Julien Phalip]

Hi Simon,

I'm a bit unsure where to stick the regression test for this. Could
you give any pointer?

Thanks!

Julien

On Jun 16, 8:16 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Jun 16, 10:00 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > I have just added a patch that allows a simple_tag to receive the
> > context as first argument, like inclusion_tag already does. It is
> > backward compatible.
>
> > I'd like to get some feedback on the code, so feel free to check it
> > out [1].
>
> Looks great to me. With the addition of some regression tests to prove
> that it works and doesn't break the old behaviour I'd love to see this
> checked in.
>
> Cheers,
>
> Simon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Context support for simple_tag #7462

[Simon Willison]

On Jun 16, 10:00 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I have just added a patch that allows a simple_tag to receive the
> context as first argument, like inclusion_tag already does. It is
> backward compatible.
>
> I'd like to get some feedback on the code, so feel free to check it
> out [1].

Looks great to me. With the addition of some regression tests to prove
that it works and doesn't break the old behaviour I'd love to see this
checked in.

Cheers,

Simon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: django evolution not working

[Russell Keith-Magee]

On Mon, Jun 16, 2008 at 6:03 PM, Vishal Gupta <[EMAIL PROTECTED]> wrote:
>
> can somebody please help me to run the evolve commands ??

Hi Vishal,

Firstly, Django Evolution is not part of the Django project itself; it
is an external project. Please direct questions regarding
Django-evolution to the mailing list for that project.

Secondly, Django-developers is a mailing list for discussing the
development of Django itself, not for general user queries. If you
want to ask a question about general Django usage, please ask on
django-users.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Context support for simple_tag #7462

[Russell Keith-Magee]

On Mon, Jun 16, 2008 at 6:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
>
> I'm a bit unsure where to stick the regression test for this. Could
> you give any pointer?

The templates regression tests would be a logical place;
tests/regressiontests/templates. Have a poke around to see if there is
anywhere appropriate in the existing tests; if not, add a completely
new test module.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Context support for simple_tag #7462

[Julien Phalip]

Hi,

I updated the patch with regression tests and documentation. Any
feedback welcome!

Julien

On Jun 16, 9:08 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Mon, Jun 16, 2008 at 6:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > Hi Simon,
>
> > I'm a bit unsure where to stick the regression test for this. Could
> > you give any pointer?
>
> The templates regression tests would be a logical place;
> tests/regressiontests/templates. Have a poke around to see if there is
> anywhere appropriate in the existing tests; if not, add a completely
> new test module.
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[Johannes Dollinger]

Second try. I promise there won't be a third.

Is there a rationale for multiple managers per model? Or is it a  
that's-how-it's-always-been thing?
If I missed something obvious, I would have received a "wrong list or  
rtfm" reply by now, supposedly.

{{{
class AManager(Manager):
 pass

class BManager(Manager):
 pass

class A(Model):
 a_objects = AManager()
 class Meta:
 abstract = True

class B(Model):
 b_objects = BManager()
 class Meta:
 abstract = True

class C(A,B):
 objects = Manager()

class D(B,A):
 objects = Manager()
}}}

Now C._default_manager == C.a_objects and D._default_manager ==  
D.a_objects.
If A and B come from different modules _default_manager will be  
picked depending on import order.

If this is by design, I'd be happy with a "wontfix" reply. I'm not  
using multiple managers anyway.

[1] http://code.djangoproject.com/ticket/7154



Am 31.05.2008 um 19:16 schrieb Johannes Dollinger:

>
> I'd like to propose a change of the Model.defaul_manager concept. My
> first concern was the inability to control the default_manager when
> subclassing a Model that already provides a default_manager (the base
> class' manager will be added before the subclass' manager).
>
> This could be solved by either an explicit default_manager
> declaration in Meta,
>
> my_manager = MyManager()
> class Meta:   
>   default_manager = 'my_manager'
>   
> or the convention that default_managers are called `objects` (then
> you wouldn't even need the default_manager concept).
> I strongly favour the latter, because it's dry and simple. Yet it's a
> backwards incompatible change ..
>   
> My attempts to come up with a good example to illustrate my proposal
> were in vain - and I begin to think, that it's always cleaner to keep
> a single Manager (and subclass as necessary) and never ever alter
> Manager.get_query_set() behaviour (or all() for that matter). Does
> anybody have a good use-case that depends on multiple managers?
>
> Here is how I would write the custom manager doc example (from [1]):
> http://dpaste.com/53948/ (Those proxy methods could use a little meta-
> programming.).
>
> Has this approach any flaws? If not, shouldn't the docs advertise
> this more flexible approach instead of multiple Managers?
>
> ___
> Johannes
>   
> [1] http://www.djangoproject.com/documentation/model-api/#custom-
> managers
>
>
> >



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Translation tickets

[Ludvig Ericson]

On Jun 16, 2008, at 01:38, Jacob Kaplan-Moss wrote:
> No, actually, they can't - language maintainers have access to their
> language(s) only and should only commit there.

Then maybe you should oversee your system.
http://code.djangoproject.com/changeset/7549

> It's true we need someone to step into the role of a translation
> maintainer. If someone can take this job -- Marc? -- email me
> privately.

That used to be Malcolm. I can't really see the point in another one,  
but it's your call.

Ludvig "toxik" Ericson
[EMAIL PROTECTED]




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[James Bennett]

On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> Is there a rationale for multiple managers per model?

Yes, and I at least use them all the time. For example, I'll often
have one manager that does no special filtering, and another that only
returns things with a "live" or "published" status. Once you start
working with them, you find lots of uses for multiple-manager tricks
like this.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[Johannes Dollinger]

If you're just want different querysets you can use something like  
this: http://dpaste.com/53948/.

Things.live.all() vs Things.objects.live().

Am 16.06.2008 um 16:37 schrieb James Bennett:

>
> On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
> <[EMAIL PROTECTED]> wrote:
>> Is there a rationale for multiple managers per model?
>
> Yes, and I at least use them all the time. For example, I'll often
> have one manager that does no special filtering, and another that only
> returns things with a "live" or "published" status. Once you start
> working with them, you find lots of uses for multiple-manager tricks
> like this.
>
>
> -- 
> "Bureaucrat Conrad, you are technically correct -- the best kind of  
> correct."
>
> >



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Django 1.0 roadmap

[Jacob Kaplan-Moss]

Hi folks --

I've posted the final Django 1.0 roadmap, incorporating all great
feedback I got here:

http://code.djangoproject.com/wiki/VersionOneRoadmap

I've also updated the features page
(http://code.djangoproject.com/wiki/VersionOneFeatures) to reflect the
new list and to have a list of committers/lieutenants. If anyone wants
to volunteer to fill the "???" slots, let me know.

As requested, I've also added milestones for 1.0 alpha, beta, and
final (as well as a "post-1.0" catch-all). Triagers, feel free to use
these milestones thusly:

* Must-have feature bugs go in the "alpha" milestone. These basically
should be all nfa-blocker tickets. *Bugs* in the must-have features
are *not* to be part of this milestone; they can be fixed after the
alpha.

* Any *feature* tickets related to the maybe list get put in the beta milestone.

* Remaining *bugs* go in the 1.0 final release.

Jacob

PS: http://dl.getdropbox.com/u/20553/django/countdown.png

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

a new middleware class for django

[lep_man]

Hi Guys,

I did not know to refer to.

i have developed a middleware that helps to debug django application
in runtime (at production)

the basic idea is if a specific useragent is accessing the site the
middleware class detects and append debug inforamtion that was added
to the request object into the web page as a remark.

and than the user can see it in the view source.

i found it vary useful in production in when debugging error that can
not be recreated in the django development server.

Thanks

-Mark Zitnik


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[[EMAIL PROTECTED]]

Has anyone else noticed that development progress seems to have
exploded since this thread was created? In the weeks/months after the
qs-rf merge, several days would go by when there wasn't a single
change committed, but suddenly there have been like 10 per day in the
last few days.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Bug in mod_python

[Ben Ford]

Hi all,

I've come across some inconsistent behavior when running django under
different conditions. This is in some existing code that has has some
problems and isn't really well written, so I'm going to ask the question
here first to avoid noise on trac before I raise a ticket.

In this code there's a context processor that checks the path (uri) of the
request and adds something if it's equal to a certain value. The code is:
if request.META['PATH_INFO'] == :

Under fastcgi, and runserver this is fine and we only noticed as we started
to migrate to mod_python. It would appear that request.META['PATH_INFO'] is
always equal to '/' when running under mod_python. I've fixed it by changing
the code to check request.path, which seems to work.

Questions then:
1) Is it better to use 'PATH_INFO' or .path (I'm guessing the latter).
However ticket 285  refers to
inconsistent behaviour WRT self.path in the WSGI environment.
2) Is it a bug in django.core.handlers.modpython.ModPythonRequest to set
META['PATH_INFO'] to self._req.path_info rather than self.path?
3) Does this need a ticket or is the use of request.META['PATH_INFO']
discouraged? (django's documentation would suggest the use of request.path)

Cheers,
Ben

-- 
Regards,
Ben Ford
[EMAIL PROTECTED]
+447792598685

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: a new middleware class for django

[Ben Ford]

Hi Mark,

This sounds really useful, I'd suggest sticking this on
djangosnippets.orgfor others to try!

Ben

2008/6/16 lep_man <[EMAIL PROTECTED]>:

>
> Hi Guys,
>
> I did not know to refer to.
>
> i have developed a middleware that helps to debug django application
> in runtime (at production)
>
> the basic idea is if a specific useragent is accessing the site the
> middleware class detects and append debug inforamtion that was added
> to the request object into the web page as a remark.
>
> and than the user can see it in the view source.
>
> i found it vary useful in production in when debugging error that can
> not be recreated in the django development server.
>
> Thanks
>
> -Mark Zitnik
>
>
> >
>


-- 
Regards,
Ben Ford
[EMAIL PROTECTED]
+447792598685

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.0 roadmap

[Karen Tracey]

On Mon, Jun 16, 2008 at 11:15 AM, Jacob Kaplan-Moss <
[EMAIL PROTECTED]> wrote:

>
> Hi folks --
>
> I've posted the final Django 1.0 roadmap, incorporating all great
> feedback I got here:
>
> http://code.djangoproject.com/wiki/VersionOneRoadmap
>
>
Cool.  One question I have regarding dates is: is there a target date for
merging newforms-admin back to trunk?  There's an nfa-sprint set for July
10-12th which makes it sound like it's still on a branch at that point, but
an alpha release set for the 20th...by which point I expect nfa will have to
be in trunk?  So is the merge targeted for somewhere between those two
dates?  Personally I think earlier would be better, even if it introduces
some trunk instability.  It is the remaining big thing for 1.0, I think
wider community use/feedback than it gets on a branch would be valuable as
soon as possible.

Karen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.0 roadmap

[Joseph Kocherhans]

On Mon, Jun 16, 2008 at 10:40 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
>
> Cool.  One question I have regarding dates is: is there a target date for
> merging newforms-admin back to trunk?  There's an nfa-sprint set for July
> 10-12th which makes it sound like it's still on a branch at that point, but
> an alpha release set for the 20th...by which point I expect nfa will have to
> be in trunk?  So is the merge targeted for somewhere between those two
> dates?  Personally I think earlier would be better, even if it introduces
> some trunk instability.  It is the remaining big thing for 1.0, I think
> wider community use/feedback than it gets on a branch would be valuable as
> soon as possible.

I'd like to merge it about a week before the sprint. (Hopefully I can
free up some time soon to help make that happen.) I think that would
give the sprinters a whole lot more to do. Most of the existing nfa
stuff is non-trivial right now, but I'd imagine there will be some
easier bugs discovered once more eyeballs are on the code.

Joseph

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.0 roadmap

[Karen Tracey]

On Mon, Jun 16, 2008 at 11:49 AM, Joseph Kocherhans <[EMAIL PROTECTED]>
wrote:

>
> On Mon, Jun 16, 2008 at 10:40 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> >
> > Cool.  One question I have regarding dates is: is there a target date for
> > merging newforms-admin back to trunk?  There's an nfa-sprint set for July
> > 10-12th which makes it sound like it's still on a branch at that point,
> but
> > an alpha release set for the 20th...by which point I expect nfa will have
> to
> > be in trunk?  So is the merge targeted for somewhere between those two
> > dates?  Personally I think earlier would be better, even if it introduces
> > some trunk instability.  It is the remaining big thing for 1.0, I think
> > wider community use/feedback than it gets on a branch would be valuable
> as
> > soon as possible.
>
> I'd like to merge it about a week before the sprint. (Hopefully I can
> free up some time soon to help make that happen.) I think that would
> give the sprinters a whole lot more to do. Most of the existing nfa
> stuff is non-trivial right now, but I'd imagine there will be some
> easier bugs discovered once more eyeballs are on the code.
>

Sounds good, that'd be about 2.5 week until merge then.  I will see what I
can do to help things along.  If you have any specific suggestions for ways
I could help do let me know.

Thanks,
Karen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[James Bennett]

On Mon, Jun 16, 2008 at 10:22 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Has anyone else noticed that development progress seems to have
> exploded since this thread was created? In the weeks/months after the
> qs-rf merge, several days would go by when there wasn't a single
> change committed, but suddenly there have been like 10 per day in the
> last few days.

Like most development processes, it runs in cycles. After qsrf there
was a lull while people were shaking it out and reporting bugs, but
before that there was a whole lot more activity. And now, once again,
there's activity.

Such is the nature of what we do.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[James Bennett]

On Mon, Jun 16, 2008 at 9:44 AM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> If you're just want different querysets you can use something like
> this: http://dpaste.com/53948/.

Or I can use managers and also add other supporting methods (which I
also often do).


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[[EMAIL PROTECTED]]

I really like the roadmap, but I'm wondering where the docs-
refactoring work comes in?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: Django 1.0 roadmap and timeline

[Marc Fargas]

El lun, 16-06-2008 a las 10:00 -0700, [EMAIL PROTECTED] escribió:
> I really like the roadmap, but I'm wondering where the docs-
> refactoring work comes in?

It in "Maybe" features, second from the bottom on
http://code.djangoproject.com/wiki/VersionOneFeatures

-- 
http://www.marcfargas.com -- will be finished some day.


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: Django 1.0 roadmap

[Jacob Kaplan-Moss]

On Mon, Jun 16, 2008 at 10:15 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> As requested, I've also added milestones for 1.0 alpha, beta, and
> final (as well as a "post-1.0" catch-all). Triagers, feel free to use
> these milestones.

BTW, I've also added a batch-modify plugin to Trac so that we can
easily update lots of tickets at once. Email me privately or find me
on #django-dev if you'd like access to the feature.

Jacob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.0 roadmap

[Jeff Anderson]

Jacob Kaplan-Moss wrote:

As requested, I've also added milestones for 1.0 alpha, beta, and
final (as well as a "post-1.0" catch-all). Triagers, feel free to use
these milestones thusly:

* Must-have feature bugs go in the "alpha" milestone. These basically
should be all nfa-blocker tickets. *Bugs* in the must-have features
are *not* to be part of this milestone; they can be fixed after the
alpha.
  
As I am new to the triaging process, I am seeking a clarification before 
I just "go crazy" and start marking tickets for milestones:
When we say *Bugs* or "Boogs", do those include usability bugs? I did a 
query on nfa-someday, thinking that they would be appropriate for the 
1.0 final release milestone. There are several that address aesthetic 
issues, quirks that already exist in the old admin, small usability 
issues, etc... Are these types of tickets "Boogs" that should be 
squished for 1.0, or are they just trivial annoyances?


Hopefully my question makes sense (it is a Monday after all)

Thanks!


Jeff Anderson

ps:
Some examples:
http://code.djangoproject.com/ticket/7179
http://code.djangoproject.com/ticket/7361
http://code.djangoproject.com/ticket/6077



signature.asc
Description: OpenPGP digital signature

Re: The Model.default_manager concept

[Ken Arnold]

So then what is the difference between a Manager and a QuerySet?

Nearly everything would work identically if Manager were simply:

class Manager(QuerySet):
pass

(except actually keeping the magic that connects it to the model
class.)

It would be exactly identical, except that:
 * the assignment to self.model is deferred until after the class is
created (QuerySet requires it as an __init__ parameter)
 * Model.objects doesn't repr() to anything interesting

If those differences don't matter, why have an unnecessary concept?

If those differences do matter, is there a generally useful technique
or pattern here?

Just a thought, feel free to ignore it,
-Ken


On Jun 16, 10:44 am, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> If you're just want different querysets you can use something like  
> this:http://dpaste.com/53948/.
>
> Things.live.all() vs Things.objects.live().
>
> Am 16.06.2008 um 16:37 schrieb James Bennett:
>
>
>
> > On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
> > <[EMAIL PROTECTED]> wrote:
> >> Is there a rationale for multiple managers per model?
>
> > Yes, and I at least use them all the time. For example, I'll often
> > have one manager that does no special filtering, and another that only
> > returns things with a "live" or "published" status. Once you start
> > working with them, you find lots of uses for multiple-manager tricks
> > like this.
>
> > --
> > "Bureaucrat Conrad, you are technically correct -- the best kind of  
> > correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.0 roadmap

[Marty Alchin]

On Mon, Jun 16, 2008 at 11:15 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> As requested, I've also added milestones for 1.0 alpha, beta, and
> final (as well as a "post-1.0" catch-all). Triagers, feel free to use
> these milestones thusly:
>
> * Any *feature* tickets related to the maybe list get put in the beta 
> milestone.

One question about this, since I'm probably best positioned to manage
the tickets related to file storage. #5361 is already added to the
beta milestone, but what should be done about the 15 other tickets
that are related to it[1]? Given how much code #5361 already has to
move, modify and replace, I've been wrapping some of the fixes up in
that one patch (keyword fs-rf-fixed), and the others will be addressed
by the documentation (keyword fs-rf-docs).

This might be considered hijacking the thread, but I can see three ways to go:

* Leave them as they are, and just tell whoever commits #5361 to
reference them in the commit message.

* Move all of the to the beta milestone, since they are indeed being
addressed, and also reference them in the comment message

* Close the fixes as duplicates now, and close the doc tickets as
wontfix once it lands (which will have to be done regardless).

Personally, I'd like to avoid the third option, since I think it's
valid to keep them going, as there's not a proper branch to checkout,
like newforms-admin has. The difference between the first two is
purely bookkeeping though, and I have no preference either way.

-Gul

[1] http://tinyurl.com/6rxpyp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.0 roadmap

[Jacob Kaplan-Moss]

On Mon, Jun 16, 2008 at 12:43 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
> * Leave them as they are, and just tell whoever commits #5361 to
> reference them in the commit message.
>
> * Move all of the to the beta milestone, since they are indeed being
> addressed, and also reference them in the comment message

Do both of these, and also tag with with a common tag (see, e.g., the
qsrf-fixed or nfa-fixed tag). I'd suggest "fstorage-fixed" or
something. Actually, if you tag them first it's easy to move them all
to the milestone -- I'd like the milestones to reflect the actually
ticket count (even for dups of this nature).

Jacob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.0 roadmap

[Jacob Kaplan-Moss]

On Mon, Jun 16, 2008 at 12:27 PM, Jeff Anderson
<[EMAIL PROTECTED]> wrote:
> When we say *Bugs* or "Boogs", do those include usability bugs? I did a
> query on nfa-someday, thinking that they would be appropriate for the 1.0
> final release milestone. There are several that address aesthetic issues,
> quirks that already exist in the old admin, small usability issues, etc...
> Are these types of tickets "Boogs" that should be squished for 1.0, or are
> they just trivial annoyances?

It's going to be a close call either way for any of these types of
tickets. I think we'll lean towards "no" if there's not an actual bug,
but mark them in the 1.0 milestone anyway - we can always defer 'em
later on.

What we *don't* want to do is get caught trying to fix these things
before the merge; stuff like this is OK to postpone.

Jacob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[Johannes Dollinger]

Am 16.06.2008 um 18:49 schrieb James Bennett:

>
> On Mon, Jun 16, 2008 at 9:44 AM, Johannes Dollinger
> <[EMAIL PROTECTED]> wrote:
>> If you're just want different querysets you can use something like
>> this: http://dpaste.com/53948/.
>
> Or I can use managers and also add other supporting methods (which I
> also often do).

You could as stick them in a single manager as well (and wouldn't  
have to remember which method is available via which manager).
My point is that one manager per model would be enough to do anything  
you can do with multiple managers (and if you want modified querysets  
you get a little extra flexibility if you just subclass QuerySet).  
Therefore (imho) the cleanest solution for the problem with  
_default_manager and model inheritance appears to get rid of multiple  
managers.
I don't really expect this to be accepted as it would break lots of  
existing code. But there should be a way to bypass the  
Manager.creation_counter magic.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[James Bennett]

On Mon, Jun 16, 2008 at 1:48 PM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> You could as stick them in a single manager as well (and wouldn't
> have to remember which method is available via which manager).
> My point is that one manager per model would be enough to do anything
> you can do with multiple managers (and if you want modified querysets
> you get a little extra flexibility if you just subclass QuerySet).

Simply "being enough" won't cut it though, because you'd end up having
to do some very ugly things and crowding up your single manager with a
lot of stuff that'd make more sense logically broken out.

It'd also hurt the reusability of managers (which is a big advantage I
and others have taken advantage of), because you wouldn't be able to
keep methods specific to a single model separate from methods which
aren't, at least not without introducing a whole chain of manager
classes inheriting from each other to bring in the right sets of
methods.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[Johannes Dollinger]

> So then what is the difference between a Manager and a QuerySet?
>
> Nearly everything would work identically if Manager were simply:
>
> class Manager(QuerySet):
> pass
>
> (except actually keeping the magic that connects it to the model
> class.)

Utility methods in managers wouldn't make much sense if Manager was a  
QuerySet:

User.objects.filter(username='foo').create_user('bar',  
'[EMAIL PROTECTED]')

Although those utilities could as well be class methods.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[Ken Arnold]

True. But surprisingly enough, the `create` method is a QuerySet
instance method. And it doesn't use any of the filtering, so

Article.objects.filter(category=cat).create(title=title,
content=content)

doesn't do what you'd expect. (Though `cat.article_set.create` should
work.) Has that actually confused anyone?

-Ken


On Jun 16, 2:57 pm, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> > So then what is the difference between a Manager and a QuerySet?
>
> > Nearly everything would work identically if Manager were simply:
>
> > class Manager(QuerySet):
> >     pass
>
> > (except actually keeping the magic that connects it to the model
> > class.)
>
> Utility methods in managers wouldn't make much sense if Manager was a  
> QuerySet:
>
> User.objects.filter(username='foo').create_user('bar',  
> '[EMAIL PROTECTED]')
>
> Although those utilities could as well be class methods.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.0 roadmap

[Marty Alchin]

On Mon, Jun 16, 2008 at 2:17 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> On Mon, Jun 16, 2008 at 12:43 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>> * Leave them as they are, and just tell whoever commits #5361 to
>> reference them in the commit message.
>>
>> * Move all of the to the beta milestone, since they are indeed being
>> addressed, and also reference them in the comment message
>
> Do both of these, and also tag with with a common tag (see, e.g., the
> qsrf-fixed or nfa-fixed tag). I'd suggest "fstorage-fixed" or
> something. Actually, if you tag them first it's easy to move them all
> to the milestone -- I'd like the milestones to reflect the actually
> ticket count (even for dups of this nature).

Tags were already done, but I've now moved them all into the beta
milestone as well. I hope I didn't overstep my boundaries here, but I
also added a note on the VersionOneRoadmap to explain the related
tickets and how the tags should be used.

-Gul

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[Johannes Dollinger]

Am 16.06.2008 um 20:56 schrieb James Bennett:
> It'd also hurt the reusability of managers (which is a big advantage I
> and others have taken advantage of), because you wouldn't be able to
> keep methods specific to a single model separate from methods which
> aren't, at least not without introducing a whole chain of manager
> classes inheriting from each other to bring in the right sets of
> methods.

That's exactly what I do now - I have model specific managers and use  
them as bases for submodel managers.
There are no reusability drawbacks and you can split functionality as  
needed.
You could add a manager_mixin attribute to Meta to make the parallel  
inheritance structure (models and managers) more convenient.




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: The Model.default_manager concept

[Johannes Dollinger]

The QuerySet method examples [1] mostly use the corresponding Manager  
proxy method.
Probably QuerySet.create() exists to use querysets where managers are  
expected.

An ugly corner case:

cat.article_set.filter(...).create(title=title)

is equivalent to

Article.objects.create(title=title)


[1] http://www.djangoproject.com/documentation/db-api/#queryset- 
methods-that-do-not-return-querysets


Am 16.06.2008 um 21:06 schrieb Ken Arnold:

>
> True. But surprisingly enough, the `create` method is a QuerySet
> instance method. And it doesn't use any of the filtering, so
>
> Article.objects.filter(category=cat).create(title=title,
> content=content)
>
> doesn't do what you'd expect. (Though `cat.article_set.create` should
> work.) Has that actually confused anyone?
>
> -Ken
>
>
> On Jun 16, 2:57 pm, Johannes Dollinger
> <[EMAIL PROTECTED]> wrote:
>>> So then what is the difference between a Manager and a QuerySet?
>>
>>> Nearly everything would work identically if Manager were simply:
>>
>>> class Manager(QuerySet):
>>> pass
>>
>>> (except actually keeping the magic that connects it to the model
>>> class.)
>>
>> Utility methods in managers wouldn't make much sense if Manager was a
>> QuerySet:
>>
>> User.objects.filter(username='foo').create_user('bar',
>> '[EMAIL PROTECTED]')
>>
>> Although those utilities could as well be class methods.
> >



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

newforms generic views

[Gary Wilson Jr.]

I was taking a look at the latest patch [1] for #3639 (many thanks to
Brian Rosner for the hard work), and trying to decide how backwards
compatible we want to be.  (I should also mention that while there has
been some work done towards class-based generic views in #6735 [3], I
believe that #3639 should be completed first as #6735 could be done
post-1.0 if need be.)  So, I come to the community for input...

Currently the create_update views take a  required ``model`` argument
and an optional ``follow`` argument.  The ``model`` argument is fine and
we can carry that forward.  The ``follow`` argument, however, is
specific to oldforms Manipulators and was used for showing/hiding form
fields (see [2] for a refresher of the follow argument).

In order to enable custom newforms-style forms, Brian has added a
``form_class`` argument to the views, which I think is the correct way
to replace the functionality lost by the ``follow`` argument.

There are a couple design decisions that need to be made, though:

1. Brian's patch replaces the required ``model`` argument with the
required ``form_class`` argument, where ``form_class`` can either be a
``forms.ModelForm`` subclass or ``model.Model`` subclass.

   a. I am thinking that we should instead keep the ``model`` argument,
but make it optional.  Then, we ensure that one of ``model`` or
``form_class`` is given.  ``form_class``, if given, would override
``model`` or if just ``model`` was given, then a ModelForm would be
created for the passed model.  Does this sound reasonable?

   b. Anyone have any other ideas here?

2. What should we do with the ``follow`` argument?

   a. We could drop it completely, which would not be backwards
compatible for anyone using the ``follow`` argument.

   b. We could issue a deprecation warning if ``follow`` is used,
letting people know that generic views now use newforms and to use
``form_class`` if you need a custom form.  This would be a bit more
backwards compatible, since if you aren't using ``follow`` everything
should work the same.  If you are using ``follow``, then those forms
might display/behave differently (i.e. fields you were trying to hide
now get displayed).

   c. We could be even more backwards compatible by trying to take
fields declared in ``follow`` and make them includes/excludes in the
inner Meta class of the generated ModelForm.

I have taken Brian's latest patch and added implementations of 1a and
2b.  Other additions were:
  * Fixed an error I was getting in the tests when using "model = model"
in the inner Meta class (works fine in my shell, but gives me model not
defined errors when I run the tests) by introducing a tmp_model variable.
  * Added a GenericViewError class and made a couple AttributeErrors use
this Exception class instead since AttributeError didn't really fit.
  * Added a get_model_and_form_class helper function to remove duplicate
ModelForm-generating code.
  * Finished off the test_create_custom_save_article test with a
custom_create view that passes a custom form to the create_update
generic view.

I have attached my patch [4] to the ticket.

Gary

[1]
http://code.djangoproject.com/attachment/ticket/3639/create_update_newforms5.diff
[2] http://code.djangoproject.com/wiki/NewAdminChanges
[3] http://code.djangoproject.com/ticket/6735
[4] http://code.djangoproject.com/attachment/ticket/3639/3639.diff


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: newforms generic views

[Brian Rosner]

On Jun 16, 2008, at 2:51 PM, Gary Wilson Jr. wrote:

>
> I was taking a look at the latest patch [1] for #3639 (many thanks to
> Brian Rosner for the hard work), and trying to decide how backwards
> compatible we want to be.  (I should also mention that while there has
> been some work done towards class-based generic views in #6735 [3], I
> believe that #3639 should be completed first as #6735 could be done
> post-1.0 if need be.)  So, I come to the community for input...

I personally agree that #3639 should be what is used in 1.0 and then  
post-1.0 can introduce the class-based view enhancements.

> In order to enable custom newforms-style forms, Brian has added a
> ``form_class`` argument to the views, which I think is the correct way
> to replace the functionality lost by the ``follow`` argument.
>
> There are a couple design decisions that need to be made, though:
>
> 1. Brian's patch replaces the required ``model`` argument with the
> required ``form_class`` argument, where ``form_class`` can either be a
> ``forms.ModelForm`` subclass or ``model.Model`` subclass.

I was going to rename ``form_class`` to ``model`` but never got around  
to it. It was to be more backward compatible, which still sounds  
reasonable to me.

>   a. I am thinking that we should instead keep the ``model`` argument,
> but make it optional.  Then, we ensure that one of ``model`` or
> ``form_class`` is given.  ``form_class``, if given, would override
> ``model`` or if just ``model`` was given, then a ModelForm would be
> created for the passed model.  Does this sound reasonable?

newforms-admin will bring in a modelform_factory that could be used.  
But in the meantime this would be fine with me.

> 2. What should we do with the ``follow`` argument?
>
>   a. We could drop it completely, which would not be backwards
> compatible for anyone using the ``follow`` argument.

I wouldn't be opposed to this.

>
>
>   b. We could issue a deprecation warning if ``follow`` is used,
> letting people know that generic views now use newforms and to use
> ``form_class`` if you need a custom form.  This would be a bit more
> backwards compatible, since if you aren't using ``follow`` everything
> should work the same.  If you are using ``follow``, then those forms
> might display/behave differently (i.e. fields you were trying to hide
> now get displayed).

+1 here. I don't know much about ``follow``, but I wouldn't want to  
see some legacy support for it while we get to 1.0. It should break  
cleanly now and then horribly later IMHO.

>
>
>   c. We could be even more backwards compatible by trying to take
> fields declared in ``follow`` and make them includes/excludes in the
> inner Meta class of the generated ModelForm.

Yuck :)

Brian Rosner
http://oebfare.com




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: newforms generic views

[Jacob Kaplan-Moss]

On Mon, Jun 16, 2008 at 3:51 PM, Gary Wilson Jr. <[EMAIL PROTECTED]> wrote:
>   a. I am thinking that we should instead keep the ``model`` argument,
> but make it optional.  Then, we ensure that one of ``model`` or
> ``form_class`` is given.  ``form_class``, if given, would override
> ``model`` or if just ``model`` was given, then a ModelForm would be
> created for the passed model.  Does this sound reasonable?

Yes, very much so. I'd like to call it ``model`` and ``form`` (instead
of ``form_class``, which is redundant), but Brian's building the shed,
so he can paint it any color he likes.

[The cute thing about allowing any form, by the way, is that if you
give it something that *looks* like a ModelForm -- i.e. defines save()
-- you can actually use the view with any form you like... Me likey.]

> 2. What should we do with the ``follow`` argument?
[...]
>   b. We could issue a deprecation warning if ``follow`` is used,
> letting people know that generic views now use newforms and to use
> ``form_class`` if you need a custom form.  This would be a bit more
> backwards compatible, since if you aren't using ``follow`` everything
> should work the same.  If you are using ``follow``, then those forms
> might display/behave differently (i.e. fields you were trying to hide
> now get displayed).

+1 here. I'd say issue DeprecationWarning until 1.0 beta, then drop it entirely.

I'll have a look at the patch itself, but from your description it
sounds like this is looking good.

Jacob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: MS SQL backend as a proper external backend (was: RFC: Django 1.0 roadmap and timeline)

[Ramiro Morales]

Ian,

On Thu, Jun 12, 2008 at 10:49 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
>> connection.autocommit is an attribute and not a method (didn't find a way to
>> cleanly monkeypatch this).
>
> It's also an attribute in cx_Oracle.  I'll have to take a look at it
> some time and figure out why it's not broken.
>

/me greps over the cx_Oracle 4.3.3 and 4.4 source trees.

It's me or cx_Oracle doesn't have an autocommit symbol at all?. In
fact, it hasn't
a set_isolation_level one either.

Confused,

-- 
 Ramiro Morales

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: MS SQL backend as a proper external backend (was: RFC: Django 1.0 roadmap and timeline)

[Ivan Illarionov]

> To solve it I proposed[1] another strategy: delegate type conversion
> to the backend. Otherwise, I think we will end with too many backend
> flags.

+1

I maintain the external Firebird backend and I would also prefer this
solution.

Ivan Illarionov
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: MS SQL backend as a proper external backend (was: RFC: Django 1.0 roadmap and timeline)

[Ian Kelly]

On Mon, Jun 16, 2008 at 5:10 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote:
> /me greps over the cx_Oracle 4.3.3 and 4.4 source trees.
>
> It's me or cx_Oracle doesn't have an autocommit symbol at all?. In
> fact, it hasn't
> a set_isolation_level one either.

It does as of version 4.3.2.  I know that it does because I wrote the
patch for it.  The attribute is defined in Connection.c and referenced
in the Cursor_InternalExecute function in Cursor.c.

In any case, I looked at this and found that the only time Django
calls the autocommit method is when creating or destroying a test
database.  The Oracle backend defines its own custom procedures for
creating and destroying test databases, so those lines never get
executed when using Oracle, and that's why it doesn't cause a problem.

-Ian

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Multiple database support

[mengel]

On May 22, 9:59 am, Simon Willison <[EMAIL PROTECTED]> wrote:

> 1. Replication - being able to send all of my writes to one master
> machine but spread all of my reads over several slave machines.


> 2. Sharding - being able to put User entries 1-1000 on DB1, whereas
> User entries 1001-2000 live on DB2 and so on.

It seems to me this isn't beyond doing in the current setup; but I'm
not sure I understand
the underlying mechanism well enough.   For case 1, you need an object
class that
creates two (or more) (apparently identical) Models.model classes, one
attached to each database, based on the field types declared as class
variables:
  * on searches, it picks one of the model classes to search
  * on saves, saves the same data to each  object class in turn

For case 2, it's very similar, except you need to run the query on all
sides (unless
you can tell it should only go to one) building a chained query-set
union type to hold
the result, and for saves pick the right model  to save to  based on
the condition.

In each case, the underlying models have to be tied to the right
databases, but this can
be done using the mechanism in the proposal so far..

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Multiple database support

[David Cramer]

I suppose I'll chime in here since we actually wrote master/slave
replication code on Curse.

Our approach:

- read_cursor and write_cursor exist. write_cursor is what cursor
would point ot.
- get queries all use the read cursor
- saves all use the write cursor
- we had a list of database connections, which stored the same
settings, just in a tuple format
- reading I believe used something like itertools.cycle but I can't
honestly say without looking at the code

Beyond this, the database itself should handle writing the objects to
the slaves. Django shouldn't even bother.

In regards to multiple databases in general. it is my feeling that
even if it is not good practice, Django _NEEDS_ to support a model
being attached to a database other than the default. So if you have
mydjango_blogs, and mydjango_forums databases, my Forum model always
goes to the write db when it queries, and same for blogs. I myself
like a Meta solution to this as it makes sense.

In MySQL as well, you can optimize things, so that if they use the
same connection, you can just query on that database. It's select X
from mydatabase.mytable. I'm not sure if something similar exists in
other database engines.

On Jun 16, 9:05 pm, mengel <[EMAIL PROTECTED]> wrote:
> On May 22, 9:59 am, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> > 1. Replication - being able to send all of my writes to one master
> > machine but spread all of my reads over several slave machines.
> > 2. Sharding - being able to put User entries 1-1000 on DB1, whereas
> > User entries 1001-2000 live on DB2 and so on.
>
> It seems to me this isn't beyond doing in the current setup; but I'm
> not sure I understand
> the underlying mechanism well enough.   For case 1, you need an object
> class that
> creates two (or more) (apparently identical) Models.model classes, one
> attached to each database, based on the field types declared as class
> variables:
>   * on searches, it picks one of the model classes to search
>   * on saves, saves the same data to each  object class in turn
>
> For case 2, it's very similar, except you need to run the query on all
> sides (unless
> you can tell it should only go to one) building a chained query-set
> union type to hold
> the result, and for saves pick the right model  to save to  based on
> the condition.
>
> In each case, the underlying models have to be tied to the right
> databases, but this can
> be done using the mechanism in the proposal so far..
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---