Re: Composite key development

[Julien Phalip]

Thank you Anssi. It’s very useful to have your perspective as you’ve done a
lot of oversight work on this specific feature before and have lots of
experience working with the ORM internals.

So it seems like the consensus at this point is to use Michal’s original
work as a basis. I like the way you’ve broken down the different steps.
This makes sense and would likely increase chances for eventually reaching
the end goal. Each one of those steps could potentially be fleshed out as
independent DEPs at some point.

Personally I’m also very keen to make this happen so I’m volunteering to
provide oversight and help with documentation, testing and code reviews.

This approach also seems in line with what Asif mentioned earlier about his
own work. Let’s give him a chance to provide some updates on this when he’s
ready, and then we can take it from there.

Thanks all!

Julien

On Mon, Mar 20, 2017 at 1:14 AM, Anssi Kääriäinen <akaar...@gmail.com>
wrote:

> Just my late 2 cents to this...
>
> First, I wouldn't put too much weight on the DEP proposals. Looking back
> to them now, I don't think they went to the right direction.
>
> For Michal Petrucha's work, it was really close to being merged some years
> ago. The problem was that migrations happened at the same time, and that
> resulted in need of substantial changes to Michal's work, and unfortunately
> this never happened. So, I'd put a lot of weight on this work.
>
> If I'd were to take on this task, I'd try to develop the feature with the
> idea of merging the work in multiple batches. For example this might be a
> possible plan:
>   1. Introduce virtual/composite field, only CREATE TABLE migrations
> support at this point, not documented as public API
>   2. Add support for primary key and unique composite fields, again
> non-public
>   3. Work on foreign keys, again non-public
>   4. Migrations support
>   5. Make the work public API (that is, document the work)
>
> This would give a chance to get the work done in incremental pieces. Doing
> this all in one go is such a large task that there is a big risk of not
> getting this done at all.
>
> Whatever approach you take, I really hope you'll be able to work on this
> and get this long waited feature in to Django.
>
>  - Anssi
>
> On Wednesday, March 1, 2017 at 7:08:35 AM UTC+2, Asif Saifuddin wrote:
>>
>> Hi Julien,
>>
>> I will publish it very soon.
>>
>> Thanks
>>
>> On Wednesday, March 1, 2017 at 5:58:50 AM UTC+6, Julien Phalip wrote:
>>>
>>> Hi Asif,
>>>
>>> That sounds good. On first look I did have some reservations about some
>>> of the design details in the current DEP, especially around the observer
>>> pattern for data binding. But I’m going to have to dig deeper into the
>>> implementation to get a clearer idea.
>>>
>>> It’d be great if you could publish your work-in-progress at some point
>>> so we can discuss the approach in more detail.
>>>
>>> Thanks,
>>>
>>> Julien
>>>
>>> On Mon, Feb 27, 2017 at 9:03 PM, Asif Saifuddin <auv...@gmail.com>
>>> wrote:
>>>
>>>> Hi Julian,
>>>>
>>>> I have been also reviewing and studying the previous works, deps,
>>>> discussions, codes and tickets. I have also been working to prepare a new
>>>> dep based on the previous works.
>>>>
>>>> Like what Michal said, from my observation, I found the works and
>>>> approaches of Michal is quite better and it's possible to break the work
>>>> down into smaller parts to implement gradually.
>>>>
>>>> I am not quite sure how much work or which approaches of  Thomas
>>>> Stephenson in 2015 could be mixed or needed with Michal's approach. In my
>>>> humble opinion Michal spent more time in working on this and I also found
>>>> his insights and suggestions on this topic more sensible.
>>>>
>>>> I would also like to work on this. My Dep is not yet ready for a push.
>>>>
>>>> You could certainly review and give you input on the Dep. Some core
>>>> members suggested me to finalize a Dep before div into code.
>>>>
>>>> Let me know what your thoughts.
>>>>
>>>> Regards,
>>>>
>>>> Asif
>>>>
>>>> I have also contact with
>>>>
>>>> On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens
>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> My company (Citus Data) is interested in sponsoring some Django w

Re: Composite key development

[Julien Phalip]

Hi Michal,

Thanks for your detailed reply. Very helpful.

I was also curious, during your work did you look into SQLAlchemy? They
seem to have a pretty elaborate system for multi-column fields. I know that
overall the SQLAlchemy and Django ORMs follow a different approach, but I’m
wondering if perhaps some inspiration could be found in how they
specifically handle composite fields, both API-wise and implementation-wise.

Julien

On Mon, Feb 27, 2017 at 12:44 PM, Michal Petrucha <
michal.petru...@konk.org> wrote:

> Hi everyone,
>
> I can't speak for Thomas' implementation, as I haven't had the time
> and energy to look into it too much, but I can try to clarify some
> aspects of what I did years ago.
>
> On Mon, Feb 27, 2017 at 11:10:55AM -0800, Julien Phalip wrote:
> > Composite primary keys (GSoC)
> >
> > =
> >
> >
> > Michal Petrucha participated in two Google Summer of Code (GSoC) projects
> > in 2011 and 2013, during which some extensive code, tests and
> documentation
> > were written. Unfortunately this project didn't reach the point where it
> > could be merged into core and it eventually fell behind. Some relevant
> > resources about these projects can be found here:
> >
> > - GSoC'2013 proposal: https://gist.github.com/konk/5408673
> >
> > - GSoC'2013 status updates:
> > https://groups.google.com/forum/#!topic/django-developers/CD7OrkJ63zc
> >
> > - Discussion about some implementation details:
> > https://github.com/django/django/pull/1407
> >
> > - Status update from Michal from last year:
> > https://groups.google.com/forum/#!topic/django-developers/SunyXc_BTVM
> >
> >
> > Michal's implementation work is divided in two separate branches
> > ("composite-fields" and "foreignkey-refactor"), presented below with
> their
> > corresponding list of commits:
> >
> >
> > "composite-fields" branch:
> >
> > - Branch: https://github.com/konk/django/tree/soc2013/composite-
> fields
> >
> > - Commits:
> > https://github.com/django/django/compare/041a076dadce547d450cf73d97401d
> 63cde8891d...konk:soc2013/composite-fields
> >
> >
> > "foreign-refactor" branch:
> >
> > - Branch:
> > https://github.com/konk/django/tree/soc2013/foreignkey-refactor
> >
> > - Commits:
> > https://github.com/django/django/compare/041a076dadce547d450cf73d97401d
> 63cde8891d...konk:soc2013/foreignkey-refactor
> >
> >
> > I took a quick stab at merging current master into those branches but
> > didn't make it too far as it turned out to be a little tedious. The main
> > reason is that since 2013 there have been extensive changes in the ORM
> > internals, in particular around the Meta api. So I'm not sure if it's
> worth
> > doing that merge at this point. However, it'd be a shame to let all that
> > great work go to waste and hopefully some of it can still be reused.
>
> Sadly, I don't see how a merge of current master would be feasible
> with those branches. This all happened before migrations, the explicit
> AppRegistry, and all the meta changes were merged, all of which cause
> quite some conflicts. It should be feasible to port significant
> portions of my old work onto master, though, commit by commit.
>
> > Some questions:
> >
> > - Are there any portions of code or some solutions from Michal's
> > implementation that could be ported over to the DEPs and to Thomas' more
> > recent implementation?
>
> I would hope so, but unfortunately, can't say with any certainty. Even
> if I just look at the interface, Thomas' approach seems quite
> different from mine, but without going through the code, it's hard for
> me to tell what parts could be relevant.
>
> > - What is the difference or relationship between the "composite-fields"
> and
> > "foreignkey-refactor" branches?
>
> Right, so the gist of it is that if we ever want to support composite
> foreign keys, it will be necessary to turn ForeignKey into a virtual
> field, which is exactly what I attempted to achieve in the
> “foreignkey-refactor” branch. This would also have the neat side
> effect of clearly defining what even is a virtual field in the ORM,
> since that was definitely not a very well defined concept at the time.
> (I think it's gotten better with the formalization of _meta, but it's
> still very heavily influenced by the early approach of “any aspects of
> GenericForeignKey that don't closely match regular fields”.)
>
> My thinking was that I'd first try to get the refactoring part as
> solid a

Re: Composite key development

[Julien Phalip]

Hi Asif,

That sounds good. On first look I did have some reservations about some of
the design details in the current DEP, especially around the observer
pattern for data binding. But I’m going to have to dig deeper into the
implementation to get a clearer idea.

It’d be great if you could publish your work-in-progress at some point so
we can discuss the approach in more detail.

Thanks,

Julien

On Mon, Feb 27, 2017 at 9:03 PM, Asif Saifuddin  wrote:

> Hi Julian,
>
> I have been also reviewing and studying the previous works, deps,
> discussions, codes and tickets. I have also been working to prepare a new
> dep based on the previous works.
>
> Like what Michal said, from my observation, I found the works and
> approaches of Michal is quite better and it's possible to break the work
> down into smaller parts to implement gradually.
>
> I am not quite sure how much work or which approaches of  Thomas
> Stephenson in 2015 could be mixed or needed with Michal's approach. In my
> humble opinion Michal spent more time in working on this and I also found
> his insights and suggestions on this topic more sensible.
>
> I would also like to work on this. My Dep is not yet ready for a push.
>
> You could certainly review and give you input on the Dep. Some core
> members suggested me to finalize a Dep before div into code.
>
> Let me know what your thoughts.
>
> Regards,
>
> Asif
>
> I have also contact with
>
> On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens wrote:
>>
>> Hi all,
>>
>> My company (Citus Data) is interested in sponsoring some Django work. In
>> particular work on support for composite primary keys. From what I
>> understand this wouldn't be the first time the work has been explored and
>> it sounds like it has a number of intricacies to it (
>> https://github.com/django/deps/blob/master/draft/0191-compo
>> site-fields.rst and https://github.com/django/deps
>> /blob/master/draft/0192-standalone-composite-fields.rst). Our hope here
>> is that it would be done in line with something that could eventually
>> become part of an official Django release vs. a one-off work around.
>>
>> While we know there's no guarantee of it being accepted, we'd love to
>> find someone with some knowledge of all the existing areas that would have
>> to be touched and has some experience contributing to Django core to
>> improve that likelihood. As part of the work, we would want the two
>> existing DEPs to be completed and work towards getting those accepted by
>> the broader community. And hopefully it goes without saying, but we'd fully
>> expect all the work to done in the open similar to other Django
>> development.
>>
>> If you're interested in doing this work please reach out as we'd love to
>> discuss further. And if we have enough interest we'll be doing a full CFP
>> for the work to try to keep the process as fair as possible.
>>
>> ~ Craig
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/cc29383b-b930-4d4c-9f48-
> 51fa10909ecd%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABFDzjDjLXGOnoWa%2BE1UtKowiZgtxzB-PcR1goSJhqP2udqUqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite key development

[Julien Phalip]

On Tuesday, November 29, 2016 at 4:10:38 AM UTC-8, Craig Kerstiens wrote:
>
> My company (Citus Data) is interested in sponsoring some Django work. In 
> particular work on support for composite primary keys. From what I 
> understand this wouldn't be the first time the work has been explored and 
> it sounds like it has a number of intricacies to it (
> https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst 
> and 
> https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst).
>  
> Our hope here is that it would be done in line with something that could 
> eventually become part of an official Django release vs. a one-off work 
> around. 
>
> While we know there's no guarantee of it being accepted, we'd love to find 
> someone with some knowledge of all the existing areas that would have to be 
> touched and has some experience contributing to Django core to improve that 
> likelihood. As part of the work, we would want the two existing DEPs to be 
> completed and work towards getting those accepted by the broader community. 
> And hopefully it goes without saying, but we'd fully expect all the work to 
> done in the open similar to other Django development. 
>
> If you're interested in doing this work please reach out as we'd love to 
> discuss further. And if we have enough interest we'll be doing a full CFP 
> for the work to try to keep the process as fair as possible.
>

Thank you Craig for bringing this up and for offering support. This is a 
long-wanted feature —the original ticket is 12 (!) years old— and as you 
know there has been extensive work done on this in the past, so it'd be 
great to find a way to push this all the way across the finish line.


I just took a bit of time and tried to review all past discussions and 
implementations on the subject. See my recap and questions below. If anyone 
here on this list has any answers or thoughts about this, please jump in! I 
will then compile all new feedback and try to help move this forward.


Composite fields DEPs

==


Currently the consensus as a first step is to finalize these two draft DEPs:


https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst

https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst


Those drafts were written by Thomas Stephenson in 2015 and were discussed 
on this thread: 
https://groups.google.com/forum/#!topic/django-developers/MZUcOE6-7GY as 
well as in this pull request: https://github.com/django/deps/pull/12


It seems that some extra topics might need to be included and fleshed out 
in those DEPs, in particular:

- Inspectdb integration

- Migration implications

- Form fields handling

- Admin integration

- Serialization/deserialization


Some questions:

- Do you agree that all the topics above should be covered in the DEPs?

- Should other topics also be covered?

- Are the current design details (observer pattern, lookup functions, 
constraints management, etc) already accepted or do they still need more 
discussion?


Thomas had also started an implementation for these DEPs in this branch: 
https://github.com/ovangle/django/tree/dep_191


I've just merged current master into that branch and pushed it to my fork. 
You can see the details here: 
https://github.com/django/django/compare/eb97af0402536a86d5d8c916859986288bb88dc9...jphalip:dep_191


Some questions:

- What is the status of this implementation work?

- What are the pieces that still need to be implemented in order to fulfill 
the existing DEPs?

- Is this implementation at a stage where it can formally be reviewed? If 
so I can create a PR to initiate a more detailed discussion.


Composite primary keys (GSoC)

=


Michal Petrucha participated in two Google Summer of Code (GSoC) projects 
in 2011 and 2013, during which some extensive code, tests and documentation 
were written. Unfortunately this project didn't reach the point where it 
could be merged into core and it eventually fell behind. Some relevant 
resources about these projects can be found here:

- GSoC'2013 proposal: https://gist.github.com/konk/5408673

- GSoC'2013 status updates: 
https://groups.google.com/forum/#!topic/django-developers/CD7OrkJ63zc

- Discussion about some implementation details: 
https://github.com/django/django/pull/1407

- Status update from Michal from last year: 
https://groups.google.com/forum/#!topic/django-developers/SunyXc_BTVM


Michal's implementation work is divided in two separate branches 
("composite-fields" and "foreignkey-refactor"), presented below with their 
corresponding list of commits:


"composite-fields" branch:

- Branch: https://github.com/konk/django/tree/soc2013/composite-fields

- Commits: 
https://github.com/django/django/compare/041a076dadce547d450cf73d97401d63cde8891d...konk:soc2013/composite-fields


"foreign-refactor" branch:

- Branch: 

Re: Deprecate admindocs?

[Julien Phalip]

On Jul 25, 2013, at 5:29 AM, Aymeric Augustin 
 wrote:

> Hello,
> 
> I'd like to deprecate admindocs. Here are my reasons:
> 
> 1) It's called the "documentation generator", but it only operates on 
> docstrings. This promotes the idea that docstrings are appropriate 
> documentation, while the Python and Django communities now favor prose 
> documentation.
> 
> 2) Even though it's possible to use docstrings to generate API documentation, 
> for instance with Sphinx' autodoc, I find that heavily formatted, 
> Javadoc-style docstrings (or late epydoc-style) [1] tend to be hard to read 
> for humans and I don't want Django to encourage them.
> 
> 3) Its age shows [2]; it was a decent idea at the time it was created but the 
> standard for documentation has evolved a lot since then.
> 
> 4) The featureset is very reminiscent of Django's origins, see for example 
> the "edit this object" bookmarklet.
> 
> 5) Generating documentation doesn't belong to a web framework. There are 
> better tools for this purpose — namely, Sphinx.
> 
> 6) There are a few old, unresolved tickets with patches, indicating low 
> interest [3].
> 
> 7) Test coverage is low (22%), discouraging contributions.
> 
> 8) We could get rid of the optional dependency on docutils.
> 
> What do you think?
> 
> [1] 
> https://docs.djangoproject.com/en/dev/ref/contrib/admin/admindocs/#view-reference
> [2] 
> https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Movedadmindocviewsintodjango.contrib.admindocs
> [3] 
> https://code.djangoproject.com/query?status=!closed=contrib.admindocs

That sounds reasonable to me. +1

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #20739 - Making LiveServerTestCase not depend on staticfiles?

[Julien Phalip]

Hi,

On Jul 15, 2013, at 9:22 AM, Carl Meyer  wrote:

> On 07/14/2013 07:16 AM, Jannis Leidel wrote:
>> Yeah, I can relate to that, it does to me, too. I think decoupling
>> the file serving slightly from how the files got to the place they
>> are served from, is a good first step. The common denominator between
>> the core ability to serve files and staticfiles is the reliance on
>> conventions like STATIC_ROOT and STATIC_URL. If we can backscale
>> LiveServerTestCase to only do the core ability out of the box and
>> document the way to do it the staticfiles way, then I think we're on
>> the right track.
> 
> This advice makes a lot of sense to me. I think we should be able to
> make the staticfiles integration pretty easy; i.e. just have a subclass
> of LiveServerTestCase that lives in django.contrib.staticfiles that
> adjusts the behavior to use the full staticfiles finders, where the base
> LiveServerTestCase in core just serves from STATIC_ROOT.

I think that's a great idea. This way, all you'd need to do to have the full 
static finders is make your TestCase inherit from that subclass, and there 
would be no need to ever run collectstatic while running your tests.

Julien

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ticket 19445

[Julien Phalip]

Hi Luke,

On May 1, 2013, at 3:31 PM, Luke Plant  wrote:

> Hi all,
> 
> Can I get some feedback on what to do about ticket 19445?
> 
> https://code.djangoproject.com/ticket/19445
> 
> I have re-opened this ticket because I don't think it was addressed
> satisfactorily. I apologise in advance that this is a bit involved!
> 
> The fundamental problem is that the validation routines attempt to do
> static validation of a ModelAdmin class, but ModelAdmin has gained
> methods that mean that many of the things that we want to validate are
> only generated at run time (by which I mean the point when a request is
> received).
> 
> So ModelAdmin.get_form() is the method used to create a form class, but
> the validation routines want to validate ModelAdmin.form . Even without
> subclassing ModelAdmin.get_form(), it's possible to create a form class
> that will not pass validation, but will work fine in practice (see
> ticket for more details).
> 
> The main reason I'm bothered about this is ticket 19733, which is about
> requiring the ModelForm.Meta.fields attribute to be present. Please see
> below for why 19733 is involved.
> 
> Even without #19733, it seems that validation of ModelAdmin.form is
> broken in the general case. The attempts to fix it so far were quite hacky:
> 
> https://github.com/django/django/commit/0694d2196f0fadde37ff2d002a9a4a8edb3ca504
> 
> And I'm fairly sure there are other bugs with validation related to the
> dynamic methods such as get_fieldsets() and get_readonly_fields(), which
> both take a request object.
> 
> Since we can't do static validation properly, I'm tempted to remove it
> altogether, but I imagine the static validation will catch lots of
> problems, which is pretty helpful for newbies. A large part of the
> ModelAdmin validation would need to be removed - everything that depends
> on knowing what fields are going to be present.
> 
> One possibility is to remove the static validation, but where specific
> errors are common (e.g. misnamed fields), we try to make the error
> handling further down the line much more friendly.
> 
> If you read the current validation routines, there are quite a few
> places where potential errors have to be ignored (e.g. a field that
> doesn't exist on the model is referred to), because there are other
> things which could mean that it is actually correct. To me this implies
> that validation is happening at the wrong point.
> 
> 
> 
> Why it matters for #19733:
> 
> https://code.djangoproject.com/ticket/19733
> 
> #19733 will (eventually) require ModelForms to have Meta.fields
> explicitly set. (Or, alternatively, Meta.exclude, but this is discouraged).
> 
> To cover the case where we really do want all fields, you can do 'fields
> = "__all__"', as discussed previously on django-devs.
> 
> However, if you are creating a ModelForm to be used solely in the admin,
> this is not good. We've agreed that that admin should use all fields by
> default, and it has its own ways of specifying which fields to use.
> Having to specify anything about fields on the custom ModelForm is
> confusing.
> 
> There is one good solution I've found: specify a ModelForm without a
> Meta inner class, or at least without a Meta.model attribute.
> 
> This already works fine with the admin. The ModelAdmin already knows the
> model to use, and happily constructs the Meta inner class for your form
> if it is missing.
> 
> This is a really good solution, because:
> 
> 1) It's DRY - you specify everything once:
> 
> ###
> class MyModel(models.Model):
>field1 = models.BooleanField()
> 
> class MyForm(forms.ModelForm):
>def clean(self, *args):
># ...
> 
> class MyAdmin(admin.ModelAdmin):
>form = MyForm
>fieldsets = (
>('Group', {
>  'fields': ['field1']
>  }),
>)
> 
> admin.site.register(MyAdmin, MyModel)
> ###
> 
> 
> 2) It is secure.
> 
> If we do 'MyForm.Meta.fields = "__all__"' just to satisfy ModelForm,
> then not only is it confusing, we've also created a functioning
> ModelForm that could end up being used outside the admin, which has all
> fields included and is therefore potentially insecure. We want to avoid
> that.
> 
> 3) It provides a simple upgrade path.for people who hit the new
> requirement on ModelForm, where they were only using them for ModelAdmin.
> 
> Instead of asking people to add a fields attribute, we tell them to
> remove the whole Meta inner class, or at least the model attribute. This
> can be in the upgrade notes.
> 
> 4) It works well in terms of implementation.
> 
> The admin uses all the ModelForm machinery in terms of location Model
> fields. However, we need ModelForms to have the opposite behaviour from
> the admin in this respect - ModelForms should not use all fields unless
> explicitly told to.
> 
> This means that the obvious place to patch up the mismatch is in the
> admin implementation - it should create an appropriate 

Re: broken pipe issue with runserver #4444

[Julien Phalip]

On Dec 18, 2012, at 5:18 AM, Emil Stenström  wrote:

> On Monday, 2 June 2008 02:45:07 UTC+2, Ludvig Ericson wrote:
> I'd rather see this be leaved as-is, since I haven't seen a single  
> report on these broken pipe 'issues'.
> 
> Here's a report:
> 
> I'm using PhantomJS (headless webkit browser) to test for javascript errors 
> on my site. Using the LiveServerTestCase it's possible to spawn a test 
> server, and using Python's subprocess I can call PhantomJS to access that 
> server and assert that there are no errors.
> 
> Problem is, the test server is spitting back broken pipe errors. By reading 
> explanations elsewhere I've understood that this is a browser problem, that 
> they are not supposed to break connections like that, but the fact is that 
> they are. It feels strange to read recommendations that I should just ignore 
> the errors, since having random stacktrace printouts in my tests feels 
> extremely sloppy. 
> 
> Given that browsers behave like they do, and we're not able to change that, I 
> suggest that ticket # is reconsidered, and no marked as wontfix.
> 
> As a workaround I would have hoped for a way to ignore the messages in some 
> other way. I've tried setting up logging to ignore the errors, but failed. My 
> guess is that these errors don't go through the logger. Maybe this couple me 
> the recommended (and documented) way of handling this?
> 
> (Here's the code if you want to reproduce: 
> http://stackoverflow.com/questions/13287490/is-there-a-way-to-use-phantomjs-in-python/13933894#13933894
>  )

Those errors are indeed extremely noisy and confusing. I'm in favor of 
modifying Django to reduce that noise, but only if it gets proven that ignoring 
those errors won't either cause the tests to fail or to pass as false positives.

Julien

-- 
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.contrib.redirects customisation

[Julien Phalip]

On Nov 15, 2012, at 12:22 PM, Лебедев Илья  wrote:

> Recently I needed functionality just like in django.contrib.redirects - 
> redirects table, that can be edited in admin. I was sad to find out that its 
> strongly not configurable. For example, I dont need status 301, but need 
> something else. I dont need 'site' field (since there is only one site), but 
> I need field 'is_active'. Also I need that redirect works for all pages, not 
> only 404.
> Right now I've did that by my own and I don't want to make it separate app 
> since Django has similar functionality.
> How about making that application a little bit more configurable and 
> convinient?
> It doesn't seems to be difficult, so I can do it myself.

More customization hooks would be welcome. Please feel free to create tickets 
in Trac. Please keep each proposed new feature into a separate ticket.

Julien

-- 
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: Admin UI improvement - actions displayed as buttons rather than drop-down list

[Julien Phalip]

Hi Marijonas,

I've left a comment in your ticket. The conversation can continue there.

Thanks,

Julien

On Nov 4, 2012, at 8:15 AM, Marijonas Petrauskas wrote:

> Yes, it's created by me. Sorry for not referencing it.
> 
> 
> On Sun, Nov 4, 2012 at 2:06 PM, Łukasz Rekucki  wrote:
> Hi,
> 
> Isn't this https://code.djangoproject.com/ticket/19235 ?
> 
> Regards,
> Łukasz Rekucki
> 
> --
> 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.
> 
> 
> 
> -- 
> 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.

-- 
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: Yak shaving the test framework on the way to pluggable user models (#3011)

[Julien Phalip]

On Aug 25, 2012, at 1:15 AM, Russell Keith-Magee wrote:

> Hi all,
> 
> So, I've been working on a Django branch [1] to implement the approach
> to pluggable user models that was decided upon earlier this year [2]
> 
> [1] https://github.com/freakboy3742/django/tree/t3011
> [2] https://code.djangoproject.com/wiki/ContribAuthImprovements
> 
> The user-swapping code itself is coming together well. However, I've
> hit a snag during the process of writing tests that may require a
> little yak shaving.
> 
> The problem is this: With pluggable auth models, you lose the
> certainty over exactly which User model is present, which makes it
> much harder to write some tests, especially ones that will continue to
> work in an unpredictable end-user testing environment.
> 
> With regards to pluggable Users, there are 5 types of tests that can be run:
> 
> 1) Contrib.auth tests that validate that the internals of
> contrib.auth work as expected
> 
> 2) Contrib.auth tests that validate that the internals of
> contrib.auth work with a custom User model
> 
> 3) Contrib.auth tests that validate that the currently specified user
> model meets the requirements of the User contract
> 
> The problem is that because of the way syncdb works during testing
> some of these tests are effectively mutually exclusive. The test
> framework runs syncdb at the start of the test run, which sets up the
> models that will be available for the duration of testing -- which
> then constrains the tests that can actually be run.
> 
> This doesn't affect the Django core tests so much; Django's tests will
> synchronise auth.User by default, which allows tests of type 1 to run.
> It can also provide a custom User model, and use @override_settings to
> swap in that model as required for tests of type 2. Tests of type 3
> are effectively integration tests which will pass with *any* interface
> compliant User model.
> 
> However, if I have my own project that includes contrib.auth in
> INSTALLED_APPS, ./manage.py test will attempt to run *all* the tests
> from contrib.auth. If I have a custom User model in play, that means
> that the tests of type 1 *can't* pass, because auth.User won't be
> synchronised to the database. I can't even use @override_settings to
> force auth.User into use -- the opportunity for syncdb to pick up
> auth.User has passed.
> 
> We *could* just mark the affected tests that require auth.User as
> "skipUnless(user model == auth.User)", but that would mean some
> projects would run the tests, and some wouldn't. That seems like an
> odd inconsistency to me -- the tests either should be run, or they
> shouldn't.
> 
> In thinking about this problem, it occurred to me that what is needed
> is for us to finally solve an old problem with Django's testing -- the
> fact that there is a difference between different types of tests.
> There are tests in auth.User that Django's core team needs to run
> before we cut a release, and there are integration tests that validate
> that when contrib.auth is deployed in your own project, that it will
> operate as designed. The internal tests need to run against a clean,
> known environment; integration tests must run against your project's
> native environment.
> 
> Thinking more broadly, there may be other categories -- "smoke tests"
> for  quick sanity check that a system is working; "Interaction tests"
> that run live browser tests; and so on.
> 
> Python's unittest library contains the concept of Suites, which seems
> to me like a reasonable analog of what I'm talking about here. What is
> missing is a syntax for executing those suites, and maybe some helpers
> to make it easier to build those suites in the first place.
> 
> I don't have a concrete proposal at this point (beyond the high level
> idea that suites seem like the way to handle this). This is an attempt
> to feel out community opinion about the problem as a whole. I know
> there are efforts underway to modify Django's test discovery mechanism
> (#17365), and there might be some overlap here. There are also a range
> of tickets relating to controlling the test execution process (#9156,
> #11593), so there has been plenty of thought put into this general
> problem in the past. If anyone has any opinions or alternate
> proposals, I'd like to hear them.

Perhaps some inspiration could be found in other testing frameworks. In 
particular, py.test has an interesting 'marking' feature [1] and I believe that 
Nose also has something similar. This allows to limit the execution of tests 
that have been marked with a particular tag, or in other terms, to dynamically 
specify which sub-suite to execute.

The challenge is that everyone in the industry seems to have different 
definitions for what constitutes a smoke, unit, functional, integration or 
system test. So it's probably best to follow a flexible, non-authoritative 
approach as the meaning for those types of tests is so subjective. Therefore my 
suggestion would be to:
- add a feature 

Re: RFC: More class based views, take two

[Julien Phalip]

Hi Andy and Iván,

On May 28, 2012, at 12:38 PM, Iván Raskovsky wrote:

> Hi Andy,
> 
> On Mon, May 28, 2012 at 7:30 AM, Andrew Ingram  wrote:
>> Hi Iván,
>> 
>> I'd temporarily given up on getting extra_views into Django because of
>> a blocking issue with pagination and formsets.
>> 
>> Assuming a goal is to be able to build a new admin using class-based
>> views, there is a prerequisite of being able to paginate, sort and
>> filter on the querysets used for modelformsets. The problem is that
>> with Django's class-based views as they are, pagination is handled at
>> the template context stage of the logic, whereas the formsets are
>> instantiated and validated much earlier. I had raised a ticket about
>> fixing this, but it was closed as wontfix because it would almost
>> certainly introduce backwards-incompatible changes
> 
> I'm not sure how to work around the issue, I didn't spend much time on
> it. But for sure we can either find a BC way to solve this or revisit
> that wontfix.
> 
>> On a related now, you mentioned that none of the libraries you've
>> mentioned are sufficiently polished. What further work do they need?
>> As I see it, my main omission right now is documentation, though that
>> is in progress.
> 
> I agree your implementation is very well done (nicer than mine), but
> from a quick inspection I could find:
> 
> * There are almost no docstrings
> * One can abstract part of the code in BaseFormSetMixin and FormMixin
> into a new Mixin
> * get_initial() could get a .copy() as in
> https://github.com/django/django/blob/master/django/views/generic/edit.py#L18
> * I don't agree with the get_success_url implementation (it defers
> from the current ones)
> * There's a get_context_data() in FormSetMixin that I think shouldn't live 
> there
> * I think you are not taking into consideration formsets prefixes clashing
> * I'm not sold on BaseInlineFormSetMixin inheriting from
> BaseFormSetMixin: do you really need e.g. get_context_data in there if
> you won't use it?
> 
> This is just a quick list I made while skimming through the code and
> what I remember from past months. I'm more than glad to be proven
> wrong! I'm sure you can make a similar list quickly with my
> implementation, I think the best thing we can do is work together,
> this is a big ticket. Get the best of each implementation and merge it
> together. It's time to get the ball rolling.
> 
> Regards,
>Iván

Backwards-compatibility should be a primary goal, however it is also ok to 
consider breaking that compatibility if it becomes necessary in order to have a 
clean and more easily maintainable codebase, as long as the upgrade path 
remains simple.

This is a significant piece of refactoring and it's hard to predict the full 
extent of the impact it will have on legacy projects and third-party apps. If 
you guys are keen to continue working on this then I encourage you to pursue. 
I'm also glad to help where I can. For a start, I've made a first pass at 
rewriting the admin views into CBVs in ticket #17208 
(https://code.djangoproject.com/ticket/17208).

Once good progress has been made, then it would also be very helpful to keep 
the maintainers of all major custom admin apps (Armstrong, FeinCMS, Django-CMS, 
Grapelli, Mezzanine, etc.) in the loop for feedback.

Thanks a lot for your great work!

Julien

smime.p7s
Description: S/MIME cryptographic signature

Re: Redesign of djangoproject.com?

[Julien Phalip]

Hi everyone,

It's really exciting to see the community offering to help in this
endeavor. I myself spent quite a bit of time last year driving a
redesign effort for djangoproject.com, so I thought I'd share my work
with you now while the momentum is picking up again.

So, using some initial briefing and feedback from Russell, Jacob, Idan
and Christian, I had designed a new IA and then built a working
prototype:

http://www.djangoproject.dotcloud.com/
Login details: preview/ihud8t4k

I'd like to emphasize that this is a *prototype*. The visuals were
intentionally left rough and unpolished, and even the IA itself was a
work in progress. I've seen many great ideas so far in this thread, so
please feel free to rip this prototype off, or to just get some
inspiration from it, or to simply ignore it altogether.

Technically-speaking, the front end uses Sass and Compass and it
implements the responsive Less framework [1]. To see an example of the
responsive behavior, try resizing your browser window on the homepage
[2]. I had also spent a lot of time tweaking the documentation's
layout and styles to make it easy to view across screen sizes [3]. For
example, the sidebar collapses into a clickable button on small
screens. Another example is with large images as in [4]; as the window
gets smaller, the image shrinks along with the window and becomes
clickable on small screens — this is to allow mobile users to access
the full-width image without breaking the layout. However, will all
that said, it might eventually be worth considering to move the
documentation entirely to RTD one day (with some special branding).

The prototype's code is available on github [5]. I hope this is of
some help to the person or team that will be driving this project.

Kindly,

Julien


[1] http://lessframework.com/
[2] Prototype homepage: http://www.djangoproject.dotcloud.com/
[3] Documentation prototype: http://docs.djangoproject.dotcloud.com/en/dev/
[4] 
http://docs.djangoproject.dotcloud.com/en/dev/internals/contributing/triaging-tickets/#triage-workflow
[5] Prototype's code: 
https://github.com/jphalip/djangoproject.com/tree/visual-redesign

-- 
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: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

[Julien Phalip]

On Apr 11, 2012, at 11:44 AM, 3point2 wrote:

> Julien, I'm not describing an edge case. Django will return an HTTP
> 500 for ANY field lookup on a related model that is not in the
> list_filter option.
> 
> To test, simply create a model that has a ForeignKey to another model
> and hook it up into the admin site. Don't include any list_filter
> options. Then craft a valid query string on the change list page that
> queries a field on the related model. You will get an HTTP 500.
> 
> For example:
> 
> myapp/models.py:
> 
> class MyModel(models.Model):
>   parent = ForeignKey(AnotherModel)
> 
> myapp/admin.py
> 
> admin.site.register(MyModel)
> 
> then visit http://localhost:8000/admin/myapp/mymodel/?parent__pk=1 and
> you will get a SuspiciousOperation exception with a return code of
> 500.
> 
> Just to be clear, I'm not against the SuspiciousOperation exception
> being raised. I just think it should use a more appropriate HTTP
> status code, like 403.

Thanks for providing a test case. It kind of is an edge case as it requires 
some specific unusual conditions to be reproduced. But anyways, I've verified 
that this behavior has been in place in Django for a long time (at least since 
1.2). Also it doesn't seem to be tested at all. I do agree that a 500 isn't 
appropriate here. However I don't think a 403 is appropriate either. Instead it 
should probably redirect you to the changelist with the querystring ?e=1, just 
like other unhandled exceptions.

Again, this behavior currently isn't tested, so more thoughts should probably 
be put in this. There's enough material to open a ticket though. Could you do 
that and provide a recap of this discussion?

Regards,

Julien

smime.p7s
Description: S/MIME cryptographic signature

Re: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

[Julien Phalip]

On Apr 10, 2012, at 4:34 AM, 3point2 wrote:

> The admin site allows the use of certain query strings to filter
> change list pages. The syntax follows queryset field lookups, for
> example http://mysite.com/admin/myapp/mymodel/?field__exact=test.
> Lookups that are not specified on the ModelAdmin's list_filter option
> raise a SuspiciousOperation exception. This is done to prevent a
> normal user from obtaining sensitive information (e.g. password
> hashes).
> 
> In production use, I'm not sure that returning an HTTP code of 500
> (internal server error) and emailing the server admins is an
> appropriate response to a user manipulating the query string.
> 
> I think that 403 (forbidden) would be more accurate. In my mind, 500
> suggests that something went wrong on the server, for example an
> unexpected condition or exception in the application code. In this
> situation, this is not the case. Django is deliberately forbidding a
> user from accessing information for which they have not been
> authorized.
> 
> Any thoughts?

I agree that no 500 response should be returned only by passing improper 
querystring parameters, unless those parameters match a custom list filter and 
that filter raises an unhandled exception. There is already a system in place 
to avoid this problem though, so if you've found an edge case could you please 
create a new ticket in Trac with a test case?

Thanks a lot,

Julien

smime.p7s
Description: S/MIME cryptographic signature

Re: Feature request: read-only admin view

[Julien Phalip]

Hi,

This feature has been discussed in the past on this mailing list (e.g.,
http://goo.gl/ezMpc and more recently: http://goo.gl/j1CPv). There has also
been talks about merging the databrowse contrib app into the admin (see
this ticket: https://code.djangoproject.com/ticket/8936 or the GSoC
proposal written by Aymeric last year:
https://code.djangoproject.com/wiki/SummerOfCode2011#Integratedatabrowseintotheadmin
).

Over the years, the admin has been built with the idea that it would only
be used for *editing* data. Perhaps the main example of that is the
changelist (note that its name includes the word "change"), which itself
contains several editing features such as admin actions or the
list-editable forms. Another example is the URL scheme, where
/admin/myapp/mymodel/1234/ points to the change form, whereas in an ideal
world that would point to the object's read-only page
and /admin/myapp/mymodel/1234/edit/ would point to the change form.

Adding the read-only functionality could be done at least by adding a new
"View" permission, extending the URL scheme and refactoring the changelist.
Doing things properly and in a future-proof way seems less than trivial and
most likely backwards incompatible. It would be a welcome change though,
and also a good opportunity to clean up some parts of the admin's codebase.
So I'd absolutely encourage anyone to dig into it and I'd personally be
happy to follow it up and provide feedback as needed.

Kind regards,

Julien

-- 
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: Message Formatting in AdminMailHandler

[Julien Phalip]

Hi,

On 27 October 2011 22:47, momo2k  wrote:

> Hello,
>
> I posted this question some time ago on django-users, but since nobody
> answered and I think about this as a serious problem, I'll post here:
>
> Is there a reason why AdminMailHandler does not use
> record.getMessage() as all other formatters do? (e.g. logging/
> __init__.py:436 Python 2.6). Correct me if I'm wrong, but most
> developers use the args of the logging call for string formatting,
> arent they?
>
> LOGGER.error('This is a %s message', some_var, exc_info=exc_info)
>
> In django this leads to unsubstituted admin mail messages.


This should already be fixed in trunk:
https://code.djangoproject.com/changeset/16715

Regards,

Julien

-- 
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 for a new templatetag definition syntax

[Julien Phalip]

On 13 October 2011 15:30, LeeS  wrote:

> Not sure if this is still an ongoing discussion, but I prefer to write
> all new tags with a simple syntax that matches Python.  There's no
> real advantage in defining a unique, custom syntax for a template
> tag.
>
> All HTML authors are already familiar with Python's kwargs syntax,
> since it exactly matches how HTML tags and attributes themselves
> work.  There's no great leap of difficulty going from:
>
> 
> to
> {% tag foo="something" bar="something" %}
>
> Allowing for arbitrary custom syntax makes tags harder for HTML
> coders, since they have to remember these special custom syntaxes
> which they're not used to.


Note that since the recent r16908 [1], this is easily achievable with
simple_tag, include_tag or assignment_tag, which now replicate the Python
way of handling *args and **kwargs.

The only thing that's still not possible with these is to define a complex
or custom syntax, e.g.: {% mytag with myvar using "blah" %}

However, if one is OK to not have a custom syntax, then the following is now
dead-easy:

{% mytag with=myvar using="blah" %}

@simple_tag
def mytag(with=None, using="Yadi Yada"):
...

Cheers,

Julien

[1] https://code.djangoproject.com/changeset/16908

-- 
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: Splitting out admin functionality

[Julien Phalip]

On 11 October 2011 14:04, tWoolie
wrote:

> > Yep. Could you outline your plan of attack for this?
>
> 1) create "newadmin" project to be a dropin replacement for admin.
>(Clone current admin and slowly replace features/trim dead code)
>
> 2) Split out filterspec functionality into newadmin.filter.
>  - Give it a nicer wrapper such that a FilterSet can be declared and
> instantiantiated much like newforms
>  - Move API for registering filters out of ModelAdmin and into
> newadmin.filter
>
> 3) Split out table generating/sorting/display into newadmin.table
>   - clone django_tables2 and do some refactoring as necessary
>   - replace admin functionality with admin.table functionality
>
> 4) Develop CBV Wrappers for the core functionality
>   - replace admin views with CVB style views


Actually, my proposal at this stage simply is to start with step #4 (i.e.
Turn admin views into CBVs, in a backwards-compatible way and without
changing existing functionality yet) with the hope that the core
functionality would then be more easily extractable and could be made more
generic.

I'd be reluctant to start a "newadmin" in core just yet without extensive
design discussions first taking place on this topic. However, nothing
prevents you or anyone who's interested to push this along by starting it
outside of Django and then potentially merge it to core once it reaches a
satisfactory state. I see that step #4 could be done in core regardless,
though, and my point is that this work would benefit other efforts that are
put into the full newadmin rewrite as it'd give us some empirical evidence
of what does or doesn't work, quickly highlighting any major snag in the
process.

Julien

-- 
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: Splitting out admin functionality

[Julien Phalip]

On 11 October 2011 12:22, tWoolie
wrote:

> > If someone is willing to take this on then I'd be happy to provide some
> > support by reviewing patches, giving feedback etc.
>
> Cheers. Would you be willing to review code that swaps out entire
> swathes of admin functionality?


Yep. Could you outline your plan of attack for this?

Julien

-- 
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: Splitting out admin functionality

[Julien Phalip]

Hi,

On 10 October 2011 15:20, tWoolie
wrote:

> I'd like to propose a project to split out the table/list
> functionality and the filtering functionality in the django admin into
> a seperate contrib app. This is really core functionality which is
> lacking from django (in terms of being locked to the admin app).
> I believe this would be beneficial because currently there are a lot
> of people who love using the admin interface but find building the
> same functionality into their own applications daunting at best. This
> leads a lot of people to try to abuse the admin app by allowing
> regular users into there.
>
> I propose moving a lot of the django-tables2 functionality into a
> contrib app and augumenting it with filterspec. Then the admin can use
> this app, or any custom subclass of Table/Filter. Currently, django-
> tables2 is fantastic but has no support for filterspecs which would be
> super super helpful, and would benefit from the level of [url]
> abstraction that d-t2 provides.
>
> I'm posting to this group to gather feedback and ask if anyone would
> actually like to see this happen. I believe it's something i'd love to
> contribute but only if the django devs would be interested in
> incorporating it.
>
> Thomas


Making the admin's codebase more flexible and reusable is definitely
something that we should aim for. In fact, there have been lots of group
discussions about this during DjangoCon. Idan and I will try to post a
detailed summary to this list soon. In a nutshell, the aim is to make the
admin more lightweight and modular so that its various components can easily
be replaced or used in different contexts. It's quite likely that a full
rewrite will eventually be necessary, following the same path as
oldforms/newforms: "newadmin".

However, I think at this stage one great way to start would be to refactor
the current admin to make use of class-based views. This would be good for a
number of reasons:

- Dogfooding: having a concrete real-world app in Django core would help
drive improvements and extensions to the CBVs themselves.
- The admin codebase would reach a position where abstracting its core
functionality out gets easier.
- This would help quickly anticipate issues (both from a technical and
usability point of view) to do with ravioli code [1].
- A complete rewrite would likely take time and would realistically not ship
in Django before the next 2-3 releases -- unless someone pulls out the work
to make me lie :-). Adding CBVs would quickly open the door to a lot of
possible improvements in oldadmin, which would in turn inform the parallel
development of newadmin.
- This would make the future transition and upgrade path to newadmin easier.

If someone is willing to take this on then I'd be happy to provide some
support by reviewing patches, giving feedback etc.

Cheers,

Julien

[1] http://lukeplant.me.uk/blog/posts/class-based-views-and-dry-ravioli/

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

jQuery.noConflict() vs. jQuery.noConflict(true)

[Julien Phalip]

Hi,

During the recent DjangoCon sprints there have been some discussions between
Jannis, Rob Hudson and I around a change which occurred in trunk a few
months ago in r16415 [1]. This change specifically made the admin use
jQuery.noConflict() instead of jQuery.noConflict(true) while namespacing its
embedded jQuery library. This change had been motivated by some concerns
raised on django-dev about the previous behaviour impeding third party
plugins relying on the presence of jQuery in the base namespace [2].
However, since that commit there have been some counterbalancing concerns in
#16776 about the change making it harder to use multiple versions of jQuery
[3].

The problem is that all the discussions so far have been quite speculative.
No concrete example of how problematic this boolean would be, whether turned
on or off, has been presented. We'd like to avoid breaking things in the
upcoming 1.4 release, so we'd appreciate getting some feedback from
developers who are used to customizing the admin with third party plugins or
with multiple versions of jQuery.

Currently the consensus is the status quo. If you have strong opinions on
whether or not the change in r16415 should be reverted, then please provide
concrete arguments for it. If you know how this question is handled in other
frameworks then that would also be quite useful to hear about.

Many thanks!

Julien

[1] https://code.djangoproject.com/changeset/16415
[2]
http://groups.google.com/group/django-developers/browse_thread/thread/c91da363ef335629
[3] https://code.djangoproject.com/ticket/16776

-- 
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: confusing things in Trac UI (was: Design decision for #1625...)

[Julien Phalip]

On 20 September 2011 14:16, Carl Meyer  wrote:

> On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote:
> > Well, I meant to mark accepted as endorsement of the patch, but that
> > made me owner.
>
> Yeah, this is confusing in our Trac UI. The "accept" radio button at the
> bottom assigns the ticket to you, it doesn't actually do anything with
> the triage state. To change the ticket from DDN to Accepted you'd use
> the dropdown next to "Triage Stage" up in the box above.
>
> I'd be in favor of just removing that "accept" radio button if it isn't
> hard to do; doesn't do anything you can't do with the "reassign" option,
> just gets confused with the triage state.
>

I too am in favour of removing this button, if that's possible. It adds no
value and causes confusion.

> I can't own it since I'm not a core committer.
>
> Hmm, I wasn't aware of this policy. We don't seem to make real
> consistent use of the "owned by" field, but as far as I was aware it was
> just a way to signal that you were working on this ticket so someone
> else with interest would check with you before diving in and doing a
> bunch of work. I thought anybody could make use of this field if they
> planned to push the ticket forward and wanted to signal that.
>

There is actually a policy for using this field which more or less matches
your assumption. It is documented here:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#claiming-tickets

However, the doc could certainly do with further clarifications. Patches
welcome :P

Julien

-- 
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: filter_horizontal back button issue under webkit

[Julien Phalip]

Hi John,

On 9 September 2011 11:28, John  wrote:

> Hi All,
>
> This is in regards to ticket #13614 (Back button breaks many to many
> widget).  I'm hoping that bringing this up might bring some attention
> to it.  This is a rather nasty bug affecting the filter horizontal
> widget's use with webkit browsers.  It causes data loss and incorrect
> data to be saved if the user isn't extremely careful.  Full details
> and steps to reproduce are in the ticket, however briefly the issue is
> if you save an object from a change form in the admin and then hit the
> back button the filter horizontal widget is populated with incorrect
> data.  Additionally simply navigating away from a change form and then
> hitting the back button results in the filter horizontal widget not
> being populated with data at all.  If the user saves after either of
> these cases, the incorrect data is saved to the database.
>
> This issue is severe enough that we've had to drop all filter
> horizontal widgets from our admin interface.


I concur that there is a serious data loss risk here. As a start, it would
be interesting to track down whether the root cause lives in Webkit itself
or in the admin's JS code. Any help investigating this would be appreciated.

Julien

-- 
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: Browser Support

[Julien Phalip]

On 30 August 2011 19:08, Julien Phalip <jpha...@yahoo.fr> wrote:

> ... perhaps the FAQ?
>

That is, assuming we'd consider this a potentially frequently-asked question
:)

-- 
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: Browser Support

[Julien Phalip]

On 30 August 2011 17:33, Idan Gazit  wrote:

> So, a while back, I announced that Django is dropping support for IE6 in
> the admin. What I _didn't_ specify is what browsers are supported.
>
> I'm currently composing a bit for the 1.4 release notes about admin browser
> support, and wanted to explicitly list what we consider to be supported:
> YUI's A-Grade, minus IE6.
>
> Link: http://yuilibrary.com/yui/docs/tutorials/gbs/
>

+1! A note in the docs would also be useful, although I'm not exactly sure
where -- perhaps the FAQ?

-- 
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: What is Django?

[Julien Phalip]

On 26 August 2011 07:55, Amirouche Boubekki wrote:

> 2011/8/25 Mikhail Korobov 
>
>
>> There are many big and well-known sites built with django and I think
>> mentioning these sites and providing testimonials from people working on
>> these sites can be better advertisement.
>>
>
> Yes and no. Advertising on big websites & applications powered by django
> would be a plus but it can be misleading. I think anybody could agree that
> this same applications could have been done in PHP or Flask with the same
> success (see Facebook ?).
>

While there are successful and large websites out there built with any
technology under the sun, I believe it is important to show that you *can*
use Django to build such sites. Nobody will trust that you are webscale™ until
you can show some concrete evidence of it :-)

Seeing that there are successful and large websites built with Django
certainly isn't enough to convince someone but it isn't just a plus either.
It is rather the *bare minimum* one needs to be reassured that they're not
wasting their time learning this new framework.


> Engineers and people that take decisions in general want to know if it gets
> things done, but also how does it compare to other solutions.
> Comparing on features would be more engineer-minded that «How do you feel
> about Django». Engineering is not about feelings, it's a complex choice that
> weights pros & cons which can be technical but also social and commercial...
>
>
> In javascript world is common to compare frameworks based on speed, size,
> we could extend this to common problems regarding website building like
> cache management, authentication, authorization, L10N, I18N, db support,
> professional support, community support and the like... and even do code to
> code comparison if it makes sens.
>

Comparisons are important but I'd rather encourage third parties to write
them up. Comparisons can really only be trusted from people who have
extended experience in all the compared frameworks and who do not appear
biased towards one or another. One should always be cautious with
websites/frameworks/products/whatever boasting that they are so much more
awesome than the others :-)

Julien

-- 
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: MultipleObjectMixin and Pagination

[Julien Phalip]

Hi Andrew,

On Jul 1, 9:12 am, Andrew Ingram  wrote:
> Hi All,
>
> I've been working with Django's class-based views a fair bit recently,
> specifically to create some additional ones (dealing with formsets
> mostly). I've been trying to inherit as much of the existing
> functionality as possible, but I've hit a bit of a snag.
>
> I've a ModelFormSetMixin which extends MultipleObjectMixin, much like
> how ModelFormMixin extends SingleObjectMixin in core.
>
> I want to take advantage of the pagination that MultipleObjectMixin
> provides, but I need it at the point of instantiating the FormSet.
> Currently MultipleObjectMixin does all the pagination handling in
> get_context_data which means I have to either re-implement a lot more
> functionality than I'd like, or execute the pagination calculation
> twice.
>
> My ideal solution would be for MultipleObjectMixin to be changed to
> have the pagination handled as early as possible so that I can take
> advantage of it for free.
>
> This is only one use case, but I'm sure there are more. I'm happy to
> try and come up with a patch if there's some agreement on this.
>
> The FormSet views I've developed can be seen 
> here:https://github.com/AndrewIngram/django-extra-views/blob/master/extra_...
>
> Regards,
> Andrew Ingram

I think your proposal makes sense and it's generally a good idea to
add more flexibility to class-based views (unless it over-complicates
the API, of course). It would definitely help assess the usefulness of
this if you posted a patch with a concrete test case, so feel free to
open a ticket. You might also be interested in ticket #16256, which is
looking at adding similar generic views to core. Perhaps this is
something you would like to contribute to based on your own experience
and use case?

https://code.djangoproject.com/ticket/16256

Regards,

Julien

-- 
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: Additional example for reverse_lazy documentation

[Julien Phalip]

Hi Alasdair,

On Jun 30, 7:49 am, Alasdair Nicol  wrote:
> Hi,
>
> I like the upcoming reverse_lazy in Django 1.4 (commit 16121). I suggest
> the examples should include using reverse_lazy in urlpatterns.
>
> I just helped a user out in stackoverflow [1] who was struggling with
> NoReverseMatch errors because their url patterns used reverse for
> optional arguments. I think adding an example might stop users from
> struggling with the same problem in future.
>
> My suggested one line addition to the examples in [2] is
>
>   * providing a reversed url in a URL pattern as an extra argument to
> the view function.
>
> On the other hand, I realise that the documentation is stating "some
> common cases", it doesn't have to be exhaustive.
>
> I'd like to make a ticket and patch if people think this is a good idea.
>
> Regards,
> Alasdair Nicol
>
> [1]:http://stackoverflow.com/questions/6512610/django-url-error-in-templa...
> [2]:https://docs.djangoproject.com/en/dev/topics/http/urls/#passing-extra...

This is a good suggestion. Feel free to open a ticket. In fact, the
doc about reverse_lazy could be further improved by providing some
concrete code samples -- so if your patch contains some, all the
better ;-)

Julien

-- 
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: Javascript Testing

[Julien Phalip]

Hi Sean,

On Jun 18, 4:24 am, Sean Bleier  wrote:
> Hello everyone,
>
> A couple months ago I started work on a django branch [1] (with the help of
> @jezdez) that introduces a framework for writing javascript unit tests using
> QUnit[2].  I started with QUnit because Django already included jQuery in
> the admin and seemed like a natural extension, but it would be nice to hear
> opinions from people that know more about javascript testing than I.
>
> Since I haven't touch it in a couple months, I thought I would share it with
> django-developers to get some more eyes on it and discuss any missing
> features or implementation details. It also be nice if Idan or any other
> designery person could look it over and give some UI/UX advice.
>
> Just to give a overview, the javascript testing framework is initiated by
> first collecting static media and then starting a special runserver:
>
>     ./manage.py collectstatic
>     ./manage.py jstest
>
> This starts a runserver that collects and serves everything you need to run
> the javascript tests found within an installed app. More detail can be found
> in these preliminary docs[3], though they need to be moved into their proper
> place within the docs directory.
>
> I'm hoping we can figure out a way forward so that we can start writing
> tests for the admin and elsewhere.
>
> Cheers,
>
> --Sean
>
> [1]https://github.com/sebleier/django/tree/qunit
> [2]http://docs.jquery.com/Qunit
> [3]https://github.com/sebleier/django/blob/qunit/django/test/javascript/...

Thanks a lot for working on this. Django is in dire need of a solid
javascript test framework.

I've actually been looking at this branch a few weeks ago and it's
looking very promising! I had a few remarks and questions.

Do you have any specific plans for testing the admin *interface*? My
main concern is that to properly test complex interactions (e.g.
dynamically adding or removing admin inlines), you would need to have
a DOM based on the up-to-date admin templates and on some test data.
Is it envisaged to plug the QUnit test platform in with a running
instance of Django that would supply admin pages on the fly, or
perhaps to introduce a management command that would generate HTML
files using the up-to-date admin codebase?

Also, one curse of javascript is that it doesn't always behave quite
the same on all browsers. It would be absolutely awesome if the
process of testing on multiple platforms and browsers could be
automated in a CI environment. The Mozilla guys have done some work in
that area: https://github.com/kumar303/jstestnet -- I haven't tried it
myself yet. Do you think this could be looked into for Django itself?

Then, as currently in your branch, QUnit tests are expected to be put
in a "tests/javascript/" folder. Does it mean that the same folder
structure can be used to run other types of JS test runners? If not,
would it be best to use a more explicit structure and require that
tests be put in, for example, "tests/qunit/", in order to leave the
room for other JS test runners to be supported in the future?

Finally, a ticket has recently been created in Trac for this:
https://code.djangoproject.com/ticket/16193 -- 'mbraak' posted a patch
with a few simple tests for the admin JS. It'd be great to see how
both your works integrate.

Thanks again, this is awesome!

Julien

-- 
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: 5-for-1?

[Julien Phalip]

On Jun 18, 11:38 am, Stephen Burrows 
wrote:
> I would love it if someone could look at 13956 [1]

RFC'd, thanks ;)

Julien

-- 
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: Logging configuration and handle_uncaught_exception

[Julien Phalip]

On Jun 17, 10:48 pm, Matt Bennett  wrote:
> > This is a case for a custom Filter object [1]. The filter object
> > implementation would only be a few lines, to reject logging when DEBUG
> > is True, and can be attached to the admin email handler in the default
> > logging configuration. [2] This way the logging call can occur in all
> > code paths, and the admin email handler itself can remain
> > general-purpose, but the backwards-compatible behavior can be maintained.
>
> > Matt, if you'd be willing to open a ticket for this, that'd be helpful.
> > If you feel like putting together a patch using the Filter approach,
> > that'd be even better ;-)
>
> Here you are:https://code.djangoproject.com/ticket/16288
>
> Since logging Filters are not specific to an individual logger or
> handler, I've just called it DebugFalseFilter. It's not a pretty name,
> but I couldn't come up with anything better - I decided it should
> convey what the filter allows through, but AFAIK there's no name for
> "not debug mode".
>
> Matt.

Hi,

Just noting that another "filtering" functionality has recently been
added to trunk [1]. It is a different kind of filtering than what's
being discussed here -- it is to filter out sensitive information from
error reports when they're being produced. Maybe the naming of one of
those functionalities might need to be reconsidered in order to avoid
confusion in the docs and APIs. I'm not sure. Just thought I'd point
it out ;)

(By the way, "production" is a common generic term used for when DEBUG
is False)

Julien

[1] 
https://docs.djangoproject.com/en/dev/howto/error-reporting/#filtering-error-reports

-- 
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: FYI: added a proper "easy" field to Trac

[Julien Phalip]

On Jun 16, 10:32 am, Julien Phalip <jpha...@gmail.com> wrote:
> On Jun 16, 3:08 am, Alex Kamedov <kame...@gmail.com> wrote:
>
> > Django documentation page Contributing to Django [1] has the same problem
> > too
> > [1]https://docs.djangoproject.com/en/1.3/internals/contributing/
>
> I've fixed the link in the wiki page. The doc is already fixed in
> trunk.

By the way, anybody with a Trac account should have edit access to the
wiki, so feel free to make the change directly next time you find an
inconsistency ;)

Julien

-- 
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: FYI: added a proper "easy" field to Trac

[Julien Phalip]

On Jun 16, 3:08 am, Alex Kamedov  wrote:
> Django documentation page Contributing to Django [1] has the same problem
> too
> [1]https://docs.djangoproject.com/en/1.3/internals/contributing/

I've fixed the link in the wiki page. The doc is already fixed in
trunk.

Thanks,

Julien

-- 
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: Sorting UX question

[Julien Phalip]

On Jun 9, 9:45 am, Luke Plant  wrote:
> In the new admin sorting UI, which now supports sorting on multiple
> fields, the behaviour can be described by the following two rules:
>
> 1. If you click on a header, it is made the primary sort field
>    (with others moved down the list as necessary).
>
> 2. If you click on a header that was already part of the sorting,
>    the sort order for that field is reversed.



> We could change the 2nd rule to:
>
> 2. If you click on a header that was already the primary sort field,
>    the sort order for that field is reversed.

The difficulty in the interface design here is that there are three
different possible behaviours, all operated by the same user action
(i.e. clicking on a header): selecting a field for sorting, ordering
the sorting fields, and toggling sorting for a given field. I actually
think that the current interface already does a pretty good job
dealing with this. Having two different behaviours for the same
action, as suggested by your new #2 rule, would actually make it less
intuitive and potentially confusing, I think. Whatever the behaviour,
good or bad, it's always better if the user can predict it (and
quickly fix it if necessary).

Perhaps the interface could be improved by dissociating the clicking
on the header and the clicking on the arrow icons. Clicking on the
header would do exactly the same as currently, i.e. select the field
for sorting, make it the primary sorting field, and toggle it. Then,
clicking specifically on the arrow icon would simply toggle the
sorting for that field, without making it the primary sorting field
(unless it already is) and without changing the order of sorting
fields.

Separately highlighting the arrow icons and the header in visually
different ways on mouse hover (e.g. change the header's background
when hovered, display an arrow icon with a different colour when
hovered) would indicate that both are associated with two different
behaviours. Adding tooltip texts would also help (e.g. for the arrow
icon: "Toggle the sorting for this field without affecting the order
of sorting fields").

I think this would resolve the main issue for me with this interface,
which is that it's frustrating having to change the order of sorting
fields when all you want is toggle a given sorting field. This is
already possible to do via clicking "toggle" in the popup, but I think
that clicking directly on the arrow would feel better and be more
intuitive.

It is a complex interface problem. Generally in this case it's OK if
the user doesn't get exactly what she wants in the first go, but at
least the interface should be forgiving and recovery should be quick.

My two cents ;-)

Julien

-- 
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: Adding UI and UX fields to Trac

[Julien Phalip]

On Jun 8, 12:25 am, Luke Plant  wrote:
> On 07/06/11 11:32, Idan Gazit wrote:
> > I'd like to propose adding two flags to Trac, "UI" and "UX".
> So would it be better to have just "UI/UX"?

I totally agree that Trac needs something specific for this, as it's a
shame we have to remove admin-related tickets from the contrib.admin
component.

I also agree with Luke that having two different fields could be
confusing. UX encompasses UI so both are not completely orthogonal
from each other. How about a single "User experience" flag? Or maybe
something more explicitly targeted to the end goal, like a "Needs
designer's talents" flag?

Julien

-- 
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: Preventing the leaking of sensitive information in error logs

[Julien Phalip]

Many thanks to all for the feedback. I've just posted a new patch,
welcoming any further feedback:
https://code.djangoproject.com/attachment/ticket/14614/14614.exception-reporter-filter.diff

Regards,

Julien

-- 
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: Preventing the leaking of sensitive information in error logs

[Julien Phalip]

On Jun 1, 7:53 pm, Luke Plant  wrote:
> Would it possible to make the sensitive decorator add some kind of
> strategy object to the request, which itself is responsible for the
> filtering, rather than a simple boolean flag?

The GET/POST parameters appearing in the error logs come from the
HttpRequest's __repr__() method. So in fact my initial patch did let
the HttpRequest itself take care of the obfuscation of sensitive GET/
POST parameters, in a similar way as with HIDDEN_SETTINGS and
get_safe_settings in the django.views.debug module:

https://code.djangoproject.com/attachment/ticket/14614/14614.obfuscate-request-parameters.diff
https://code.djangoproject.com/ticket/14614#comment:6

However, Russell comment was that the issue here is purely related to
debugging or logging business, and therefore the HttpRequest shouldn't
have to be involved directly. This makes it difficult to have any fine-
grained control over request parameters though.

> The strategy object interface might be:
>
> class ExceptionReporterFilter(object):
>     def show_request(self, request):
>         # return True or False
>
>     def filter_request_POST(self, request, post_dict):
>         # if show_request is True, this is passed request.POST
>         # and returns a sanitised version
>
>     def show_traceback(self, request):
>         # True or false
>
>     def show_traceback_vars(self, request):
>         # called only if show_traceback() returns True
>
>     def filter_traceback_vars(self, request, tb_frame, vars):
>         # filters vars to be shown at each level.
>
> OK, could get carried away there - maybe we should start simple, e.g.
> just 'show_request' and 'show_traceback_vars'. But something like that
> would allow us to provide a working 'sensitive' decorator, but with a
> mechanism that allows for something more fine-grained, and allows us to
> add more features to it easily in the future. For the admin and CBVs it
> would work as well, since there are always places you can override a
> method and attach something to the request object.

I quite like this and will try it in a new patch.

Thanks for the feedback!

Julien

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

Preventing the leaking of sensitive information in error logs

[Julien Phalip]

Hi,

Recently I've been a bit embarrassed to receive a 500-error email
report containing a client of mine's password displayed in clear
because the admin login view had encountered an unhandled exception.
This is probably OK in a debug environment but in production this can
potentially have damaging consequences when handling passwords, credit
card numbers, etc. It may also go against certain policies and
standards such as the PCI-DSS (http://en.wikipedia.org/wiki/
Payment_Card_Industry_Data_Security_Standard).

There is already an open ticket to address this issue:
https://code.djangoproject.com/ticket/14614

I first wrote a patch allowing a lot of granularity to control which
POST/GET parameters should get obfuscated when producing the error
logs: 
https://code.djangoproject.com/attachment/ticket/14614/14614.obfuscate-request-parameters.diff

Russell pointed out that this implementation approach was overly
complicated. It also doesn't address the stack frame variables being
logged in some situations. So I've posted another patch with a more
radical approach, where all stack frame variables and the request's
information are systematically and entirely omitted from the logs for
exceptions occurring in views marked with the @sensitive decorator:
https://code.djangoproject.com/attachment/ticket/14614/14614.sensitive-request.diff

Perhaps the ideal solution lies somewhere between the two approaches.
The default loggers should also probably provide this protection by
default but still allow easy customisation/overriding of this
behaviour, for example for debugging purposes in safe environments.

I'm bringing this up to the dev-list as I'm keen to hear if someone is
interested in this problem and has suggestions towards a robust
solution. It is a pretty serious issue that I hope can be resolved by
the 1.4 release.

Many thanks,

Julien

-- 
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: Reshaping the "Contributing to Django" documentation

[Julien Phalip]

On May 21, 2:15 am, "Jonas H."  wrote:
> > "[...] try and duplicate it. If you can duplicate it [...]"
>
> I'd stick with "reproduce" here because "duplicate" may be confused with
> "duplicate tickets".

Yes that's a good point. I fixed that in the latest patch. 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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Reshaping the "Contributing to Django" documentation

[Julien Phalip]

On May 21, 1:33 am, Waylan Limberg  wrote:
> One nitpick thought. I expect that people reporting bugs will go to
> the "bugs-and-features" page, which is fine. However, as is often the
> case, when their ticket is marked "accepted" (or some other triage
> stage) they often get confused about what that means (as we all know).
> If they are only looking to get their one ticket fixed, I doubt they
> will find on there own the explanations of the various stages now
> under "triaging-tickets" ("I just want my one ticket fixed. I don't
> have time to work on other peoples tickets, Why would I look there?").
> Perhaps a link to those explanations should be added to the
> "bugs-and-features" section? Just a thought.

Thanks for the tip! In the latest patch I've added such links at the
bottom of those two sections:
http://dl.dropbox.com/u/3364022/djangodoc/internals/contributing/bugs-and-features.html#reporting-bugs
http://dl.dropbox.com/u/3364022/djangodoc/internals/contributing/bugs-and-features.html#requesting-features

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

Reshaping the "Contributing to Django" documentation

[Julien Phalip]

Hi there,

I've been working on reshaping the documentation about contributing to
Django, in particular the rather dense historical page [1] and the
excellent recently added how-to guide [2]. This documentation has sort
of grown organically over the years and has become a bit difficult to
read, so I tried to improve things a bit.

I've submitted a patch in the designated ticket: 
http://code.djangoproject.com/ticket/15796
You can also browse the html output here:
http://dl.dropbox.com/u/3364022/djangodoc/internals/contributing/index.html

The vast majority of the content was preserved. What I've done is:

- broke the content down into logical sections.
- merged information about "the documentation" from [1] and [3].
- merged information about "ticket triage" from [1] and [2].
- made a few edits, clarified a few things here and there, shifted a
few bits around and smoothed out the transitions.
- cross-linked the various sections.
- added descriptions for the recently added "type" and "severity"
attributes.
- added a few suggestions for ways new contributors can help.

I hope that it turns this documentation into a more maintainable and
extensible shape and, as a result, that it will facilitate
contributions from the community.

It is a big change so I thought I'd bring it up here in case you have
ideas and suggestions to improve it further or differently. Any
feedback is welcome.

Thanks a lot!

Julien

[1] http://docs.djangoproject.com/en/dev/internals/contributing/
[2] http://docs.djangoproject.com/en/dev/howto/contribute/
[3] http://docs.djangoproject.com/en/dev/internals/documentation/

-- 
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 fields options

[Julien Phalip]

On May 7, 2:21 am, Alex Gaynor  wrote:
> Sounds like a bad idea to me.  unique_together doesn't exist on a specific
> field precisely because it isn't an option for any specific fields, it's for
> a set of fields.  All the other options belond to specific fields.

I agree in principle, however I've recently come across a use case
where being able to *override* an individual field's options (in my
case 'unique') with a simple API from the Model's Meta options would
have been nice: http://code.djangoproject.com/ticket/15953

I don't know enough about the ORM to predict if that sort of things
could have bad side effects. What do you think?

Julien

-- 
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: PatchHammer 40,000

[Julien Phalip]

On May 6, 8:25 am, Luke Plant  wrote:
> I do think this could be useful though. If someone submits a patch that
> *immediately* doesn't apply to trunk, then it will be useful to know
> that, and hooking this in to Trac at the point the patch is uploaded
> would be useful.

On a related note, it would be great to focus on reviewing the most
recent patches, as those are the ones which are more likely to still
apply to trunk and to reflect a more up-to-date discussion, and
therefore are the ones that are standing a better chance for inclusion
in core.

This is the query to get them:
http://code.djangoproject.com/query?status=assigned=new=reopened_better_patch=0_tests=0_docs=0_patch=1=Accepted=1=changetime

This is the same query as the one in the Reports page ("Patches that
need review" in http://code.djangoproject.com/wiki/Reports) except
ordered by descending "modified" date. If you think it's useful, could
someone with write access edit the Reports page with that query?

Cheers!

Julien

-- 
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: Make redirection customizable in ModelAdmin view

[Julien Phalip]

On May 4, 4:13 pm, Yishai Beeri  wrote:
> +1 on breaking backwards compatibility, defaulting the arg to None.

Just a note. Defaulting to None in itself does not break
compatibility. Defaulting to None allows to do the url reversal from
inside response_add. But then the tradeoff of preserving backwards
compatibility is that we need to write some convoluted/ugly code (see
[1]). But I think the main motivation here for breaking compatibility
is to allow for more flexibility, as the developer could provide
whichever url they want (in the form of a pre-formatted string).

> However, in [1] Julien suggests to also allow a callable - which I think  
> would be very useful, and provide all the flexibility one would need.

I too think that could be useful but it might be a bit much for a
start. At this stage I'd preferred to wait till we hear from concrete
use cases where this would be needed. It can always be added later as
a new feature.

Julien

[1] 
http://code.djangoproject.com/attachment/ticket/8001/8001_redirection_backward_compatibility.diff

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

Re: Make redirection customizable in ModelAdmin view

[Julien Phalip]

On May 4, 10:59 am, Dario Ocles  wrote:
> Hello everybody.
>
> Ramiro Morales and me were working on this ticket #15294 [0] and
> Julien linked this one #8001 [1]. We had a little discussion about two
> possible solution for #8001 and Julien suggested that we should hear
> your opinion (you can read all comments on ticket #15294).
>
> The discussion was about if we have to take care of backward
> compatibility on this issue.
>
> I uploaded two patches to #8001, one of them taking care of backward
> compatibility.
>
> I think that the reason for keeping backward compatibility, is just
> that it is good.
>
> And the reasons for deprecating the old behavior are:
> - Cleaner code.
> - This is not a documented part of Django's API, so we either can or
> cannot take care of backward compatibility.
> - I don't like to put any ugly try/catch.
>
> I'm sorry for my English.
>
> Regards,
> Dario Ocles (burzak).
>
> [0]http://code.djangoproject.com/ticket/15294
> [1]http://code.djangoproject.com/ticket/8001

Thanks for bringing this up, Dario. I'll try to summarise here the
discussion that we've had in those tickets.

As part of the effort in #15294 to remove all hardcoded urls from the
admin's codebase, it was suggested that the hardcoded
post_url_continue parameter in the response_add method be addressed as
well:

def response_add(self, request, obj, post_url_continue='../%s/'):
...

post_url_continue is generally used to redirect you to the new
object's change page after it's been created. Since it is impossible
to reverse that object's change page url if you don't know the
object's model details and primary key, it was suggested that
post_url_continue default to None and that the url be reversed from
inside the response_add method.

Now, it was also pointed out that the current use of post_url_continue
was a bit limiting in that it assumes the value to be a formattable
string with one format parameter (i.e. the pk). There is a backwards
compatible way of dealing with this [1], and a backwards incompatible
way [2]. The former first assumes that it receives a formattable
string like in the "old" way, and if that generates an error then it
assumes it's a pre-formatted string. The latter only assumes it's a
pre-formatted string. I personally tend to prefer the latter as the
implementation is cleaner and also more flexible -- it is based on the
assumption that it is the developer's responsibility to provide a pre-
formatted string if they want to override the default behaviour,
instead of letting Django's response_add method do the formatting for
you.

If we go with [2] then this may be a small inconvenience for people
who are relying on the current behaviour of response_add, but the
upgrade path is very easy (i.e. just format the string yourself).
Also, response_add is not officially documented.

So, this all leads to the reason why this was brought up to the dev
list: shall we go ahead and break backwards compatibility? As far as I
can tell from the policy [3] we're pretty safe to go ahead, but it'd
be helpful to collect more opinions on this (and if possible also more
generally on the rest of the admin's codebase).

Thanks a lot!

Julien

[1] 
http://code.djangoproject.com/attachment/ticket/8001/8001_redirection_backward_compatibility.diff
[2] http://code.djangoproject.com/attachment/ticket/8001/8001_redirection.diff
[3] http://docs.djangoproject.com/en/dev/misc/api-stability/

-- 
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: NoSQL support

[Julien Phalip]

On Apr 28, 4:59 pm, Russell Keith-Magee 
wrote:
> I haven't used the django-nonrel branch, and I'm not aware of anyone that
> I know and trust that has.

For what it's worth, I am currently using django-nonrel and its
companions djangoappengine, djangotoolbox, and django-dbindexer [1] in
a project on Google App Engine and so far I have been impressed by how
stable and simple it is to use and by how closely it tracks Django
trunk.

I can't vouch for the implementation details as I haven't reviewed
them very closely and I don't know enough about all the issues at
stake, but I can vouch for its simplicity of use and for the fact that
it does work in real projects. All in all, django-nonrel appears to me
as a very promising solution.

Cheers,

Julien


[1] http://www.allbuttonspressed.com/projects/djangoappengine#installation

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

A coupla patch reviews

[Julien Phalip]

Hi there,

I've just posted a patch for #14262 to add a new assignment_tag helper
function. Is anyone keen to review it?

Also, it would be great if someone could review the latest patch for
#15805. If that one gets checked in then we'll also be able to fix
#14608 and then I'll start work on #15838.

Many thanks!

Julien

http://code.djangoproject.com/ticket/14262
http://code.djangoproject.com/ticket/15805
http://code.djangoproject.com/ticket/14608
http://code.djangoproject.com/ticket/15838

-- 
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: Request for comments: custom admin filters

[Julien Phalip]

On Apr 14, 8:46 am, Julien Phalip <jpha...@gmail.com> wrote:
> Thanks a lot for your feedback. I agree with all your points and have
> made the corresponding amendments in a new 
> patch:http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filt...

Sorry, just in case you've already started reviewing the patch (but no
rush!), I've just realised I had missed one small thing in it, which
is now fixed: the get_query_set() method now receives the request as
parameter too.

Everything is now ready for review in the latest patch:
http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filterspecs.5.diff

Thank you!

Julien

-- 
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: Request for comments: custom admin filters

[Julien Phalip]

On Apr 14, 3:11 am, Jacob Kaplan-Moss  wrote:
> Hi Julien --
>
> Thanks for your work on this! I'm working my way through the patch,
> and it's looking good. I'm pretty happy with the internals, though I
> do have some questions about the public API:
>
> * I'm rather unhappy with the `SimpleListFilter`/`FieldListFilter`
> breakdown, and especially the way `FieldListFilter` is documented.
> This isn't friendly:
>
>     Note that this method is far more complex than simply using a field
>     name or a ``SimpleListFilter`` class, as there currently is no simple
>     way available to manipulate a ``FieldListFilter``. You may, however,
>     find some useful examples with the built-in filters defined in
>     :mod:`django.contrib.admin.filterspecs`.
>
> Ugh.
>
> It seems to me that `FieldListFilter` is something of an internal
> detail required to maintain the existence of a bunch of pre-refactor
> stuff, right? If so, I think I'd like to see `SimpleListFilter`
> renamed to something more obvious (maybe call it `ListFilter` and call
> the parent class `BaseListFilter` or collapse it into a single class).
> Then the docs can explain that a list filter could be a
> `FieldListFilter` but that that API is considered internal and prone
> to change/refactoring. Make sense?
>
> * There's a weird discrepancy (to me) between the signatures of
> `get_choices(self, request)` and `get_query_set(self, changelist,
> queryset)`. I'd expect to have the `request` available to both
> methods, I think, and I don't really know what `changelist` is doing
> there or what I'd use it for. Can you talk a bit about why those
> signatures work that way?
>
> * `def get_title(self): return "size"` seems like overkill -- why not
> just `title="size"`?
>
> Thanks again!
>
> Jacob

Hi Jacob,

Thanks a lot for your feedback. I agree with all your points and have
made the corresponding amendments in a new patch:
http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filterspecs.4.diff

Let me know if you've got any further feedback on this.

Cheers!

Julien

-- 
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: Request for comments: custom admin filters

[Julien Phalip]

Hi Mikhail,

On Apr 14, 4:56 am, Mikhail Korobov  wrote:
> Will your patch simplify creating filters not based on choices? E.g.
> min/max filters where exact minimun and maximum values can be entered
> (using form with method=GET and input fields for values)? I want a
> pony ;)

No, this patch does not allow this. This would be a new separate
feature. Feel free to open a ticket ;)

> It would also be good to make FilterSpec.output using template, not
> the hardcoded python.

I totally agree that using a template would be better, but I'd like to
keep this patch focused on what has been requested in #5833. Again,
feel free to open a specific ticket for that ;)

Julien

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

Request for comments: custom admin filters

[Julien Phalip]

Hello there,

I've just posted a patch with a suggested implementation of custom
admin filters: 
http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filterspecs.3.diff

I've written some pretty comprehensive tests and have also had a stab
at writing some documentation. You should find all the details there
but I thought I'd give a little teaser here first. Here's an example
of what you could do with it:

The model:

class Book(Model):
title = models.CharField()
pages = models.PositiveIntegerField()

The admin:

from django.contrib import admin

class BookSizeFilter(admin.SimpleListFilter):

def get_title(self):
return u'size'

def get_choices(self, request):
return (
(u'small', u'Small'),
(u'medium', u'Medium'),
(u'large', u'Large'),
)

def get_query_set(self, changelist, queryset):
size = self.get_value()
if size == u'small':
return queryset.filter(pages__gte=1, pages__lte=100)
if size == u'medium':
return queryset.filter(pages__gte=101, pages__lte=200)
if size == u'large':
return queryset.filter(pages__gte=201)
return queryset

class BookAdmin(admin.ModelAdmin):
list_filter = [BookSizeFilter,]

Custom filters is a feature that has been requested by many people and
for a long time. If you're one of those eager people, it would be
awesome if you could take a look at the patch and, if you like the
proposed API, try it in your own real projects to see if all the edge
cases are covered.

I'm also really keen to hear your thoughts on the various sub-features
that ship with that patch, on the suggested API, and on the various
implementation details.

The patch is pretty hefty so I'd really like to take this to a close
ASAP before it grows stale and becomes harder to maintain.

Many thanks!

Julien :-)

-- 
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: Something wrong about AssertRaisesRegexp and assertFieldOutput

[Julien Phalip]

On Apr 12, 2:00 pm, Karen Tracey  wrote:
> Adding re.escape in that function does break some tests, from a quick look
> it seems mostly ones that are raising multiple errors but only one has been
> listed by the caller of that utility function. It isn't clear to me from the
> docstring of that utility function how it is supposed to work in this
> case...is the caller required to be passing in all errors or is the function
> supposed to find it acceptable if the raised errors include the one that is
> passed in? I don't know.

Thanks for looking into this, Karen. I agree that the API for
assertFieldOutput is quite confusing. Since assertRaisesRegexp does a
search (and not a match), I guess it means that providing one of the
errors is enough to pass the test. However, regardless of that, from
an end-user perspective it doesn't really make sense that it uses
regular expressions at all. I tend to think that assertFieldOutput
shouldn't use assertRaisesRegexp but either use the good old
assertRaises instead.

I think I may have found a fix for this and posted a patch to a new
ticket: http://code.djangoproject.com/ticket/15805

Thank you,

Julien

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

Something wrong about AssertRaisesRegexp and assertFieldOutput

[Julien Phalip]

Hi,

I've found two similar (and potentially linked) weird problems in the
test framework while trying to understand why the perfectly looking
tests in #14608 were failing. Before I open some tickets I'd like to
hear if anybody has any clue about what's going on or if I'm missing
anything.

1) assertFieldOutput calls assertRaisesRegexp and passes the expected
error messages as a unicode string (in django/trunk/tests/
regressiontests/forms/localflavor/utils.py#L40):

self.assertRaisesRegexp(ValidationError, unicode(errors),
required.clean, input
)

... then further down the track in assertRaisesRegexp, that string is
compiled as a regular expression (in django/trunk/django/utils/
unittest/case.py#L991):

expected_regexp = re.compile(expected_regexp)

Now, the issue here is that the error message in the patch for #14608
contains some '-' characters, and that the errors list is cast to
unicode wrapping it with '[' and ']' characters:

class INLocalFlavorTests(LocalFlavorTestCase):
def test_INPhoneNumberField(self):
error_format = [u'Phone numbers must be in 02X-7X or
03X-6X or 04X-5X format.']
...

and:

unicode(errors) == u"[u'Phone numbers must be in 02X-7X or 03X-6X
or 04X-5X format.']"

Therefore, when assertRaisesRegexp compiles the unicode string it
interprets "X-7", "X-6" and "X-5" as ranges, and then throws a 'bad
character range' exception making the tests fail. If we remove those
'-' characters from the expected error message, then the tests will
pass.

I find it really weird that the error message is assumed to be a
compilable regular expression...

2) While debugging the problem above I've found another (possibly
linked) weirdness. Basically the error message that is passed to
assertRaisesRegexp is not always matched as you would expect. Here's a
simple test case I've made:

class AssertRaisesRegexp(TestCase):

def test_error_message_match(self):
def func():
raise ValidationError("No no no!")
self.assertRaisesRegexp(ValidationError, "No no no!", func) #
This passes - all good.
self.assertRaises(AssertionError, self.assertRaisesRegexp,
ValidationError, "Yes yes yes!", func) # This passes, as expected.
self.assertRaises(AssertionError, self.assertRaisesRegexp,
ValidationError, "[Yes yes yes]", func) # This fails, why?!

You'll notice that the only difference between the last two lines are
the use of '[' and ']' in the last line. So, when wrapping the error
message with '[' and ']', the error message is purely ignored and the
test just passes. This, by the way, means that pretty much all the
tests in 'regressiontests.forms.localflavor' using 'assertFieldOutput'
are currently passing without really being sure that the provided
error messages are correct.

I'm not sure how to properly fix this or where the core issue is. Am I
missing something or is it worth opening a ticket?

Thank you!

Julien

-- 
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: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

[Julien Phalip]

On Apr 6, 12:09 am, Matt Hoskins  wrote:
> My apologies for reposting this - I originally posted this at the end
> of January and as soon as I posted it I realised that with the push
> for bug squashing for the 1.3 release going on I probably wouldn't get
> any attention (and thus comment or replies :), so I'm trying a repost
> now that 1.3 is out. If someone knowledgeable about the query code in
> django could comment on whether the behaviour is by design or an
> oversight that would be useful!
>
> (Below where I say "reverse name" I mean using that reverse name from
> the model that the OneToOneField relates to)
> -
> Working on some code I've hit that the reverse name for a
> OneToOneField cannot be used, it seems, in values_list or values. I
> couldn't see why there would need to be such an exclusion, given it is
> a one-to-one relationship, so am wondering if it's just an oversight
> in the code or a deliberate exclusion?
>
> The portion of code that is rejecting doing e.g.
> "values_list('onetoonereversename')" is in setup_joins where the if
> line reads:
>
>             if not allow_many and (m2m or not direct):
>
> The values of "m2m" and "direct" come from opts.get_field_by_name and
> it seems that the reverse of a OneToOne gives the same results as the
> reverse of a ForeignKey, as of course both are not m2m and are not
> direct. Looking at the code later on in setup_joins it describes the
> path where direct is false and m2m is false as being "One-to-many
> field (ForeignKey defined on the target model)", so it looks like the
> logic I've quoted above of "if not allow_many and (m2m or not direct)"
> has the "not direct" clause in to reject reverse ForeignKey
> relationships and in doing so also rejects reverse OneToOne
> relationships (and with the latter case I suspect it need not!).
>
> If someone a bit more knowledgeable about the query machinery could
> comment on whether it does look like an oversight or is a deliberate
> exclusion, then if it's the former I'll log it as a bug.
>
> Assuming the rest of the code is ok in the case of a reverse OneToOne
> then something along the lines of "if not allow_many and (m2m or (not
> direct and not isinstance(getattr(field,'field',None),OneToOneField))"
> instead could work to allow OneToOne reverses through in setup_joins
> when allow_many is False.
>
> Regards,
> Matt

Hi Matt,

Do you think this could be related to http://code.djangoproject.com/ticket/11448
?

If so, do the patches attached to that ticket help resolve your issue?

Thanks,

Julien

-- 
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: switch to HTML5 for bundled templates

[Julien Phalip]

FYI, I've just stumbled on ticket #7452 and this thread:
http://groups.google.com/group/django-developers/browse_thread/thread/f346813ab89d4155/

One interesting idea that was suggested is to introduce a setting for
controlling the type of HTML.

-- 
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: Suggestion: a new "nature" field in Trac

[Julien Phalip]

On Apr 1, 10:36 am, Russell Keith-Magee 
wrote:
> On Wed, Mar 30, 2011 at 7:42 AM, Russell Keith-Magee
>
>  wrote:
> > Barring objection, I'll try to find some time this afternoon to
> > introduce the new flags.
>
> A little later than originally intended... but I've just made these changes.
>
> Ladies and Gentlemen start your triage!
>
> Russ %-)

Awesome! It only took 36 emails to get there :-)

Updating the 1800 open tickets is a big task, and to avoid duplicating
work I have set up a spreadsheet to coordinate our efforts:
https://spreadsheets.google.com/ccc?key=0AoGUYlz9V54IdFQtbEpyZTctQzhhQTlfMWdmWGt2a3c=en

If you'd like to volunteer, please put your name next to the page
numbers (18 pages x 100 tickets per page in total). Here's the list of
open tickets ordered by ids: 
http://code.djangoproject.com/query?status=!closed=id

Maybe I'm over-engineering this, oh well... ;-)

Happy triaging!

Julien

-- 
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: Suggestion: a new "nature" field in Trac

[Julien Phalip]

On Apr 1, 10:36 am, Russell Keith-Magee 
wrote:
> On Wed, Mar 30, 2011 at 7:42 AM, Russell Keith-Magee
>
>  wrote:
> > Barring objection, I'll try to find some time this afternoon to
> > introduce the new flags.
>
> A little later than originally intended... but I've just made these changes.
>
> Ladies and Gentlemen start your triage!
>
> Russ %-)

Just a quick note, Russell -- The 'Type' isn't showing up in the
ticket summary (yellow frame) at the top. The 'Severity' is showing
though.

Julien

-- 
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: Suggestion: a new "nature" field in Trac

[Julien Phalip]

On 29 March 2011 22:42, Luke Plant  wrote:

> As for the gardening, there are about 1700 open tickets that need the
> type setting. Those needing the severity field changing to 'Blocker' can
> be found more easily here:
>
>
> http://code.djangoproject.com/query?status=assigned=new=reopened=~regression=id=summary=keywords=status=owner=component=priority
>
> Can we get 20 volunteers to do this, and someone to volunteer to
> organise us all?
>
> I'm happy to spend time doing, say, 100 tickets. We could perhaps divide
> up by ticket number to avoid duplicating work, remembering that there
> are far more open tickets with higher numbers. Remember we can use the
> batch modify plugin to avoid sending 1000s of e-mails, but if you are
> not a Trac admin you'll need some permissions adding, probably
> temporarily, to use that feature.
>

If we decide to do a massive refresh of all tickets, then count me in as a
volunteer to help out.

However, I'm not sure that we actually need to do this. I've been thinking
about this and I tend to think that it's probably just good enough to catch
up with the backlog bit by bit and update the attribute for new tickets and
other tickets that we browse during our routine rounds. If some tickets
never get updated, then it means that nobody cares enough about them, so
they're probably OK to leave as-is and not worry about.

Just a thought.

Julien

-- 
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: Trac components cleanup

[Julien Phalip]

On Mar 29, 4:47 pm, Gabriel Hurley  wrote:
> The component re-organization is done now, as per Julien's (and Jannis')
> suggestions above. I even re-categorized the 84 tickets that were in
> "Contrib apps" into their new separate contrib.foo components (thank god for
> Trac bulk modify privileges!).
>
> The organization definitely makes more sense now, though I fear the list has
> actually grown longer (due to all the contrib apps that were lumped together
> before). If anything, that should be a reminder that some of those apps are
> rather stale these days, but that's a conversation for another day. ;-)
>
> If you find any problems feel free to let me know.
>
> All the best,
>
>     - Gabriel

Wow, fantastic! We owe you a few cold beers :D

Julien

-- 
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: switch to HTML5 for bundled templates

[Julien Phalip]

On Mar 29, 4:01 pm, Stephen Burrows 
wrote:
> 3. There is a simple workaround going back to ie6 for handling the css
> problems related to unrecognized tags. [3]

...snip...

> [3]http://diveintohtml5.org/semantics.html#unknown-elements

The workaround works if javascript is enabled. So we can't consider it
if we want to support IE6 with javascript turned off.

However, in the case of inputs, the tag definitely is known by IE6 --
it's the 'type' attribute's values that will not be recognised. I'm
not sure if that affects CSS though.

Julien

-- 
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: Trac components cleanup

[Julien Phalip]

On Mar 29, 8:58 am, Gabriel Hurley  wrote:
> I can work on it late tonight (about 6-8 hours from now) if no one else gets
> to it.
>
> All the best,
>
>     - Gabriel

Excellent, thank you Gabriel! There's no rush -- whenever it suits
you. Let me know if I can help in any way.

Julien

-- 
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: Trac components cleanup

[Julien Phalip]

On Mar 29, 2:01 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Mon, Mar 28, 2011 at 12:56 AM, Julien Phalip <jpha...@gmail.com> wrote:
> > Now that 1.3 has been released (yay!), I'm reviving this thread to see
> > if we can make Trac a little more efficient on our way to 1.4. I'll
> > try to summarise what's been suggested so far in regard to improving
> > and clarifying the "Component" field:
>
> Agree with everyone else -- this makes perfect sense. Do you have the
> relevant bits in Trac to make these changes yourself? If so feel free
> to do so; otherwise ping me and I'll give you the perms.

I wouldn't mind trying but I don't have much experience administering
Trac and I wouldn't want to make a mess. Earlier in this thread
Gabriel has offered to help as he's got the Trac skillz.

Gabriel, are you around? :-)

Julien

-- 
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: Suggestion: a new "nature" field in Trac

[Julien Phalip]

On Mar 28, 10:49 pm, Karen Tracey  wrote:
> +1 on having a distinction between bug, feature, and optimization.
>
> I don't think both "Uncategorized" and "Other" are necessary.

My reasoning for "Other" was that there might be things that are
neither a bug, a feature or an optimisation. I admit that I can't
think of any specific example for it right now, but I thought there
might sometimes be general tasks that do not require a code change --
but maybe that's never the case and therefore not necessary?

And the default "Uncategorized" was for when the reporter could not
decide or simply didn't bother (which is still better than picking a
wrong option).

Julien

-- 
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: Suggestion: a new "nature" field in Trac

[Julien Phalip]

On 28 March 2011 17:28, Russell Keith-Magee  wrote:

> > * Uncategorized (default)
> > * Feature request: for adding something new.
> > * Bug report: for when an existing thing is broken or not behaving as
> > expected.
> > * Optimisation: for when an existing thing is not broken but could be
> > made better, faster, stronger.
> > * Other: none of the above.
>
> I would suggest two modifications to this:
>
> First, I would call "Feature Request" -> "New Feature" to remove any
> suggestion that just by opening a ticket, it will magically be
> implemented by the feature ponies.
>

+1, that's even clearer.


> Second, this ontology doesn't do the one type of filtering that we
> need for release management -- identifying bugs that are release
> blocking. This means that either the 'bug report' category needs to be
> expanded into:
>  * Bug
>  * Bug causing data loss
>  * Regression
>  * Bug with new feature
>
> Or we need to add a separate boolean flag for "release blocker".
>
> We used keywords for the 1.3 release, and I think that proved a
> helpful resource; I think it's worth promoting these to full UI
> elements.
>

I think there will rarely be many blockers at any given time, so I'd rather
keep all bugs under "Bug" to keep the dropdown box succinct, and introduce a
new "Release blocker" flag which will be enough to get people's attention.
Whether it's a regression, bug in new feature, etc. can then easily be
guessed by reading the ticket comment thread.

Julien

-- 
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: Suggestion: a new "nature" field in Trac

[Julien Phalip]

Hello,

I'm not sure if the consensus so far is either "Meh" or "Let's give it
a try", or if there's even a consensus. I'm still keen on the idea but
I don't want to insist too much if it doesn't gather enough support,
so I'll re-submit it here one last time. The latest proposal is to
introduce a new "Type" (or "Nature" or "Kind"...) field in Trac with
the following options:

* Uncategorized (default)
* Feature request: for adding something new.
* Bug report: for when an existing thing is broken or not behaving as
expected.
* Optimisation: for when an existing thing is not broken but could be
made better, faster, stronger.
* Other: none of the above.

The idea is to prompt people to think more carefully about the nature
of their request, and also to help focus on the relevant tickets when
we enter feature-freeze.

If we do want to give it a try, then it'd be great to implement it
quite soon so we have enough time to trial it properly on our way to
1.4. If not, then no worries ;-)

Cheers,

Julien

-- 
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: Trac components cleanup

[Julien Phalip]

Hi all,

Now that 1.3 has been released (yay!), I'm reviving this thread to see
if we can make Trac a little more efficient on our way to 1.4. I'll
try to summarise what's been suggested so far in regard to improving
and clarifying the "Component" field:

* The "Contrib apps" component would be made redundant and new
components for each missing contrib app (e.g. contenttypes, sitemaps)
would be added. Also, for readability's sake, "django.contrib.foo"
would be renamed to simply "contrib.foo".

* For consistency, the "Authentication" component would be renamed to
"contrib.auth", and "RSS framework" to "contrib.syndication".

* Consolidate "django-admin.py", "django-admin.py inspectdb" and
"django-admin.py runserver" into one component (called "Management
commands" perhaps?).

* Rename "Django Web site" to "Djangoproject.com Web site"

* Lastly, potentially the most controversial change: for clarity's
sake, rename "Core framework" to "Core (Other)", "Cache system" to
"Core (Cache system)", "django.core.mail" to "Core (Mail)", and
"Serialization" to "Core (Serialization)".

Let me know if any of that is total yak shaving or if it's worth
implementing. By the way, the reason why I care about this
specifically is because I think that by making the component data more
accurate and consistent, we'll drive in more useful contribution from
people who feel they are expert or simply interested in specific areas
of the codebase.

Many thanks!

Julien

-- 
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: Trac components cleanup

[Julien Phalip]

On Feb 28, 10:58 am, Paul McMillan  wrote:
> I think the django-admin.py categories could be consolidated into a single 
> one.
>
> In the interest of readability, we might rename django.contrib.foo to
> simply contrib.foo.
>
> As long as we're clarifying, "Django Web Site" might be better named
> "DjangoProject Web Site".

Yes I totally agree with those points. Perhaps "django-admin.py"
should also be renamed "Django built-in commands", and add ".com" in
"DjangoProject.com Web Site".

I'm not a Trac expert, but it feels as though the component values are
stored as full strings. So if changes are made it's likely we'll have
to run SQL queries to bulk-update the corresponding database entries.

Julien

-- 
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: Suggestion: a new "nature" field in Trac

[Julien Phalip]

> On Mon, Feb 21, 2011 at 3:05 PM, Julien Phalip <jpha...@gmail.com> wrote:
> > Hello,
>
> > I was wondering if others would find it useful to introduce a new
> > field in Trac to characterise the nature of a ticket, allowing to
> > choose from at least: "bug report", "feature request", or
> > "optimisation".

Going back to the original proposal, I suggest we introduce the
following options:

* Uncategorized (default)
* Feature request: for adding something new.
* Bug report: for when an existing thing is broken or not behaving as
expected.
* Optimisation: for when a thing is not broken but could be made
better, faster, stronger.
* Other: none of the above.

I anticipate at least one grey area, for when a new feature must be
introduced to fix a bug - I guess that this would be resolved on a
case-by-case basis, and that which side of the fence it eventually
falls would depend on the actual importance/gravity of the bug and on
the Beta/Alpha/RC stages.

Can you think of any other specifically useful options, or
alternatives for the ones above?

Cheers,

Julien

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

Trac components cleanup

[Julien Phalip]

Hi,

Tweaking Trac seems to be in the air, so I had some more ideas to
suggest :)

The "component" field in Trac is very useful when people look for
tickets in their areas of familiarity/expertise. I think there are a
few things that should be cleaned up to make the system a bit more
useful and effective:

* The "Contrib apps" component [1] should be made redundant and new
components for each missing contrib app (e.g. contenttypes, sitemaps)
should be added. I mean, even databrowse has its own component! :) The
"Contrib app" mixes lots of unrelated things, making it a bit
pointless.
* For consistency, the "Authentication" component should be renamed to
django.contrib.auth, and "RSS framework" to
django.contrib.syndication.
* Clarify what the "Core framework" component [2] means, as it ends up
being used for a lot of irrelevant things (for example, I've just
cleaned out a lot of ORM-related tickets). Note that django.core.mail
has its own component, but there are so many things that could be
considered as part of the core framework that it might be difficult
and counter-productive to split it in a gazillion components (as
opposed to the number of contrib apps which is reasonably small and
will never grow). At the very least, the name "Core framework" should
be disambiguated if possible.
* Merge the "User experience" component [3] with django.contrib.admin
since it contains very few tickets and the vast majority of user
experience related tickets will likely always be related to the admin
anyway.

What do you think?

Cheers,

Julien

[1] Contrib apps component:
http://code.djangoproject.com/query?status=assigned=new=reopened=Contrib+apps=id=summary=component=status=milestone=version=priority
[2] Core framework component:
http://code.djangoproject.com/query?status=assigned=new=reopened=Core+framework=id=summary=component=status=milestone=version=priority
[3] User experience component:
http://code.djangoproject.com/query?status=assigned=closed=new=reopened=User+Experience=id=summary=component=status=milestone=version=priority

-- 
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: "needsinfo": resolution vs. triage stage

[Julien Phalip]

On Feb 24, 7:17 pm, Gabriel Hurley  wrote:
> In regards to #14702 , which so
> far has been a universally favored idea, there's one lingering issue:
>
> Do we want to implement it as a resolution (i.e. you close a ticket as
> "needsinfo" and the reporter reopens to provide the information) or as a
> triage stage (like DDN, RFC, etc.)?
>
> Here's a quick overview arguments for each...
>
> Resolution:
>
>    - Keeps Trac free from the clutter of old tickets that the author never
>    returns to clarify.
>    - Indicates clearly that the ticket in it's current state is unresolvable
>    and has no forward path.
>    - Will show up more prominently in the timeline (tickets being
>    closed/reopened attract attention).
>
> Triage stage:
>
>    - May intimidate new contributors to see that their ticket was "closed".
>    - Doesn't discount the fact that there may be a valid issue here which we
>    don't want to forget about.
>
> I'll disclose my personal bias that I'm +1 for the resolution and -0 for the
> triage stage (I think another stage just adds clutter).
>
> I'd like to put it to a vote, though, and see what the community (and the
> core team) decides.
>
> *So which shall it be: resolution or triage stage?*
> *
> *
> I'll take care of the docs patch and the Trac admin change once its decided.
>
> All the best,
>
>     - Gabriel

+1 for a close resolution. As long as the attached comment _politely_
asks the reporter to provide more info and to reopen the ticket if the
bug is genuine, then there should be no hard feelings or intimidation.

Julien

-- 
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: Suggestion: a new "nature" field in Trac

[Julien Phalip]

On Feb 22, 3:22 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip <jpha...@gmail.com> wrote:
> > I know there already is a "Has patch" flag, but I actually find that
> > one a bit useless since there's no way to distinguish from the mass of
> > tickets where there are good, solid patches (whose authors themselves
> > think could be RFC or simply in need for review) versus the draft or
> > tentative patches. In fact, I'd make both the "Has patch" and "Patch
> > needs improvement" flags redundant and instead introduce a new "Patch
> > ready for review" stage.
>
> This smells a bit like a bikeshed to me. What's the difference between
> having a *state* that says "patch needs review" and a boolean flag
> that says "patch needs review"?
>
> A draft or tentative patch is a patch that the author has themselves
> flagged as "needs improvement". Or, demonstrating the flexibility of
> the system -- you could also treat that case by simply not flagging
> the 'has patch' state. Either way, it is possible to provide a patch
> without indicating that it is ready for review.
>
> > To illustrate this, I've got two patches currently in this virtual
> > "Patch ready for review" state: #13091 and #12475 :-)
>
> #13091 isn't ready for review, because it's still marked DDN. That
> means that a decision still needs to be made.
>
> #12475 turns up here:
>
> http://code.djangoproject.com/query?status=new=assigned...
>
> ... along with 313 other tickets. I've just added this query to the
> "reports" page [1], which is itself linked from the
> code.djangoproject.com home page. A range of other queries have always
> been there, but there wasn't a simple "needs review" query.
>
> [1]http://code.djangoproject.com/wiki/Reports

Thanks Russell, you've convinced me I was doing a little bike-shedding
there :-)
It does seem that some reports can already be generated to get the
results I was after.

> Like I have said many times in the past -- issuing queries to find
> tickets needing review isn't a problem we have. The information that
> is needed is all there. What we *do* have are two other problems:
>
>  1) Finding people willing to be altruistic and review someone else's
> work, rather than their own
>  2) Directing people who are inclined to be altruistic to the right place.
>
> I know that UX can affect engagement, so it's entirely possible that
> the whole Trac process is an impediment to engagement of potential
> reviewers. However, I strongly challenge the assertion that either of
> these problems can be fixed by simply adding a triage states alone. A
> triage state just changes the query (arguably simplifying it) -- it
> doesn't by itself increase the number of people volunteering.
>
> The problem we have is a much deeper problem of community engagement.
> Unfortunately, this is also problem that I don't have any magic
> solutions for. Convincing people to be altruistic is hard.
>
> A triage state also doesn't help people who *are* inclined to help to
> actually find the information that would allow them to help. That
> means the contribution guide, and the Trac reports page. Hopefully,
> #14401 will address this somewhat. Either way, I don't think a Trac
> flag will help -- it's a more fundamental IA problem for the project
> itself (i.e., how to direct people to the right information).
>
> One Trac feature that I suspect *might* help in this regard is one
> that I've raised before -- allowing users to flag individual issues
> that they have an interest in seeing solved. This isn't just another
> flag, because it provides a way to slice and present the data in a
> different way. It would allow us to provide a project-wide leaderboard
> of the "most wanted bugs", providing a focus for volunteer activity
> that doesn't currently exist. However, this requires someone to spend
> time developing that feature for Trac, because it isn't (to my
> knowledge) an out-of-the-box feature.

I'm voting +1 for the voting feature suggested by Daniel in his
previous reply to this thread.

As far increasing community engagement is concerned, off the top of my
head there are at least three things worth exploring:

1) Advertise

For example:

* The reports page is useful but it's easily missed. Perhaps there
should be a reminder and a link to it in every future sprint
announcements.
* There should be a huge "Contribute to Django" button (with round
cornerz) on the djangoproject.com homepage linking to more info (e.g.
to the page that Gabriel has been drafting recently).
* I believe the vast majority of django users come to the
djan

Re: Suggestion: a new "nature" field in Trac

[Julien Phalip]

On Feb 21, 4:35 pm, Gabriel Hurley  wrote:
> I'm still in favor of adding the "needsinfo" resolution and would love to
> see that happen... I guess technically I could even do that one myself via
> Trac's web admin if we're all agreed on it.

I agree this is a good idea. By the way, for reference it is #14702.

> I'm ambivalent about adding the "ticket type" field back in, though. It can
> be useful, but it *is* an extra item to keep managed and argue about... My
> bigger concern, though, is the 1700+ existing tickets which will be
> uncategorized. It would end up meaning that using that flag for queries in
> Trac wouldn't give you a complete picture (at least not for a very long time
> while things catch up).

I share your concern about the existing tickets but I think that
things would catch up reasonably quickly. This would be mostly helpful
in conjunction with the milestone flag for coordinating the alpha,
beta and final releases in the future (There seems to have been "only"
about 2-300 tickets floating around for 1.3 in recent months). Perhaps
this is something that could be trialled for the next cycle until the
1.4 release and see whether it helps or not.

While I'm at it, I've also recently felt there was a gap between the
"Accepted" and "Ready for checkin" stages, which might coincide with
the 'needs feedback' state that Russell has mentioned in an earlier
reply to this thread. When one posts a patch and believes that it is
correct (or closed to be so), there is no easy and persistent way to
request that someone else review the patch and then potentially
promote it to RFC. Currently the only ways are transient (e.g. posting
on the django-dev mailing list or IRC channel) and as such not very
efficient if no one is both interested and available exactly at that
time.

RFC'ing one's own patch is bad form unless the patch is absolutely
straightforward, and more generally it is always better to have an
extra pair of eyes cast over it. I fear that because of this gap in
the process, too many good patches go unnoticed and then grow stale or
forgotten, whereas had those been staged to, for example, "Patch ready
for review" they would have gotten noticed, reviewed and eventually
checked-in much quicker.

I know there already is a "Has patch" flag, but I actually find that
one a bit useless since there's no way to distinguish from the mass of
tickets where there are good, solid patches (whose authors themselves
think could be RFC or simply in need for review) versus the draft or
tentative patches. In fact, I'd make both the "Has patch" and "Patch
needs improvement" flags redundant and instead introduce a new "Patch
ready for review" stage.

Here's a typical example scenario:

- A reports a bug #123.
- B verifies the bug and stages #123 to "Accepted".
- B posts a patch and is pretty confident it works. B then stages #123
to "Patch ready for review".
- C has a few minutes on his hands and pulls the list of tickets with
patches ready for review, opens #123, scans the patch and sees a few
issues. C stages #123 back to "Accepted" (or in fact may as well leave
it as "Patch ready for review") and writes a comment explaining the
issues with the patch.
- B posts a new updated patch (and re-stages #123 to "Patch ready for
review" if it has been staged back to "Accepted").
- D verifies the patch is now correct and then stages #123 to "RFC".

To illustrate this, I've got two patches currently in this virtual
"Patch ready for review" state: #13091 and #12475 :-)

What do you think?

Julien

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

Suggestion: a new "nature" field in Trac

[Julien Phalip]

Hello,

I was wondering if others would find it useful to introduce a new
field in Trac to characterise the nature of a ticket, allowing to
choose from at least: "bug report", "feature request", or
"optimisation". I think this would help bring the right focus during
alpha and beta stages, and also help people looking for tickets when,
for example, they're in the mood for fixing bugs. I believe the
Keywords field has been used in an ad hoc way for this before, but it
feels that something more structured would be more helpful.

Cheers,

Julien

-- 
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: Enabling context access in simple_tag

[Julien Phalip]

On Dec 15, 10:52 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Wed, Dec 15, 2010 at 6:41 PM, Julien Phalip <jpha...@gmail.com> wrote:
> > On Dec 14, 7:34 pm, Christian Hammond <chip...@gmail.com> wrote:
> >> On Dec 14, 12:02 am, Julien Phalip <jpha...@gmail.com> wrote:
>
> >> > On Dec 13, 10:16 am, Tai Lee <real.hu...@mrmachine.net> wrote:
>
> >> > -snip-
>
> >> > > One suggestion from #1105 was to split out this functionality into
> >> > > individual decorators, @takes_context, @takes_block. I'm not sure how
> >> > > easy this would be technically to implement, but I think it would
> >> > > solve the `takes_context_plus` sink problem Malcolm describes as we
> >> > > potentially add more special case tag types (simple, inclusion,
> >> > > assignment, etc.)
>
> >> > The djblets (created by the guys at reviewboard.org) contain two nifty
> >> > decorators for exactly this purpose:
> >> > @basictag:https://github.com/djblets/djblets/blob/master/djblets/util/decorator...
> >> > @blocktag:https://github.com/djblets/djblets/blob/master/djblets/util/decorator...
>
> >> > This now seems to me like the perfect compromise. It would generally
> >> > allow for more versatility and to keep simple_tag (and the future
> >> > assignment_tag) free of takes_xxx cruft.
>
> >> > Any chance these two decorators could be considered for inclusion in
> >> > Django core?
>
> >> For what it's worth, these two decorators have seriously cut down on
> >> our development and maintenance burdens. Whether they'd be sufficient
> >> as-is, I don't know (though you're welcome to have the code), but I'd
> >> also love to see equivalent functionality in Django.
>
> >> If I can help in some way to get these in shape (assuming you'd want
> >> to go that direction), just let me know.
>
> >> Christian
>
> > I think the djblet tags approach is the most reasonable one. It
> > provides the feature originally requested without disrupting any
> > existing code or API. The current code works and has been successfully
> > tested in production environments for a long time.
>
> > I'm keen to push this through, but I'm also concerned that the future
> > freeze deadline is upon us. I don't want to create too much noise in
> > the issue tracker, so could a core dev advise on the way to go from
> > here? Considering the djblet approach is judged reasonable, shall we
> > create two different tickets (one for each tag)?
>
> I'm only one voice, but I'm *really* not a fan of decorators changing
> function signatures like that. I don't deny it works; it just grates
> me the wrong way.
>
> I've already indicated my preferred approach -- consistency with 
> inclusion_tag.
>
> Yours
> Russ Magee %-)

Ok, it looks like we've got a consensus which will scratch the
original itch. I've created a ticket for it and will work on a patch
over the weekend: http://code.djangoproject.com/ticket/14908#preview

Thank you all!

Regards,

Julien

-- 
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: Enabling context access in simple_tag

[Julien Phalip]

On Dec 14, 7:34 pm, Christian Hammond <chip...@gmail.com> wrote:
> On Dec 14, 12:02 am, Julien Phalip <jpha...@gmail.com> wrote:
>
>
> > On Dec 13, 10:16 am, Tai Lee <real.hu...@mrmachine.net> wrote:
>
> > -snip-
>
> > > One suggestion from #1105 was to split out this functionality into
> > > individual decorators, @takes_context, @takes_block. I'm not sure how
> > > easy this would be technically to implement, but I think it would
> > > solve the `takes_context_plus` sink problem Malcolm describes as we
> > > potentially add more special case tag types (simple, inclusion,
> > > assignment, etc.)
>
> > The djblets (created by the guys at reviewboard.org) contain two nifty
> > decorators for exactly this purpose:
> > @basictag:https://github.com/djblets/djblets/blob/master/djblets/util/decorator...
> > @blocktag:https://github.com/djblets/djblets/blob/master/djblets/util/decorator...
>
> > This now seems to me like the perfect compromise. It would generally
> > allow for more versatility and to keep simple_tag (and the future
> > assignment_tag) free of takes_xxx cruft.
>
> > Any chance these two decorators could be considered for inclusion in
> > Django core?
>
> For what it's worth, these two decorators have seriously cut down on
> our development and maintenance burdens. Whether they'd be sufficient
> as-is, I don't know (though you're welcome to have the code), but I'd
> also love to see equivalent functionality in Django.
>
> If I can help in some way to get these in shape (assuming you'd want
> to go that direction), just let me know.
>
> Christian

I think the djblet tags approach is the most reasonable one. It
provides the feature originally requested without disrupting any
existing code or API. The current code works and has been successfully
tested in production environments for a long time.

I'm keen to push this through, but I'm also concerned that the future
freeze deadline is upon us. I don't want to create too much noise in
the issue tracker, so could a core dev advise on the way to go from
here? Considering the djblet approach is judged reasonable, shall we
create two different tickets (one for each tag)?

Many thanks!

Julien

-- 
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: Enabling context access in simple_tag

[Julien Phalip]

On Dec 13, 10:16 am, Tai Lee  wrote:

-snip-

> One suggestion from #1105 was to split out this functionality into
> individual decorators, @takes_context, @takes_block. I'm not sure how
> easy this would be technically to implement, but I think it would
> solve the `takes_context_plus` sink problem Malcolm describes as we
> potentially add more special case tag types (simple, inclusion,
> assignment, etc.)

The djblets (created by the guys at reviewboard.org) contain two nifty
decorators for exactly this purpose:
@basictag: 
https://github.com/djblets/djblets/blob/master/djblets/util/decorators.py#L96
@blocktag: 
https://github.com/djblets/djblets/blob/master/djblets/util/decorators.py#L161

This now seems to me like the perfect compromise. It would generally
allow for more versatility and to keep simple_tag (and the future
assignment_tag) free of takes_xxx cruft.

Any chance these two decorators could be considered for inclusion in
Django core?

Cheers,

Julien

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

Enabling context access in simple_tag

[Julien Phalip]

Hello,

I'd like to bring up an itch that I've been desperate to scratch since
my very early days with Django: the inability to access the context
from a simple_tag.

There are especially two use cases which I encounter on a near weekly-
basis:

(a) Generate a simple string or some very concise html code based on
the context.
(b) Update the context itself.

Both use cases can currently be achieved either by creating a Node
class and a parser (tedious and boilerplatey) or by using an
inclusion_tag (overkill having to create a template). You may also use
some workarounds such as in ReviewBoard's Djblets [1], but that means
you'd have to introduce a dependency in your projects or copy/paste
those workarounds in every project. Really, I've always thought that
life as a Django developer would be so much easier if only simple_tag
could access the context...

To give a bit of history: when I first got interested in this problem,
I created #7462, and then was advised to close it in favour of an
older one #1105. Finally, nearly two years later, #1105 got closed as
a duplicate of #14262.

#14262 particularly addresses use case (b), that is, create a special
template tag that would make updating the context easy while
presumably returning an empty string. In #1105, however, I had written
a patch which would have killed two birds with one stone by addressing
both (a) and (b). Plus that patch would have allowed you to update the
context AND to return some result if you wanted to (instead of just
returning an empty string). That patch enabled context access in
simple_tag, following the same declarative syntax as for
inclusion_tag:

@register.simple_tag(takes_context=True)
def mytag(context, foo, bar):
...

It never made sense to me why inclusion_tag could access the context,
and not simple_tag. One common argument I've heard is that it is
because simple_tag should remain "simple". However, I don't see how
enabling context access would necessarily make simple_tag "complex".
>From my own developer's perspective, the "simple" in "simple_tag"
mostly means that the *template syntax* should be straightforward as
opposed to a complex syntax like {% mytag arg1 with arg2 as var1 and
var2 %} for which you should definitely prepare yourself to go down
the dark alley of Nodes and parsers (or give it a chance with the
rather neat django-template-sugar [2]).

I think the main reason why #1105 has been closed is that it has
drifted a bit too far off. I started by adding content access in my
initial patch, and then I got carried away following people's
suggestions by adding access to the inner block as well. This led to
the 'takes_context_plus_sink' problem that Malcolm rightly pointed out
in a recent tweet [3]. Even if I'd love to have easy access to the
inner block, I now admit it might be a bit much to make that work with
simple_tag (probably should be a separate new ticket?).

This topic has received some support from Simon [4] [5] and Jacob [6]
when I initially brought it up on this list 2 years ago. I believe
Malcolm and Chris Beaven, amongst others, have also expressed some
interest by participating in the relevant tickets. I hope that people
still want this and that there's a chance to make it ship in 1.3
(since 1.3's focus is on scratching all those annoying little itches).

In summary, what do you think about enabling context access in
simple_tag (using the takes_context syntax)? If the response is
positive, I'm very keen to lead the way and promptly write a patch for
it. A side question is: would this make #14262 redundant?

Thanks!

Julien :)

[1] 
http://www.chipx86.com/blog/2008/02/29/django-development-with-djblets-custom-tag-helpers/
[2] https://github.com/alex/django-templatetag-sugar
[3] http://twitter.com/malcolmt/status/13145334247063552 (click on the
'In reply to...' links to get the whole discussion)
[4] 
http://groups.google.com/group/django-developers/browse_thread/thread/fba22c3e3c910bb9/b39a0a79ed991ca8
[5] 
http://groups.google.com/group/django-developers/browse_thread/thread/62d0cefde54a50a3/e58e2202ef125976
[6] 
http://groups.google.com/group/django-developers/browse_thread/thread/afb7c3cd93e7a659/637973df3b839b45

Relevant tickets:
http://code.djangoproject.com/ticket/1105
http://code.djangoproject.com/ticket/2619
http://code.djangoproject.com/ticket/7462
http://code.djangoproject.com/ticket/14262

Also discussed in:
http://groups.google.com/group/django-developers/browse_thread/thread/8737db04db7e60af/e3276998ab34f022
http://groups.google.com/group/django-developers/browse_thread/thread/d83241466444a02/bcb78463537c82f3

-- 
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: Tests for generic views' pagination

[Julien Phalip]

On Jul 6, 5:54 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Tue, Jul 6, 2010 at 1:43 PM, Julien Phalip <jpha...@gmail.com> wrote:
> > Hi,
>
> > I'm starting to work on ticket #2367 ("Pagination for date based
> > generic views" -http://code.djangoproject.com/ticket/2367) and I'm
> > looking into the object_list generic view as a reference.
>
> > For the life of me I cannot find any tests for object_list's
> > pagination. Am I missing something or are there really no tests for
> > this yet?
>
> It looks like you may be correct. The generic view tests are all under
> regressiontests/views; there are tests for object_detail, but I not
> for object_list. Paginators are tested in modeltests/pagination and
> regressiontests/pagination_regress, but there's no specific tests for
> the object_list.
>
> Feel free to rectify this omission :-)

Glad to hear I didn't go insane! :)

I've created a new ticket for the record: 
http://code.djangoproject.com/ticket/13897

I'm happy to take a look at it. Off the top of your head, is there
some existing testing code that I could plug into or reuse for this?

Cheers,

Julien

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

Tests for generic views' pagination

[Julien Phalip]

Hi,

I'm starting to work on ticket #2367 ("Pagination for date based
generic views" - http://code.djangoproject.com/ticket/2367) and I'm
looking into the object_list generic view as a reference.

For the life of me I cannot find any tests for object_list's
pagination. Am I missing something or are there really no tests for
this yet?

Many thanks.

Kind regards,

Julien

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

Introducing a CACHE_MIDDLEWARE_KEY_PREFIX-like setting for all cacheing operations (#12831)

[Julien Phalip]

Hi,

Several people have expressed interest in ticket #12831, which has
also been marked as DDN. So I thought the next step would be to bring
it up on this list - let me know if that's not the right thing to do.

Basically, I think that it would make sense and that it would be very
useful if a new setting was introduced to allow the systematic
addition of a prefix to avoid key collisions across multiple site
instances, that is for all cacheing operations, not just for per-site
cacheing (which is currently possible with the
CACHE_MIDDLEWARE_KEY_PREFIX setting).

What do you guys think about this? Does this ticket have a chance to
be accepted or is it fundamentally a bad idea?

Many thanks.

Kind regards,

Julien

-- 
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: admin reuse

[Julien Phalip]

On Aug 15, 9:14 pm, Russell Keith-Magee 
wrote:
> On Sat, Aug 15, 2009 at 3:52 PM, Haroldo
>
> Stenger wrote:
> >  I've seen the admin evolve to very sophisticated user interaction.
> > Nonetheless, the param to  HttpResponse() when a model object has been
> > saved, is hardcoded and most of the times "../../.." or "../.."  (see
> > options.py in contrib.admin).
>
> This is a historical artefact. As of v1.1, the 'right way' to do this
> would be to use a named URL pattern. Some of the usages of '../..'
> paths have been corrected, but there are still some remaining. It
> doesn't harm anything while they remain, but I expect that they will
> eventually get cleaned up.
>
> > Being able to change that string by some means
> > of instantiation or runtime configuration, could allow a view to use the
> > admin to edit an object, and once the model object has been saved modified,
> > automatically return to the view (or another view registered in URLconf). I
> > wonder if this has ben thought before, and if there would be much resistance
> > to a change in that HttpResponse's parameter flexibility.
>
> I'm not sure I see why this parameter needs to be configurable. When
> you save an object, it goes back to the list of objects of the same
> type. I can't think of any other logical place for the view to
> redirect.
>
> It sounds like you're trying to use the admin edit views within your
> own application. If this is the case, let me advise you that Django's
> admin isn't intended as a way to avoid writing edit views for your own
> site. If you want to edit objects in your own site, just write write
> edit views - it isn't that hard to use a modelform.
>
> If you have another use case, I'd be interested to hear it.
>
> Yours,
> Russ Magee %-)

About a year ago (pre-Django 1.0) I had posted a ticket with a similar
request: http://code.djangoproject.com/ticket/8001

I agree that the redirection shouldn't be hardcoded. This is
inconsistent because some views allow for customisation (with the
'post_url_continue' parameter) but other views don't.

Haroldo, maybe the posted patch would be a good starting point for
your problem?

Russ, one use case that I've had is with a menu app. I wanted to have
an integrated way to manage items in a menu, for example with the
following URLs:
http://blah.com/admin/menus/menu/1/additem/
http://blah.com/admin/menus/menu/1/items/3/

To edit/add items, I used an unregistered ModelAdmin class to benefit
from all the admin machinery. It worked fine except that the default
hardcoded redirection didn't allow for it, so I had to overwrite some
bits in the views. Not a huge deal, but it's one of those little
customisation hooks that make life easier ;)

Cheers,

Julien
--~--~-~--~~~---~--~~
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: Unified access to response.context in test client (follow-up)

[Julien Phalip]

On Mar 12, 11:10 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> On Thu, Mar 12, 2009 at 8:31 PM, Julien Phalip <jpha...@gmail.com> wrote:
>
> > On Mar 12, 9:30 pm, Russell Keith-Magee <freakboy3...@gmail.com>
> > wrote:
> >> On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip <jpha...@gmail.com> wrote:
>
> >> > Hi,
>
> >> > A few months ago James raised the issue on this list:
> >> >http://groups.google.com/group/django-developers/browse_thread/thread...
>
> >> > Basically, the type for the test client's response context is
> >> > inconsistent. Sometimes it's a dictionary and other times it's a list
> >> > of dictionaries, depending on whether or not the tested page was built
> >> > with a hierarchy of templates.
>
> >> > I don't think this has been fixed yet. Could someone confirm? If it
> >> > hasn't, then does it have a chance to make it into 1.1? I haven't been
> >> > able to find any ticket for it, should one be created?
>
> >> The status of this issue hasn't changed. It hasn't been fixed. There
> >> isn't an existing ticket to the best of my knowledge. As Jacob noted
> >> the last time you asked, this is a relatively small change, so if a
> >> suitably complete patch were to materialize out of the ether, it would
> >> probably find itself in trunk for v1.1.
>
> > Thanks Russ. I'm keen to have a go at it during the upcoming sprints.
> > You and Jacob say it's a small change. Could you please give a hint on
> > what that is? Just so that I have something to start with and so I can
> > pull off the groundwork more quickly.
>
> James (Bennett) pretty much described what needs to happen - it hinges
> on adding __getitem__ operator for the context object which is
> sensitive to whether the context is being subscripted by integer or by
> string. i.e.,
>
> request.context[3] will get the third context in the stack
> request.context['foo'] will try to find the key 'foo' in the context.
>
> James gave a bit more detail in his post.

Makes perfect sense. I created a ticket for it (#10482) and will start
with a patch soon.

Cheers,

Julien
--~--~-~--~~~---~--~~
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: Unified access to response.context in test client (follow-up)

[Julien Phalip]

On Mar 12, 9:30 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip <jpha...@gmail.com> wrote:
>
> > Hi,
>
> > A few months ago James raised the issue on this list:
> >http://groups.google.com/group/django-developers/browse_thread/thread...
>
> > Basically, the type for the test client's response context is
> > inconsistent. Sometimes it's a dictionary and other times it's a list
> > of dictionaries, depending on whether or not the tested page was built
> > with a hierarchy of templates.
>
> > I don't think this has been fixed yet. Could someone confirm? If it
> > hasn't, then does it have a chance to make it into 1.1? I haven't been
> > able to find any ticket for it, should one be created?
>
> The status of this issue hasn't changed. It hasn't been fixed. There
> isn't an existing ticket to the best of my knowledge. As Jacob noted
> the last time you asked, this is a relatively small change, so if a
> suitably complete patch were to materialize out of the ether, it would
> probably find itself in trunk for v1.1.

Thanks Russ. I'm keen to have a go at it during the upcoming sprints.
You and Jacob say it's a small change. Could you please give a hint on
what that is? Just so that I have something to start with and so I can
pull off the groundwork more quickly.

Cheers,

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

Unified access to response.context in test client (follow-up)

[Julien Phalip]

Hi,

A few months ago James raised the issue on this list:
http://groups.google.com/group/django-developers/browse_thread/thread/1b10084ea969141e

Basically, the type for the test client's response context is
inconsistent. Sometimes it's a dictionary and other times it's a list
of dictionaries, depending on whether or not the tested page was built
with a hierarchy of templates.

I don't think this has been fixed yet. Could someone confirm? If it
hasn't, then does it have a chance to make it into 1.1? I haven't been
able to find any ticket for it, should one be created?

Cheers,

Julien
--~--~-~--~~~---~--~~
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: reason for missing readline() in uploaded files?

[Julien Phalip]

On Feb 4, 3:12 am, Marty Alchin  wrote:
> I suppose I should probably weigh in over here. For those who don't
> know, I worked on much of Django's file handling, refactoring
> FileField, adding storage options and standardizing the File interface
> across models, forms, storage and uploads. If there are methods
> missing, I'm almost certainly the man to blame.
>
> First, I want to point out one thing: adding readline() is different
> from supporting a catch-all for any methods we might have missed. The
> arguments for each are quite different, and this thread has
> transitioned from one to the other, making things a bit murky. With
> that in mind, I'll slpit the rest of this email into two parts,
> addressing each issue.
>
> readline()
>
> I'm not opposed to adding readline(). It's part of the standard file
> protocol, and it can be added even without the underlying file needing
> to support it. After all, iterating over the file already yields one
> line at a time, so we could just stop after the first line is
> retrieved. That said, you can also do that yourself, currently.
>
> for line in file:
>     is_valid = validate_csv_format(line)
>     break
>
> It's not the prettiest, but it's a reasonable workaround in the
> absence of an explicit readline(). In fact, I'd much rather using a
> Python approach to readline() that does something similar, rather than
> simply deferring to the _file attribute. That way, we're more able to
> make sure it's there for other objects that might not implement it
> directly. As long as the file is iterable, and the iterator works the
> way the protocol describes, a simple Python method will work just
> fine.
>
> def readline(self):
>     for line in self:
>         return line
>
> Other methods
>
> First, I'll be clear. Not all the missing methods were forgotten.
> readline() probably was overlooked, but that's simply because nobody
> had expressed a need for it at the time, but I want to make it clear
> that Malcolm was right: not all methods make sense in all situations.
> We had a lot of back and forth with seek() and tell(), for instance,
> because our chunking mechanism for file access assumes content will
> always only be read from start to finish. This caused problems with
> the zipfile module, because ZIP files don't work that way.
>
> One of the main things we're trying to keep in mind is consistency.
> Much line Django's model lookup API should support all features (or as
> many as humanly possible) across all available databases, I'd like to
> make sure that the provided file methods work on as many file-like
> objects as possible. That's made harder by the fact that there's no
> finite list of supported file objects like there is for supported
> databases. In the end, it may prove to be a losing battle, but I'd
> rather not give up on it quite yet, and that's exactly what deferring
> to the wrapped file object feels like to me.
>
> In general, I'd like to see any new methods receive a "yes" to each of
> the following questions before being implemented in core. I'm not a
> core developer, so I don't have any power to enforce this, but here
> they are, all the same.
>
> 1. Have people actually expressed interest in making it available?
> 2. Does it make sense in the context of a web application?
> 3. Can it be implemented in a way that's equally supported across true
> files, storage-backed files and anonymous (StringIO-type) files?
>
> As you can see, readline() passes all of these tests. Others, like
> truncate(), don't. Just for reference, consider implementing
> truncate() on files backed by a storage backend. In order to work
> properly for things like S3, you'd need to actually read the specified
> number of bytes from the beginning of the file (over the web), then
> write them back out (again, over the web) in order to achieve the
> documented behavior. That's hardly what I'd call "equally supported"
> alongside native filesystem files which have OS functions to do that
> directly.
>
> Anyway, those are my thoughts on the subject.
>
> -Gul

Hi,

I'm taking the chance to remind about 2 relevant tickets:

- #9344 [1]: The tell() proxy is missing in the specific
implementation of TemporaryFile for Windows. That causes PIL to crash.
- #9404 [2]: Some proxies are missing in InMemoryUploadedFile.

In [3] Karen explained that one reason why those tickets had not been
checked-in yet was the absence of tests. But in fact, the existing
proxies are currently not explicitly tested in Django's test suite,
and I think some of them are not tested at all.

I'm unsure how to go about testing these. Do you have suggestions?

Regards,

Julien

[1] http://code.djangoproject.com/ticket/9344
[2] http://code.djangoproject.com/ticket/9404
[3] 
http://groups.google.com/group/django-developers/browse_thread/thread/7085109ceace2e37
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 

Re: #9344 and policy for small bug reports

[Julien Phalip]

On Jan 23, 6:42 pm, Karen Tracey <kmtra...@gmail.com> wrote:
> On Fri, Jan 23, 2009 at 12:38 AM, Julien Phalip <jpha...@gmail.com> wrote:
>
> > Hi,
>
> > I just wanted to draw your attention to what appears to be a bug in
> > Django: the 'tell()' proxy is missing from the Windows-specific
> > implementation of TemporaryFile. This causes Django to crash when
> > manipulating the uploaded file with PIL, for example. Ticket #9344
> > contains a patch to fix that.
>
> I probably looked at that ticket initially, at least briefly.  Here's a peek
> into what likely went on in my head:
>
> - I should look at that...though I don't know the code involved...nor much
> about PIL...still, it's Windows-specific, I've got Windows boxes to test on,
> many (most...all?) other committers don't.
> - Hmmcrash when manipulating uploaded file with PIL...do I know offhand
> how to recreate that...nodo I want to learn enough about PIL to dream up
> how to recreate it...not really.
> - Maybe the patch has a test? Oh, there are 2 patches...I wonder why?
> They're identical...wha? Oh, the first had a spacing error.  But regardless,
> no test.
> - Should there be a test?  Is this something that can't be tested? Is that
> why no test was provided?  Is it blindingly obvious to anyone who knows the
> first thing about PIL how to recreate this problem and that's why no
> specifics on how to recreate were included?  Dunno...this is too hard, let's
> find something easier to look at.
>
> At this point I really should have noted in the ticket what stopped me from
> doing anything with it, but I didn't.  I'm bad that way, particularly when I
> get to a point of thinking that maybe it's my own lack of knowledge that's
> the problem.
>
> So, what that ticket was lacking for me to look at it more closely was
> specific instructions as to how to recreate the problem so I could verify
> the fix.  Even better, a test integrated into the test suite, then it's
> clear to anyone looking later on what exact problem was fixed, and there is
> built-in protection against it breaking again.  If it's not feasible for
> some reason to add a test to the test suite then a note indicating why no
> test is possible would help.
>
> Now, the fix may be trivial (and I'll agree it looks trivial), but I'm not
> going to check in anything without testing it.  Been there, done that, broke
> things, try real hard not to do it any more.  So I want to be able to see
> the problem myself before the fix and verify the problem is gone after the
> fix.
>
> > Now, I know that this is sort of an edge case, and I also know that
> > there are more important and more urgent matters at this moment. But
> > I'd be keen to hear what is the official (or tacit) policy for that
> > kind of small bug reports. There probably are a few other tickets in
> > that situation (#9404 is another example). So, what is the best way to
> > go for people interested in having them checked in? Is it simply by
> > bringing them up on this mailing list from time to time? If so, then I
> > can try again after 1.1 lands.
>
> Best way to make sure "small" tickets do not get hung up on the way to
> checkin is to make them dead easy, even for someone who may not be
> intimately familiar with that area of the code, to understand the problem
> and verify the fix. Include tests integrated into the Django test suite that
> fail before the fix and pass afterward.  If integrated tests aren't
> possible, explain why the fix should be checked in even without tests, and
> include manual recreation instructions so the person who is considering the
> fix knows how to test it manually.
>
> Karen

Thank you Karen for this detailed answer. Your reasoning regarding
this ticket does make a lot of sense. I totally agree with you that
tests are highly important and that this ticket is lacking useful
information for whoever is not familiar with that area of the code. If
I recall, the reason I hadn't written tests for the patch was because
of the way #7769 had been checked in shortly before 1.0's release. I
had thought that, like #7769, the patch was "trivial" enough for not
including tests. But again, as you said, the ticket was lacking
information and I should have at least put a link to #7769 in the
description. I've just done that. I'll think about writing tests but
it seems a bit overkill in this case for something which looks like a
small oversight.

Thank you,

Julien

http://code.djangoproject.com/ticket/7769
--~--~-~--~~~---~--~~
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: #9344 and policy for small bug reports

[Julien Phalip]

On Jan 23, 5:14 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> On Fri, Jan 23, 2009 at 2:38 PM, Julien Phalip <jpha...@gmail.com> wrote:
>
> > Now, I know that this is sort of an edge case, and I also know that
> > there are more important and more urgent matters at this moment. But
> > I'd be keen to hear what is the official (or tacit) policy for that
> > kind of small bug reports. There probably are a few other tickets in
> > that situation (#9404 is another example). So, what is the best way to
> > go for people interested in having them checked in? Is it simply by
> > bringing them up on this mailing list from time to time? If so, then I
> > can try again after 1.1 lands.
>
> Hi Julien,
>
> Unfortunately, there's no simple answer to this question.
>
> The short answer is that it is all about timing and opportunity.
>
> A polite, well-timed message to the mailing list is certainly one way
> to get attention. Keep an eye on the grand schedule. If you make noise
> when the core devs are under the hammer trying to hit a feature
> deadline or manage a planning phase, you're probably going to get
> ignored. However, raising the ticket when the core devs are paying
> attention to bugs - just before a bug fixing sprint, or in the leadup
> to a beta release for example - is likely to get some traction.
>
> Gentle IRC reminders can also work - again, strategically timed
> (during a bug sprint would be a very good time, for example).
>
> Another way to get traction is to pull related items together. When I
> jump into the code to fix a bug in an area I haven't touched for a
> while, it can take a few minutes to refresh my memory on exactly how
> things work. If you collect minor bugs together into similarly themed
> groups, you make an attractive target for us core devs (who are, after
> all, exceedingly lazy and like easy jobs much more than hard jobs :-)
>
> I wish I could give you a concrete answer (ask by email, written in
> sanskrit, between 1 and 1:10 pm UTC on Tuesday afternoons :-) but like
> all things open source, it isn't that simple.
>
> Yours,
> Russ Magee %-)

Thank you Russell for your clear explanation. In fact, I would copy/
paste your reply right into the Django documentation (http://
docs.djangoproject.com/en/dev/internals/contributing/#id1). Those tips
are very useful to know!

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

#9344 and policy for small bug reports

[Julien Phalip]

Hi,

I just wanted to draw your attention to what appears to be a bug in
Django: the 'tell()' proxy is missing from the Windows-specific
implementation of TemporaryFile. This causes Django to crash when
manipulating the uploaded file with PIL, for example. Ticket #9344
contains a patch to fix that.

Now, I know that this is sort of an edge case, and I also know that
there are more important and more urgent matters at this moment. But
I'd be keen to hear what is the official (or tacit) policy for that
kind of small bug reports. There probably are a few other tickets in
that situation (#9404 is another example). So, what is the best way to
go for people interested in having them checked in? Is it simply by
bringing them up on this mailing list from time to time? If so, then I
can try again after 1.1 lands.

Thanks a lot!

Regards,

Julien

http://code.djangoproject.com/ticket/9344
http://code.djangoproject.com/ticket/9404
--~--~-~--~~~---~--~~
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: logout() method for custom authentication backends

[Julien Phalip]

On Dec 1, 11:07 pm, David Reynolds <[EMAIL PROTECTED]>
wrote:
> On 1 Dec 2008, at 11:49, David Reynolds wrote:
> > I have a custom authentication backend that requires a method to be
> > run to log out of the system.  It would be quite useful if there was a
> > way
> > to hook into the django.contrib.auth.logout method to run this custom
> > method.

I think you could achieve that without patching Django. You could
simply create a custom view which wraps around auth.logout and calls
your other method.
--~--~-~--~~~---~--~~
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

[Julien Phalip]

On Nov 26, 11:43 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Wed, Nov 26, 2008 at 2: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.
>
> I'm going to be the stick in the mud and say -0.
>
> I don't have any particular love of or need for Python 2.3, but it has
> taken us a lot of effort to get and maintain Python 2.3 compatibility.
> I know maintaining this support is a pain, but in the grand scheme of
> things it doesn't bite us that often.
>
> I know the GIS stuff is bound to 2.4+, but other than this, is there
> any particularly compelling reason to drop 2.3 support other than the
> annoyance factor for 1.1? I'm just not convinced that the first minor
> release after a major 1.0 release is the right time to do it.
>
> Russ %-)

Maybe the best approach would be to warn people one or two releases in
advance. For example: "Python 2.3 support will be dropped in Django
1.3, so be warned and get ready for it."
--~--~-~--~~~---~--~~
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.1 feature: unify access to response.context in test client

[Julien Phalip]

On Nov 9, 7:56 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> The Djangotestclient exposes theContextused to render the returned
> response, so that unit tests can inspect thatContextand verify that
> it contained what it was expected to contain. This is all well and
> good, except that there is no consistent way to write tests which do
> this.
>
> When an inheritance chain of multiple templates is used to render the
> response, ``response.context`` is alistof dictionaries,
> corresponding to theContextat each template and so, for example, one
> might want to check ``response.context[0]['some_var']``. But when
> inheritance is not used, ``response.context`` is simply a dictionary,
> leading to a check lik ``response.context['some_var']``.
>
> This makes it extremely difficult/tedious to write truly portable unit
> tests, since atestwhich passes on one installation of an application
> might fail on another for no other reason than that the type of
> ``request.context`` has changed from dictionary tolist, or
> vice-versa, raising spurious ``TypeError`` or ``KeyError`` depending
> on which way it changed.
>
> For a real-world example, consider django-registration: I have a local
> project set up to run its unit tests, with minimal (non-inheriting)
> templates; thetestsuite accesses ``request.context``
> dictionary-style, and passes. But a user of django-registration
> attempted to run thetestsuite on an installation which uses
> inheritance, and saw multipletestfailures as a result:
>
> http://www.bitbucket.org/ubernostrum/django-registration/issue/3/fail...
>
> I believe quite strongly that unit tests, if they are to be useful,
> need to be portable. And currently, it seems the only way to make them
> portable is to include type checks on response.contexteach time atestwill 
> inspect thecontext, e.g.,::
>
>     if isinstance(response.context,list):
>         self.assertEqual(response.context[0]['foo'], 'bar')
>     else:
>         self.assertEqual(response.context['foo'], 'bar')
>
> This is painful and ugly.
>
> For 1.1, could we look into unifying the interface to
> ``response.context`` to avoid this sort of problem? Unless I'm
> thinking about this the wrong way, it shouldn't be too hard to
> differentiate dictionary-style access fromlist-style access, since
> the former -- in the case of aContext-- will always be using string
> keys and the latter will always be using integer indexes.

Hi,

I could not find any mention of this in the Version 1.1 features or
roadmap. I guess it'll have to wait till next release. Could you
please confirm?

Thanks,

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

Upgrading Trac?

[Julien Phalip]

I know that this is likely to be a tricky/boring task and that it is
probably low-priority since we're on the way to 1.1, but I thought at
least I'd ask: Is there any plan in the short/mid term to upgrade
Trac?

My personal itch is that the current version (0.10.4) doesn't allow
email obfuscation. I now exclusively use RSS feeds to track tickets
but in the early days I used to use the CC field. And that has been
the cause of an ongoing and significant amount of spam. Email
obfuscation is available since version 0.11 [1].

That's my main concern about Trac but maybe someone else will bring up
other good features that would justify an upgrade.

Again, I understand it's low-priority and I won't push for it too
hard.

Cheers,

Julien

[1] http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.11
--~--~-~--~~~---~--~~
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: Declarative syntax for widgets in ModelForm

[Julien Phalip]

On Sep 29, 11:40 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote:
>
> > Why not do something like this:
>
> > class MyForm(forms.ModelForm):
> > class Meta:
> > fields = {
> > 'text': forms.CharField(widget=forms.Textarea(), ...),
> > 'other_field': None,
> > }
>
> This syntax would not be completely DRY. If, for example, the model's
> 'text' field was optional (blank=True), you would need to explicitly
> specify the form field as optional (required=False) as well:
>
> ...
>  'text': forms.CharField(widget=forms.Textarea(),
> required=False...),
> ...
>
> By having a separate 'widgets' option you could modify the widgets
> independently from anything else. Not only is that DRY but also that
> would prevent some potential mistakes.

Also, you can already completely override a field like follows:

class MyForm(forms.ModelForm):
title = forms.CharField(widget=forms.Textarea(), ...)

class Meta:
model = Article
--~--~-~--~~~---~--~~
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: Declarative syntax for widgets in ModelForm

[Julien Phalip]

On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote:
> Why not do something like this:
>
> class MyForm(forms.ModelForm):
> class Meta:
> fields = {
> 'text': forms.CharField(widget=forms.Textarea(), ...),
> 'other_field': None,
> }

This syntax would not be completely DRY. If, for example, the model's
'text' field was optional (blank=True), you would need to explicitly
specify the form field as optional (required=False) as well:

...
 'text': forms.CharField(widget=forms.Textarea(),
required=False...),
...

By having a separate 'widgets' option you could modify the widgets
independently from anything else. Not only is that DRY but also that
would prevent some potential mistakes.

> On Sep 29, 11:07 am, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> > Bah, it was just prototype code but point taken ;)
>
> > I do feel like it leads to slippery slope though. LikeMichael said,
> > "why stop at widgets?" I often need to change labels and help text
> > too.
>
> > On Sep 29, 8:56 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> > > SmileyChris wrote:
> > > > I've always just done this by doing:
>
> > > > MyForm(ModelForm)
> > > > model = MyModel
> > > > def __init__(self, *args, **kwargs):
> > > > self.fields['name'].widget = Textarea()   # or whatever
>
> > > You've forgot to call `super` :-). I know that it's only an example but
> > > it adds another line and also shows that such things can easily be
> > > forgotten in real code.
>
> > > > Do we really need another way of doing this? Or am I overlooking
> > > > something that this new method introduces?
>
> > > I've addressed this exact thing my first email on subject, so quoting
> > > myself:
>
> > > > Here the problem is that it has enough boilerplate code to be, shall we
> > > > say, not beautiful. And also it defeats nice declarative nature of a
> > > > ModelForm.
>
> > > So, yes, it's not the end of the world but it's the same convenience as
> > > `fields` or `exclude` that all could be simulated in __init__.
--~--~-~--~~~---~--~~
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: Letting Library.simple_tag access context (code ready)

[Julien Phalip]

On Sep 28, 4:20 am, Leaf <[EMAIL PROTECTED]> wrote:
> Out of necessity, I've made a modification to my Django trunk. It
> gives a parameter to the Library.simple_tag() function named
> takes_context.

You might want to take a look at ticket #1105. I addresses the issue
you're raising here, and has been put on the version 1.1 wish-list.

Regards,

Julien

http://code.djangoproject.com/ticket/1105
http://code.djangoproject.com/wiki/Version1.1Features
--~--~-~--~~~---~--~~
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: installmedia command - A story for distributing media with apps

[Julien Phalip]

On Sep 17, 8:49 am, Brian Beck <[EMAIL PROTECTED]> wrote:
> On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> > Serving is totally orthogonal -- everyone is already serving up
> > MEDIA_ROOT in their projects somehow anyway, and this just copies
> > files to MEDIA_ROOT.
>
> Sorry, I guess that's not totally true -- everyone who uses more than
> just the admin app has set up static file serving for MEDIA_ROOT.

I really like the idea. However, I think there should also be a way to
configure it to not copy to MEDIA_ROOT but to somewhere else.

It would also be good to get that deployment system play nicely with
custom file storage (if you're hosting your media on S3 for example).

Also, instead of just copying the media files, it should also do some
cleanup. Say, if you're tracking trunk for a given app, when you SVN
update that app you want stale media files to be removed.

Just some thoughts.
--~--~-~--~~~---~--~~
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: installmedia command - A story for distributing media with apps

[Julien Phalip]

On Sep 17, 7:09 am, "Don Spaulding" <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 16, 2008 at 11:26 AM, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> > $ python manage.py installmedia appname [appname ...]
>
> > The command is "dumb."..
>
> Could it be a little smarter, and in the absence of specific apps, iterate
> over all INSTALLED_APPS, and install their media automagically?

+1 for some sort of media.autodiscover().
It would have to be optional though, as that might break backwards-
compatibility.

Also, there's an issue about the way files are served. For example, in
my projects I make Apache serve 'admin_media' files independently.
What would be an approach to make that serving configuration happen
for custom apps?
--~--~-~--~~~---~--~~
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: I want a pony: Django Cheeseshop

[Julien Phalip]

On Sep 14, 8:35 am, Martin Diers <[EMAIL PROTECTED]> wrote:
> The answer to the current package chaos is not a centralized  
> repository. I do not like that idea one bit. It's too storm-
> trooperish. Who is going to decide whether a package is repository-
> worthy?

I would take the example of jQuery. They have a single repository at
google code to store pretty much every plugin [1], the good the bad
and the ugly. So, no discrimination, anyone can have their plugin
hosted there. I think the jQuery team have a deal with Google to
handle such big volumes of data, for free.

There is also a centralized interface [2] for all the community
activities related to plugin development: discussion boards, voting,
bug tracking, etc.

I think that is a very sensible and useful approach. Everything is in
one place, and it is much easier to compare plugins and find the best
ones. It both keeps the jQuery community focused and makes users' life
a lot easier.

I would argue that this system was part of jQuery's success, and I
would love to see a similar thing with Django.

> The answer is community packaging guidelines. Somebody needs to write  
> or adapt an existing doc on how to package django apps using existing  
> Python tools (which are excellent already), how to name them, etc.  
> That doc could then be incorporated into djangoproject.com. The usual  
> community-driven caveats apply: let it be discussed, debated, etc. If  
> the major Django contributors begin using it for their own package  
> submissions, and the guidelines make sense, the community as a whole  
> will follow suit.

I agree and I like this idea. While I think packaging an app should
remain the responsibility of each app's developer, some documentation
with best practices (from a Django's perspective) would be welcome.

[1] http://code.google.com/p/jqueryjs/source/browse/#svn/trunk/plugins
[2] http://plugins.jquery.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
-~--~~~~--~~--~--~---

Model examples missing in refactored doc

[Julien Phalip]

Hi,

First, apologies if this is already being looked after.

Since the refactoring of the docs and the old docs being shut down,
the model examples have gone. Also, some links are now outdated (4
occurrences in [1]).

I just see it's been reported again in #9007, and I think this will be
a trap especially for all the new users looking for documentation on
models.

These models examples seemed to be auto-generated from the actual
model tests. Are they easy to restore in the new docs? I believe the
1.0 docs will be frozen soon so it'd be good to fix it before then.

Thanks,

Julien ;)

[1] http://docs.djangoproject.com/en/dev/topics/db/models/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---