Re: Simplify the default project template

2013-01-28 Thread Ryan D Hiebert
Since the admin is turned on by default, should there be a admin.py template 
file in the app template as well?

Ryan

-- 
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: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

2012-08-23 Thread Ryan D Hiebert
> In 1.7 we could raise a loud exception when stream_content=True and 
> response.content is accessed directly. Middleware can do nothing if they 
> don't care about or need to worry about streaming responses. If they are 
> capable of functioning with a streaming response, they can check 
> response.stream_content and wrap the content generator with `response.content 
> = wrap(response)`.

Rather than requiring stream-capable middleware to check if it is stream 
content, and also require them to handle non-stream content separately, can we 
have .stream_content return an auto created generator with some sane automatic 
divisions (at newlines or every x bytes/characters). This would allow 
stream-aware middleware to act as if everything they do is streams, even if in 
reality it is not.

If we don't do this, it seems likely enough that middlewares that are 
stream-aware might end up doing this conversion anyway. If that's the case, 
moving that work into .stream_content can save them some common boilerplate 
code.

One possible problem with this approach would be that if there are many 
middlewares, alternating back and forth between stream aware and stream 
unaware, that the overhead might be significant. If it turned out that was the 
case, then proper ordering of middlewares would be part of optimizing a 
project, if it isn't already.

Ryan 

-- 
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 git guidelines

2012-05-18 Thread Ryan D Hiebert
On May 18, 2012, at 12:19 PM, Anssi Kääriäinen wrote:
> I do not want us to have single commit per pull request. Instead I
> would like to see nice clean logical commits. These make bisecting as
> easy as possible. So, we mostly agree here.

My feeling is that we want every commit in the main tree to be a working 
commit, even if its an early one in a multi-commit pull. This doesn't 
eliminate the possibility of multi-commit pull requests, but it seems to 
point to most small-change pull requests typically being a single commit.

I'm not entirely sure what that should mean to feature branches that get 
merged in, since they can often be very large and start with commits that 
don't have the feature working. Probably that they just need to make sure 
that each commit along the way does not break anything outside of the new 
feature.

-- 
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: start using less (and bootstrap!)

2012-02-03 Thread Ryan D Hiebert
I think that Django's admin app is a killer feature for two main reasons:
1. It is automatically installed, and integrated into the tutorial.
2. It is used all over in third-party apps, because they can expect it to be 
there.

While I appreciate that there may be differences in core vs admin that may slow 
down development of the admin, I'm wary of removing it from the django install, 
thinking that it might hurt reason 2, even if it is integrated in the tuturial, 
and possibly even installed automatically.

Although as far as the automatic install goes, I'm not sure how that would 
work. Would it be a dependency? That doesn't make sense.

On Feb 3, 2012, at 6:21 AM, Max Thayer wrote:

> The point about admin's appeal to new people is important, but externalizing 
> it and keeping new people from ever seeing it are very different. Consider: 
> admin isn't even enabled by default. You have to follow the tutorial on how 
> to enable it. If admin weren't included in Django proper, we could just 
> change the tutorial to "Apps are awesome; here's how to download and install 
> one written by someone else." New users could meet pip sooner, and otherwise 
> understand how to integrate with the broader python/django community's 
> various creations.
> 
> Actually, a friend of mine and I have been plotting out externalizing various 
> parts of contrib, like admin and auth. Are any groups currently pursuing 
> those goals as well?
> 
> Best regards,
> Max
> 
> On Fri, Feb 3, 2012 at 8:35 AM, Brendan Smith 
>  wrote:
> I give +1 to the idea of separating out the admin and letting people fork and 
> modify to their hearts content
> 
> I also still give my +1 to having it utilize less, but I am also cautious 
> like others about prescribing bootstrap specifically , especially the JS 
> since as others have pointed out is somewhat unstable right now and not very 
> easy to use at times (took me a long time to figure out modals)
> 
> Sent from my iPhone
> 
> On Feb 3, 2012, at 1:25 AM, Harris Lapiroff  wrote:
> 
> > The Django admin is a major—if not *the* major—selling point to
> > budding developers. I worry that externalizing it (hence making it a
> > *separate* piece of software that needs to be discovered and
> > installed, which seems simple but can be quite a challenge to new
> > coders) might take away Django's non-expert appeal. When I started
> > using Django, I knew no python. The only reason I was able to make
> > that work was because of the Django admin. If the admin gets kicked
> > out, I think it should be made *very* obvious where to find one.
> >
> > I'd be wary of putting them in core but I think using Bootstrap and
> > Less for a new admin (whether internal or external) would make its
> > development much faster. Dependencies should not be a problem. I think
> > jQuery is a pretty apt analogy here. You probably won't write much
> > javascript for the Django admin without learning jQuery. You can if
> > you want to. But most people don't need or want to write javascript
> > for the Django admin anyway. I think a framework like Bootstrap it
> > would actually simplify adding new features. It provides so many CSS
> > classes that there's a pretty good chance your feature wouldn't
> > require you to write even a line of CSS. I was able to convert an
> > unstyled app that I've been working on to functionally using Bootstrap
> > in just about an hour after starting to learn it.
> >
> > That having been said, I'd still be cautious with Bootstrap. It is a
> > young piece of software that is incredibly impressive and mind-
> > bogglingly easy to use, but obviously still in flux.
> >
> > On Feb 2, 5:38 pm, Sean Brant  wrote:
> >> 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 *outs