On Mar 29, 4:47 pm, Gabriel Hurley wrote:
> The component re-organization is done now, as per Julien's (and Jannis')
> suggestions above. I even re-categorized the 84 tickets that were in
> "Contrib apps" into their new separate contrib.foo components (thank god for
> Trac bulk modify privileges!)
On Mar 29, 4:01 pm, Stephen Burrows
wrote:
> 3. There is a simple workaround going back to ie6 for handling the css
> problems related to unrecognized tags. [3]
...snip...
> [3]http://diveintohtml5.org/semantics.html#unknown-elements
The workaround works if javascript is enabled. So we can't co
The component re-organization is done now, as per Julien's (and Jannis')
suggestions above. I even re-categorized the 84 tickets that were in
"Contrib apps" into their new separate contrib.foo components (thank god for
Trac bulk modify privileges!).
The organization definitely makes more sense
I think, cron jobs is an overhead in many simple cases where old behaviour
was useful and more simpler.
Why you don't want include DeletingFileField[1] in django?
[1] https://gist.github.com/889692
On Mon, Mar 28, 2011 at 9:07 PM, Jacob Kaplan-Moss wrote:
> On Mon, Mar 28, 2011 at 4:16 AM, -RAX-
FWIW, I vaguely recall how the last thread on X-sendfile and the files API
got conflated (derailed?) and as far as I understood it then and as far as I
understand it now, they're related only because some backends (which we
currently don't directly support) are difficult to work with without suc
Anyone interested in reading about html5 can find a lot of great
information at http://diveintohtml5.org/.
Some of the highlights:
1. a change to the doctype of the admin from http://www.w3.org/TR/xhtml1/DTD/xhtml1-
strict.dtd"> to should still keep ie6 in Almost
Standards Mode [1]
2. Browsers
Switching to the HTML5 doctype won't hurt IE6 rendering (having dealt with
this myself several times). To the best of my knowledge--from my own tests
and third-party sources--using the new input attributes also doesn't hurt
IE6. However, if we start delving deeper into HTML5 and using the new HT
On Mar 29, 2:29 pm, Julien Phalip wrote:
> On Mar 29, 1:26 pm, Luke Plant wrote:
>
> > The further enhancements I'm thinking of are things like an EmailInput
> > widget (which I'd suggest was the default widget for EmailField, but
> > could be just available in django/forms/widgets.py). This widg
On Mar 29, 1:26 pm, Luke Plant wrote:
> The further enhancements I'm thinking of are things like an EmailInput
> widget (which I'd suggest was the default widget for EmailField, but
> could be just available in django/forms/widgets.py). This widget would
> output . AFAIK, this is fully backwards
On Tue, Mar 29, 2011 at 10:26 AM, Luke Plant wrote:
> On 29/03/11 03:10, Russell Keith-Magee wrote:
>> Of course, this depends a great deal on the details of exactly what is
>> to be done, and where. Luke's proposal says we should "use HTML5
>> features at least as an option in places like the adm
Hi,
Since we've recently been discussing a few ways to improve Trac, I'm
suggesting to move the discussion which started a few minutes ago in
#5833 here so as not to pollute the ticket with too many meta
conversations. I'd also like to apologise for the confusion I seem to
have stirred by changing
On 29/03/11 03:10, Russell Keith-Magee wrote:
> Of course, this depends a great deal on the details of exactly what is
> to be done, and where. Luke's proposal says we should "use HTML5
> features at least as an option in places like the admin", but the
> provided patch is a unilateral switch to HT
On Tue, Mar 29, 2011 at 6:08 AM, Wim Feijen wrote:
> +1. All major browsers now support html5 and by the time django 1.4
> will be released we will be right on time though a bit late.
Statements like "All modern browsers support it" misses the point. It
isn't the *modern* browsers that are the is
+1
No harm, as it breaks nothing currently using the templates.
Sets a great message that Django moves forward. I like it.
On Mon, Mar 28, 2011 at 12:38 PM, Luke Plant wrote:
> Hi all,
>
> I'd like to put forward the proposal that we switch to HTML5 for all
> Django supplied templates in Django
+1. All major browsers now support html5 and by the time django 1.4
will be released we will be right on time though a bit late.
In response to Gabriel, in my opinion, legacy problems should not be
addressed by not moving forward, but they can be resolved by either 1.
updating or 2. staying on a l
On Mar 29, 8:58 am, Gabriel Hurley wrote:
> I can work on it late tonight (about 6-8 hours from now) if no one else gets
> to it.
>
> All the best,
>
> - Gabriel
Excellent, thank you Gabriel! There's no rush -- whenever it suits
you. Let me know if I can help in any way.
Julien
--
You rece
I agree with the others. This is very much the correct step going
forward. These fallback methods have worried me, and definitely weaken
the security of the improvements.
One idea I had been kicking around was some way to tell Django what
version of these things to expect, and disable the fallback
I can work on it late tonight (about 6-8 hours from now) if no one else gets
to it.
All the best,
- Gabriel
--
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 u
+1, this seemed kludgy to me and had potential insecurities as it was.
You're only as strong as your weakest link, right?
All the best,
- Gabriel
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dj
On Mon, Mar 28, 2011 at 4:19 PM, Luke Plant wrote:
> Proposal: remove compatibility fallbacks for short-lifetime signed data
> (shortening the deprecation process).
Sounds perfectly fine to me. Skipping versions is generally a dicey
idea anyway, so recommending a brief stop in 1.3 for people goin
While on a personal level I agree wholeheartedly about moving to HTML5, I do
have reservations about it from the perspective of Django's "enterprise"
customers (AKA the ones with legacy and bureaucratic issues).
Thankfully we don't have major backwards-compatibility issues to deal with
from a f
As with the others, I'll chime in to support this idea. It will really
help move Django in the direction that the web is going, without
seriously breaking existing code (aside from the people who are really
using the XHTML features, and those people can almost certainly figure
out how to change bac
Proposal: remove compatibility fallbacks for short-lifetime signed data
(shortening the deprecation process).
= Explanation =
In 1.3, various bits of code were updated to use a better system for
signing using the SECRET_KEY. However, for compatibility with existing
data, the old methods were left
On Mon, Mar 28, 2011 at 4:08 PM, Julien Phalip wrote:
> I wouldn't mind trying but I don't have much experience administering
> Trac and I wouldn't want to make a mess. Earlier in this thread
> Gabriel has offered to help as he's got the Trac skillz.
>
> Gabriel, are you around? :-)
Sweet. I'll l
On Mar 29, 2:01 am, Jacob Kaplan-Moss wrote:
> On Mon, Mar 28, 2011 at 12:56 AM, Julien Phalip wrote:
> > Now that 1.3 has been released (yay!), I'm reviving this thread to see
> > if we can make Trac a little more efficient on our way to 1.4. I'll
> > try to summarise what's been suggested so fa
On Mon, Mar 28, 2011 at 3:36 PM, Jacob Kaplan-Moss wrote:
...
> PS: 66,045 lines of code plus 51,174 lines of tests.
Yes, but how many lines of docs? :-P
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On Mon, Mar 28, 2011 at 3:29 PM, Andrea Zilio wrote:
> I was just wondering if anyone knows the total number of lines of code
> of Django.
Hi Andrea --
This question's off-topic for this list. Django-dev is for discussion
development of Django itself, and the length isn't really relevant. In
the
Hi!
I was just wondering if anyone knows the total number of lines of code
of Django.
Andrea
--
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
On Mon, Mar 28, 2011 at 1:13 PM, Waldemar Kornewald
wrote:
> That's a good goal and as long as you only focus on file downloads
> it's possible to reuse the middlewares setting. However, if you ever
> want to provide an abstract file uploads API we're back to the same
> problem.
I'm trying to tal
On Mon, Mar 28, 2011 at 6:40 PM, Jacob Kaplan-Moss wrote:
> On Mon, Mar 28, 2011 at 11:22 AM, Waldemar Kornewald
> wrote:
>> I do agree that it's too complicated (esp., the forms) and I plan to
>> improve django-filetransfers in this regard. The biggest complexity
>> comes largely from file uploa
On Mar 28, 2011, at 9:40 AM, Jacob Kaplan-Moss wrote:
> If I've got that wrong, you need to explain to me (and
> anyone else) why uploads and downloads belong together in the same
> patch and why a simple "just support X-Sendfile and friends" patch
> can't possibly work.
+1. It's entirely possi
I agree completely that we should move to HTML5. It seems like it will be
even more important as more and more people use Smart Phones or Pads for
surfing the net, and I believe all of these are supporting HTML5. I've
started attending some HTML5 user group meetings, and I'm quite impressed
with t
Hi Luke,
On 03/28/2011 12:38 PM, Luke Plant wrote:
> Overall, I think the advantages outweigh the disadvantages, that we have
> to make the move sometime, and now is about the right time, or perhaps
> slightly late.
100% agreed, for all the reasons you outlined. We've been using the
HTML5 doctype
On Mon, Mar 28, 2011 at 11:22 AM, Waldemar Kornewald
wrote:
> I do agree that it's too complicated (esp., the forms) and I plan to
> improve django-filetransfers in this regard. The biggest complexity
> comes largely from file upload handling (which I understand isn't a
> problem you're trying to
Hi all,
I'd like to put forward the proposal that we switch to HTML5 for all
Django supplied templates in Django 1.4 (apart from some of the GIS
templates which apparently require XHTML to work under IE). I'm quite
prepared for this to get shot down in flames, but I think it is at the
point where
On Mon, Mar 28, 2011 at 5:05 PM, Jacob Kaplan-Moss wrote:
> On Sat, Mar 26, 2011 at 8:45 AM, Waldemar Kornewald
> wrote:
>> That's pretty much exactly what django-filetransfers tries to do on
>> the download side:
>> http://www.allbuttonspressed.com/projects/django-filetransfers
>> Hotever it's n
On Mon, Mar 28, 2011 at 11:04 AM, Dan Fairs wrote:
> We don't have a core site base template. Each client on our system gets
> their own, as IA/branding etc. varies considerably (and indeed includes
> chunks of markup that the client supplies directly).
... and congratulations, you've successfull
- preprocess inheritance. (one important incompatibility: {% extend
"..." %} should only get a string as parameter, not a variable! But
honestly, I really don't know why someone would do that.
For the record - we do!
We don't have a core site base template. Each client on our system gets
their
On Mon. 2011-03-28 at 03:07 AM EDT, Russell Keith-Magee
wrote:
> One
> possibility: have two 'bug' options -- "Bug" and "Release-blocking
> bug". Easy to filter on, relatively easy to understand, and easy to
> correct if it gets mistriaged.
Apache HTTP Server uses a Severity field, with values
On 28/03/11 15:50, Russell Keith-Magee wrote:
> However, I accept your point about splitting bug into two categories.
> Making it two different flags was a suggestion for expediency of
> implementation, but I can see how it will complicate your life with
> reports. So I suppose we'll just have to
On Sat, Mar 26, 2011 at 8:45 AM, Waldemar Kornewald
wrote:
> That's pretty much exactly what django-filetransfers tries to do on
> the download side:
> http://www.allbuttonspressed.com/projects/django-filetransfers
> Hotever it's not only for X-Sendfile, but also for any other file
> serving mecha
On Mon, Mar 28, 2011 at 4:16 AM, -RAX- wrote:
> Said so I will start implementing such a maintenance job, and I am
> willing to share it so maybe we could include it in a future release
> of django.
Sounds good -- I look forward to seeing your code!
Jacob
--
You received this message because y
On Mon, Mar 28, 2011 at 12:56 AM, Julien Phalip wrote:
> Now that 1.3 has been released (yay!), I'm reviving this thread to see
> if we can make Trac a little more efficient on our way to 1.4. I'll
> try to summarise what's been suggested so far in regard to improving
> and clarifying the "Compone
On Mon, Mar 28, 2011 at 10:32 PM, Luke Plant wrote:
> On 28/03/11 13:21, Russell Keith-Magee wrote:
>
>> Ok - so at this point, the option list is looking like:
>>
>> * Uncategorized
>> * Bug
>> * Release blocking Bug
>> * New Feature
>> * Optimization
>>
>> Yours,
>> Russ Magee %-)
>>
>
> I'
On 28/03/11 13:21, Russell Keith-Magee wrote:
> Ok - so at this point, the option list is looking like:
>
> * Uncategorized
> * Bug
> * Release blocking Bug
> * New Feature
> * Optimization
>
> Yours,
> Russ Magee %-)
>
I'm definitely +1 on this new field, and just sat down in order to pu
Hi all,
I have also been working for about a year on such a template compiler,
and recently published it on Github. You may be interested in this
project:
https://github.com/citylive/django-template-preprocessor
** Short summary of what already is possible, and what still needs to
be done:
The
On Mon, Mar 28, 2011 at 8:04 PM, Julien Phalip wrote:
> On Mar 28, 10:49 pm, Karen Tracey wrote:
>> +1 on having a distinction between bug, feature, and optimization.
>>
>> I don't think both "Uncategorized" and "Other" are necessary.
>
> My reasoning for "Other" was that there might be things th
On Mon, Mar 28, 2011 at 5:16 PM, -RAX- wrote:
>> One query for each model
>> containing one or more FileFields is enough to build a list of the files
>> that ought to exist, and any file not in that list can presumably be
>> removed.
>
> How can I sleep at night knowing that there is a maintenance
On Mar 28, 4:08 pm, Justin Holmes wrote:
> By "current app," do you mean the app which contains the view to which
> the current URL is mapped?
I mean the "namespace" (instance name) for the requested URL or the
"current_app" attribute of a context object which is supposed to be
used as a hint for
On Mar 28, 10:49 pm, Karen Tracey wrote:
> +1 on having a distinction between bug, feature, and optimization.
>
> I don't think both "Uncategorized" and "Other" are necessary.
My reasoning for "Other" was that there might be things that are
neither a bug, a feature or an optimisation. I admit tha
On Mon, Mar 28, 2011 at 2:28 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
> On Mon, Mar 28, 2011 at 2:12 PM, Julien Phalip wrote:
> > Hello,
> >
> > I'm not sure if the consensus so far is either "Meh" or "Let's give it
> > a try", or if there's even a consensus. I'm still keen on th
On Mar 27, 5:48 am, "G.Boutsioukis" wrote:
> Hi, I'm thinking about submitting a proposal for template compilation
> and I'm posting this as a request for more info.
>
> In particular, I remember this project being discussed last year and I
> pretty much assumed that Alex Gaynor's proposal would h
By "current app," do you mean the app which contains the view to which
the current URL is mapped?
On Mon, Mar 28, 2011 at 12:39 AM, Tai Lee wrote:
> Now that 1.3 is out, does any core dev have an opinion, feedback or
> suggestions on this?
>
> I've solved my immediate need with two template loade
On Monday, March 28, 2011 9:15:45 PM UTC+11, Gustavo Narea wrote:
>
> On 26/03/11 11:31, Graham Dumpleton wrote:
> >
> > Yes and no as nginx also has a X-Sendfile module, again possibly
> > optional (can't remember).
>
> I didn't know there was an X-Sendfile module for Nginx -- Search results
> f
On 26/03/11 11:31, Graham Dumpleton wrote:
>
> Yes and no as nginx also has a X-Sendfile module, again possibly
> optional (can't remember).
I didn't know there was an X-Sendfile module for Nginx -- Search results
for "nginx xsendfile" point me to X-Accel-Redirect.
> In Apache/mod_wsgi when usin
On 28.03.2011, at 07:56, Julien Phalip wrote:
> Now that 1.3 has been released (yay!), I'm reviving this thread to see
> if we can make Trac a little more efficient on our way to 1.4. I'll
> try to summarise what's been suggested so far in regard to improving
> and clarifying the "Component" fiel
> One query for each model
> containing one or more FileFields is enough to build a list of the files
> that ought to exist, and any file not in that list can presumably be
> removed.
How can I sleep at night knowing that there is a maintenance cron job
deleting files which can be "presumably be r
On Mon, Mar 28, 2011 at 2:37 PM, Julien Phalip wrote:
> On 28 March 2011 17:28, Russell Keith-Magee wrote:
>>
>> > * Uncategorized (default)
>> > * Feature request: for adding something new.
>> > * Bug report: for when an existing thing is broken or not behaving as
>> > expected.
>> > * Optimisat
58 matches
Mail list logo
