Re: unittest.TestCase vs. django.test.TestCase in overview example
I created a Django Trac ticket for this: https://code.djangoproject.com/ticket/20165 On Saturday, March 30, 2013 11:30:44 PM UTC-4, Brian Schott wrote: > > There is really a bigger question in my mind about the appropriateness of > using django.utils.unittest in the testing overview section. It is an > optimization that the warning admits is fairly limited for real testing and > is premature for the first example. It would be better to break out the > optimization as a Note "if your tests don't rely on database access, you > can ... optimize with django.utils import...". The testing overview > section should import the class that works correctly when testing > Animal.objects.create() or self.lion.save(). > > It's also not a case of catering. Enclosed is a link to a screen shot > that starts with "Writing tests" and ends with "For more details about > unittest, see the Python documentation". > https://www.dropbox.com/s/9eh2zgkxphc5rvo/django_test_doc_screen.png > Nowhere on that first screen of documentation on a 20 inch monitor does it > refer to django.test.TestCase and "For more details..." reads like the end > of the section. It's really easy to not see the warning and the first two > examples of what someone glancing at the docs to manually create a tests.py > file will read is "from django.utils import unittest". which causes a > very non-obvious unit test failures in the most typical test cases. > > Thanks for reconsidering the patch! Lorin's version is much clearer. > Brian > > On Mar 25, 2013, at 2:08 PM, Tim Graham > > wrote: > > It seems like it could be a dangerous precedent to cater to people who > don't take the time to fully read the docs, but in this case I'm a bit > sympathetic. On the other hand, this example will probably be a bit more > obvious when we drop support for Python 2.6 and no longer have > django.utils.unittest. At the least, we could probably move the warning > above the example so it's a bit more visible. > > On Saturday, March 16, 2013 8:27:01 PM UTC-4, Lorin Hochstein wrote: >> >> Hi there: >> >> On the Django testing overview doc page < >> https://docs.djangoproject.com/en/dev/topics/testing/overview/>, the >> initial example uses unittest.TestCase. A Django developer who was looking >> for a quick reminder on how to write unit tests is likely to hit this page >> first. If that developer doesn't read the "warning" section below, they >> could mistakenly use unittest.TestCase when their unit tests change the >> database. This very scenario happened to a colleague of mine. >> >> I proposed changing this to django.test.TestCase < >> https://github.com/django/django/pull/903>, but that pull request with >> closed out by Aymeric Augustin, with reference to < >> https://code.djangoproject.com/ticket/15896>. I don't think ticket >> #15986 covers quite the same issue, despite its title. Django devs, can you >> reconsider this doc patch? >> >> Take care, >> >> Lorin >> >> > -- > 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-develop...@googlegroups.com . > To post to this group, send email to django-d...@googlegroups.com > . > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: javascript view for named urls
As Andrew says, some "rely" on the obscurity of this server side
information. The same can be said of translations. I'd like to see better
support for javascript preprocessing.
gettext(...) in javascript could be preprocessed if the language is known.
url_resolve('name', { ...}) could probably also be precomputed, if you're
smart.
When projects evolve, translation files and url patterns can become large,
and you don't always want to simply expose all of them.
I'm not sure whether there's already a recommended way for adding compile
hooks to collectstatic. In debug mode, a fallback to some catalog could be
a solution.
Le samedi 30 mars 2013 17:24:36 UTC+1, Bernhard Ja a écrit :
>
> Am Freitag, 29. März 2013 21:05:05 UTC+1 schrieb Andrew Ingram:
>
>>
>> I like the concept of this, because it's something I've often wanted
>> myself. But I want to bring up a couple of points:
>>
>> 1) Some websites rely on the obscurity of some of their URLs as an
>> additional security measure (i.e. have the admin at something other than
>> /admin/). This is admittedly not a great measure, since a persistent
>> attackers will probably get around it. But the key would be a way to manage
>> which patterns get included in the javascript catalog, possibly even having
>> it configurable at the the view level so that some templates can request a
>> different subset of the patterns to others.
>>
>
> I agree. A way to manage the existenz in the js catalog is necessary.
>
>
>> 2) It'd be nice if it could be integrated with internationalisation, so
>> that if you're using Django's i18n_patterns, the view automatically fills
>> in the country segment based on the request's locale. Much like the
>> translation string view only returns the strings for the request's
>> language.
>>
>
> I did some tests and the language code prefix appears in the generated
> urls. Am i missing sth.?
>
> Whats the best was to propose this feature for the django core?
>
> Bye, Boerni
>
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Kickstarter for Django Admin?
On Sat, Mar 30, 2013 at 7:20 PM, Victor Hooi wrote: > > From the existing projects, we can draw two clear requirements that people > want: > >- Changing the look and feel - I'm not sure what Django core's >feelings on it, but there seems to be a feeling from the community that the >look of the current Django Admin is somewhat dated? Also, any new admin >should probably be responsive, and work on mobile or non-desktop devices, >if that's possible. > > Personally I dont see the default design a problem because it can be customized with external CSS, although the design shipped with django can be changed, I support the idea of having the admin templates clean, non-coupled to the design and javascript independent. I think the HTML in the templates should be coded independently from the design, there are some structural mistakes more important than the design, I have sent a ticket related to this here: Ticket #18511 ( https://github.com/django/django/pull/180) >- More customisations - a lot of people want to create dashboards >around the admin, add new sections/tabs, or move things around - the >current Admin doesn't have much scope for that, or it's not easily >accessible. > > I would like to see a RESTful api to the admin methods and bigger separation between the views and the templates, in a way that the admin could be operated from anywhere (android for example). Currently the admin app is website interface to CRUD operations, I think the admin app could be improved and turned into a CRUD engine independent of the presentation that exposes a interface that could be implemented or extended from any presentation form (android, html, rest calls). Regards -- Serge G. Spaolonzi Cobalys Systems http://www.cobalys.com -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
unittest2 discovery proposal
Hi all, There are some important design decisions to be made if we include unittest2 discovery into Django. This message documents a proposed API, the pros and cons, and decisions that need to be made. https://code.djangoproject.com/ticket/17365 -- Limitation of current test setup: -- * Tests can only be in tests.py. * Tests must be included inside the app. * Full dotted paths to test cases don't work. -- How unittest2 discovery works: -- Unittest discovery has two advantages: 1) Better discovery for the existing case of testing an app Besides the old model and doc tests, current test discovery is limited to tests in tests.py. Unittest2 discovery allows files to be matched by pattern. For instance, these are all valid test modules: tests.py test_views.py test_models.py Further, a custom pattern can be set if the test files don't match the naming convention "test*.py". 2) Custom root folders can be specified for test discovery If the tests aren't in the app directory--a common case for reusable apps-- a custom root folder can be specified for discovery. ./manage.py test --root=../tests 3) Can use Python dotted paths to modules. These would all work: ./manage.py test myapp ./manage.py test myapp.tests ./manage.py test myapp.test_views ./manage.py test myapp.tests.MyTest ./manage.py test myapp.tests.MyTest.test_method ** The current "myapp." notation is not part of unittest2, and would go away. -- The Proposed API -- The unittest2 discovery is roughly-compatible with the existing custom Django discovery. Here's what the API could look like: # Discover tests under current directory ./manage.py test # Test with discovery under different root ./manage.py test root="../tests # Test with a custom top level directory ./manage.py test --root="../tests --top_level=../../top # Test with different pattern matching ./manage.py test --pattern="tests_*" # Test single installed app with discovery ./manage.py test contact # Test multiple apps with discovery ./manage.py test myapp1 myapp2 myapp3 # Test specific test module ./manage.py test myapp1.tests ./manage.py test myapp1.tests_views ./manage.py test myapp1.test_models # Test with mixed arguments ./manage.py test myapp.test_views myapp.test_models # Test single testcase ./manage.py test contact.tests.ContactTest # Test single method ./manage.py test contact.tests.ContactTest.test_contact # Test all installed apps with discovery ./manage.py test --installed -- Notes on above API: -- * Running `./manage.py test myapp` does discovery within the app and runs the tests. That means test in existing `tests.py` will be found, as well as in any file name "test*.py" * Root, pattern, and top-level options are passed from the `test` command to the unittest discovery. * Running a single test case uses a full dotted path, rather than the short path that Django currently uses (myapp.tests.MyTest vs myapp.MyTest) * The old behavior of running all installed app tests can be triggered by using the `--installed` flag. -- Opting into the new discovery -- To allow a deprecation cycle, the new discovery is an opt-in. To use the discover runner, a user must update their settings.py: TEST_RUNNER = 'django.test.runner.DiscoverRunner' Until Django 1.8, the 'django.test.simple.DjangoTestSuiteRunner' is still available, including it's ability to run doctest, model tests, etc. -- Backwards-incompatible changes -- * The new runner doesn't run doctests or tests in models.py * Some valid test structures in Django don't work with unittest2. For instance, tests in `tests/__init__.py` don't match a patter than unittest would recognize if running discovery on a module. Design Decisions 1) Any changes to the API? I think the above API covers all the common use-cases. Is anything missing? 2) Should this be opt-in or not? The current patches are set up as opt-in. Until Django 1.8, a user has to manually update their test runner setting to use the DiscoverRunner. This lets current setups continue working, doctests and model tests included. Is there a reason not to follow the normal deprecation cycle? 3) What do to about doctests? There is discussion to roll doctest removal into this patch. https://code.djangoproject.com/ticket/18727 On one hand that's okay, but removing doctests has no bearing on using unitest2 discovery. It's simply a backwards-compatibly break to the old `django.test.simple.DjangoTestSuiteRunner`. Do we really want to do a hard cut-off for that? Should it really be part of the new discovery branch? If we remove doctests, why not remove support for discovery in models.py at the same time? 4) Option names for the `test` command. What should the discovery option names be? Above, I proposed this: ./manage.py test --root=../tests --top-level=../../top -- pattern="te
Re: Testing project code that resides outside of installed apps
That's excellent news! Thanks, Carl. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Kickstarter for Django Admin?
On Sun, Mar 31, 2013 at 6:20 AM, Victor Hooi wrote: > heya, > > Aha, yes - we need a roadmap, and somebody from the team to execute it > *grins*. > No - We need someone from the core team to *commit* it. We don't need someone from the core team to *build* it. It's also worth pointing out that this is a classic example of a project that can develop external to Django's core. In theory, Django's admin could be a completely separate project. If a replacement is to be developed, it makes sense for that replacement to be developed external to the core repository, and only be included in core when it reaches a certain level of maturity. > For the former - I believe there was already discussions on that sort of > thing on this board? > > There's a wiki page with some notes as well: > > https://code.djangoproject.com/wiki/AdminNext > There's a world of difference between "some notes" and "a clear plan and direction" :-) > I also had a look at some of the existing projects: > >- https://github.com/yawd/yawd-admin >- https://github.com/michaelhelmick/django-bootstrap-admin (Doesn't >appear to be too active) >- https://github.com/riccardo-forina/django-admin-bootstrapped >- https://github.com/aobo711/bootstrap-django-admin >- > https://github.com/gkuhn1/django-admin-templates-twitter-bootstrap(Doesn't > appear to be too active) >- https://github.com/divio/djangocms-admin-style > > And there's obviously Grapelli. > > A lot of these are obviously just reskins, while others offer a bit more. > > From the existing projects, we can draw two clear requirements that people > want: > >- Changing the look and feel - I'm not sure what Django core's >feelings on it, but there seems to be a feeling from the community that the >look of the current Django Admin is somewhat dated? Also, any new admin >should probably be responsive, and work on mobile or non-desktop devices, >if that's possible. > > I don't think you'll get any argument from the core team that Django admin could use a visual refresh, and that mobile accessibility should be part of that redesign. > >- More customisations - a lot of people want to create dashboards >around the admin, add new sections/tabs, or move things around - the >current Admin doesn't have much scope for that, or it's not easily >accessible. > > For the latter, not sure I can help you there...lol. I thought Idan Gazit > was working on something before though? Or are there other designers on the > Core team? > There are two BDesignersFL - Idan and Bryan Veloso. However, both are extremely busy men. Idan did some initial work at DjangoCon 2 years ago, but I don't think there's been a whole lot of progress since then. Yours, Russ Magee %-) -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
