Re: Refactor year, month, day lookups?

[Anssi Kääriäinen]

+1 for implementing these. They weren't part of the original patch because the 
patch was a large one already without these.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4e98e7d1-f4d5-4c5d-af11-cb787edb407a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Refactor year, month, day lookups?

[Josh Smeaton]

Hi,

Firstly (and least importantly) opening a PR makes it a lot easier to 
review code, especially when there are lots of commits. A [WIP] pull 
request is common and useful. If you get a chance, you should open one with 
this change.

I think it's a good idea. So much so that I opened a ticket about a year 
ago: https://code.djangoproject.com/ticket/22394. You'll note some comments 
there about retaining the Year based behaviour as a `BETWEEN X and Y` 
rather than `Extract(YEAR)`. Otherwise, I think the support is rather 
positive. At a high level, your code looks fairly solid and I think would 
be a useful addition.

Another thing I would really like to see is transform based annotations. 
I'm not 100% sure on whether .annotate(F('X__transform')) is supported or 
not, but if it is, we'll get some really nice behaviour from the use of 
transforms.

Think:

sales_per_month = Model.objects.annotate(month=F('mydate__month')).values(
'month').Aggregate(sales=Sum('sale'))

If Transforms don't yet work with annotate, that'll probably be what I'd 
like to implement next. But the first step is having transforms to work 
with, where date based transforms are (to me) the most useful.

Cheers,

On Wednesday, 25 March 2015 13:39:39 UTC+11, Jon Dufresne wrote:
>
> Hi, 
>
> I have been spending some time learning and investigating the custom 
> lookups feature that was newly introduced in 1.7 [0]. While 
> investigating, I wanted to learn by example so I started looking 
> through the Django code. In the end, I didn't find many examples. 
> However, I did notice that there exists lookups for the year, month, 
> day, (and more) value from a database date or datetime value [1]. 
> These appear to be implemented as special case "builtin" lookups and 
> not through the new lookup mechanism. Is there a specific reason for 
> this or is it historical momentum? 
>
> I started investigating if these could be refactored to use the common 
> code path and implemented using the new lookup mechanism. To my 
> delight it was not very difficult and I now have all tests passing 
> after refactoring these lookups. Right now, this lives in a branch of 
> mine and not in a ticket or pull request. The WIP branch is located 
> at:  
>
> Would this be something welcome as a ticket and pull request? While 
> there is no outward change in functionality, I see it as a beneficial 
> refactoring because with this change: 
>
> 1. The year, month, day, etc lookups are no longer treated as special 
> cases, but instead use the common code path. 
> 2. There now exists complete and useful examples of registering new 
> lookups in the Django code itself. This might help others build more 
> lookups. 
> 3. The lookups are now limited to the correct Field types where as 
> previously this was not true. I demonstrate this with a unit test. 
>
> If this looks like it could be a welcome change I will can go forward 
> with a typical ticket and pull request. 
>
> Cheers, 
> Jon 
>
> [0] https://docs.djangoproject.com/en/dev/howto/custom-lookups/ 
> [1] https://docs.djangoproject.com/en/dev/ref/models/querysets/#year 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6b07e38a-d45a-4f48-9702-d185aa512b74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for feedback on GSoC proposal "Test framework cleanup"

[Russell Keith-Magee]

Hi Varun,

I've just taken a look at this proposal; I've got some concerns.

 * You say you can get test coverage from 81% to 90% - that's an admirable
goal, but is there any reason to believe that it is achievable? In many
cases, the coverage is low because a feature/branch is so difficult to test
that the cost in developing test harnesses vastly exceeds the likelihood of
breakage, or because the branches that aren't covered aren't *ever* going
to be executed (i.e "you shouldn't be here" branches).

Don't get me wrong - more coverage would be better - but you're going to
need to provide evidence of what you're going to focus on to gain 9% in
test coverage. It's not just a matter of saying "I'm gonna get 9% more".

 * I am in no way convinced that shuffling deck chairs to have a
unit/integration/regression separation will be in any way helpful. Django
once had a separate regression tests directory - we *removed* that
separation specifically because it was becoming burdensome to identify
whether a test was a "core function" test or a "regression" test.

 * I'm not convinced that more options to ./runtests.py is an area where we
should be spending effort - or, to the extent that it is, we should only be
seeking to expose functionality provided by the base unittest runner. If
this means that changes are needed in unittest itself, then that's a
project to direct towards Python core - which unfortunately puts it out of
scope for Django.

 * I'm not convinced that a runner to help run all database backends at
once is ultimately that helpful - I wouldn't have considered the burden of
running three different test runs (or relying on the CI server, which does
this for you) was sufficiently onerous to warrant spending time on the
problem.

 * Regarding schedule - I've said this in other threads, and I appreciate
that this is a first cut proposal -- but I'm *deeply* sceptical of any
proposal that contains estimates of granularity > 2 weeks. The bulk of your
timeline is in a 5 week block and a 4 week block - but you haven't provided
any evidence that 5 weeks is an appropriate amount of time for the work
provided, rather than just a number that adds up nicely to 12 weeks.

Yours,
Russ Magee %-)


On Wed, Mar 25, 2015 at 9:18 AM, Varun Sharma  wrote:

> Hi All,
>
> I've been writing this proposal from past few days. After going through
> the pycon talks of Carl Meyer and Julien Phalip on Django's testing
> framework and working on the test framework from last 2 months, I have
> drafted some improvements but I'm not sure about any roadblocks or
> feasibility issues that may arise during the implementation. In order to
> minimise that, I request you all to have a look at the proposal and help me
> out on the feasibility issues. I'd really appreciate any kind of feedback
> and will do the required changes accordingly.
>
> Proposal: https://gist.github.com/varunsharma/597058c5da51d86698e3
>
>
> Thanks
> Varun
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJ7sbhEcj4uCk9U0%3DwbMY8wV1J0wQRjcma703W_%2BMe%2Br0Gmj%2BA%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-HXigucbZdnisN3xwi4E96RDMr3HNWdUGFPznvaKPUxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Refactor year, month, day lookups?

[Jon Dufresne]

Hi,

I have been spending some time learning and investigating the custom
lookups feature that was newly introduced in 1.7 [0]. While
investigating, I wanted to learn by example so I started looking
through the Django code. In the end, I didn't find many examples.
However, I did notice that there exists lookups for the year, month,
day, (and more) value from a database date or datetime value [1].
These appear to be implemented as special case "builtin" lookups and
not through the new lookup mechanism. Is there a specific reason for
this or is it historical momentum?

I started investigating if these could be refactored to use the common
code path and implemented using the new lookup mechanism. To my
delight it was not very difficult and I now have all tests passing
after refactoring these lookups. Right now, this lives in a branch of
mine and not in a ticket or pull request. The WIP branch is located
at: 

Would this be something welcome as a ticket and pull request? While
there is no outward change in functionality, I see it as a beneficial
refactoring because with this change:

1. The year, month, day, etc lookups are no longer treated as special
cases, but instead use the common code path.
2. There now exists complete and useful examples of registering new
lookups in the Django code itself. This might help others build more
lookups.
3. The lookups are now limited to the correct Field types where as
previously this was not true. I demonstrate this with a unit test.

If this looks like it could be a welcome change I will can go forward
with a typical ticket and pull request.

Cheers,
Jon

[0] https://docs.djangoproject.com/en/dev/howto/custom-lookups/
[1] https://docs.djangoproject.com/en/dev/ref/models/querysets/#year

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b4C4y5ZUHvNEugizHrqjL4EWoQJQcc8nne%2BjxsmU-L3uA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Request for feedback on GSoC proposal "Test framework cleanup"

[Varun Sharma]

Hi All,

I've been writing this proposal from past few days. After going through the
pycon talks of Carl Meyer and Julien Phalip on Django's testing framework
and working on the test framework from last 2 months, I have drafted some
improvements but I'm not sure about any roadblocks or feasibility issues
that may arise during the implementation. In order to minimise that, I
request you all to have a look at the proposal and help me out on the
feasibility issues. I'd really appreciate any kind of feedback and will do
the required changes accordingly.

Proposal: https://gist.github.com/varunsharma/597058c5da51d86698e3


Thanks
Varun

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJ7sbhEcj4uCk9U0%3DwbMY8wV1J0wQRjcma703W_%2BMe%2Br0Gmj%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC: Turn contrib.admin into a customizable management interface

[tyrion-mx]

On Tuesday, March 24, 2015 at 11:48:59 PM UTC+1, Curtis Maloney wrote:
>
> Let's not get bogged down in minutiae just yet :)
>

> How to implement a grid and what level of browser support is something 
> that can be threshed out in the process.
>
I agree 

I love the idea of a Dashboard with custom Widgets.
>
> Allowing the existing "App list" widgets, along with new custom non-model 
> widgets will open Admin a lot.
>
> This idea is so good, grappelli have had it for years :p
>
Infact I am now trying to look and understand the documentation and code of 
grappelli and also of django-xadmin ( 
https://github.com/sshwsfc/django-xadmin ).
I don't know yet how these projects implemented a dashboard, so I am going 
to study them a little. Anyway if you want to suggest a good architecture 
to implement this, please do it. 
 

> Does this also, then, imply the need for sub-dashboards, as Admin has 
> currently per-app?  Or would we use our new-found flexibility to, for 
> instance, accordion-out "folders" of widgets?
>
  I am not sure I understand what you mean here. If you are talking about 
the possibility to have a custom dashboard for every app in the app index 
page (i.e. /admin/$app), it is ok for me. The only constraints now are the 
little time remained to write the proposal and the time available to do the 
GSOC.

However I think that app dashboards and widgets groups could be left out 
initially and added later if we want them.
 

> And I may as well suggest allowing widgets to hint at their size [e.g. 
>  1x1, 2x1, 1x2, etc..]
>
  Yes my idea was to put these information in the html like this, probably:



where widget.size and order could come from the database or the user's 
session for example.
The only problem here is that we would have to decide what 1x1, 2x1 etc 
means (i.e. do we want a grid or do we want to leave the developers of 
widgets to define their own css)
I am not too expert with css, so it is not super-clear to me what would be 
the best way to handle this. 

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a76eccd-650b-48a3-b3e4-a5cc520f521e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Russell Keith-Magee]

I agree with Tim's assessment - this is not a compelling proposal at the
moment.

There is value in converting *some* of the function based views to CBVs,
but unilaterally converting all of them doesn't seem especially worthwhile.
The key thing is to identify what features need to be factored out. A view
doesn't get better just because it's class-based. It gets better because
the class-based structure allows you to factor out key functionality in a
way that subclasses can override or modify that functionality. I might be
more enthusiastic about this aspect of the proposal if you detailed what
features of each view you were hoping to make user-overridable.

The Formset and Admin parts of your proposal are sufficiently nebulous that
it's impossible to see what you have in mind. "The good parts" from
formset-extras and "the goodies" from admin2 could easily be a project in
itself.

The lack of a timeline is also a major omission. For me, the timeline is
the most important part of the proposal.

Yours,
Russ Magee %-)

On Wed, Mar 25, 2015 at 6:15 AM, Tim Graham  wrote:

> Sorry, but to be honest I am not enthusiastic about this proposal. I'm not
> sure there's a great need or value in converting all function based views
> to class-based views. Your plans regarding django-extra-views and admin
> improvements have not been described in sufficient detail that give me a
> good idea of what you plan to do. Finally, the lack of a timeline leaves me
> wondering how many weeks worth of work you have planned.
>
> On Tuesday, March 24, 2015 at 1:55 :40 PM UTC-4, Asif Saifuddin wrote:
>>
>> Have a look. though rough draft and many place for improvment
>>
>> https://gist.github.com/auvipy/1da0d96f826bd8da4d47
>> 
>>
>> On Mon, Mar 23, 2015 at 4:43 AM, Tim Graham  wrote:
>>
>>> Please explain what you plan to implement in the other apps rather than
>>> what's already been implemented in contrib.auth. You'll also need to
>>> explain your reasoning for addressing a ticket that's been marked as "won't
>>> fix."
>>>
>>> On Sunday, March 22, 2015 at 4:36:26 PM UTC-4, Asif Saifuddin wrote:

 I do belive to implement auth patch cleanly wont take more then a few
 days. But I have plans with django admin app and others which will need
 more tasks and also thinking about working with formset . The part I posted
 here is just a very little/start point of my proposal :)

 And I am working on a draft gist for full proposal. This part was
 posted to have an Idea if I'm going to right direction. I found admin-docs
 up to date with class based views and using that as a good reference to
 understand the implementation and also getting ideas about the problems
 people faced earlier and theie thoughts about the possible solutions :)

 I'm I in right direction? at least in some context? knowing that will
 help me a lot

 ./auvipy



 On Mon, Mar 23, 2015 at 1:14 AM, Tim Graham  wrote:

> I see there's already a patch attached to the ticket that implements
> your proposal. While it likely needs to be updated to apply cleanly, I
> don't imagine that will take more than a few days?
>
>
> On Sunday, March 22, 2015 at 2:19:37 PM UTC-4, Asif Saifuddin wrote:
>>
>> Hi All,
>>
>> during my analyzing and making proposal for django best practices
>> updates (class based view etc)  I found this ticket related
>> https://code.djangoproject.com/ticket/16256 [though closed by a core
>> dev I think this should be addressed to resolve some issues in admin as 
>> per
>>  https://code.djangoproject.com/ticket/17209]
>>
>>
>> Here goes some of my initial proposal plan I will be updating
>> regularly to complete the proposal in a gist and share that again. before
>> that please give some feedback :)
>>
>> Background
>>
>> Over the years, as Django has evolved, the idea of what constitutes
>> "best practice" has also evolved. However, some parts of Django haven't
>> kept up with those best practices. For example, contrib apps do not use
>> class based views.
>>
>> In short, Django has been bad at eating it's own dogfood. The
>> contents of contrib should be audited and updated to make sure it meets
>> current best practices.
>>
>> For updating best practices first think to consider is to convert the
>> functional views of django contrib apps to class based views where 
>> possible
>> and necessary. To do so first app to consider is django contrib auth.
>>
>> contrib-auth views.py now have function based views and they are
>>
>> login logout logout_then_login redirect_to_login password_reset
>> password_reset_done 

Re: GSOC: Turn contrib.admin into a customizable management interface

[Curtis Maloney]

Let's not get bogged down in minutiae just yet :)

How to implement a grid and what level of browser support is something that
can be threshed out in the process.

I love the idea of a Dashboard with custom Widgets.

Allowing the existing "App list" widgets, along with new custom non-model
widgets will open Admin a lot.

This idea is so good, grappelli have had it for years :p

Does this also, then, imply the need for sub-dashboards, as Admin has
currently per-app?  Or would we use our new-found flexibility to, for
instance, accordion-out "folders" of widgets?

And I may as well suggest allowing widgets to hint at their size [e.g.
 1x1, 2x1, 1x2, etc..]


... I'll comment more when I can focus better ...

--
C

On 25 March 2015 at 04:33, Patrick Guido  wrote:

> About IE 9 support it is possible to use a polyfill for flexbox, even
> thought this causes performance problems and/or it (the polyfill) could not
> implement the full spec. https://github.com/doctyper/flexie
>
> Another options is to go mobile first *even* on IE 9 (eg, everything on
> one column), I saw an article where someone was describing this approach
> (for ie8), if I find the link I'll post it here. If we add some IE9
> specific css it could look good.
>
> Patrick
>
> On Tue, Mar 24, 2015 at 5:16 PM Aaron C. de Bruyn 
> wrote:
>
>> On Tue, Mar 24, 2015 at 9:10 AM, Germano Gabbianelli
>>  wrote:
>> > Uhm, missing IE9 support. It is the default browser on vista, which has
>> > extended support until 2017 :|
>>
>>
>> "Beginning January 12, 2016, only the most current version of Internet
>> Explorer available for a supported operating system will receive
>> technical support and security updates."
>>
>> https://support.microsoft.com/en-us/lifecycle/search?sort=
>> PN=internet%20explorer
>>
>> I'm not a Windows guy, so I'm not sure if newer versions of IE run on
>> Vista.  If they do, it looks like we're less than a year away from IE9
>> being unsupported.
>>
>> Then again, I know my company has clients that still have ~40% of
>> machines running Windows XP due to upgrade costs. ;)
>>
>> -A
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-developers/CAEE%2BrGq%2Bn%2Bi5LA%
>> 2B1Fs47LY3xKCvCZ%3DZBVDjZRnB8%2BBPw%3DdyTNw%40mail.gmail.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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAOUxZcsur_mn0q3EoXPe-QEZ1dRHYgw9jJycSUJVJqUBnyxLhQ%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAZE8u9V-N3c9obN4rp8Kz20m0pyQoELGWF09N2hWeiqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2015

[Russell Keith-Magee]

Hi Zafack Billy,

Welcome! If you're interested in being a GSoC student with Django, you
should read our wiki page on the program.

https://code.djangoproject.com/wiki/SummerOfCode2015

>From there, you need to pick a project, and prepare a proposal describing
what you expect to achieve over the 12 week program.

If you've got any questions, let us know!

Yours,
Russ Magee %-)

On Tue, Mar 24, 2015 at 6:24 PM, Billy Ruffin Zafack <
billy.sum.zaf...@gmail.com> wrote:

> Let me first briefly introduce myself to the group as a student developer
> and an aspiring GSoC-2015 Participant
>
> Name: Zafack Billy
>Currently Computer Engineering Student(4th year) at National
> Advanced School of Engineering
>Yaounde, Cameroon
>
>Have gone through the ideas page and will be coming up with some
> reactions.
>
>I believe I have a lot to learn from this group and a lot to contribute.
>Thanks for having me.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b0c1e870-3403-4ad9-a778-57fed1e53d8a%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-hMdYOhMay20JdeiZ-iVw6tUT8K%2BiQv8O_qSOKoeYHBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Tim Graham]

Sorry, but to be honest I am not enthusiastic about this proposal. I'm not 
sure there's a great need or value in converting all function based views 
to class-based views. Your plans regarding django-extra-views and admin 
improvements have not been described in sufficient detail that give me a 
good idea of what you plan to do. Finally, the lack of a timeline leaves me 
wondering how many weeks worth of work you have planned.

On Tuesday, March 24, 2015 at 1:55 :40 PM UTC-4, Asif Saifuddin wrote:
>
> Have a look. though rough draft and many place for improvment
>
> https://gist.github.com/auvipy/1da0d96f826bd8da4d47 
> 
>
> On Mon, Mar 23, 2015 at 4:43 AM, Tim Graham  > wrote:
>
>> Please explain what you plan to implement in the other apps rather than 
>> what's already been implemented in contrib.auth. You'll also need to 
>> explain your reasoning for addressing a ticket that's been marked as "won't 
>> fix."
>>
>> On Sunday, March 22, 2015 at 4:36:26 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> I do belive to implement auth patch cleanly wont take more then a few 
>>> days. But I have plans with django admin app and others which will need 
>>> more tasks and also thinking about working with formset . The part I posted 
>>> here is just a very little/start point of my proposal :)
>>>
>>> And I am working on a draft gist for full proposal. This part was posted 
>>> to have an Idea if I'm going to right direction. I found admin-docs up to 
>>> date with class based views and using that as a good reference to 
>>> understand the implementation and also getting ideas about the problems 
>>> people faced earlier and theie thoughts about the possible solutions :)
>>>
>>> I'm I in right direction? at least in some context? knowing that will 
>>> help me a lot
>>>
>>> ./auvipy
>>>
>>>
>>>
>>> On Mon, Mar 23, 2015 at 1:14 AM, Tim Graham  wrote:
>>>
 I see there's already a patch attached to the ticket that implements 
 your proposal. While it likely needs to be updated to apply cleanly, I 
 don't imagine that will take more than a few days?


 On Sunday, March 22, 2015 at 2:19:37 PM UTC-4, Asif Saifuddin wrote:
>
> Hi All,
>
> during my analyzing and making proposal for django best practices 
> updates (class based view etc)  I found this ticket related 
> https://code.djangoproject.com/ticket/16256 [though closed by a core 
> dev I think this should be addressed to resolve some issues in admin as 
> per 
>  https://code.djangoproject.com/ticket/17209]
>
>
> Here goes some of my initial proposal plan I will be updating 
> regularly to complete the proposal in a gist and share that again. before 
> that please give some feedback :)
>
> Background
>
> Over the years, as Django has evolved, the idea of what constitutes 
> "best practice" has also evolved. However, some parts of Django haven't 
> kept up with those best practices. For example, contrib apps do not use 
> class based views.
>
> In short, Django has been bad at eating it's own dogfood. The contents 
> of contrib should be audited and updated to make sure it meets current 
> best 
> practices.
>
> For updating best practices first think to consider is to convert the 
> functional views of django contrib apps to class based views where 
> possible 
> and necessary. To do so first app to consider is django contrib auth.
>
> contrib-auth views.py now have function based views and they are
>
> login logout logout_then_login redirect_to_login password_reset 
> password_reset_done password_reset_confirm password_reset_complete 
> password_change password_change_done
>
> and in urls.py url mapping for function based views as follows
>
> urlpatterns = [ url(r'^login/$', views.login, name='login'), 
> url(r'^logout/$', views.logout, name='logout'), 
> url(r'^password_change/$', 
> views.password_change, name='password_change'), 
> url(r'^password_change/done/$', views.password_change_done, 
> name='password_change_done'), url(r'^password_reset/$', 
> views.password_reset, name='password_reset'), 
> url(r'^password_reset/done/$', views.password_reset_done, 
> name='password_reset_done'), url(r'^reset/(?P[0-9A-Za-z_-]+
> )/(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$', 
> views.password_reset_confirm, name='password_reset_confirm'), 
> url(r'^reset/done/$', views.password_reset_complete, 
> name='password_reset_complete'), ]
>
> and tests for this in tests/auth_tests/test_views.py
>
> the views have to be converted into CBV and also the urls. and this 
> should be done in a backward compatible manner.
>
> as an example password_change_done 

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Have a look. though rough draft and many place for improvment

https://gist.github.com/auvipy/1da0d96f826bd8da4d47

On Mon, Mar 23, 2015 at 4:43 AM, Tim Graham  wrote:

> Please explain what you plan to implement in the other apps rather than
> what's already been implemented in contrib.auth. You'll also need to
> explain your reasoning for addressing a ticket that's been marked as "won't
> fix."
>
> On Sunday, March 22, 2015 at 4:36:26 PM UTC-4, Asif Saifuddin wrote:
>>
>> I do belive to implement auth patch cleanly wont take more then a few
>> days. But I have plans with django admin app and others which will need
>> more tasks and also thinking about working with formset . The part I posted
>> here is just a very little/start point of my proposal :)
>>
>> And I am working on a draft gist for full proposal. This part was posted
>> to have an Idea if I'm going to right direction. I found admin-docs up to
>> date with class based views and using that as a good reference to
>> understand the implementation and also getting ideas about the problems
>> people faced earlier and theie thoughts about the possible solutions :)
>>
>> I'm I in right direction? at least in some context? knowing that will
>> help me a lot
>>
>> ./auvipy
>>
>>
>>
>> On Mon, Mar 23, 2015 at 1:14 AM, Tim Graham  wrote:
>>
>>> I see there's already a patch attached to the ticket that implements
>>> your proposal. While it likely needs to be updated to apply cleanly, I
>>> don't imagine that will take more than a few days?
>>>
>>>
>>> On Sunday, March 22, 2015 at 2:19:37 PM UTC-4, Asif Saifuddin wrote:

 Hi All,

 during my analyzing and making proposal for django best practices
 updates (class based view etc)  I found this ticket related
 https://code.djangoproject.com/ticket/16256 [though closed by a core
 dev I think this should be addressed to resolve some issues in admin as per
  https://code.djangoproject.com/ticket/17209]


 Here goes some of my initial proposal plan I will be updating regularly
 to complete the proposal in a gist and share that again. before that please
 give some feedback :)

 Background

 Over the years, as Django has evolved, the idea of what constitutes
 "best practice" has also evolved. However, some parts of Django haven't
 kept up with those best practices. For example, contrib apps do not use
 class based views.

 In short, Django has been bad at eating it's own dogfood. The contents
 of contrib should be audited and updated to make sure it meets current best
 practices.

 For updating best practices first think to consider is to convert the
 functional views of django contrib apps to class based views where possible
 and necessary. To do so first app to consider is django contrib auth.

 contrib-auth views.py now have function based views and they are

 login logout logout_then_login redirect_to_login password_reset
 password_reset_done password_reset_confirm password_reset_complete
 password_change password_change_done

 and in urls.py url mapping for function based views as follows

 urlpatterns = [ url(r'^login/$', views.login, name='login'),
 url(r'^logout/$', views.logout, name='logout'), url(r'^password_change/$',
 views.password_change, name='password_change'),
 url(r'^password_change/done/$', views.password_change_done,
 name='password_change_done'), url(r'^password_reset/$',
 views.password_reset, name='password_reset'),
 url(r'^password_reset/done/$', views.password_reset_done,
 name='password_reset_done'), url(r'^reset/(?P[0-9A-Za-z_-]+
 )/(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$',
 views.password_reset_confirm, name='password_reset_confirm'),
 url(r'^reset/done/$', views.password_reset_complete,
 name='password_reset_complete'), ]

 and tests for this in tests/auth_tests/test_views.py

 the views have to be converted into CBV and also the urls. and this
 should be done in a backward compatible manner.

 as an example password_change_done view is now implemented as below.

 @login_required def password_change_done(request,
 template_name='registration/password_change_done.html',
 current_app=None, extra_context=None): context = { 'title': _('Password
 change successful'), } if extra_context is not None:
 context.update(extra_context)

 if current_app is not None:
 request.current_app = current_app

 return TemplateResponse(request, template_name, context)

 this could be changed to cbv like below

 class PasswordChangeDoneView(TemplateView):
 template_name='registration/password_change_done.html'
 current_app=None extra_context=None

 @method_decorator(login_required)
 def dispatch(self, request, *args, **kwargs):
 return 

Re: GSOC: Turn contrib.admin into a customizable management interface

[Patrick Guido]

About IE 9 support it is possible to use a polyfill for flexbox, even
thought this causes performance problems and/or it (the polyfill) could not
implement the full spec. https://github.com/doctyper/flexie

Another options is to go mobile first *even* on IE 9 (eg, everything on one
column), I saw an article where someone was describing this approach (for
ie8), if I find the link I'll post it here. If we add some IE9 specific css
it could look good.

Patrick

On Tue, Mar 24, 2015 at 5:16 PM Aaron C. de Bruyn 
wrote:

> On Tue, Mar 24, 2015 at 9:10 AM, Germano Gabbianelli
>  wrote:
> > Uhm, missing IE9 support. It is the default browser on vista, which has
> > extended support until 2017 :|
>
>
> "Beginning January 12, 2016, only the most current version of Internet
> Explorer available for a supported operating system will receive
> technical support and security updates."
>
> https://support.microsoft.com/en-us/lifecycle/search?sort=
> PN=internet%20explorer
>
> I'm not a Windows guy, so I'm not sure if newer versions of IE run on
> Vista.  If they do, it looks like we're less than a year away from IE9
> being unsupported.
>
> Then again, I know my company has clients that still have ~40% of
> machines running Windows XP due to upgrade costs. ;)
>
> -A
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAEE%2BrGq%2Bn%2Bi5LA%
> 2B1Fs47LY3xKCvCZ%3DZBVDjZRnB8%2BBPw%3DdyTNw%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOUxZcsur_mn0q3EoXPe-QEZ1dRHYgw9jJycSUJVJqUBnyxLhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC: Turn contrib.admin into a customizable management interface

[Aaron C. de Bruyn]

On Tue, Mar 24, 2015 at 9:10 AM, Germano Gabbianelli
 wrote:
> Uhm, missing IE9 support. It is the default browser on vista, which has
> extended support until 2017 :|


"Beginning January 12, 2016, only the most current version of Internet
Explorer available for a supported operating system will receive
technical support and security updates."

https://support.microsoft.com/en-us/lifecycle/search?sort=PN=internet%20explorer

I'm not a Windows guy, so I'm not sure if newer versions of IE run on
Vista.  If they do, it looks like we're less than a year away from IE9
being unsupported.

Then again, I know my company has clients that still have ~40% of
machines running Windows XP due to upgrade costs. ;)

-A

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEE%2BrGq%2Bn%2Bi5LA%2B1Fs47LY3xKCvCZ%3DZBVDjZRnB8%2BBPw%3DdyTNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC: Turn contrib.admin into a customizable management interface

[Germano Gabbianelli]

On 24/03/15 13:06, Riccardo Magliocchetti wrote:

Il 24/03/2015 12:37, Germano Gabbianelli ha scritto:


On 24/03/15 11:56, Riccardo Magliocchetti wrote:
With these sentences I was thinking about customizing the properties 
of the
ModelAdmin without editing the code. For example controlling what 
fields are
shown in the changelist view or even controlling what models are 
visible in the

admin interface.


So your proposal is to store them in the db right?

Yes, or in the session maybe. I am not really sure yet what is the best way


> It is not responsive.

That is a problem indeed, i'd suggest to just opt for a grid instead 
of going

for a full ui framework (or least a very minimal one). Am Maintaining a
bootstrap based theme and it always end up with tons of bootstrap 
specific

classes on every tag thus making difficult to reuse upstream templates.

Better to coordinate with the recent css cleanup by Elky too.
Thanks for the hint, I was planning to use flexbox which seems 
supported by

almost all browsers ( http://caniuse.com/#feat=flexbox )


Uhm, missing IE9 support. It is the default browser on vista, which 
has extended support until 2017 :|
Caniuse says that IE9 share is only 1.82%. In my opinion that could be 
considered negligible if the proposed solution is "future-proof" and a 
lot simpler than alternatives (I would have to investigate a bit here to 
confirm this)



--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55118C7C.8020204%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

For the wont fix ticket I'm considering that to introduce django extra view 
like features in django will help fix many problem related to FormSet and 
ModelFormSet and then use them in improving django admin and possibly 
django-admin2 like features in django.

On Monday, March 23, 2015 at 4:43:30 AM UTC+6, Tim Graham wrote:
>
> Please explain what you plan to implement in the other apps rather than 
> what's already been implemented in contrib.auth. You'll also need to 
> explain your reasoning for addressing a ticket that's been marked as "won't 
> fix."
>
> On Sunday, March 22, 2015 at 4:36:26 PM UTC-4, Asif Saifuddin wrote:
>>
>> I do belive to implement auth patch cleanly wont take more then a few 
>> days. But I have plans with django admin app and others which will need 
>> more tasks and also thinking about working with formset . The part I posted 
>> here is just a very little/start point of my proposal :)
>>
>> And I am working on a draft gist for full proposal. This part was posted 
>> to have an Idea if I'm going to right direction. I found admin-docs up to 
>> date with class based views and using that as a good reference to 
>> understand the implementation and also getting ideas about the problems 
>> people faced earlier and theie thoughts about the possible solutions :)
>>
>> I'm I in right direction? at least in some context? knowing that will 
>> help me a lot
>>
>> ./auvipy
>>
>>
>>
>> On Mon, Mar 23, 2015 at 1:14 AM, Tim Graham  wrote:
>>
>>> I see there's already a patch attached to the ticket that implements 
>>> your proposal. While it likely needs to be updated to apply cleanly, I 
>>> don't imagine that will take more than a few days?
>>>
>>>
>>> On Sunday, March 22, 2015 at 2:19:37 PM UTC-4, Asif Saifuddin wrote:

 Hi All,

 during my analyzing and making proposal for django best practices 
 updates (class based view etc)  I found this ticket related 
 https://code.djangoproject.com/ticket/16256 [though closed by a core 
 dev I think this should be addressed to resolve some issues in admin as 
 per 
  https://code.djangoproject.com/ticket/17209]


 Here goes some of my initial proposal plan I will be updating regularly 
 to complete the proposal in a gist and share that again. before that 
 please 
 give some feedback :)

 Background

 Over the years, as Django has evolved, the idea of what constitutes 
 "best practice" has also evolved. However, some parts of Django haven't 
 kept up with those best practices. For example, contrib apps do not use 
 class based views.

 In short, Django has been bad at eating it's own dogfood. The contents 
 of contrib should be audited and updated to make sure it meets current 
 best 
 practices.

 For updating best practices first think to consider is to convert the 
 functional views of django contrib apps to class based views where 
 possible 
 and necessary. To do so first app to consider is django contrib auth.

 contrib-auth views.py now have function based views and they are

 login logout logout_then_login redirect_to_login password_reset 
 password_reset_done password_reset_confirm password_reset_complete 
 password_change password_change_done

 and in urls.py url mapping for function based views as follows

 urlpatterns = [ url(r'^login/$', views.login, name='login'), 
 url(r'^logout/$', views.logout, name='logout'), url(r'^password_change/$', 
 views.password_change, name='password_change'), 
 url(r'^password_change/done/$', views.password_change_done, 
 name='password_change_done'), url(r'^password_reset/$', 
 views.password_reset, name='password_reset'), 
 url(r'^password_reset/done/$', views.password_reset_done, 
 name='password_reset_done'), url(r'^reset/(?P[0-9A-Za-z_-]+
 )/(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$', 
 views.password_reset_confirm, name='password_reset_confirm'), 
 url(r'^reset/done/$', views.password_reset_complete, 
 name='password_reset_complete'), ]

 and tests for this in tests/auth_tests/test_views.py

 the views have to be converted into CBV and also the urls. and this 
 should be done in a backward compatible manner.

 as an example password_change_done view is now implemented as below.

 @login_required def password_change_done(request, 
 template_name='registration/password_change_done.html', 
 current_app=None, extra_context=None): context = { 'title': _('Password 
 change successful'), } if extra_context is not None: 
 context.update(extra_context)

 if current_app is not None:
 request.current_app = current_app

 return TemplateResponse(request, template_name, context)

 this could be changed to cbv like below

 class PasswordChangeDoneView(TemplateView): 
 

Fwd: Misleading 404 exception during unit tests.

[Benjamin Scherrey]

Raising the issue here. Ultimately, I think the 404 is ok but it needs to
add details that will let the developer understand why a 404 is being
returned. Of course this conflicts with much of the stated purpose of
returning a 404 rather than the misconfigured exception but isn't the
policy to NOT use this in production? So if we reveal a few extra details
in a 404 exception that should be just fine, right?

thanx,

  -- Ben


-- Forwarded message --
From: Tim Graham 
Date: Mon, Mar 23, 2015 at 10:41 PM
Subject: Re: Misleading 404 exception during unit tests.
To: django-us...@googlegroups.com


To have the decision revisited, you should raise it on django-developers.

On Monday, March 23, 2015 at 10:39:57 AM UTC-4, Ben Scherrey wrote:
>
> Hey Tim,
>
>Appreciate the link. It looks like we're trying to have it go both ways
> here. If we don't want to allow it into production then make it explicit
> and break it - just as before. If we want to recommend that it not go into
> production but then let users actually do it, don't silently break it -
> just let it work and buyer beware. Requiring --insecure is fine but without
> it the explicit exception should be thrown I believe. In other words the
> original behaviour seems correct to me.
>
>I think silently absorbing exceptions is more dangerous than just
> outright breaking and exposing the root problem early. Many of the issues
> with the ORM have been due to a misapplication of this policy. I get the
> intent of the change but I'm not sure of the risk security-wise and have
> just experienced the impact of the misleading exception result personally.
>
>   -- Ben
>
> On Mon, Mar 23, 2015 at 9:19 PM, Tim Graham  wrote:
>
>> Please see https://github.com/django/django/commit/4c6ffcf7 for the
>> rationale for the change. I am open to ideas, but I'm concerned that
>> including details about the reason for the 404 might cause information
>> leakage in production which wouldn't be desirable.
>>
>> On Monday, March 23, 2015 at 10:06:25 AM UTC-4, Ben Scherrey wrote:
>>>
>>> I see now that the behaviour of serve() was changed for 1.7 and it now
>>> returns a silent misleading 404 result rather than the old
>>> ImproperlyConfigured exception which would have provided a clue as to the
>>> actual root cause.
>>>
>>> See: https://docs.djangoproject.com/en/1.7/ref/contrib/staticfile
>>> s/#django.contrib.staticfiles.views.serve
>>>
>>> I don't understand the purpose of this change but it certainly sent me
>>> on a wild goose chase trying to understand the 404 response. Would be VERY
>>> useful if this 404 at least provided some information as to what it's
>>> really all about - preferably with the above link embedded in it.
>>>
>>> Thanx to Rene Fleschenberg on irc for the doc link.
>>>
>>>
>>> On Mon, Mar 23, 2015 at 8:42 PM, Benjamin Scherrey 
>>> wrote:
>>>
 Can someone explain the test condition on line 31 of
 https://github.com/django/django/blob/master/django/contrib/
 staticfiles/views.py - Just spent a few hours trying to get my unit
 tests to pass and couldn't figure out what was going on until I found this
 weirdness.

 I understand serve() isn't meant for production but, prior to having
 production ready it's nice to be able to unit test my code as it's being
 developed with serve() as a temporary measure. Right now I'm using serve()
 as a temporary hack to stand in for an external URI router that isn't
 present yet. Throwing a 404 without any helpful indication of the true
 cause of the exception simply confuses people and makes them wonder why the
 URI they're passing in is not being found when they can try it on the
 command line and see it work just fine. At minimum this exception should be
 more explicit.


 --
 Chief Systems Architect Proteus Technologies 
 Chief Fan Biggest Fan Productions 
 Personal blog where I am not your demographic
 .

 This email intended solely for those who have received it. If you have
 received this email by accident - well lucky you!!

>>>
>>>
>>>
>>> --
>>> Chief Systems Architect Proteus Technologies 
>>> Chief Fan Biggest Fan Productions 
>>> Personal blog where I am not your demographic
>>> .
>>>
>>> This email intended solely for those who have received it. If you have
>>> received this email by accident - well lucky you!!
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users...@googlegroups.com.
>> To post to this group, send email to django...@googlegroups.com.
>> Visit this group at 

Re: GSOC: Turn contrib.admin into a customizable management interface

[Riccardo Magliocchetti]

Il 24/03/2015 12:37, Germano Gabbianelli ha scritto:


On 24/03/15 11:56, Riccardo Magliocchetti wrote:
With these sentences I was thinking about customizing the properties of the
ModelAdmin without editing the code. For example controlling what fields are
shown in the changelist view or even controlling what models are visible in the
admin interface.


So your proposal is to store them in the db right?


> It is not responsive.

That is a problem indeed, i'd suggest to just opt for a grid instead of going
for a full ui framework (or least a very minimal one). Am Maintaining a
bootstrap based theme and it always end up with tons of bootstrap specific
classes on every tag thus making difficult to reuse upstream templates.

Better to coordinate with the recent css cleanup by Elky too.

Thanks for the hint, I was planning to use flexbox which seems supported by
almost all browsers ( http://caniuse.com/#feat=flexbox )


Uhm, missing IE9 support. It is the default browser on vista, which has extended 
support until 2017 :|



A final thought is about AdminWidget, whatever you end up with please think of
something different pattern than the Form's Media class as makes it impossible
to override css / js without touching python code.


This is one big problem to be honest and I don't think I would have the time to
solve it. There could also be some other student working on it, so I am not sure
about what is the best thing to do. My plan was to ignore the problem and
provide by default widgets that use only simple js or do not use js at all, and
let the user that wants to customize the admin choose how to handle the problem,
for example by using something like django-sekizai.


Well usually adding js / css in templates is enough to make theme people life 
easier :)



I have still not mentioned that I also plan to rewrite contrib.admin using class
based views.


You should well be aware of these projects, a reference of them in your
proposal would ne nice since you can possibly reuse a lot of code:
https://github.com/pydanny/django-admin2
https://github.com/AndrewIngram/django-extra-views


I am well aware of django-admin2 I also did a small patch for them, but they use
a lot of dependencies (i.e. restframework) and this makes it almost impossible
to be used as a base for contrib.admin I think.
... Unless someone decides that contrib.admin should not be included in django
anymore and have its own package (Thing that I would not necessarily disagree
with, as it would allow it to have external deps).


I didn't mean you need to follow admin2 design, i meant it's always nice to 
point out related prior work


thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55115343.4030204%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help needed with Oracle GIS backend

[Tim Graham]

I also advertised this on the geodjango mailing list with the following 
message 
:

Do we have any users of the Oracle GIS backend that have interest and 
ability to help maintain it? Claude has worked on several issues for 1.9 
that need to be completed on Oracle. If we cannot find help, then I think 
we'll be forced to declare the Oracle GIS backend unmaintained and drop 
support for it.

issues:
* https://code.djangoproject.com/ticket/12400#comment:12
* https://github.com/django/django/pull/4027

On Monday, March 16, 2015 at 3:20:40 PM UTC-4, Claude Paroz wrote:
>
> Hi,
>
> In ticket #24214, I built a patch to replace all geo-specific Manager 
> methods by class-based ORM functions. This will allow us to get rid of 
> convoluted query code in the GeoDjango ORM. It will also be far much easier 
> to add support for specific database functions. The code is already in good 
> shape, however we are missing the Oracle part of the patch. I won't work on 
> that part myself, that's why I'm here to ask for help with it from anyone 
> which is a bit familiar with the Oracle GIS backend. Help much appreciated!
>
> https://code.djangoproject.com/ticket/24214
>
> Claude
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9a43a6d2-eec9-4518-afc3-0d3d0b4e5bef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC: Turn contrib.admin into a customizable management interface

[Germano Gabbianelli]

On 24/03/15 11:56, Riccardo Magliocchetti wrote:
Please don't throw out the baby with the bath water :) It's quite cool 
to just register a model in the admin to have a crud interface.
Exactly, this is super cool. I meant hard to extend to add other 
"widgets" to the home that are not models. Or even to add different 
views to a ModelAdmin.




>Editing the code is required for every, even aesthetical, 
customization. I
> think it would be better to allow managers (i.e. non-coders) to 
customize the
> appearence of the admin pages as much as possible without touching 
the code.
> This could be accomplished by storing part of the ModelAdmin options 
in the

> database.

I don't agree with "even aeasthetical" bits, there are themes 
available that does not touch any django code. Still there's quite a 
lot of annoyances, often reported in the ticketing system.


With these sentences I was thinking about customizing the properties of 
the ModelAdmin without editing the code. For example controlling what 
fields are shown in the changelist view or even controlling what models 
are visible in the admin interface.



> It is not responsive.

That is a problem indeed, i'd suggest to just opt for a grid instead 
of going for a full ui framework (or least a very minimal one). Am 
Maintaining a bootstrap based theme and it always end up with tons of 
bootstrap specific classes on every tag thus making difficult to reuse 
upstream templates.


Better to coordinate with the recent css cleanup by Elky too.
Thanks for the hint, I was planning to use flexbox which seems supported 
by almost all browsers ( http://caniuse.com/#feat=flexbox )


A final thought is about AdminWidget, whatever you end up with please 
think of something different pattern than the Form's Media class as 
makes it impossible to override css / js without touching python code.


This is one big problem to be honest and I don't think I would have the 
time to solve it. There could also be some other student working on it, 
so I am not sure about what is the best thing to do. My plan was to 
ignore the problem and provide by default widgets that use only simple 
js or do not use js at all, and let the user that wants to customize the 
admin choose how to handle the problem, for example by using something 
like django-sekizai.


I have still not mentioned that I also plan to rewrite contrib.admin 
using class

based views.


You should well be aware of these projects, a reference of them in 
your proposal would ne nice since you can possibly reuse a lot of code:

https://github.com/pydanny/django-admin2
https://github.com/AndrewIngram/django-extra-views


I am well aware of django-admin2 I also did a small patch for them, but 
they use a lot of dependencies (i.e. restframework) and this makes it 
almost impossible to be used as a base for contrib.admin I think.
... Unless someone decides that contrib.admin should not be included in 
django anymore and have its own package (Thing that I would not 
necessarily disagree with, as it would allow it to have external deps).


BTW there was a recent discussion about the admin where people 
suggested they are just creating a thin rest api over models and 
reimplementing the ui from scratch. A use case you may want keep into 
account.
Umh, this seems to mean "throw away the admin" and start over, I would 
like instead to provide also some backward-compatibility if possible. I 
am going to search on the ML for this discussion anyway, thanks!


--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55114C66.40007%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL matching problem

[Ma Yuping]

Actually:
In my project url, I have:

urlpatterns = patterns('',

 url(r'^blog/', include('blog.urls', namespace="blog")), 

)
In the App, I have:

urlpatterns = patterns('',

#url(r'/$', views.index, name='index'),

url(r'(?P\d+)/$', views.index, name='index'),

url(r'(?P\d+)/article/(?P\d+)/$', views.article, 
name='article'),

url(r'(?P\d+)/resume/$', views.resume, name='resume'),

url(r'write/$', views.write.as_view(), name='write'),

)



在 2015年3月24日星期二 UTC+8上午10:45:33，Curtis Maloney写道：
>
> Firstly, this is really a question for django-users ... this mailing list 
> is for discussion of the development _of_ Django, not _with_ Django.
>
> On 24 March 2015 at 13:16, Ma Yuping  
> wrote:
>
>> django V1.6.8
>>
>> Let URL be:
>>
>> url(r'^blog/(?P\d+)/$', views.index, name='index'),
>>
>> url(r'^blog/(?P\d+)/article/(?P\d+)/view/$', 
>> views.article, name='article'),
>>
>
> Are you certain these are the exact patterns you have, and the only 
> patterns starting with blog/ ? 
>
> Either you've not restarted your app server after making changes, or you 
> have another url pattern that's catching all of these.
>
> --
> Curtis
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3418be1d-e7f6-44de-99fa-ac90ec92b36d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSoC 2015

[Billy Ruffin Zafack]

Let me first briefly introduce myself to the group as a student developer 
and an aspiring GSoC-2015 Participant

Name: Zafack Billy
   Currently Computer Engineering Student(4th year) at National 
Advanced School of Engineering
   Yaounde, Cameroon

   Have gone through the ideas page and will be coming up with some 
reactions.

   I believe I have a lot to learn from this group and a lot to contribute.
   Thanks for having me.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b0c1e870-3403-4ad9-a778-57fed1e53d8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL matching problem

[Ma Yuping]

It solved.
It should be exact: I should put '^' before the APP's URL. 

url(r'^(?P\d+)/$', views.index, name='index'),

url(r'^(?P\d+)/article/(?P\d+)/$', views.article, 
name='article'),

Thanks




在 2015年3月24日星期二 UTC+8上午10:45:33，Curtis Maloney写道：
>
> Firstly, this is really a question for django-users ... this mailing list 
> is for discussion of the development _of_ Django, not _with_ Django.
>
> On 24 March 2015 at 13:16, Ma Yuping  
> wrote:
>
>> django V1.6.8
>>
>> Let URL be:
>>
>> url(r'^blog/(?P\d+)/$', views.index, name='index'),
>>
>> url(r'^blog/(?P\d+)/article/(?P\d+)/view/$', 
>> views.article, name='article'),
>>
>
> Are you certain these are the exact patterns you have, and the only 
> patterns starting with blog/ ? 
>
> Either you've not restarted your app server after making changes, or you 
> have another url pattern that's catching all of these.
>
> --
> Curtis
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fd2e0ada-23f5-470b-a98b-5f335fdbe700%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC: Turn contrib.admin into a customizable management interface

[Riccardo Magliocchetti]

Hi Germano,

Il 24/03/2015 11:11, tyrion-mx ha scritto:

Discussing on #django-dev with FunkyBob and others I concluded that refactoring
contrib.admin to become a generic management interface (and not a model-centric
one as it is now) could be a good thing, so I started a project proposal.
It still a draft and I hope to complete it in time, anyway I would like to know
as much as possible what others think about it :)


Cool project!


Here is the link: https://gist.github.com/tyrion/537ab187f458ba1ae9e9


Unfortunately one cannot comment on specific lines of gists, c some text 
below.

>It is model centric and really hard to extend. For example there is no
> simple way to customize the admin homepage (which I will call dashboard from
> now on) by defining new widgets.

Please don't throw out the baby with the bath water :) It's quite cool to just 
register a model in the admin to have a crud interface.


>Editing the code is required for every, even aesthetical, customization. I
> think it would be better to allow managers (i.e. non-coders) to customize the
> appearence of the admin pages as much as possible without touching the code.
> This could be accomplished by storing part of the ModelAdmin options in the
> database.

I don't agree with "even aeasthetical" bits, there are themes available that 
does not touch any django code. Still there's quite a lot of annoyances, often 
reported in the ticketing system.


>It is not responsive.

That is a problem indeed, i'd suggest to just opt for a grid instead of going 
for a full ui framework (or least a very minimal one). Am Maintaining a 
bootstrap based theme and it always end up with tons of bootstrap specific 
classes on every tag thus making difficult to reuse upstream templates.


Better to coordinate with the recent css cleanup by Elky too.

A final thought is about AdminWidget, whatever you end up with please think of 
something different pattern than the Form's Media class as makes it impossible 
to override css / js without touching python code.



I have still not mentioned that I also plan to rewrite contrib.admin using class
based views.


You should well be aware of these projects, a reference of them in your proposal 
would ne nice since you can possibly reuse a lot of code:

https://github.com/pydanny/django-admin2
https://github.com/AndrewIngram/django-extra-views

BTW there was a recent discussion about the admin where people suggested they 
are just creating a thin rest api over models and reimplementing the ui from 
scratch. A use case you may want keep into account.


thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/551142C7.1060406%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

GSOC: Turn contrib.admin into a customizable management interface

[tyrion-mx]

Discussing on #django-dev with FunkyBob and others I concluded that 
refactoring contrib.admin to become a generic management interface (and not 
a model-centric one as it is now) could be a good thing, so I started a 
project proposal.
It still a draft and I hope to complete it in time, anyway I would like to 
know as much as possible what others think about it :)

Here is the link: https://gist.github.com/tyrion/537ab187f458ba1ae9e9

I have still not mentioned that I also plan to rewrite contrib.admin using 
class based views.

Thanks

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d1f2e18f-aa56-4f9b-9b79-681de6972ca1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2015

[Russell Keith-Magee]

Hi Mesut,

It wasn't clear that you were asking a question.

Django's GSoC wiki page contains details of what you need to do in order to
be a GSoC student for the Django project; the next step from your
perspective is for you to do some research on the projects that interest
you and write a proposal detailing what you hope to achieve in the 12 week
GSoC program. If you want feedback on your proposal, or if you'd like
clarification about a specific detail of the project, we're here to help -
but you need to ask a specific question if you're hoping to get an answer.

Yours,
Russ Magee %-)


On Tue, Mar 24, 2015 at 2:26 PM, Mesut Gülecen 
wrote:

> Helooo any body is here?
>
> 22 Mart 2015 Pazar 16:14:03 UTC+2 tarihinde Mesut Gülecen yazdı:
>>
>> Hi, my name is Mesut Gülecen,   currently in second year of engineering
>> at Canakkale Onsekiz Mart University in Turkey.
>> I want to contribute to the development of Django. I have working upon
>> Django already and  I want to learning something with you.
>>
>> I know some Flask,mongoDB
>>
>>  Blog: www.mesutgulecen.com
>>  Github: MesutGulecen
>>  e-mail: mesutgule...@hotmail.com
>>
>>  What can I can do for started this project?
>>
>>
>>
>> Thanks
>>
>  --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3317172d-ed2b-4366-9c64-f8594e113b5d%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-Hp_EAv_uPBHX1-ERU9nBikU2%3DF0m%3DRuKX%3Du4qv-6fGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2015

[Mesut Gülecen]

Helooo any body is here?

22 Mart 2015 Pazar 16:14:03 UTC+2 tarihinde Mesut Gülecen yazdı:
>
> Hi, my name is Mesut Gülecen,   currently in second year of engineering 
> at Canakkale Onsekiz Mart University in Turkey.
> I want to contribute to the development of Django. I have working upon 
> Django already and  I want to learning something with you. 
>
> I know some Flask,mongoDB
>
>  Blog: www.mesutgulecen.com
>  Github: MesutGulecen
>  e-mail: mesutgule...@hotmail.com
>
>  What can I can do for started this project?  
>
>
>
> Thanks   
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3317172d-ed2b-4366-9c64-f8594e113b5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.