Re: Addition of optional id in template endblocks

Thanks Malcom, No, I do not have an example! I did not realize that the system actually checks to make sure you unwind your blocks in the right order. That is good! I suppose you could add a comment in the documentation to that effect. If that wasn't obvious to me, I suppose others might wo

Re: Addition of optional id in template endblocks

On Tue, 2007-02-13 at 01:51 +, JMCameron wrote: > The recent patch to template endblocks to allow an identifier is nice > (Tickets #3351, #4489), but it may lead the unwary to think that the > parser is actually using the identifiers to make sure your start and > end blocks line up correctly.

Addition of optional id in template endblocks

The recent patch to template endblocks to allow an identifier is nice (Tickets #3351, #4489), but it may lead the unwary to think that the parser is actually using the identifiers to make sure your start and end blocks line up correctly. It may be worthwhile to add a short comment to the document

Re: Getting started in Django development.

On Mon, 2007-02-12 at 06:56 +, zbelzer wrote: > Hi all. > > I've been learning about and working with Django for a little while > now and I have decided that I would like to help contribute to the > project and community. I'm decent with python, but I still find that > looking through the ent

Re: Passing external data to Form objects in newforms

Speaking as a Python newbie who is currently learning Django then OOP (i.e. the opposite of the logical, preferred order), I would really love documentation on this sort of thing. I wrote a hackish workaround to a very similar problem just yesterday which I can currently updating with your example

#3465 - template variable list-index lookup on an unsubscriptable object raises TypeError

Added fix and regression tests, could someone please review. http://code.djangoproject.com/ticket/3465 Gary --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send em

Re: Getting started in Django development.

Thanks everyone! I'll look into all your suggestions tonight after work (I'm so sick of PHP). I appreciate the help, Zach --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this

Re: newforms: proposal ModelForm Baseclass for model related Forms

that wouldnt remove the strict distinction betwen form_for_model and form_for_instance (the only difference i see, is that one of them has a initial instance and i really would like to have a base class, since i like to avoid monkey-patching using the function result as a base-class would be an

Re: Adding support for replacing the auth User model to fit custom needs

sweet - thats a good start On 12 Feb., 17:21, "Gary Wilson" <[EMAIL PROTECTED]> wrote: > On Feb 12, 9:01 am, "RonnyPfannschmidt" <[EMAIL PROTECTED]> > wrote: > > > in some case the only way to do it right is a replacement (like using > > a mail as username) > > You would probably be interested in

Re: newforms: proposal ModelForm Baseclass for model related Forms

On 2/12/07, Scott Paul Robertson <[EMAIL PROTECTED]> wrote: > On Mon, Feb 12, 2007 at 07:45:52AM -0800, RonnyPfannschmidt wrote: > > > > The actual method of creating Model related forms is a set of > > functions returning form classes > > > > thats nice to use, but not very nice to extend > > > >

Re: Adding support for replacing the auth User model to fit custom needs

On Feb 12, 9:01 am, "RonnyPfannschmidt" <[EMAIL PROTECTED]> wrote: > in some case the only way to do it right is a replacement (like using > a mail as username) You would probably be interested in ticket 3011, which aims to make the auth User model replaceable. There is even a patch to get you s

Re: newforms: proposal ModelForm Baseclass for model related Forms

On Mon, Feb 12, 2007 at 07:45:52AM -0800, RonnyPfannschmidt wrote: > > The actual method of creating Model related forms is a set of > functions returning form classes > > thats nice to use, but not very nice to extend > > Im proposing a Base class wich allows to pass models/instances to > gener

Re: Adding support for replacing the auth User model to fit custom needs

You could write an authentication backend to auth on the email address: John. On 2/12/07, RonnyPfannschmidt <[EMAIL PROTECTED]> wrote: > > adding a profile doesnt fix all problems > > in some case the

Re: newforms, "reverse inline" editing, fieldsets

I'm wondering how hard it would be to build this kind of reverse edit_inline functionality into the admin contrib. It would open up some basic model inheritance possibilities if used in combination with generic relations. Personally I've not yet ventured into the django core libraries. Can anyone

newforms: proposal ModelForm Baseclass for model related Forms

The actual method of creating Model related forms is a set of functions returning form classes thats nice to use, but not very nice to extend Im proposing a Base class wich allows to pass models/instances to generate forms, or inherit to extend the forms default usage would be ModelForm(model=

Re: Adding support for replacing the auth User model to fit custom needs

adding a profile doesnt fix all problems in some case the only way to do it right is a replacement (like using a mail as username) some might argue you could use profiles to do this stuff, but that would encourage messy code, denormalized data models and not really good practices to make it work

Re: Adding support for replacing the auth User model to fit custom needs

Hi, http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model does this help? You can extend the User model with another class that gets related to it. Sure it should be documented in djangoproject.com but couldn't find it there... I'll look deeper ;) On 2/12/07, RonnyPfannschmid

Adding support for replacing the auth User model to fit custom needs

The build-in User model is nice in many Cases, but sometimes it just is a bad limit for Development cause of its limits, but just droping it would cause the loss of all auth features, and doesnt play well with 3rd Party apps Examples are : * Email as Username * _long_ Usernames * special Characte

Adding support for replacing the auth User model to fit custom needs

The build-in User model is nice in many Cases, but sometimes it just is a bad limit for Development cause of its limits, but just droping it would cause the loss of all auth features, and doesnt play well with 3rd Party apps Examples are : * Email as Username * _long_ Usernames * special Characte

Adding Support for optional relations to Unregistred Users in the Database

Right now there is no Support for relating Data like Permissions, Posts, Comments, Wikipages and others to Unregistred Users The usual Solutions are nullable Relations, but * they break select_related An selfmade special User, but * checking if its the anonymous User is Complicated My Proposal

Re: Getting started in Django development.

zbelzer wrote: > Hi all. > > I've been learning about and working with Django for a little while > now and I have decided that I would like to help contribute to the > project and community. I'm decent with python, but I still find that > looking through the entire code base is pretty intimidatin

Re: Getting started in Django development.

Hi, I'd like to add that you can learn a lot by looking into the existing tickets, and try to follow what they do. Some areas are hard to follow, others quite easy, poke a bit around to find what you like. It would be a great contribution if you could look into the approved tickets that need tes