Re: start using less (and bootstrap!)
I'm sure Idan can add to this if he cares to, but at Djangocon kicking the
admin out of django.contrib for admin2 was something that was actively
considered, both during development and, depending on how it worked out,
possibly as its new home.
I'm massively +1 on that because it does allow a lot of "freedom" to people
wanting to experiment with it and new ways of handling administrative tasks.
-T
On Thu, Feb 2, 2012 at 4:17 PM, Alex Gaynor wrote:
>
>
> On Thu, Feb 2, 2012 at 5:01 PM, Adrian Holovaty wrote:
>
>> On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant wrote:
>> > Is this up somewhere public? I've been fighting the urge to do this as
>> > well. Using django-compressor with less on Heroku is a non-starter
>> > since you can't install node. Having this as a Python module would be
>> > handy.
>>
>> Not yet, alas, but hopefully soon.
>>
>> Adrian
>>
>> --
>> 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.
>>
>>
> Perhaps this is too far in the future looking. But at a certain point the
> admin must become a separate project. One of the major goals of
> newforms-admin ('lo those years ago) was to demote the admin from special
> status, with hooks inside core left and right, to "just an app". Let's
> carry that to the logical conclusion: just an app *outside of Django*.
>
> That gives the maintainers the freedom to reinvent it, and use tools like
> less or bootstrap without it needing to be an issue of policy for all of
> Django. Because when I first read saw this thread my thought was, "Hmm,
> what unholy mess of requirements am I going to need if I want to just run
> the test suite. Will I still be able to write new features in forms
> without needing to learn what the hell less or compass is?". Several years
> ago, I opposed using jQuery in the admin, on the principle that Django
> should be completely free of entangling alliances. I made that argument
> more or less out of habit, just because I felt it was an argument that
> ought to be made, but really I was pretty happy to get to use jQuery. Now
> I'm saying, it's pretty clear that admin 2.0 (or 3.0, or 4.0, anyone
> counting?) is going to be a beast that far outstrips almost anything else
> in Djanog (besides the ORM ;)) in complexity, with more dependencies,
> more associated tooling, and more usecases (i.e. it's not just a tool for
> developers to use, it's also something for end users of *our* users' apps
> to use). Keeping that in Django itself is going to stunt it's growth, and
> it's going to suck for new developers to Django who, like many of us (or at
> least myself), were and still are, Python developers at heart, who can
> write some HTML, badly.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
> --
> 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.
>
--
Travis Swicegood | @tswicegood (most everywhere) | Senior Open Source
Engineer @ Texas Tribune / Armstrong | 512.693.7051
--
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: GSOC2012 Proposal for 'Finishing off the App Refactor'
On Wednesday, March 28, 2012 at 9:16 AM, Nauho Zen wrote:
> > I believe that the baton was somewhat passed to tswicegood at pycon, see:
> >
> > https://github.com/tswicegood/django/commit/241c455d9b8d03144a24f869f819efda031813ba
> >
>
> I will take a good look at it.
The best place to start is the pull request:
https://github.com/django/django/pull/129
That has the current state of the app-loading branch against Django's master
branch.
Before I go into any further specifics, one thing I want to do (whether this
makes it into GSoC or not) is make sure that we keep the scope reigned in on
this merge. From my point-of-view (and hopefully Jannis will correct me if I'm
off) these are the things this branch should do:
* Introduce the concept of an App object to represent each
* Keep the concept of an `app_label` as just the last part of an app's module
name (example: django.contrib.auth has an app_label of auth).
* Be entirely backwards compatible
The majority of the above work is already done. Right now the two biggest
hurdles to getting the code merged in are:
* Getting the main test suite running again. The tests break spectacularly
with the new code. Some of the failures are tests using internal APIs that
changed, other are valid public APIs that haven't been ported yet. Ideally
this merge should be able to take place without a single test having to be
changed.
* Buy-in from all of the core-devs that this is a needed and/or good change.
All of this said, I'd love for this to be a GSoC project, but I agree Preston
that yet-another-GSoC slot spent on this might not be the best use of the
project's GSoC slots.
> > This is, as far as I can tell from my review, and unresolved limitation in
> > the current branch - that django.contrib.auth and mypackage.auth collide.
> > Seems a duplicate of your #3 below.
> OK, there is still not a workaround way?
There is not a way to work around this. The app-loading branch provides a path
forward, but does not take it. I don't think this pull request should fix this
problem.
Dealing with application conflicts requires a broader design decision on what
constitutes an application's "name": it's app_label
("django.contrib.auth".split(".")[-1]), or it's full name
("django.contrib.auth"). The biggest issue is backwards compatibility -- we
have to keep app_label around for awhile, so we need to deal with both. We
can't immediately switch all table names around to refer to something other
than the app_label.
> > > 2) can deploy several instaces of the same application
> >
> > If you see the discussion here:
> >
> > http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/5045645100f5b8ea?lnk=gst&q=app+loading#5045645100f5b8ea
> >
> >
> > It was determined that this feature was too problematic to tackle as part
> > of app_loading
> A good start point to check if previous work has solved this problem or not ?
This is a problem and I recommend punting on it (see above).
-T
--
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: GSOC2012 Proposal for 'Finishing off the App Refactor'
On Thursday, March 29, 2012 at 10:50 AM, Nauho Zen wrote: > > > > All of this said, I'd love for this to be a GSoC project, but I agree > > > Preston that yet-another-GSoC slot spent on this might not be the best use > > > of the project's GSoC slots. > > > > > How about combing the "Test framework cleanup" idea on the SummerOfCode2012 > wiki page with > "Finishing off the App Refactor" to one proposal, which can make better use > of our GSOC slots? > > If you agree, I will refactor my proposal. I think we should probably stick with one problem domain per-application just to keep things simple. -T -- 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 Javascript Roadmap/Brainstorming
On Nov 30, 2012, at 7:42 AM, Florian Apolloner wrote: > Hi Tyler, > > On Wednesday, November 28, 2012 6:24:57 PM UTC+1, Tyler Ball wrote: > - jQuery: Inlines are written as a jQuery plugin, DateTime and i18n are > written without jQuery. The version of jQuery included is 1.4.2, which is ~3 > years old. Do we want to have jQuery in this project? I think Django should > include it, as it helps solve a lot of browser inconsistencies and is > familiar to all JS devs. But if so, we should try to keep it up to date. > > Django namespaces it's jquery under django.jquery, there should be no issue > including an up2date version for your projects. Django probably will never > keep up with jquery's release cycle. I can vouch for this. It would be nice to keep it more up-to-date, but it is namespaced in a way that keeps it from bother other parts of the code that require a more modern version of jQuery. I'm currently using 1.7.x in my admin alongside Django's jQuery 1.4 version. > - Not extensible: Behaviour for the jQuery plugins are defined in template > blocks which are somewhat easy to customize, while DateTimeShortcuts uses > href="javascript:void" links generated dynamically, which are nearly > impossible to override. I'd like to rewrite the Admin JS to use a Backbone > like structure, where all the necessary JS is initialized as an instance from > one place by calling `new` and a .extend() function can be used where the > developer wants to customize behaviour. This change would be pretty radical > but I feel it would be for the better. Agreed that this code is not a good as it could be. Having created a custom admin on top of admin_tools[1], I've come across a lot of pain points and have slowly (more slowly than I'd like) been refactoring bits of the admin JS into something that's more extensible.[2] As for your actual idea, I'd have to see it to fully understand what you're proposing here. Could you mock up some pseudo code that shows what you're trying to accomplish? It doesn't need to be complex, just something that shows the order of execution using comments and what would be called. -T [1]: https://github.com/tswicegood/pops [2]: https://github.com/django/django/commit/4754f122dd9b41fc9b2dee3fa74e19fc384237ab -- 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 Admin Revamp - Any updates?
Is there a wiki page on the admin and changes that are planned for it? This
comes up every few months with a "hey, I've done X with the admin, can we just
use it to replace/update contrib.admin?" Would be nice to have everyone's (and
by everyone's, I mean Idan's) thoughts on where the admin is heading so this
conversation doesn't have to keep popping up (or at least it can be answered by
"go contribute to {{ insert url }}."
/me goes back to yelling at kids on his lawn...
-T
--
Travis Swicegood | @tswicegood (most everywhere)
On Dec 14, 2012, at 8:00 AM, is_null wrote:
> I'm not sure if it's worth mentioning ...
>
> 2. Secure CRUD one-liner goal
>
> The new admin app should, like the current admin app, allow the user to
> enable full secure (permission-based) CRUD in one line of code.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/fxyL124kbP8J.
> 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: Guidance regarding Django Deployment Process
Howdy; Friendly reminder that this mailing list is for the discussion of the development of Django. Please take your questions about specific implementation issues over to django-users. Thanks! -T -- Travis Swicegood | @tswicegood (most everywhere) On Feb 11, 2013, at 7:11 AM, Ashwin Kumar wrote: > can you show a screen cast or a detailed setup procedure steps, > > i tried gunicorn documentation but failed. > > With Best > -Ashwin. > +91-9959166266 > > > On Mon, Feb 11, 2013 at 11:57 AM, Ray Ch wrote: > My suggestion is using gunicorn + nginx > They are very light weight. > > nginx - static content ( images, js and css ). If you are using AWS for > static content you can go with apache. > > Gunicorn - for django is amazing. > > -- > 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. > > > > > -- > 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. > > -- 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: ANN: Django website redesign launched
It looks great. Awesome work, everyone involved! Jannis/Russ -- y'all mentioned a style guide in the blog post, but I don't see one in the docs. Is that available somewhere? -T --- Travis Swicegood 512-693-7051 | @tswicegood (most everywhere) On Tue, Dec 16, 2014 at 8:32 AM, ramesh naidu wrote: > > Thats a Fantastic feel > > Ramesh > > On Tue, Dec 16, 2014 at 9:47 PM, Bobby Mozumder > wrote: >> >> Looks great. Thanks. >> >> Will this same look apply to the admin backend? >> >> -bobby >> >> >> > On Dec 16, 2014, at 11:09 AM, Jannis Leidel wrote: >> > >> > Hi everyone, >> > >> > We're incredibly proud to share with you the new design of the Django >> website, the documentation and the issue tracker. >> > >> > This is a long time coming and we couldn't be happier to finally ship >> it :) >> > >> > As you can imagine, there will be bugs, so please bear with us and >> report issues to the issue tracker at >> https://github.com/django/djangoproject.com/issues >> > >> > More infos about the redesign and its history can be found in the blog >> post: >> > >> > >> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/ >> > >> > Happy coding, everyone! >> > >> > Jannis >> > >> > -- >> > 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/EE1A1FDE-4750-4CED-A450-F2BB0F579FC1%40gmail.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/C76CB2DE-D6D2-4154-8B78-F096B392FEF9%40gmail.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Best Regards, > D Ramesh Naidu > > -- > 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/CAD_E%2Bs54L0GZfFbowsG0U4%2BLu_4Q4FqokYHodLNTtAjsqd%3DOEw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAD_E%2Bs54L0GZfFbowsG0U4%2BLu_4Q4FqokYHodLNTtAjsqd%3DOEw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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/CAFbaWt28heZvCEV-Nb%2Bw3aMrPJNE6gH6GC8qzrDn%3DNLbgMR8Og%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: django test-runner annoyances
Hello; I second all of what Carl said and would like to point out the app-refactor. I believe the most current code still lives in the app-loading branch on jezdez's repository on GitHub[1]. The reason I point this out is because the current testing structure is a legacy of the way Django internally finds out what "apps" are tested. I've gone down this rabbit hole before and the solution I ended up with was modifying the way loading apps worked which has all manner of side-effects. One of the first steps down that path is the app-loading branch which makes referring to an app by it's full name possible. -T [1]: https://github.com/jezdez/django/tree/app-loading On Wed, Sep 14, 2011 at 3:16 PM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/13/2011 08:46 AM, mvr wrote: > > Why doesn't the django test management command / test builder allow > > fully-qualified package names instead of just app-relative ones? > > > > At work we've been using the method below to monkey-patch the test > > builder, so that > > > > $ django-admin.py test my_module.my_app.tests.some_test_file > > > > always works as expected. We'd like to get rid of this monkey-patch, > > and since this functionality can be added in such a way that it's > > completely backwards compatible, where is the harm? I'm also willing > > to submit a diff that modifies django in-place, but the monkey patch > > below should be easy to read and first I wanted to hear if anyone has > > any thoughts on why the existing behaviour really is exactly what it > > should be. > > I'm generally in favor of updating Django's test runner to be more > consistent with what the rest of the Python testing world does. Being > able to reference test files, suites, and tests by > fully-qualified-dotted-path rather than magical-applabel-path would be a > good start, IMO. > > Another piece would be adding support for unittest2 test discovery, to > lift the requirement that all tests have to live directly in tests.py or > models.py. It's not that I think putting tests inside a tests package is > a bad convention, but if you have a lot of tests it's unfortunate that > you currently have to manually import all the suites into > tests/__init__.py. > > But I'm getting off-track -- these should be separate tickets anyway. If > you'd like to file the first one and upload a backwards-compatible > patch, I'm +1 on the concept. > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk5xC54ACgkQ8W4rlRKtE2eNFgCg7gVEkO6Y+tmXcsWlidmh67ge > SQwAn0PqFg74dy1yLsSPDYab1Jj+jNZ+ > =bAbE > -END PGP SIGNATURE- -- 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: new feature idea: even and odd forloop iteration variables
Hey Karlis;
This is a cool idea. I don't do enough template work to always remember the
cycle syntax, but an odd/even is pretty simple to remember.
As for getting this into Django, check out the Contributing Docs[1]. It has
everything you need on how to help out. In particular the Requesting New
Features[2] section will be of interest to you. The first thing to do is
bring it up here on the list (like you've done) and see if others are
interested in adding it. You might also want to include links to any code
that you've changed so other's can take a look at the code.
Hope this help,
-T
[1]: https://docs.djangoproject.com/en/dev/internals/contributing/
[2]:
https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/#requesting-features
On Mon, Sep 19, 2011 at 5:58 AM, skazhy wrote:
> Hi all!
>
> I've been working with Django for a while now, but today I decided to
> make a first contribution to Django that would make templates less
> ugly by adding these two values to loop_dict (in django/template/
> defaulttags.py):
>
> loop_dict['even'] = (i %2 == 0)
> loop_dict['odd'] = (i %2 != 0)
>
> Using {% if forloop.even %} would be more clear and readable than {%
> if forloop|divisibleby:"2" %}.
> As I am new to working *on* Django I don't know the history of this
> idea (if there is one) and the correct way of sending patches, all
> comments (and corrections!) are appreciated!
>
>
> -Karlis Lauva /skazhy/
>
> --
> 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.
>
>
--
Travis Swicegood | @tswicegood (most everywhere) | Senior Open Source
Engineer @ Texas Tribune / Armstrong
--
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.
