Re: start using less (and bootstrap!)

[Joe & Anne Tennies]

I'll throw in my 2 cents.

Please, please do not remove auth or admin. They really are the selling
point and reason to use Django over something else. That being stated, you
do not have to keep auth or admin in their current forms. I have no problem
whatsoever with making them more of an API than an implementation.

Figure out the signals an auth backend should have and the basic things
expected to be implemented. For instance, a User should have a user_id,
human-readable name (optional), email address (optional), profile?,
permissions, auth_groups, and backend authenticated with (I'm sure there
may be others that should be here). I think the current signals are
probably fine. Also needed would be some sort of "backend plugin loader"
(like the one for the ORM allowing MySQL, Postgres, etc.) Then include a
very basic implementation that just does username/password authentication
with the database as an app that can be used. (Others can maintain an open
id, facebook, etc. outside the core of Django, but the standard is there.)
PS: Something like Twisted.cred may a good reference for such an abstract
thing.

Ditto for the admin. So what if it's not ajax or less, just make a simple
one that works and let others extend/reimplement to get a fancy version.

This to me is congruent with the answer I had heard thrown around for
South. Don't include South in Django, but include a base specification that
South and nashvegas can agree to. (required parts needed in the ORM and
schema revision tracking, etc.) Then include a simple implementation that
can migrate databases via some script but not autodetect changes.


Basically, I see a big need for Django to start providing specifications to
how things
-- 
Joe & Anne Tennies
tenn...@gmail.com

-- 
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: Documentation for creating a new database backend?

[Anssi Kääriäinen]

On Feb 4, 1:01 am, Alex Vidal  wrote:
> We're using django-pyodbchttp://code.google.com/p/django-pyodbc/here at
> the office and ran into a few snags when testing Django 1.4. I forked the
> project onto github and made some changes to support 1.4
> (https://github.com/avidal/django-pyodbc/compare/master...django-1.4), but
> I was thinking about making further, more significant changes to it. Is
> there documentation in regards to creating a new database backend, or do we
> just need to look at the existing ones and piece it together?

I don't think there is any documentation about this. So, you just need
to dig through the different backends and see what they do. Of course,
the test suite will point out most problems for you.

 - Anssi

-- 
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.

Documentation for creating a new database backend?

[Alex Vidal]

We're using django-pyodbc http://code.google.com/p/django-pyodbc/ here at 
the office and ran into a few snags when testing Django 1.4. I forked the 
project onto github and made some changes to support 1.4 
(https://github.com/avidal/django-pyodbc/compare/master...django-1.4), but 
I was thinking about making further, more significant changes to it. Is 
there documentation in regards to creating a new database backend, or do we 
just need to look at the existing ones and piece it together?

-- 
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/-/f4hDf4tjcsUJ.
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!)

[Anssi Kääriäinen]

Just adding my point of view to this thread. I haven't even heard of
Bootstrap before. I know less (and other similar systems) but haven't
ever used them. I do need to do frontend work. I am not good at all in
it, and I do not enjoy it. But I need to do it.

Now, if Admin would begin using less and bootstrap, that would be a
problem for me. I would need to learn those tools to effectively
customize the Admin. While CSS and HTML can be expected to be known, I
don't think you can expect people to know less or bootstrap.

My viewpoint (in general, not just related to admin) is that Django
should contain as much hooks as possible and no, or only simple,
implementations. It might be possible to design the Admin in such a
way that you could completely overhaul how it looks and maybe even
behaves by subclassing. So, external projects could rely that there is
an Admin application, and that it has a common API. External projects
could customize it. I don't know the admin well, and I really don't
know the latest tools in the frontend development world. So, maybe
what I just said is impossible to do in practice.

I do feel that there needs to be some data editing application
inbuilt. Maybe admin has just become too complex. Make it simpler,
while allowing external projects to extend it (as said, if at all
possible).

About Github and forking. This is all good and well, but customize-by-
forking tends to have the problem that internal parts become de-facto
public. Something like the situation with model._meta. I really feel
that if Django encourages forking, then there must be strong consensus
that the non-public parts of Django really are non-public. I am
worried that otherwise changing anything in Django will become harder
than it needs to be. For example, if the ORM internals were to be
refactored, but this resulted in breaking django-nonrel and maybe
other projects like that, would that be OK?

 - Anssi

-- 
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: Feature Request: Client side validation classes for forms

[Henrique Bastos]

Django's form could use a more high level solution for both client side form 
validation and asynchronous form validation.

Djaxproject.com is ok, but is too ad hoc. It would be nice to have Adrian's and 
Łukasz perspectives combined somehow.

[]'s,
--
Henrique Bastos
+55 21 9618-6180
http://henriquebastos.net
http://twitter.com/henriquebastos

On 03/02/2012, at 19:57, Łukasz Rekucki  wrote:

> On 3 February 2012 22:03, Adrian Holovaty  wrote:
>> On Fri, Feb 3, 2012 at 11:46 AM, Karthik Abinav
>>  wrote:
>>>   I was thinking about a feature that could be implemented. For common
>>> fields like username having only alphanumeric , or phone numbers having only
>>> numbers, a client side validation need not be written every time.Instead one
>>> could directly write something like,
>>> 
>>> forms.CharField(validator = "usernamevalidation")
>>> 
>>> in the forms definition and the client side validation for that field would
>>> automatically be taken care of by the validator class. This will save a lot
>>> of time while making large websites with lot of registration forms and in
>>> general be helpful to people who dont really know javascript and yet want
>>> some amount of frontend validation in place.
>> 
>> I like the idea of having a JavaScript version of form validation.
>> Basically we could make a view class that takes a Form object in
>> __init__() and returns JSON of the errors in a consistent way -- this
>> would be very easy to do. Then we could provide some standard
>> JavaScript to parse that JSON and add the error messages to the
>> appropriate fields in the form in a consistent way.
> 
> I don't get it. That would require sending the data to the server
> (right?), so it's not
> really client-side. I think http://www.dajaxproject.com/ does exactly that.
> 
> What I would like to see instead is providing HTML5 attributes for
> standard fields and
> making it easier to add ones to custom ones. Some simple to implement
> ones are: "required", min/max for number fields, max_length for a
> textarea. Regular expression can be supported via "pattern" (with some
> code to translate them to JS regexp syntax).
> 
> -- 
> Łukasz Rekucki
> 
> -- 
> 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.
> 

-- 
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!)

[Ric]

a less compiler is needed to make developers add custom variables to
match color scheme they like.

i prefeer using an existing framework, a lot of work less to do, no
docs to make, just a link.
bootstrap it's fantastic, it's well done and is flexible.

django should use a base style, already compiled for backward
compatibility.

i would make a theme framework, something like django.contrib.themes,
a css/js/less framework to customize every view and the admin.

imagine a subclass of django.forms.Media

class MediaMiddleware(object):

def process_exception(self, request, e):
request.media = GlobalMedia()

user can add css doing

>>> request.media.add_css(

django admin could do this to add media it gets from admin forms doing

request.media += self.media + adminForm.media

and then push media in context


we could create a GlobalMediaContextProcessor, it import an instance
of global_media and put it in every template with a namespace of
"global_media".

def base(request):

return {
'media':request.media,
}

and than in template use

{{ media.css }}

now, with this kind of hook, user can choose, site wide, what media
use.
with a context_processor, a media class is injected in every template,
and views can add js and css on the fly, pushing them over
request.media

with some less rule, admin template could be reskinned, and user can
select a different type of themes

THEME_CLASS = "django.contrib.themes.DefaultTheme"

then wu could add a "django.contrib.themes.Bootstrap"

a globalmedia class that host less definition for a bootstrap theme.

with an app like this users could choose if continue to use default
theme or switch to a bootstrap template, to develop faster a front-end
interface.

no backward compatibility issues, just one more possibility for
developers.


what views can do is to
On 3 Feb, 20:07, Ryan D Hiebert  wrote:
> 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 

Re: Feature Request: Client side validation classes for forms

[Łukasz Rekucki]

On 3 February 2012 22:03, Adrian Holovaty  wrote:
> On Fri, Feb 3, 2012 at 11:46 AM, Karthik Abinav
>  wrote:
>>   I was thinking about a feature that could be implemented. For common
>> fields like username having only alphanumeric , or phone numbers having only
>> numbers, a client side validation need not be written every time.Instead one
>> could directly write something like,
>>
>> forms.CharField(validator = "usernamevalidation")
>>
>> in the forms definition and the client side validation for that field would
>> automatically be taken care of by the validator class. This will save a lot
>> of time while making large websites with lot of registration forms and in
>> general be helpful to people who dont really know javascript and yet want
>> some amount of frontend validation in place.
>
> I like the idea of having a JavaScript version of form validation.
> Basically we could make a view class that takes a Form object in
> __init__() and returns JSON of the errors in a consistent way -- this
> would be very easy to do. Then we could provide some standard
> JavaScript to parse that JSON and add the error messages to the
> appropriate fields in the form in a consistent way.

I don't get it. That would require sending the data to the server
(right?), so it's not
really client-side. I think http://www.dajaxproject.com/ does exactly that.

What I would like to see instead is providing HTML5 attributes for
standard fields and
making it easier to add ones to custom ones. Some simple to implement
ones are: "required", min/max for number fields, max_length for a
textarea. Regular expression can be supported via "pattern" (with some
code to translate them to JS regexp syntax).

-- 
Łukasz Rekucki

-- 
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: Feature Request: Client side validation classes for forms

[Adrian Holovaty]

On Fri, Feb 3, 2012 at 11:46 AM, Karthik Abinav
 wrote:
>   I was thinking about a feature that could be implemented. For common
> fields like username having only alphanumeric , or phone numbers having only
> numbers, a client side validation need not be written every time.Instead one
> could directly write something like,
>
> forms.CharField(validator = "usernamevalidation")
>
> in the forms definition and the client side validation for that field would
> automatically be taken care of by the validator class. This will save a lot
> of time while making large websites with lot of registration forms and in
> general be helpful to people who dont really know javascript and yet want
> some amount of frontend validation in place.

I like the idea of having a JavaScript version of form validation.
Basically we could make a view class that takes a Form object in
__init__() and returns JSON of the errors in a consistent way -- this
would be very easy to do. Then we could provide some standard
JavaScript to parse that JSON and add the error messages to the
appropriate fields in the form in a consistent way.

Good idea! It's a bit too late now to add it to Django 1.4, but I'd
like to implement this for the next version.

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.

Re: start using less (and bootstrap!)

[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 

Feature Request: Client side validation classes for forms

[Karthik Abinav]

Hi,

  I was thinking about a feature that could be implemented. For common
fields like username having only alphanumeric , or phone numbers having
only numbers, a client side validation need not be written every
time.Instead one could directly write something like,

forms.CharField(validator = "usernamevalidation")

in the forms definition and the client side validation for that field would
automatically be taken care of by the validator class. This will save a lot
of time while making large websites with lot of registration forms and in
general be helpful to people who dont really know javascript and yet want
some amount of frontend validation in place.


Regards,
Karthik Abinav

-- 
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!)

[Brendan Smith]

I had not heard about the move to GitHub but I am +10 on that move. 


On Feb 3, 2012, at 11:20 AM, Adrian Holovaty wrote:

> On Fri, Feb 3, 2012 at 12: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 agree with this sentiment. I think separating the admin into a
> standalone app would be a step backward, at least at this point.
> 
> It strikes me that "the Django admin is hard for people to fork and
> modify" is a symptom of something else, not a problem in itself. The
> bigger problem is that our current development infrastructure
> (Subversion/Trac) doesn't allow for easy forking workflow. We're going
> to solve that with our move to Git/GitHub, which will make it much
> easier for people to fork and much easier for core developers to
> integrate contributions.
> 
> Before making any final judgment on separating the admin, we should
> see how our community's move to GitHub goes. I'm suspecting the pain
> points around forking will vanish at that point.
> 
> P.S. In case you haven't heard about the GitHub move, here's a blog
> post you should read: http://www.holovaty.com/writing/back-to-django/
> ETA is sometime soon after we launch 1.4.
> 
> 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.
> 

-- 
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!)

[Max Thayer]

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 <
bren...@nationalpriorities.org> 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 *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 

Re: start using less (and bootstrap!)

[Adrian Holovaty]

On Fri, Feb 3, 2012 at 12: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 agree with this sentiment. I think separating the admin into a
standalone app would be a step backward, at least at this point.

It strikes me that "the Django admin is hard for people to fork and
modify" is a symptom of something else, not a problem in itself. The
bigger problem is that our current development infrastructure
(Subversion/Trac) doesn't allow for easy forking workflow. We're going
to solve that with our move to Git/GitHub, which will make it much
easier for people to fork and much easier for core developers to
integrate contributions.

Before making any final judgment on separating the admin, we should
see how our community's move to GitHub goes. I'm suspecting the pain
points around forking will vanish at that point.

P.S. In case you haven't heard about the GitHub move, here's a blog
post you should read: http://www.holovaty.com/writing/back-to-django/
ETA is sometime soon after we launch 1.4.

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.

Re: start using less (and bootstrap!)

[Adam "Cezar" Jenkins]

I heard this before from others. When someone installs Django from pypi it
can install things like the admin without admin being inside the Django
codebase. This is the simplest solution in my opinion.

On Fri, Feb 3, 2012 at 12: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 *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 

Re: AJAX generic views

[Dustin Farris]

I am also interested in where this is going.  I have written simple
extensions of BaseDetailView similar to the approach taken in the
"HybridDetailView" example in the documentation (https://
docs.djangoproject.com/en/1.3/topics/class-based-views/#more-than-just-
html).  Would love to hear other ideas.

On Feb 3, 3:43 am, gert  wrote:
> Hi
>
> I've been using the class based views from day one and loving it!
>
> It would be great if there was a generic view to bring some
> consistency to the way everybody implements AJAX.
>
> Or if not a view then maybe a mixin or two (JSONResponseMixin used in
> the documentation comes to mind).
>
> Any thoughts on this?
>
> Regards
> Gert

-- 
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!)

[Brendan Smith]

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 *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." -- 

AJAX generic views

[gert]

Hi

I've been using the class based views from day one and loving it!

It would be great if there was a generic view to bring some
consistency to the way everybody implements AJAX.

Or if not a view then maybe a mixin or two (JSONResponseMixin used in
the documentation comes to mind).

Any thoughts on this?

Regards
Gert

-- 
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.