Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

[Brian Rosner]

On Aug 13, 2009, at 1:59 PM, Kevin Henry wrote:

>
>> Well, surprise is in the eye of the participant. As noted above, it
>> would be surprising to a lot of us if it did pick up the attributes
>> because it removes control from the user. The current behaviour isn't
>> illogical.
>
> Oh, I wasn't suggesting that the user shouldn't be able to override
> those values, I was only talking about what the default behavior
> should be if the user doesn't specify anything. If the user
> instantiates a form field, and doesn't specify what 'required' should
> be (and the field itself doesn't set this value), it just seems far
> more natural to pick up the value the user already specified in the
> model, rather than arbitrarily choosing 'True'.

It isn't choosing arbitrary defaults. When you declare a form field  
declaratively in your ModelForm we have to assume you want that field  
and everything that comes with it. So, behind the scenes the declared  
form field simply overrides what is the field for that particular  
field. Therefore the value it uses in-place of the model form field is  
the default value for that attribute of that form field you've just  
declared as being the replacement.

>
> Part of the reason I think this represents a common use case is that
> these attributes seem fairly orthogonal to the purposes of validating/
> rendering that fields and widgets are used for. That is, I wouldn't
> imagine that it's common that your choice of which field or widget to
> use to represent a model field will affect whether or not that field
> is required, say. Of course, my experience is limited.

I won't argue that you are wrong here, but to accomplish what you have  
asked for is going to involve more trickery than it is really worth  
(plus being backwards incompatible at this point). There has been  
mention of providing a simpler way to overriding widgets for a field  
(as that is the common case) without affecting the field. That  
particular proposal will go further than what you've brought up.

>
> I don't know enough yet to suggest how this would be implemented, I
> just wanted to throw the idea out there. But unless there's a
> groundswell of support for my position, I guess I'll just file a
> documentation ticket.

No doubt the documentation needs to be revised slightly for this. It  
is mentioned, but only as a single sentence that almost makes no  
sense ;-)

Please file a ticket for the documentation fix it would be greatly  
appreciated. :-)

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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.2 proposal: revisit admin autodiscover improvement for custom sites

[Brian Rosner]

On Aug 19, 2009, at 3:32 PM, Manuel Saelices wrote:

> This ticket was marked by duplicate of #8500, but I think #8572
> approach is better (better explicit than implicit). Ticket number is
> not important, but I think that functionality is easy to implement
> (with several strategies) and has no colateral effects, being
> backwards compatible.

I am in agreement the approach in #8572 is best. This has something  
that has bitten me on a few occasions and would like to get this fixed  
in Django. If you are fired up about getting this in I would recommend  
including documentation and tests and attaching it to #8500.

Of course I welcome the thoughts of others too.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner




--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Advocacy for Email-01 (email backends)

[Brian Rosner]

On Oct 30, 2009, at 6:10 AM, Russell Keith-Magee wrote:

> I'm still keen to see a resolution to this problem. Can anyone -
> especially those that voted -0 or -1 - offer any feedback?

I've reviewed the RC patch on #10355. Overall, I am okay with it. I  
hadn't kept up with with many of the details of the original proposal  
and was afraid of over-complication. Thanks for putting in the work to  
get this ready for commit, Russell.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner


--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Model validation incompatibility with existing Django idioms

[Brian Rosner]

On Jan 6, 2010, at 2:56 PM, Joseph Kocherhans wrote:
> I had another idea that I think might work out. What if
> ModelForm.validate() only validated fields on the form, like it worked
> before the merge, and ModelForm.save() would automatically validate
> the excluded fields, raising ValidationError if there was a problem?
> Validation for each field would only happen once, it would accommodate
> the commit=False idiom, and it would still ensure that the model
> itself is validated in common usage.

I like this. It would then provide far superior error messages in cases where 
there was real developer error.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model validation incompatibility with existing Django idioms

[Brian Rosner]

On Jan 6, 2010, at 2:48 PM, Łukasz Rekucki wrote:

> Maybe you could do something like this:
> 
> with form.valid_model() as model: # i'm not good at inventing names
> model.user = request.user
> model.primary_contact = somecontact
> 
> The valid_model() would be a context manager that does form validation and 
> form.save(commit=False) on enter + model validation and save() on exit. Of 
> course this will only work on Python 2.5+, so it's probably no good for 
> django 1.2. Just wanted to share an idea.

FTR, this is a pretty neat idea. The naming is a bit off, but that can be 
worked out. Unfortunately, we couldn't much with it now, but I'd like to look 
at the possibility for 1.3. Thanks for sharing.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model validation incompatibility with existing Django idioms

[Brian Rosner]

On Jan 6, 2010, at 3:46 PM, Jeremy Dunck wrote:

> On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans  
> wrote:
> ...
>>>> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison  
>>>> wrote:
> ...
>>>>> form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
>>>>> if form.is_valid():
>>>>>p = form.save(commit=False)
>>>>>p.user = request.user
>>>>>p.primary_contact = somecontact
>>>>>p.save()
> ...
>> I had another idea that I think might work out. What if
>> ModelForm.validate() only validated fields on the form, like it worked
>> before the merge, and ModelForm.save() would automatically validate
>> the excluded fields, raising ValidationError if there was a problem?
>> Validation for each field would only happen once, it would accommodate
>> the commit=False idiom, and it would still ensure that the model
>> itself is validated in common usage.
> 
> Note that p in the example above is the unsaved model instance, not
> the ModelForm.  So to fix the idiom, the excluded field validation
> would need to be done on Model.save, not ModelForm.save, right?

Yeah, I think that must have been a typo in Joseph's mail. The way I read it 
that the model knows what fields it has already validated and the call to a 
Model.save would validate the rest.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model validation incompatibility with existing Django idioms

[Brian Rosner]

On Jan 6, 3:57 pm, Brian Rosner  wrote:

> Yeah, I think that must have been a typo in Joseph's mail. The way I read it 
> that the model knows what fields it has already validated and the call to a 
> Model.save would validate the rest.

Actually, I just realized that Model.save doesn't do validation now
does it?

Brian Rosner
http://oebfare.com
http://twitter.com/brosner
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model validation incompatibility with existing Django idioms

[Brian Rosner]

On Jan 6, 2010, at 3:59 PM, Joseph Kocherhans wrote:

> On Wed, Jan 6, 2010 at 4:46 PM, Jeremy Dunck  wrote:
>> On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans  
>> wrote:
>> ...
>>>>> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison  
>>>>> wrote:
>> ...
>>>>>> form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
>>>>>> if form.is_valid():
>>>>>>p = form.save(commit=False)
>>>>>>p.user = request.user
>>>>>>p.primary_contact = somecontact
>>>>>>p.save()
>> ...
>>> I had another idea that I think might work out. What if
>>> ModelForm.validate() only validated fields on the form, like it worked
>>> before the merge, and ModelForm.save() would automatically validate
>>> the excluded fields, raising ValidationError if there was a problem?
>>> Validation for each field would only happen once, it would accommodate
>>> the commit=False idiom, and it would still ensure that the model
>>> itself is validated in common usage.
>> 
>> Note that p in the example above is the unsaved model instance, not
>> the ModelForm.  So to fix the idiom, the excluded field validation
>> would need to be done on Model.save, not ModelForm.save, right?
> 
> Ugh. Yes it would. I did mean ModelForm.save(), but as you've pointed
> out, that won't work (at least for the idiom). One of the early
> decisions was that Model.save() would never trigger validation for
> backwards compatibility purposes. Maybe something from the idea is
> salvageable, but it won't work as I presented it. I think having the
> model track which validators have been run and which haven't is a
> non-starter. That's something Honza actively avoided in the design.

Saw this after my e-mails. This does present an issue. For sake of backwards 
compatibility it would seem that the second step of validation could just be 
done by the developer? This is mostly to prevent double validation, but also 
maintain compatibility with the Django idiom.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

#9015 — signal connection decorator

[Brian Rosner]

Hey all —

I wanted to get some feedback on a patch [1] I wrote for #9015. I am on board 
with the notion decorators can be used for registration patterns. Recently, 
I've been using signals a bit more which has spiked my interest in this ticket. 
Since Django 1.2 has a Python 2.4 minimum requirement and we're before the 
feature freeze I figured I'd take a stab at it.

The approach I took was slightly different than what zvoase took in his 
patches. I felt that using the connect method of Signal would be risky 
business. It is stable API that I didn't want to go modifying. Also, the idea 
of the decorator is to only connect which makes other methods on the signal 
useless. I appreciate the work zvoase did though, so thanks!

My approach introduces new API @receiver from django.dispatch. It takes the 
signal and kwargs and calls connect appropriately. Here's a quick example:

from django.db.models.signals import pre_save
from django.dispatch import receiver

@receiver(pre_save, sender=MyModel)
def my_receiver(sender, **kwargs):
...

Any thoughts or objections to committing?

[1]: 
http://github.com/brosner/django-svn/commit/970dcae959af16699b78ebca13ac878a6ffe86a7

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #9015 — signal connection decorator

[Brian Rosner]

On Jan 23, 2010, at 6:45 AM, Ulrich Petri wrote:
> Just an idea:
> 
> Wouldn't it be a bit nicer API to have receiver be a method on Signal?
> So you could do:
> 
> @pre_save.receiver(sender=MyModel)
> def my_receiver(sender, **kwargs):
>...
> 

This isn't a bad idea. It does reduce an import and does help make it more 
clear than using connect. I'd be in favor of changing it to this.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: dbsettings, and user configurable app settings

[Brian Rosner]

On Mar 10, 2010, at 7:16 AM, Joan Miller wrote:

> It's a disaster from the maintenance view point. If it were not so,
> then people would not be proposing to refactor the settings as has
> been made in Pinax, or from multiple posts so many times.

Like I mentioned in the post you made to the pinax-core-dev mailing list the 
problem Pinax is trying to solve is *not* because the settings are written in 
Python, but rather loading order and scope. Many projects quickly realize that 
running a Django project with a single settings file is nearly impossible with 
different environments all interacting with a single code base. Some projects 
turn to importing a local_settings.py file which is what Pinax currently does. 
This has worked wonderful for us for years. However, there has always been a 
scoping issue. It was difficult to easily change settings defined at the 
"global" level (this being project-wide settings that are environment 
agnostic). You'd have to copy them to the local_settings.py and add in extra 
values or remove existing values. One approach to solve this problem is to flip 
the loading order (imports happen at the settings.py level including the 
project level settings). While this works it presents a problem to usability. 
It would require an extra step on behalf of the user to either copy or create a 
missing settings file to run. This was a non-starter in Pinax since a 
fundamental goal is to get up and go once you've created the project. We've 
ultimately ended up on the solution Carl gave which can be read on our mailing 
list.

I don't see how your YAML configuration solves any of these problems. You'd 
have to create a similar mechanism with where you parse YAML files and then you 
are solving the same problem we are. If there is a solution you have in mind 
that magically solves everyone's problem nicely then present that instead of 
hand waving.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Brian Rosner]

On Apr 30, 2010, at 9:06 AM, Jeremy Dunck wrote:

> Does anyone have crib notes on what upgrading from (presumed) 0.10.4
> to 0.11.7 would buy us?  If not, I can go read changelogs.
> 
> Separate from that, I'd like to open discussion on what it would take
> to do the upgrade.
> 
> Who has access to the server?  What do I need to do to convince to let
> me upgrade?

I've volunteered off-list by speaking to Jacob. We were supposed to meet up
this week, but haven't made contact yet. I do plan on helping/performing the
upgrade to 0.11.X. I do not yet know what it will take.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Static media handling - ticket 12323

[Brian Rosner]

On May 27, 2010, at 9:23 AM, Luke Plant wrote:

> A Django 1.3 proposal.  It is a pretty small feature/change in some 
> ways, but needs some discussion.
> 
> = Motivation =
> 
[...]

I am on board with the motivation here. The reasons given are exactly why
we made a similar change to Pinax.

> = Options =
> 
> We could:
> 1) add 'STATIC_URL' and use it for widgets and all other media.
> 2) add 'USER_MEDIA_URL' and 'USER_MEDIA_ROOT' and use them for file 
> storage.

I am torn between these two. I am in favor of both to some extent. I like the
direction of being more clear about which is used by FileFields. On the other
hand calling the static resources for a site STATIC_* seems the most correct
to me.

Of course Pinax had to take some direction and since we couldn't go changing
all the FileFields of the world we had to introduce new settings. My stance
would definitely favor option 2 for the added clarity it provides. Pinax could
end up with best of both worlds ;-)

> (using backwards compatible defaults either way).
> 
> If 1), then, additionally, do we need 'STATIC_ROOT' as well?  What 
> for? It wouldn't be used anywhere in Django.

For Pinax we added STATIC_ROOT because we support a command called
build_static which collects static files from apps and writes them to
STATIC_ROOT. It has worked *extremely* well for us, but I don't think you
are looking at going this far yet. If so, under option 2 essentially
MEDIA_ROOT could serve that purpose. However, going with option 2 would make
MEDIA_ROOT obsolete until something like this is added? Might make that a bit
tricky.

> I strongly suspect that static media are far more common than user 
> uploaded files, so doing 2) will require far fewer changes to existing 
> apps.  Also, I suspect that almost all direct use of MEDIA_URL in apps 
> will be for static media: file fields provide a URL attribute which 
> automatically includes MEDIA_URL, but it will be common to use 
> MEDIA_URL for calculating URLs (e.g.  in templates).

This is a decent assumption as when I went through my code to move to
STATIC_URL it was largely changing all MEDIA_URL references.

> Also, use of 'media' for static media is consistent with 
> ADMIN_MEDIA_PREFIX, which is lost with option 1)

Good point.

> Finally, once these things are sorted out, is this a small enough 
> change that I should go ahead and commit it, or should I wait for 
> voting on Django 1.3 features?

I suppose this is dependent on whether we want to introduce app media handling
or if we want this to separate from that. In my opinion I can see them as two
different bits that be done independently.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Static media handling - ticket 12323

[Brian Rosner]

On May 27, 2010, at 5:27 PM, burc...@gmail.com wrote:

> Hi all,
> 
>> - a media files path resolver -- following a similar directory structure as 
>> the app templates loader (/media/ vs. /templates/)
>> - build_static -- a mangement command that'll collect media files from apps 
>> from various locations using the media files path resolver and uses a file 
>> storage backend to copy (or link to) the found files (file storage backend 
>> by default), used during deployment
>> - an extended media file serving view that uses the media files path 
>> resolver (in debug mode), backwards compatible replacement for 
>> django.core.servers.basehttp.AdminMediaHandler
> 
> Couldn't agree more. But three more points:
> 1) Media files are linked from applications forms, so what will happen
> if user rename an app?

If someone changes the name of the app there is no way they will get by
without modifying source code in the app. Why should this be any different?
I wouldn't really buy the argument that it reduces the amount of change they'd
have to do. It applies to the convention people use when storing/referencing
templates too.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

empty PATH_INFO env var

[Brian Rosner]

I wanted to bring up some discussion here about an empty PATH_INFO
value.  The ticket #3414 also reports this problem.  I attempted to
see how to patch it, but the problem seems to be more than meets the
eye.  I can't just test for an empty value in request.path and append
a slash and then let it redirect since the next request will still
report an empty value for PATH_INFO and turns into an infinite
redirect loop.

I searched on Google and came across RFC 3875 4.1.5 located at
http://www.ietf.org/rfc/rfc3875.  It describes the CGI/1.1 protocol
and allows an empty value for PATH_INFO.

What are other people's thoughts on this?


--~--~-~--~~~---~--~~
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: Uploading pictures problem

[Brian Rosner]

On 2007-05-11 14:09:06 -0600, Martin Tomov 
<[EMAIL PROTECTED]> said:

> 
> I am making a photo gallery as a project from school and I got stuck
> on the uploading picture part of it. Initially I started with the
> oldforms and I successfully uploaded pictures. But I have 2 questions.
> So I have this code:
> 
> if request.method == 'POST':
> # If data was POSTed, we're trying to create a new Place.
> new_data = request.POST.copy()
> new_data.update(request.FILES)
> 
> OK, here is the part where I want to take the name of the picture,
> rename it with its corresponding ID[dot]the_extension and save it in
> the table. I think that they are 2-3 lines of code, but i don't know
> the functions.
> 
> 
> Secondly, I want to ask if that:
> new_data["user"] = User.objects(id=1)
> is the right way to populate the user column in the very same table
> ( again with the oldforms ).
> 
> And lastly - is there a way to upload pictures with the new form
> engine.
> Thanks !
> 
> 
> 
Please direct these type of questions to django-users.  django-devel is 
used for discussion about the internal development of Django itself and 
not usage questions.
-- 
Brian Rosner
http://www.brosner.com/blog



--~--~-~--~~~---~--~~
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 releases

[Brian Rosner]

On Jun 7, 2008, at 1:06 PM, Jacob Kaplan-Moss wrote:
>
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- here's the controversial part -- make
> newforms-admin an "optional" part. If it's done, awesome; if not,
> include it in the next release. The current admin has some bugs, yes,
> but it's usable enough. As long as we advertised that it's on the way
> out we shouldn't have too much trouble.
>

+1. I think this needs to happen to the Django release cycle in  
general. I think it is a good way to keep developers motivated to  
complete features and continually get releases out the door. The  
Django trunk needs to be place were we can dump these features and get  
constant feedback from the community of those who want to keep up with  
the bleeding edge.

newforms-admin only has a few "absolutely have to have done before a  
merge" items IMO. The rest of the nfa-blockers can be dealt with on  
trunk. It is already a big enough backward-incompatible change that  
people will be having to do the changes or wait to find time. I think  
that newforms-admin needs to land as soon as possible. The whole idea  
of newforms-admin has been accomplished. The admin is using newforms.  
There are a ton of hooks. The rest can be worked on with the full  
Django core team and the many contributors in the community.

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: #5731

[Brian Rosner]

On Jun 11, 2008, at 11:11 AM, Jeff Anderson wrote:

> Joseph Kocherhans wrote:
>>
>> Commented. http://code.djangoproject.com/ticket/5731#comment:7
>>
>> You might want to hop on #django-dev on irc.freenode.net to ask Brian
>> (brosner) if he's looked at it recently since the ticket is still
>> assigned to him.
>>
> It looks like he assigned himself this morning-- I had the ticket  
> loaded in my browser since last night.
>

I did. I am planning on working on this today.

> Since you say yank the old code, it looks like the only thing left  
> is to make an up-to-date unified patch, and commit.

There is a bit more to it than just that unfortunately. The code is  
dependent on a patch from another ticket. I need to investigate this  
and see what can be done to just get it included in newforms-admin. I  
plan on doing that today. If you can get a unified patch on there that  
would be great. If not no worries.

>
>
> I'll hop onto IRC and see if brosner is there.

I am there if you want to discuss further. :)

>
>
> Thanks!
>
>
> Jeff Anderson
>

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: RFC: Django 1.0 roadmap and timeline

[Brian Rosner]

This hits the nail right on the head. +1 from me.

On Jun 11, 2008, at 8:03 PM, Jacob Kaplan-Moss wrote:

> 2. Replacement of ``oldforms`` throughout Django.
>
>   Nothing in Django 1.0 should rely on the deprecated ``oldforms``  
> package.
>   We'll need to replace ``oldforms`` usage in generic views, and in
>   ``django.contrib.auth``

Just wanted to point out that the newforms-admin branch has already  
ported django.contrib.auth to newforms.

> * A big fucking party.

A *really* big fucking party ;)

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
-~--~~~~--~~--~--~---

Admin media handling #7129

[Brian Rosner]

Hello,

I need to draw some quick attention to media handling in newforms- 
admin. Ticket #7129 [1] was opened with the intension of the old  
admin's behavior with the js inner Admin option. The trunk  
documentation states:

If you use relative URLs — URLs that don’t start with http:// or / —  
then the admin site will automatically prefix these links with  
settings.ADMIN_MEDIA_PREFIX.

However with the use of the new Media class the default behavior of  
relative paths will prepend settings.MEDIA_URL. I am wondering if the  
change to force an explicit prepend of ADMIN_MEDIA_PREFIX is now the  
requirement on newforms-admin? Should the admin handle media slightly  
different or should there be note in the docs about this? When the  
media handling code landed there wasn't any docs in regard to the  
admin specific handling of media, it was just implied from the regular  
media handling code for newforms.

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

Thanks,
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

[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: more DDN Tickets

[Brian Rosner]

On Wed, Jun 25, 2008 at 9:42 AM, Joseph Kocherhans <[EMAIL PROTECTED]>
wrote:

> More discussion is needed, but it seems like we're at a point where we
> should be discussing a list of possible options. I forget what all of
> them are, but maybe someone can write them up and post them here?


Yes. Let me do that today along with my opinions :)

-- 
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 Admin - Overriding the Save Method of a ModelForm

[Brian Rosner]

On Jul 2, 2008, at 9:08 AM, John Boxall wrote:
>
> But in NFA - it seems the save method isn't called!
>

It works for me. If the print statement is not working then see about  
tracking it down and post a detailed ticket with what is happening.  
Also you will want to make sure you are returning the value from the  
super call. The parent save method will return an instance that is  
needed else where in the newforms-admin views.

A quick side note, it is best to ask these question on the django- 
users mailing list. django-developers is meant for the development of  
Django.

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: Shared declarative syntax in both ModelAdmin and ModelForms.

[Brian Rosner]

On Jul 6, 2008, at 4:36 PM, Yuri Baburov wrote:

> At least they have or might have in common:
> * editable fields
> * readonly fields
> * fields display order
> * associated model
> * inline subforms
> * dynamic choices
> * widgets
> * widget resources: css/js files
> * validators and validation
>
> The idea is that they have lots of similar functionality, so we can
> borrow ideas and implementations from one form and apply them to
> another form and so make both things better. And if they will use same
> words for same declarative features, even better.
>

I think there is some confusion here. A ModelAdmin and a ModelForm are  
two completely different things. ModelAdmin classes define the  
functionality around a model in the admin (views, a form, and maybe  
some inlines). This happens to include a ModelForm, but surely *is  
not* a ModelForm. You seem to have jumped back and forth between what  
a ModelAdmin and a ModelForm provide.

Also, formsets (inline subforms, in your list) are already completely  
abstracted out and can be used standalone outside the admin. These are  
known as inlines in the admin.

I am not saying that this list is entirely bad. There are places in  
the ModelAdmin API that just plain need some fixing to get to the  
better granularity level that you can get with a ModelForm.

> Regarding implementation, I'd like to see admin form as a ModelForm
> with some specific options. If it's worth it, of course.

Not sure I understand what you mean here? A form representation of a  
model *is* a ModelForm.

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
-~--~~~~--~~--~--~---

newforms-admin Status Update

[Brian Rosner]

Hey all,

I wanted to quickly update everyone on the status of the
newforms-admin branch. It is quite literally a few tickets away! I
have either fixed or triaged many tickets today so that the branch can
get merged into trunk. The tickets triaged really shouldn't have been
made blocker tickets and since we are rapidly approaching the 1.0
alpha they can be looked at after the merge to trunk.

There are couple of tickets I want to get some opinions on.

#5490 [1] - The patch has been marked ready for check-in, but to me
something doesn't feel right with the patch. The patch introduces
URL_SAFE_CHARACTERS in django.utils.http and is used in the admin by
passing it in as the safe keyword argument to urlquote. Wouldn't it
seem reasonable to just make it the default value of safe?

#5780 [2] - Honza and Joseph have been looking at this. While this
seems reasonable, it seems to involve a lot more than just what the
patch does. Ideally all the save functionality is refactored in
ModelAdmin a bit to allow for commit=False behavior. Should this still
be considered a nfa-blocker?

#7353 [3] - I am not exactly sure what this ticket is trying to say
that is wrong with newforms-admin? AddManipulator no longer exists as
functionality code with the branch. Could someone give a bit more
information to get this fixed or just close it.

Other than those, I have the remaining tickets as WIP locally. They
will be finished tomorrow.

The documentation is pretty much done. I would like for people to give
it some attention and shake out any problems. Not a big deal and can
be dealt with after a merge. The tutorial needs a bit of
newforms-admin love. I haven't touched it due to the sensitivity of it
so if Adrian or Jacob can take a whip at that that would be great!

The branch has seen a lot of usage and I don't think it needs a call
for testing, but for those who would like to test it now is that time.
Please bang on it and report bugs in Trac.

[1]: http://code.djangoproject.com/ticket/5490
[2]: http://code.djangoproject.com/ticket/5780
[3]: http://code.djangoproject.com/ticket/7353

Thanks,

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-admin Status Update

[Brian Rosner]

On Jul 15, 2008, at 10:50 PM, Brian Rosner wrote:

> The documentation is pretty much done. I would like for people to give
> it some attention and shake out any problems. Not a big deal and can
> be dealt with after a merge. The tutorial needs a bit of
> newforms-admin love. I haven't touched it due to the sensitivity of it
> so if Adrian or Jacob can take a whip at that that would be great!
>

I have created a ticket [1] for this.

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

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 admin: Validator for ModelAdmin classes broke my admin

[Brian Rosner]

On Jul 17, 2008, at 4:26 AM, Ross Lawley wrote:

> Hi all,
>
> The recent changes in newforms admin r7529 changed the validation  
> for newforms admin models.  However, it is a bit too strict and  
> doesn't allow customizable admin forms to output non model fields.
>
> I've added a patch with tests to: http://code.djangoproject.com/ticket/7790 
>  - which also checks against any explicitly declared forms.
>
> Please can some one review?

Yes. Good catch. I will take a look today and get it fixed.


--~--~-~--~~~---~--~~
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-admin branch has been merged into trunk

[Brian Rosner]

I have just recently merged the newforms-admin branch into trunk as of  
r7967 [1]. This is an extremely backward incompatible change. The  
entire admin application in contrib has been refactored. The newforms  
module has a few new features, but those changes are backward  
compatible. The branch also converted django.contrib.auth to use  
newforms. I have documented these changes in the usual place [2].

I would like to thank Karen Tracey for her tremendous work triaging  
tickets, finding the root of problems and supplying patches where  
needed. Also, on behalf of the core developers involved with the  
branch we would like thank everyone who has tested the branch and  
reported bugs. Without your hard work and contribution we couldn't  
have made Django this much better without you! Thanks.

Bugs should no longer be marked with version 'newforms-admin' as the  
branch is now closed.

Onward to 1.0!

[1]: http://code.djangoproject.com/changeset/7967
[2]: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges


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: Use admin.autodiscover() by default?

[Brian Rosner]

On Jul 19, 2008, at 2:08 AM, James Bennett wrote:

> Adding 'admin.autodiscover()' to the project's root URLConf fixes
> this; normally I'd just check in a quick change to the tutorial to
> indicate that this should happen, but it feels to me like the right
> thing to do here is instead tweak the project template so that line is
> in the default URLConf (but commented out like the rest of the admin
> stuff), at which point the tutorial can simply stay as-is.
>
> Thoughts?

Yeah, I agree that this should be done. I originally took the stance  
that it might be an uncommon thing since most people might want a  
custom AdminSite instance, and boy was I wrong ;)

Tweaking the tutorial would be a good idea too. Give a bit of  
information about it would be a good thing.

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: Installing alpha over 96.x?

[Brian Rosner]

On Jul 21, 2008, at 12:17 PM, Karen Tracey wrote:

> I just tried installing current svn (via setup.py) on a machine  
> where I had previously installed 0.96.2.  Install works but I notice  
> that there are files (contrib/admin/urls.py, contrib/admin/utils.py  
> are two I knew to check for) that used to exist in the old version  
> but have been deleted in current -- these files are still present in  
> the django directory under site-packages after installing current on  
> top of 0.96.2.
>
> Might these leftover files cause a problem?  I fear we are going to  
> run into mutant problems with leftover files like this.
>

django/admin/urls.py can lead to some difficult to debug migrations.  
utils.py I wouldn't worry about, but if we are at it trying to get rid  
of one, mind as well do both.

> Should we document somewhere how people who have previously  
> installed a release should delete the old release before installing  
> a new one?

Whatever it would take to remove those would be really ideal.

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: Ability to delete contents of FileField and ImageField in admin

[Brian Rosner]

On Mon, Aug 18, 2008 at 7:30 AM, David Reynolds
<[EMAIL PROTECTED]> wrote:
> I notice some discussion about this from a while back but as far as I
> can tell it has all gone quiet. This may be because it has been
> fixed, or possibly because it has been forgotten about. Can anyone
> give me a status update of whether or not it is possible to delete
> the contents of a FileField or ImageField from within the admin?

Keep an eye on http://code.djangoproject.com/ticket/7048.

-- 
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: initial data for inlineformset_factory

[Brian Rosner]

On Tue, Aug 19, 2008 at 12:10 PM, patrickk <[EMAIL PROTECTED]> wrote:
>
> any reason, why it´s currently impossible to use "initial" with
> inlineformset_factory. is it planned to integreate this feature?

I guess I am failing to see how this is useful? initial data in an
inline model formset is based on the queryset such as it is a subclass
of model formset. Could you provide a use case where it might be worth
it to also provide initial data for an inline model formset? It would
seem that a default value on a model field would be sufficient. Seems
a bit overkill for the general case due to the unknown size of the
queryset.

-- 
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: BaseModelFormSet and ModelForm.instance

[Brian Rosner]

On Wed, Aug 20, 2008 at 12:57 AM, Justin Fagnani
<[EMAIL PROTECTED]> wrote:
> I'm not sure what parts of BaseModelFormSet are considered official
> API. In the patch ModelForm.save() is now called by
> ModelFormSet.save(), and I think the methods save_new, save_existing,
> save_existing_objects, and save_new_objects are no longer needed.

I sort of wonder myself too. I think it might definitely introduce
some breakage. But ultimately this fixes formsets to work more
naturally which is good. I am slightly unclear on what is allowed to
be broken in this phase of Django development. I suspect it is okay
since those methods are not explicitly documented and a quick note on
the wiki would be decent. Someone please correct me if I am wrong, but
will make this item post-1.0.

> I don't think get_queryset is needed either.

This however I just don't understand. What is the reasoning for this
change. Removing the method will certain break code and is documented,
but it seems the patch doesn't need this to be removed. I see there is
no need for in the save stage, but surely can still be used as an
extensibility hook. Passing the queryset directly in as initial data
has problems too and needs to be ran through model_to_dict to fix
those issues. I don't see why that needed to be removed.

>
> I know it's a rough patch, so any advice on how to improve it, or what
> tests to add?

Just out of curiosity do the tests pass with your patch? If so, I
suspect the coverage isn't good enough ;)

-- 
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: BaseModelFormSet and ModelForm.instance

[Brian Rosner]

On Wed, Aug 20, 2008 at 12:57 AM, Justin Fagnani
<[EMAIL PROTECTED]> wrote:
> ps. The *_factory methods seem odd to me. I wonder why metaclasses
> weren't used here, but I understand that it's to close to 1.0 change
> anything.

Ah, missed this in the first e-mail. There was an effort to do this,
but failed miserably. It may be revisited again, but IMO providing a
declarative syntax to everything in the world doesn't fix the world ;)
It simply would provide a better API for users which I understand is
good. However, the factory function do provide functionality in places
where things need to be dynamic. The admin relies on them heavily. If
in any event we do go about a declarative syntax it would need to be a
subset of the factories. However, right now I am -0 on introducing
them since to me adds cruft to formsets. At any rate it would
certainly be a post-1.0 if we did decide to so something.

-- 
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: BaseModelFormSet and ModelForm.instance

[Brian Rosner]

On Wed, Aug 20, 2008 at 11:42 AM, Justin Fagnani
<[EMAIL PROTECTED]> wrote:
>
> On Wed, Aug 20, 2008 at 8:39 AM, Brian Rosner <[EMAIL PROTECTED]> wrote:
>> I am slightly unclear on what is allowed to
>> be broken in this phase of Django development. I suspect it is okay
>> since those methods are not explicitly documented and a quick note on
>> the wiki would be decent. Someone please correct me if I am wrong, but
>> will make this item post-1.0.
>
> I could rewrite the patch to preserve those methods, but it'd be a lot
> less elegant. I could see the argument that save_existing_objects(),
> and save_new_objects() are useful in some ways.

One thing that I may have missed, but how are you dealing with
save_new in BaseInlineFormSet? From a quick glance that would seem
broken.

> Yup, the tests pass. If I'm looking in the right places, the coverage
> seems pretty bad. ModelFormSets and InlineFormSets are not tested at
> all.

Did you look at
http://code.djangoproject.com/browser/django/trunk/tests/modeltests/model_formsets/models.py?

>
> Do you have a suggestion for not passing a queryset as the 'initial'
> argument to FormSet? I'm thinking that either the queryset is
> translated to a list of dicts like before, so the forms will have both
> an instance and initial data, or BaseFormSet.__init__() should be
> broken up so that _initial_form_count is set in another method that
> can be overridden. I like the later.

I think the better solution here is to keep the __init__ code the same
but we need an instance level of the queryset persistent so we can use
the use the caching it would provide. Then use the the indexing like
you have with i local variable in _construct_form.

-- 
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: Please force ticket 8367 to inclusion.

[Brian Rosner]

On Fri, Aug 22, 2008 at 2:26 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> Hi core devs,
>
> could you please force http://code.djangoproject.com/ticket/8367 to
> include into 1.0 asap?

Please don't do this. The ticket is marked as 1.0 and is accepted. It
will get into 1.0.

-- 
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: Altering data uploaded to FileField before save is called

[Brian Rosner]

On Wed, Sep 10, 2008 at 8:13 AM, shadfc <[EMAIL PROTECTED]> wrote:
> The problem is that FieldFiles get saved to the storage backend even
> on a save(commit=False), and (according to a more knowledgeable SeanL-
> on #django), the FieldFile will only get saved once, the first time
> through.  So the only way I can accomplish what I want is to do two
> saves to my backend -- one when the formset is saved with commit=False
> and then I must call the storage backend's save() directly in order to
> upload the changes I've made to the mp3 file in memory.

Ouch. In a formset sounds like you could be calling save up to N*2 times.

> I think that the commit=False (or save=False in FieldFile.save() )
> should not do the save to the storage backend.

Agreed. I have been considering treating FileFields the same as
many-to-many fields when commit=False in a ModelForm. In the event
that commit=False a new method is available to perform the file saving
explicitly. This would help in the event of wanting to name the file
the same as the primary key for instance.

>
> Another option might be to pass the save argument along to the storage
> backend and give the backend designer control over the behavior --
> perhaps to reserve a filename in a cache with a short ttl.  This would
> still require that the save() on FieldFile be called more than once
> though.

We need to avoid calling save on a file backend as much as possible.
That operation may be very expensive.

Go look for a ticket about this. If there isn't one I would say report
one. This seems like a reasonable thing to do in general.

-- 
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: Altering data uploaded to FileField before save is called

[Brian Rosner]

On Wed, Sep 10, 2008 at 8:50 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> I agree with what you're saying, but wouldn't changing whether the file is
> saved when commit=False be a backwards-incompatible change?  Do we need to
> preserve current behavior for backwards-compatibility sake and find a way to
> enable the desired behavior going forward?

Yes it would be backward incompatible. I haven't thought this all the
way through, yet. In general the solution I proposed is the ultimate
fix. For a fix like this I still need to get grips on what exactly the
process for this is going to be and when exactly it can be
implemented. A less than ideal way of accomplishing this now in user
code if they need to do this now is to override save on the ModelForm
and use their own save_instance function, but seems to be the best way
avoiding some other really ugly hack and make going forward much
simpler.

-- 
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: 1.0.1 release blockers?

[Brian Rosner]

On Tue, Nov 11, 2008 at 5:02 AM, Daniel Roseman
<[EMAIL PROTECTED]> wrote:
>
> Sorry to bring this discussion back to the original topic...
>
> http://code.djangoproject.com/ticket/9498 is a pretty serious
> regression for us, which will prevent us upgrading to 1.0.1. There is
> a patch, and I've just added some tests - is there any chance this
> will make it into the release?

Notice how I have not only marked the issue accepted, but I assigned
it to myself. I would think that is a decent indication that this is a
serious issue considering things are broken and that it will make the
release :)

-- 
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: Dropping Python 2.3 compatibility for Django 1.1

[Brian Rosner]

On Tue, Nov 25, 2008 at 10:08 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> Hi folks --
>
> I'd like to officially drop Python 2.3 support in Django 1.1. Discuss.

+1. This needs to happen. Python 2.3 is getting pretty old and I would
imagine that most people have at least 2.4 available to them or they
can hang out in 1.0 land until they are able to upgrade. Remember
PyCon 2008? :)

-- 
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: Distributed workflow and the woes of slow testsuite

[Brian Rosner]

On Mon, Jan 12, 2009 at 5:53 AM, mrts  wrote:

> What if we try to be nice to ourselves and get #8138 and something in
> the lines of http://oebfare.com/blog/2008/mar/25/faster-django-test-suite/
> into trunk ASAP, especially now that the dynamic workflow is really
> gaining ground (both aggregates and model-validation is managed this
> way)?

I am all for a faster test suite and #8138 is going to give us a nice
speed boost, but my test runner is not ultimately a great way to go at
this point. It would require the processing library thus making it
really only viable for those running Python 2.6+. While it can be made
optional, that is what it is now. I am all for its inclusion, but lets
wait until it becomes, first, more stable (used by more people than
me), and two, more people can actually take advantage of it out of the
box.

-- 
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Sanity check #8306 (cleaning up formfield_for_dbfield), please

[Brian Rosner]

On Thu, Jan 15, 2009 at 2:56 PM, Jacob Kaplan-Moss  wrote:
> I'm pretty happy with the approach, but honestly I don't use the admin
> all that hard so I'm not 100% confidant that the design is perfect. So
> I'd love a quick review of the latest patch on #8306 (also available
> on github: 
> http://github.com/jacobian/django/commits/trac/8306-admin-field-overrides).

I think this definitely the right direction. An outstanding admin
ticket that this is touching very heavily on is #3987. You've done a
really good job making the right abstractions. I went a step further
and figured this should be included as it does change the method
signature [2].

[1]: http://code.djangoproject.com/ticket/3987
[2]: 
http://github.com/brosner/django/commit/d6c0a47be4a2ea7743c9e90a4accd43993b4f5bd

-- 
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

#5903 DecimalField returns default value as unicode string

[Brian Rosner]

Hey all,

I recently came across the issue described in #5903 [1] earlier. There
are two distinct patches that fix the problem, but at different
levels. My inclination is to fix this issue at the model field level
and properly override get_default. My feeling is that allowing Decimal
objects to pass through force_unicode (when strings_only=True) might
cause ill-effects in other parts of Django, but I am not entirely sure
(running the test suite with the fix in force_unicode didn't cause any
failed test, but that doesn't make it right to me :). I don't see much
reason to do so. Perhaps someone can shed some light on this?

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

-- 
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: New transaction API with multiple databases

[Brian Rosner]

On Mar 13, 2009, at 4:51 PM, Adrian Holovaty wrote:

> * Transactions are managed via methods on connection objects. NOT via
> some strange decorator and magic global django.db.transaction variable
> that comes out of thin air.

I agree that the global functions are not anything to write home  
about. However, I disagree that the decorators need to be written off  
so quickly. I like the idea that transaction management can be done on  
this new connection object. I see the decorators are still useful and  
I use them all the time. They can be modified to not only work on the  
default connection, but couldn't they take a connection as an argument?

@transaction.commit_on_success(conn)

When no arguments are given it can simply fallback to the default  
connection. The decorators provide, IMHO, a quick way to wrap a  
function in some sort of transaction scheme that work really well.

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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Patch status for ticket #9122

[Brian Rosner]

On Mar 19, 2009, at 5:47 PM, Preston Timmons wrote:

> Might somebody be able to review the patch and tests for this ticket
> to see if they are acceptable? I am hoping it can get in as a bug fix
> for 1.1. If something is lacking here I would like to try to fix it.

The patch looks generally acceptable. I'd like to see some  
documentation on it. I will definitely review this in time for 1.1.  
Thanks for the heads up.

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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC Status update (week 2) - HTTP & WSGI Support

[Brian Rosner]

On Fri, May 1, 2009 at 12:10 PM, ccahoon  wrote:
> I have also been looking in to how I want to do revision control
> locally. After playing around with various systems, I think I've
> settled on Git. Does anyone have any recommendations for local
> revision control? Is using anything other than Subversion locally
> overkill for my purposes?

I don't think it is overkill because you start getting in the habit of
working locally it becomes quite empowering. If you do decide to go
with Git be sure to take a look at
http://github.com/django/django/tree/master where you can fork from
and keep your local repository in-sync with upstream changes.

-- 
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC Status update (week 2) - HTTP & WSGI Support

[Brian Rosner]

On Fri, May 1, 2009 at 1:17 PM, Malcolm Tredinnick
 wrote:
> Given that Summer of Code students will be given a subversion branch at
> djangoproject.com to commit to -- in order to provide maximum visibility
> for their work within the community -- it's probably worth just using
> git-svn and pulling from the upstream repository, even initially.

Ah, I completely forgot about the GSOC SVN branches. I, too, would
recommend the usage of git-svn.

Chris, shoot me a direct e-mail if you would like a clean and in-sync
git-svn repo of Django's SVN. Should save you a few hours of time.

> As always, there are multiple approaches and I don't want to slight or
> invalidate Brian's experiences. It's definitely a case of doing whatever
> works easiest for oneself and trying out a few options initially is
> encouraged, too.

Agreed.

-- 
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Can we use a django application class?

[Brian Rosner]

On 2007-05-29 05:43:08 -0600, Ahmad Alhashemi 
<[EMAIL PROTECTED]> said:

> 
> Hello,
> 
> Right now, django applications are strange creatures. They are python
> packages with some magic. They have to have a "models" module.
> Everything else is free form. We have strong conventions like urls.py,
> maybe admin.py, but they all have to be explicitly called and used in
> the project.
> 
> How about creating an actual class for django applications. This way
> django applications can be actual objects instead of just being
> magical python packages. We can make it a convention to put the djagno
> application object in the __init__.py module of the package. We can
> then use this class to add various functions related to other parts of
> djagno, like defining application specific url patterns and admin
> objects.
> 
> Imagine something like this:
>   from apps.weblog import weblog_app
>   INSTALLED_APPS = (weblog_app, )
> 
>   from apps.weblog import weblog_app
>   urlpatterns = patterns('',
>(r'^weblog/', weblog_app)
>   )
> 
> This will also be the natural place to add any future functionality
> and still be backwards compatible. In contrib.admin for example, we
> can easily take a look into weblog_app and see if it defines an
> "admin" property or not.
> 
> It makes the application less magical because we don't have to have a
> "models" module any more, it makes applications more self contained,
> it adds the ability to expand application features in the future.
> 
> The __init__.py file of the application will look something like:
>   from . import models, admins, urls
>   from django.somewhere import Application
>   weblog_app = new Application()
>   weblog_app.models = models
>   weblog_app.admins = admins
>   weblog_app.urls = urls
> 
> 
> 
I like this idea, but really doesn't solve much in the common case.  It 
provides for more modularity of an app and offers the ability to make 
things feel even more Pythonic.  However, most things can be solved by 
using custom settings in settings.py and just knowing how to make a 
module work right.

One thing this makes me think of is allowing custom display names for 
applications.  Currently there is no way to mark application names for 
translation (that I know of).  This is a solution that can work in a 
more modular way than making INSTALLED_APPS a dictionary for example.

-- 
Brian Rosner
http://www.brosner.com/blog



--~--~-~--~~~---~--~~
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: GSoC 2007 - Object-Level Caching

[Brian Rosner]

On 2007-05-29 01:37:50 -0600, Paul Collier 
<[EMAIL PROTECTED]> said:

> 
> Hello all!
> 
> Continuing with the string of posts regarding this year's GSoC, I'm
> pleased to be working on new caching functionality for Django's ORM
> under the mentorship of Gary Wilson[1]! Big thanks to him and all the
> people from the community who made this possible. Now I've just got to
> hold up my end of the bargain ;)
> 
> An updated version of my original proposal is available on Django's
> wiki[2] and the project repository is available from Google Project
> Hosting[3].
> 
> This project aims to condense common caching idioms into simple
> QuerySet methods that deal with cached data intelligently, refill
> expired cache, track instance modification/deletion, descend through
> relationships, and so on. I've tried to make it accommodate the most
> common use cases, be it dumping front-page news articles to cache or
> keeping user profile data on hand when rendering a more dynamic site,
> but I'd definitely love to hear about how cached data is really used
> out in the field.
> 
> Currently, three QuerySet methods, .cache(), .cache_related(),
> and .cache_set() handle individual, relation, and aggregate data
> caching, respectively. Each can take arguments to specify options like
> expiry time. Signals are registered behind the scenes to sync the
> cache, and there's also a proposal for transactional caching. Generic
> relations will also benefit greatly from .cache_related().
> 
> More detail is available on the wiki page, but lots of the little
> issues that surround the implementation are still bouncing around in
> my head; the page is going to be expanding and mutating throughout the
> next few months, I'm sure. The timeline is a little underdeveloped,
> for one. Comments and criticisms are always welcome!
> 
> The project itself is currently a single module which has a class
> derived from QuerySet with all of the new functionality, and a little
> hack to inject the .cache(), etc methods right back into QuerySet. It
> also ships with a project in which I'll be writing proper tests. Some
> sort of miniature cache-testing framework may be in order too.
> Eventually, perhaps it'll become fit for inclusion in the Django
> proper--but either way it doesn't require a huge amount of core
> modification.
> 
> I'm also curious about the progress of QuerySet refactoring, which
> would understandably have a huge impact on the code I'm writing.
> Either way, this new code applies directly to a Django project I've
> been working on for the last while, so I have the motivation to
> maintain this project wherever it may go!
> 
> Thanks,
> Paul Collier
> 
> [1] http://gdub.wordpress.com/
> [2] http://code.djangoproject.com/wiki/ObjectLevelCaching
> [3] http://code.google.com/p/django-object-level-caching/
> 
> 
> 
It looks like you are working some really neat stuff Paul!  I came 
across ticket #17 last week and thought it was an interesting ticket 
and started through some prototyping.  It seemed to be in my 
prototyping that the project you are working on sort of overlapped some 
of my ideas.  It appears to actually be two different things, but kind 
of not.

#17 looks like it tries to solve having multiple instances of the same 
object in memory.  When thinking about implementing this it starts to 
work itself in to the QuerySet and how it would select an object since 
it would need to look into memory first then the database.

I guess what I am trying to get at is how does your project and ticket 
#17 corrolate, or better yet, is this something you thought of.  Your 
project seems to be when objects need to be cached over several 
requests which could mean multiple instances of Django in memory at 
different times.

-- 
Brian Rosner
http://www.brosner.com/blog



--~--~-~--~~~---~--~~
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-admin: queryset as list_filter

[Brian Rosner]

Adrian posted an idea that would actually be very neat and solve your
problem too.  Check out http://code.djangoproject.com/ticket/3987.  I
started some work on a better patch using the ModelAdmin hooks, but
don't think I will be getting it done very soon.  But a starting place
none the less ;)

On Jun 22, 12:00 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> I haven't been tracking the newforms-admin branch, so this may already
> be done, but I think it'd be a good idea to allow querysets (or Q's)
> to be used for list_filter.
>
> For example, I'd like to make it easy for an admin to see just the
> list of un-geocoded objects, which is where latitude == None (or
> similar).
>
> I think Q's are probably a better choice since they can be composed
> for multiple active filters (like pub_date and status).


--~--~-~--~~~---~--~~
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: #4418 - Newforms Media, ready for commit?

[Brian Rosner]

On 2007-07-09 09:45:34 -0600, "Russell Keith-Magee" 
<[EMAIL PROTECTED]> said:

> 
> Hi all,
> 
> Attached to #4418 is the latest version (v3) of the newforms Media
> patch. It incorporates some suggestions made before I disappeared on
> my grand adventure last month.
> 
> For those not keeping track, the idea of this patch is to enable a
> newforms widget to define the javascript/css that it requires; then,
> when a form is generated that uses that widget, it is possible to
> determine the minimum set of javascript/css that is required to render
> the form. More details on the ticket; example usage in the regression
> test.
> 
> Other than needing some documentation, I think this is pretty close to
> being ready for committal. At last count, Jacob was +1 to the idea,
> Malcolm said the idea was growing on him but he hadn't looked at the
> patch. Any feedback (especially objections to committing) would be
> appreciated.
> 
> Changes in this version of the patch:
> 
> - It handles https, as well as https absolute paths.
> 
> -  tags are closed with a  rather than being  tags.
> 
> - CSS definitions are now dictionaries, rather than lists. This allows
> for CSS for different media types. See the regression tests for
> examples of usage.
> 
> - Inherited widgets now inherit the media of their parents, unless overridden.
> 
> - MultiWidgets inherit the media definitions of their component widgets.
> 
> - Fixed a problem with the addition operator on Media objects.
> 
> I have also attached the same patch with some extra bits for the
> newforms-admin branch. With this patch applied:
> 
> - FormSets, FieldSets and AdminForms can be interrogated for media,
> just like Forms
> 
> - Any application can reference an 'AdminDateWidget' or
> 'AdminTimeWidget' and they will get all the javascript definitions
> required to render a pretty calendar/time widget
> 
> - Date/Time widgets now always appear on inline forms when required.
> Previously, they wouldn't be displayed unless the base form also
> required the widget.
> 
> Yours,
> Russ Magee %-)
> 
> 
This is an excellent patch and does solve many good issues as well as 
add some good new functionality.  One thing I want to point it is 
ticket #4398.  You might want to make sure that is also incorporated.
-- 
Brian Rosner
http://www.brosner.com/blog



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

choices being a QuerySet or callable

[Brian Rosner]

I have recently come across needing to have the choices of a 
django.db.models.Field be dynamic or atleast a callable.  I asked in 
the IRC room, but it turns out choices only accepts a iterable.  While 
an QuerySet is an iterable, it would end up caching the value of the 
returned values.  I don't know if a QuerySet will even work.  In my 
situation I am attempting to pass in a call to a function, but the 
returned value is then cached and won't be reloaded until the model or 
the server is reloaded.

I have found this ticket in Trac:

http://code.djangoproject.com/ticket/1891

I was wondering what everyone's stance is on inclusion of something like this.

-- 
Brian Rosner
http://www.brosner.com/blog



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

FormSets cleaned_data -> cleaned_forms

[Brian Rosner]

I am using the FormSet class found in newforms-admin for a site since 
it needed functionality that it offers.  The form that my users use 
lets them upload up to five files and an associated description.  I 
have this defined in its own model and use the following code to get it 
setup:

FlightFileForm = form_for_model(FlightFile, fields=('file',
'description'), formfield_callback=flightlink_formfield_callback)
FlightFileFormSet = formset_for_form(FlightFileForm, num_extra=5)

When it came time for me to commit this data to the database and save 
the file to disk I really had no reference to what forms to call save() 
on.  The BaseFormSet class gives me access to the cleaned data of each 
form, but not the actual form.  So now I am having to implement logic 
to do this myself.  While this isn't a big deal it would be nice if 
FormSets gave me cleaned_forms that I can iterate over and do what I 
need with each form that was used.

Any feedback?

-- 
Brian Rosner
http://www.brosner.com/blog



--~--~-~--~~~---~--~~
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: FormSets cleaned_data -> cleaned_forms

[Brian Rosner]

On 2007-08-29 10:45:07 -0600, Brian Rosner 
<[EMAIL PROTECTED]> said:

> 
> I am using the FormSet class found in newforms-admin for a site since
> it needed functionality that it offers.  The form that my users use
> lets them upload up to five files and an associated description.  I
> have this defined in its own model and use the following code to get it
> setup:
> 
> FlightFileForm = form_for_model(FlightFile, fields=('file',
> 'description'), formfield_callback=flightlink_formfield_callback)
> FlightFileFormSet = formset_for_form(FlightFileForm, num_extra=5)
> 
> When it came time for me to commit this data to the database and save
> the file to disk I really had no reference to what forms to call save()
> on.  The BaseFormSet class gives me access to the cleaned data of each
> form, but not the actual form.  So now I am having to implement logic
> to do this myself.  While this isn't a big deal it would be nice if
> FormSets gave me cleaned_forms that I can iterate over and do what I
> need with each form that was used.
> 
> Any feedback?

Actually this is better solved using the FormSet support in 
django.newforms.models.  My bad.

-- 
Brian Rosner
http://www.brosner.com/blog



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Discussion on #5721

[Brian Rosner]

I wanted to raise some discussion about the problem descibed in [1].  I 
also came across this and did something that made it work.  However it 
wasn't exactly a good fix.  I looked into the issue in depth and 
discovered some odd things.

inline_formset uses formset_for_model which ends up using 
form_for_model.  This works well for forms that are not bound to an 
instance.  To make forms with instances work in a formset there is a 
function called initial_data which returns a dictionary mapping field 
names to values of the given instance.  This is called in the __init__ 
method of BaseModelFormSet.  Then when the formset builds the change 
forms it uses the form class built with form_for_model.

The problem here is that django.db.models.fields.FileField's formfield 
method that is called through the formfield_callback is never able to 
make the field not required when there is initial data (which would 
have come from form_for_instance).  It looks like as it stands that 
formfield_callback functions will never be able to check if there is 
initial data in the form in change forms that are bound to an object.

I wanted to fix this, but it seems I am hitting a wall.  As I was 
trying to fix this I began to see some functionality overlapping with 
how generic foreign keys might want to integrate.

Basically, I was attempting to write a new function, 
formset_for_instance that would be given an instance and I just hard 
coded in the fetching of data which only works in my particular 
environment.  It would also use form_for_instance to create forms for 
just the change_forms.  Then I had to overload the _get_change_forms to 
make it all work, sorta.

I hope someone understands what I am getting at.  You can pretty 
disregard my implementation, but hopefully I have explained the problem 
well enough to warrent some ideas on how I might go about implementing 
something.

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

-- 
Brian Rosner



--~--~-~--~~~---~--~~
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: Discussion on #5721

[Brian Rosner]

On Oct 10, 7:38 pm, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote:
> On 10/10/07, Brian Rosner <[EMAIL PROTECTED]> wrote:
>
>
>
> > I hope someone understands what I am getting at.
>
> I do. You've pretty much discovered one of the reasons why I didn't
> try to write formset_for_instances or something similar in the first
> place. I just spent about a half hour thinking about it again and came
> to the same conclusions. If you want to come up with a patch, I'll
> definitely take a look and help try to iron it out, but as you've
> already discovered, it's tricky. FWIW I'm working on a replacement for
> form_for_instance that uses initial_data, but it'll probably be awhile
> before I finish it up.

Take a look at http://code.djangoproject.com/ticket/5733.  It is a
start.  Perhaps you could expand it out?  It doesn't seem to be 100%
complete either.

>
> The oldforms file widgets have 2 separate html inputs, a hidden one
> for the current file value, and second for the actual file input. I
> think getting the file widget/field to render and check for such a
> hidden field might be a cleaner and easier approach. The initial_data
> function may need to be tweaked slightly to get this to work. I don't
> remember what it does with file fields.

Yeah that is a much better way of doing it.  It seems that the
formfield methods in the database Field's classes shouldn't be messing
with initial.

>
> For instance, html for an oldforms file field looks like this:
>
>  name="photo_file" />
>  value="img/photos/2007/10/10/blah.jpg" />
>
> 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, sqlite3 and OS X

[Brian Rosner]

On 2007-10-11 17:10:30 -0600, jf 
<[EMAIL PROTECTED]> said:

> 
> Hi all, I am currently using Django on a project with a database of
> fairly large table sizes, and I have encountered a strange and
> potentially dangerous bug, of which I am not sure the cause. This is
> not really a bug report, as I haven't really had the time necessary to
> gather enough information to file an official bug report, but I would
> like to get some more expert opinions on the matter if I could.
> 
> Here goes: Using Django, I am inserting rather large amounts of
> records into an sqlite3 database on OS X v10.4.10. I have yet to
> perfect my Django development cycle, and so I spend a decent amount of
> time changing around models and recreating databases as I develop. At
> one point, after spending hours writing to the database, the python
> process had finished, however the database still appeared to be empty,
> except for the fact that the filesystem thought its size was ~53Mb.
> Not having time to investigate further, I deleted the database and
> decided to try again later. For a separate part of the project, I
> wanted to install matplotlib and pylab, and so I moved on to do this
> next instead. However, compilation errors abounded when I did so,
> namely that there were odd characters in my system and various other
> header files. When I looked at these files, they indeed appeared to
> binary, except for the fact that there were visible strings of ASCII
> text, which clearly came from the data I had been trying to insert
> into the database (strangely enough these were actually DNA sequences,
> but not from a virus).
> 
> I was able to restore the headers that I needed in order to compile,
> however, I have no idea what else on my system may have been touched
> by this. Days later I had a problem with import site every time I
> would start up python, and found another string of DNA had inserted
> itself into my Numeric.pth file. The difficulties so far have been
> easy enough to fix, but this is such a strange, and potentially
> dangerous problem, that I am cautious about writing to the database
> any further until I have identified its cause. I understand that this
> is likely a sqlite issue, but if anyone has any further insight it
> would be greatly appreciated.
> 
> Thanks!
> Jared
> 
> 
> 
Hey Jared,

Questions of this nature should be directed to django-users and/or one 
of the other projects as it sounds like your issue isn't 100% Django.  
django-dev is reserved for the development of Django itself.

-- 
Brian Rosner



--~--~-~--~~~---~--~~
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 couple of newforms-admin questions

[Brian Rosner]

On Oct 11, 12:03 pm, Karen Tracey <[EMAIL PROTECTED]> wrote:
> At 06:00 PM 10/10/2007, Joseph Kocherhans  wrote:
>
>
>
> > > >You're probably right. Something like radio_admin_fields on the
> > > >ModelAdmin class sounds reasonable. Could you file a ticket for this
> > > >so we don't lose track? I don't recall seeing one, but I could be
> > > >wrong.
>
> > > I couldn't find one either, so I opened one:
>
> > >http://code.djangoproject.com/ticket/5731
>
> > > I'll probably take a look at what's involved in doing it, but given
> > > my unfamiliarity with the code it's quite possible someone else could
> > > whip up a patch sooner.
>
> >Here's a hint that will hopefully help you (or anyone else really) get
> >started: this should probably happen in the formfield_for_dbfield
> >method of the ModelAdmin class.
>
> Upon further investigation I'm not sure a replacement for radio_admin
> is needed in newforms-admin.  It seems the capability already exists,
> since the user can supply their own custom widgets by overriding
> formfield_for_dbfield.  This thread shows it is already being done by
> some people:
>
> http://groups.google.com/group/django-developers/browse_thread/thread...
>
> It may not be as easy, and it may not be possible for the user to get
> it to look quite exactly like it did in the old scheme, but the basic
> capability exists.  So perhaps all that is needed is to remove the
> old radio_admin Field attribute?
>
> (Before I discovered this I did get it working by adding support for
> "radio_admin_fields" in a manner very similar to how "raw_id_fields"
> is done, and it's not a lot of code or anything too hairy.  But
> coming to newforms-admin without the legacy of the old way, I think
> I'd wonder why there's this "radio_admin_fields" special case when
> the design supports a more general and flexible solution.)
>
> Thoughts?
>

I haven't dug to deeply into this, but from the sound of it, the
ModelAdmin class will need the radio_admin_fields because the look and
feel of the widget in the admin will differ from the generalized one
provided by newforms.  This has been done with a few widgets and are
found in django.contrib.admin.widgets.  In terms of what Joseph meant
by the formfield_callback is to hook the fields defined in
radio_admin_fields through the ModelAdmin formfield_callback method to
hook it into an admin specific widget that subclasses the newforms
provided one to get the same look and feel the oldforms admin gives.

> 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: ./manage.py sqlreset --apply

[Brian Rosner]

There is no need for this. ./manage.py reset runs sqlreset.

On Oct 17, 11:58 pm, Derek Anderson <[EMAIL PROTECTED]> wrote:
> hey,
>
> what are thoughts on a new option to sqlreset (and others, as
> appropriate) to apply the change to the db?  something like this:
>
> ./manage.py sqlreset --apply
>
> just as a time saver.  i'd write the patch if no one's opposed.
>
> derek
>
> --
>   looking to buy or sell anything?
>
>  try:http://allurstuff.com
>
>   it's a classified ads service that
>   shows on a map where the seller is
>   (think craigslist + google maps)
>
>   plus it's 100% free :)


--~--~-~--~~~---~--~~
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: Proposal: shortcut to display one field from newforms

[Brian Rosner]

The as_* methods are helpers to display the form fields quickly.  As
mentioned above you can accomplish exactly what you are describing.
Just create a templatetag to make it more DRY.

On Oct 30, 2:52 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> > On the other hand, it's kind of an edge case, since if you're using the
> > same set of tags for every field, it quite limits the amount of
> > customized layout you can do :)
>
> I don't think so - most of the people control the layout via css
>
> I think using {{ form.foo.as_p }} is a great idea.


--~--~-~--~~~---~--~~
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 features -- the definitive list

[Brian Rosner]

On Nov 30, 7:27 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> Adrian Holovaty wrote:
> > Without further ado, here's my list:
>
> > * newforms-admin
> > * queryset-refactor
> > * django.newforms becomes django.forms
> > * Model-level validation
> > * Change django.templatetags not to use __path__ hacking
> > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> > * #5361 -- File storage refactoring
> > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> > What am I forgetting?
>
> newforms in generic views and comments too.  This isn't being taken care of in
> newforms admin is it?

No this isn't being done in newforms-admin.  I would post the ticket
number, but I have created a patch with docs and tests for converting
the generic views over to newforms.  Be great if it can get some more
eyeballs and maybe get merged in tomorrow.

>
> We also have the features page made before the last 
> sprint:http://code.djangoproject.com/wiki/VersionOneFeatures
>
> On a related note, the maxlength argument is currently issuing a
> PendingDeprecationWarning.  It was talked that we would change to
> DeprecationWarning before the next release, but I think it should die before
> .0.
>
> Should we change to DeprecationWarning now and remove it before the release or
> just axe it all now?
>
> > And, finally, a bit of a controversial statement, but...
>
> > I think we ought to call the release 2.0.
>
> "The birth of Django"
> 1.910
>
> Gary
--~--~-~--~~~---~--~~
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 features -- the definitive list

[Brian Rosner]

On Nov 30, 11:38 pm, Brian Rosner <[EMAIL PROTECTED]> wrote:
> On Nov 30, 7:27 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
>
>
> > Adrian Holovaty wrote:
> > > Without further ado, here's my list:
>
> > > * newforms-admin
> > > * queryset-refactor
> > > * django.newforms becomes django.forms
> > > * Model-level validation
> > > * Change django.templatetags not to use __path__ hacking
> > > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> > > * #5361 -- File storage refactoring
> > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> > > What am I forgetting?
>
> > newforms in generic views and comments too.  This isn't being taken care of 
> > in
> > newforms admin is it?
>
> No this isn't being done in newforms-admin.  I would post the ticket
> number, but I have created a patch with docs and tests for converting
> the generic views over to newforms.  Be great if it can get some more
> eyeballs and maybe get merged in tomorrow.

Er, I meant to say that I can't post the ticket since the site is down
for maintenance and that I have created a patch ;)

>
>
>
> > We also have the features page made before the last 
> > sprint:http://code.djangoproject.com/wiki/VersionOneFeatures
>
> > On a related note, the maxlength argument is currently issuing a
> > PendingDeprecationWarning.  It was talked that we would change to
> > DeprecationWarning before the next release, but I think it should die before
> > .0.
>
> > Should we change to DeprecationWarning now and remove it before the release 
> > or
> > just axe it all now?
>
> > > And, finally, a bit of a controversial statement, but...
>
> > > I think we ought to call the release 2.0.
>
> > "The birth of Django"
> > 1.910
>
> > Gary
--~--~-~--~~~---~--~~
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: ModelForm.__init__() argument signature versus other newforms forms

[Brian Rosner]

On Dec 11, 2:10 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hello Guys,
>
> I am following this post about ModelForm and I am still puzzled on how
> this new class can address the dynamic generation of a form. I would
> like to see how it is possible to do it with this new API.
>
> Let us imagine that for an Online Survey application 
> :http://yml.alwaysdata.net/
> I need to dynamically create a form representing an "Interview" to my
> user. This form is build with the following logic :  it presents the
> "Survey" with all its related "Questions" and the "Choices" related to
> the question.
> A simple example can be seen 
> there:http://yml.alwaysdata.net/apps/survey/interview/add/3/
>
> So the question behind this is how to display a form with nested
> ForeignKey.

This is something that is being addressed in newforms-admin. It is
necessary for django.contrib.admin and
django.views.generic.create_update (#3639 - newforms patch) to have
some helper function to dynamically create a ModelForm since the model
is not known until runtime.  I think what you are trying to get at is
something similar to a FormSet found in the newforms-admin branch.
You might want to check it out.

> Thank you
> --yml
>
> On 11 déc, 04:22, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> > Joseph Kocherhans said the following:
>
> > > I'm close to checking this in and adding a note to
> > > BackwardsIncompatibleChanges, but I'm still a little uneasy about
> > > generating the form fields at form instantiation time. It just feels
> > > weird to me, but I can't really come up with any actual reasons why. I
> > > mean, I think the functionality is neat, but I'm not comfortable with
> > > the syntax.
>
> > Looking at the latest patch, I don't think it ended up supporting that -
> > it instead only uses the fields defined in the common form, no
> > fields/exclude args required.
>
> > Though admittedly, I don't know ModelForms very well yet, so I could be
> > missing something :)
>
> > --
> > Collin Grady
>
> > Earth is a beta site.
--~--~-~--~~~---~--~~
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-admin and django.contrib.auth

[Brian Rosner]

On 2007-12-16 21:04:10 -0700, "James Bennett" 
<[EMAIL PROTECTED]> said:

> 
> While playing around a bit with newforms-admin, I noticed that it's
> ever-so-close to being able to handle one cool use case which came up
> during the design discussion at PyCon: running django.contrib.admin
> without django.contrib.auth.
> 
> The implemention of has_permission() on AdminSite, and
> has_(add|change|delete)_permission() on ModelAdmin, gets it almost all
> the way there, but leaves two stumbling blocks:
> 
> 1. Creating instances of LogEntry, which FK to
> django.contrib.auth.models.User, and
> 2. Creating instances of Message, which also FK to
> django.contrib.auth.models.User.
> 
> Right now, you *can* work around this by overriding/duplicating a lot
> of code in ModelAdmin, but factoring out log entries and messages into
> methods -- similar to what's already been done with permission checks
> -- would make that unnecessary.
> 
> I'm not particularly attached to these method names, but adding
> methods on ModelAdmin, say, log_action() and send_user_message(), and
> having the object-saving code call those methods instead of directly
> handling logging and messages, would solve this pretty cleanly (and
> also add a little bit more useful functionality for someone who wants
> to roll their own implementation of these features).
> 
> Anyone have strong feelings one way or another?

+1. There are a few other places in ModelAdmin that should be split out 
into its own method, but unrelated to this. This would definitely solve 
this problem cleanly for those looking for this feature.

-- 
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
-~--~~~~--~~--~--~---

Splitting django.newforms.models

[Brian Rosner]

I would like to propose splitting django.newforms.models. The reasoning 
behind this stems from the work going on in newforms-admin. 
django.newforms.models now consists of ModelForm, the model choice 
fields and the model related formset code. I am working on a patch that 
adds declarative style formsets which increases the code related to 
model formsets. Its just becoming a bare to work with sometimes. I 
wanted to see how everyone felt if it were to be split up like so:

django
|
- newforms
  |
  - models
|
- __init__.py
- fields.py
- forms.py

That would be how it would layout in trunk so then newforms-admin would 
add a formsets.py to the mix and nicely cleaning everything up. I am 
more than happy to open a ticket and write up a patch if everyone is in 
favor of this small clean up.

-- 
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
-~--~~~~--~~--~--~---

FileField with ModelForm

[Brian Rosner]

It appears that the usage of FileField with ModelForm is not working 
correctly. [1] is the ticket in Trac. The problem, put briefly, is that 
when a ModelForm is given an instance it is marked as required and 
requires the user to upload a file to bypass the validation. Keep in 
mind that if the FileField is explicitly marked as not required then 
this is a non-issue.

This is currently a bug in the newforms-admin that I have been working 
on for a little while now. After working alot on the formset refactor 
patch the problem really seems to lie in newforms itself.

This wasn't a problem with the form_for_* helper functions since 
form_for_instance knew the model data when creating the form class. 
That is why the FileField model class has the following code in its 
formfield method:

# If a file has been provided previously, then the form doesn't require
# that a new file is provided this time.
if 'initial' in kwargs:
defaults['required'] = False

This will no longer work correctly because initial will never be passed 
in the kwargs since the form creation is now done in the 
ModelFormMetaclass. In looking at the FileInput widget tests it makes 
note that its data is useless due to the nature of how file uploads are 
handled. That makes complete sense, however, is causing this problem 
when the data is coming from the model and not the web browser.

To write a patch I created a new widget named BoundFileInput that 
inherits from MultiWidget to display the FileInput and HiddenInput 
widgets. The FileInput widget works the same as it does now. The 
HiddenInput widget maintains the data that came from the model. As I 
understand it this is how it used to work in oldforms, but perhaps just 
the admin in trunk.

This is where the problem comes in. To hook BoundFileInput widget into 
the correct place I found out that doing so in the newforms FileField 
__init__ method is still too soon to check for the initial data. This 
then made me realize that perhaps this actually had to be done in the 
BaseForm. It wouldn't seem correct to do this only in the ModelForm, 
but perhaps I am wrong.

I then figured that changing the widget based on the initial data in 
the BaseForm __init__ still seems very hackish, but I may be wrong 
again. I then remebered about BoundField which basically defines a 
field and its data. Well, that is only used for the display of the 
widget as opposed to both display and validation. This seems to be a 
gap that might need to be filled to accomplish this fix properly.

So, with all that said I ask:

1. Should FileInput be aware of its data since one use-case is valid.
2. How should the widget be handled when a validation error occurs?

Any ideas/ensight would be greatly appreciated.

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

-- 
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: FileField with ModelForm

[Brian Rosner]

On 2008-01-08 18:46:02 -0700, Malcolm Tredinnick 
<[EMAIL PROTECTED]> said:

> 
> 
> On Tue, 2008-01-08 at 18:40 -0700, Brian Rosner wrote:
> [...]
> 
>> To write a patch I created a new widget named BoundFileInput that
>> inherits from MultiWidget to display the FileInput and HiddenInput
>> widgets. The FileInput widget works the same as it does now. The
>> HiddenInput widget maintains the data that came from the model. As I
>> understand it this is how it used to work in oldforms, but perhaps just
>> the admin in trunk.
> 
> I'd prefer that we worked out a way to get the initial data passed
> through. Sticking this in a hidden field would mean that you pretty much
> always have to include some kind of security hash as well to avoid the
> hidden field value being changed. This is why Russell's improvements for
> file uploading in newforms were a slightly better design.

Ok, that makes more sense. I had a feeling I was taking the wrong 
approach. I hadn't seen his proposal, perhaps I should have done a bit 
more research ;) Should FileField be special cased for initial data or 
make a global change to all fields?

> 
> Regards,
> Malcolm


-- 
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: FileField with ModelForm

[Brian Rosner]

On 2008-01-09 16:20:39 -0700, Malcolm Tredinnick 
<[EMAIL PROTECTED]> said:

> 
> 
> On Wed, 2008-01-09 at 14:04 -0700, Brian Rosner wrote:
>> On 2008-01-08 18:46:02 -0700, Malcolm Tredinnick
>> <[EMAIL PROTECTED]> said:
>> 
>>> 
>>> 
>>> On Tue, 2008-01-08 at 18:40 -0700, Brian Rosner wrote:
>>> [...]
>>> 
>>>> To write a patch I created a new widget named BoundFileInput that
>>>> inherits from MultiWidget to display the FileInput and HiddenInput
>>>> widgets. The FileInput widget works the same as it does now. The
>>>> HiddenInput widget maintains the data that came from the model. As I
>>>> understand it this is how it used to work in oldforms, but perhaps just
>>>> the admin in trunk.
>>> 
>>> I'd prefer that we worked out a way to get the initial data passed
>>> through. Sticking this in a hidden field would mean that you pretty much
>>> always have to include some kind of security hash as well to avoid the
>>> hidden field value being changed. This is why Russell's improvements for
>>> file uploading in newforms were a slightly better design.
>> 
>> Ok, that makes more sense. I had a feeling I was taking the wrong
>> approach. I hadn't seen his proposal, perhaps I should have done a bit
>> more research ;) Should FileField be special cased for initial data or
>> make a global change to all fields?
> 
> I'd special-case FileField, since all the related field (ImageField, any
> custom upload fields) will be subclasses of that. More specifically,
> it's really keyed off the HTML widget, since it's only the file upload
> widget that has this particular problem. Without looking at the code, I
> couldn't say if it's better to do test the widget type or the formfield
> type, but the former is probably more robust, if you can do it.

I have attached a possible patch to the ticket [1]. I would argue that 
the widget really doesn't play a role in this issue. The only thing the 
widget is doing is rendering the data passed into it which is either 
from request.POST or initial data. While it does know how to retreive 
its data from request.POST that would only be because of some way it 
decided to handle the data in the HTML. Let me know if I am missing 
that logic somewhere.

My patch is grabbing the initial data and throwing it at the clean 
method of the FileField to ensure it is properly cleaned. Then based on 
its clean value save_form_data of the model FileField is able to 
determine with a check type check whether or not to save the file. One 
thing I want to point out here, which is described in the tests, is 
when the file changes there is no garbage collection of the previous 
file. I wasn't sure if this should be done by Django, the user or at 
all.

Also, fields such as ComboField and MultiValueField probably need to be 
made aware of initial data if there is a FileField/ImageField among its 
fields.

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

> 
> Regards,
> Malcolm


-- 
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: FileField with ModelForm

[Brian Rosner]

On 2008-01-10 03:12:29 -0700, 
"[EMAIL PROTECTED]" 
<[EMAIL PROTECTED]> said:

> 
> Looked at the latest patch, great stuff.
> 
> About other fields needing initial data, what about havig a commom
> baseclass (for use with isinstance) for those fields or a
> takes_initial attribute so it is not only specific to filefields.
> 

I was thinking the same thing. I think adding the takes_initial 
attribute would be the best. It would follow the same convention that 
needs_multipart_form on the FileInput widget.

-- 
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: FileField with ModelForm

[Brian Rosner]

On 2008-01-10 17:34:11 -0700, Malcolm Tredinnick 
<[EMAIL PROTECTED]> said:

> 
> 
> On Thu, 2008-01-10 at 02:12 -0800, 
> [EMAIL PROTECTED] wrote:
>> Looked at the latest patch, great stuff.
>> 
>> About other fields needing initial data, what about havig a commom
>> baseclass (for use with isinstance) for those fields or a
>> takes_initial attribute so it is not only specific to filefields.
> 
> Why is this needed? How many other fields are there that are represented
> by an HTML widget which does not allow setting of the initial value?
> That is the only case that seems to require this handling. So if there's
> another case unrelated to the HTML file upload widget which requires
> this, we may have a reason to generalise, otherwise it's not going to be
> required. It's not worth over-generalising just because we can; we do it
> because we need to.
> 

To my knowledge there are none. However, there are two fields that may 
contain a FileField or ImageField. ComboField and MultiValueField would 
need to just pass initial through to the clean method of the FileField. 
So a type check needs to be in place for the FileField there as well as 
either extending the type check in full_clean to include both 
ComboField and MultiValueField or use an takes_initial attribute on the 
class. The takes_initial approach may still be overkill for two more 
fields, but it would allow users to create some crazy other field that 
needs initial or needs to pass it through.

-- 
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: Performance / Memory/CPU Usage of A Django App with 10,000+ Models in a High Traffic Site

[Brian Rosner]

Please direct questions of this nature to the django-users mailing 
list. This list is meant for the development of Django and not the 
usage of Django. Thanks!

-- 
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: Object name for object_list generic view

[Brian Rosner]

> 
> If we over ride the template name for object_list view, by using
> template_object_name parameter, this adds a _list to the value
> specified in the paramater. Since this is a manual override adding a
> _list to the name seems weird. I lost some time today for this, so
> wondering if this might be gotcha for many people, and should we
> rethink adding _list?

The documentation, [1], clearly states that _list will be appended to 
the template_object_name. The default value for template_object_name is 
object therefore creating object_list. Changing this behavior will 
break everyone's code using the object_list generic view and is not 
really going to be even considered.

Brian

[1]: 
http://www.djangoproject.com/documentation/generic_views/#django-views-generic-list-detail-object-list
 




--~--~-~--~~~---~--~~
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: Should manage.py startapp create a urls.py file?

[Brian Rosner]

> If it's common advice to make apps portable and bundle urls along with
> an app, shouldn't manage.py startapp also drop in a default urls.py
> file?

-1. While Django is a web framework it would seem logical for a urls.py 
to be created with startapp. However, I am sure the original design 
decision was that it would tie this to much to a HttpRequest object 
being present which isn't always the case.

IMHO, I think that having a urls.py created automatically is beneifical 
and it shouldn't stop there. A forms.py is very useful and once 
newforms-admin is merged in an admin.py. I feel that if something like 
this should happen it will happen in other skeletons. Perhaps startapp 
should take an argument like http that would create a skeleton based on 
things needed in that environment.


-- 
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: ModelForm fieldsets?

[Brian Rosner]

> Is there any good reason why the "fieldsets" option of ModelAdmin (in
> newforms-admin) shouldn't be pushed down into the newforms library?
> What I'm doing right now by overriding change_form.html would be even
> easier if I could define my fieldsets on a ModelForm.

I don't see reason why it shouldn't be at the newforms level. I agree 
with Malcolm and say that this shouldn't be scoped to just ModelForms.

Now that I think about this a little more it would really fix up the 
fiddly bits with the ModelAdmin class and the form_add/form_change 
methods. It might be a bit too much, but why should there even be 
fieldsets on ModelAdmin when this can all be done with a custom form.

This puts me at a +1 on the idea.


-- 
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
-~--~~~~--~~--~--~---

#django-dev and logger

[Brian Rosner]

Hey all,

I wanted to let everyone know about #django-dev on freenode. It was an 
idea that I threw out on TWiD and a few people said it would be a good 
idea. #django now gets intermixed with usage and development questions 
and I felt it would be good to split them out to avoid the cross noise.

I am also the creator/maintainer of the DjangoBot and have been working 
on alot of new things. The current logbot that used to work at 
http://simon.bofh.ms/logger/django/ has not been working for several 
days. It is a resource I use ALL the time. So providing I have been 
working on this bot for a while I decided to take the matter into my 
own hands. The DjangoBot is now logging three channels: #django, 
#django-dev and #django-sprint so that those records are there for 
future reference. I find them tremendously useful. You can find it at 
http://oebfare.com/logger/django/

I understand the process for registering #django is underway, not sure 
if this would be a good time to bring up registration of #django-dev or 
if it really matters.

Thanks for your time and see, hopefully, many of you at PyCon!

-- 
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: If form_for_model is deprecated, what is its replacement?

[Brian Rosner]

> I like the syntactic sugar provided by declarative APIs such as
> ModelForm, but I think it's important to provide a non-declarative
> alternative for people who need to dynamically construct something at
> runtime rather than baking the details in to their source code.

I agree with you Simon. ModelForms really fixed the usage of  
form_for_instance and form_for_model still has its place in the world.  
In newforms-admin we have _modelform_factory that basically does the  
same as form_for_model, but uses a ModelForm. It is used in the admin  
application for dynamically creating the form used on the add/change  
pages. It looks like that is what you want, but that is newforms-admin  
specific. I still feel that form_for_model should just be updated for  
a ModelForm and allow those who know how to use it to use it.

Brian Rosner

--~--~-~--~~~---~--~~
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: Queryset-refactor merge in newforms-admin branch broke date_hierarchy filter

[Brian Rosner]

On Apr 27, 2008, at 12:02 PM, Marcob wrote:
>
> I found that after queryset-merge in newforms-admin date_hierarchy
> filter doesn't work anymore: years and month are repeated.
> To fix it I wrote this quick hack in django/contrib/admin/ 
> templatetags/
> admin_list.py:

Can you open a ticket in Trac with your patch attached. That will be  
much easier to track than in the mailing list. Thanks.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Patch on #6776

[Brian Rosner]

I have attached a patch to #6776 [1] that solves the AlreadyRegistered  
[2] problem according to what seemed to be the consensus. Which  
basically is to throw the AlreadyRegistered exception on registration  
of a different ModelAdmin that may have been previously registered  
with a model. I am looking to gather some input. It seems that I have  
needed to implement this similar to the way the AppCache works, which  
deals with locking the cache when loading new apps. I am not 100% sure  
whether I need this or not.

Thoughts?

[1]: 
http://code.djangoproject.com/attachment/ticket/6776/6776_modeladmin_fix.2.diff
[2]: 
http://groups.google.com/group/django-developers/browse_frm/thread/1a40c64e9c952c48/7e3d1967d71e4edc?tvc=1&q=ModelAdmin#7e3d1967d71e4edc

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: Patch on #6776

[Brian Rosner]

On Apr 29, 2008, at 8:07 AM, Michael wrote:

> Thanks for the work, Brian;
>
> I assume the patch that goes to /dev/null should be going to contrib/ 
> admin/loading.py. Don't really get a chance to work with git all too  
> often.
>
> One thing that I am noticing real quick, while applying this patch.  
> Any model that is being imported, whether it is in the installed  
> apps or not, is being put into the admin. This is a real hassle for  
> multiple sites that might share for example a user profile.

Ah, that is a good catch. I will go ahead and get that fixed up. Thank  
you for your feedback.

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
-~--~~~~--~~--~--~---

newforms-admin FormSet API

[Brian Rosner]

Hello all,

The newforms-admin branch is getting close to finalizing the formset  
API. However, to do so we would like to run it by the developer  
community for ideas. I have posted a diff [1] of documentation showing  
the API. The diff shows the API without a leading underscore on the  
factory functions. Meaning in source they are defined as:

  * _formset_factory
  * _modelform_factory
  * _modelformset_factory
  * _inlineformset_factory

Joseph and I believe that just dropping the leading underscore will be  
good enough for a finalized API. What do others think of the API? My  
documentation writing skills are *not* to be criticized :P However,  
any errors or corrections to improve them would be greatly appreciated.

[1]: http://dpaste.com/hold/51750/

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-admin FormSet API

[Brian Rosner]

On 2008-05-27 05:33:01 -0600, "Russell Keith-Magee" 
<[EMAIL PROTECTED]> said:

> Is there any particular reason that you can't just add a Meta class to
> this class definition, in the same way that a ModelForm works:
> 
> class ArticleFormSet(FormSet)
> class Meta:
> form = ArticleForm
> extra = 2
> can_delete = True
> 
> def clean(self):
> raise forms.ValidationError, u'An error occured.'
> 
> I'm guessing InlineFormSet and ModelFormSet will need their own meta
> class processing to handle their specific options, but there should be
> a lot of common code between them.

I made an attempt to normalize the API in 6241 [1]. That is where we 
decided that it was really complicating things. It may have been in my 
implementation itself. I am still not opposed to doing some sort of 
normalization, but at this point not sure how to go about simplifying 
the implementation.

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

-- 
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-admin FormSet API

[Brian Rosner]

> Should I be looking at any other documentation, or code, that you are
> developing?

Yes. What you have brought up is actually not the use case for 
formsets. However, you do bring up something that makes me want to 
clarify in the docs a bit more. When I say multiple forms per page, 
that really doesn't mean having fields from N models that are grouped 
together in some fashion and presented in different locations on the 
page to make it more user friendly. What it really means is having 
multiple Form/ModelForm objects that are equivalent in fields and bound 
to some list dataset. Just like the edit_inline functionality found in 
the admin. All your other issues deal directly with newforms yourself. 
I would give the newforms and modelforms documentation again.

newforms: http://www.djangoproject.com/documentation/newforms/
modelforms: http://www.djangoproject.com/documentation/modelforms/

-- 
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
-~--~~~~--~~--~--~---