one 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
te
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 t
> 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
e 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
a. 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" gro
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
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
On Jan 6, 3:57 pm, Brian Rosner <bros...@gmail.com> 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,
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
ing 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
&quo
ssages 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 un
h 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 becau
g 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
"Djan
uld 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.
--
B
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" gro
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
ally 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 unsubscr
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
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 Rosn
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.
east 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 dev
roken 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
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@googlegr
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 subscri
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
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
id 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@googlegroup
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@googleg
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
nyone
> 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
e 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 ar
ncommon 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
--~--~-~--~~~---~--~~
Y
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
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
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 hav
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 unsubs
th 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 dev
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
Djang
hem 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 e
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
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 g
sage 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 Rosn
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
-
n 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
tation/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
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 G
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
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-develop
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
lly 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.
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
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 subscribe
y. 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
--~--~-~--~~~---~--~
>
> 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
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
n 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 oth
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.
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 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 disp
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&q
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
other?
+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
--~--~-~--~~~---~--~~
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
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
> > > * qu
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
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
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
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
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
--~-
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
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
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 desc
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 g
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 ;)
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 multi
y 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
s 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 discus
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
78 matches
Mail list logo