Feature request: make django.contrib a namespace package

2012-02-04 Thread bhuztez 
When trying to fix ticket #14087, I got an idea on how to separate out
all contrib apps.

Make django.contrib a namespace package. Every django release just
ship one more package which does not bundle any contrib apps. The
other one just bundle latest stable versions of contrib apps. Thus
contrib apps could be developed separately from django core, while
django releases are still batteries included, and it might be a litter
easier to develop an app to be included in django.contrib.



-- 
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-04 Thread Mateusz Marzantowicz 
On Sat, Feb 4, 2012 at 11:23 AM, Ric  wrote:

> no no, my point is not to remove admin, you misunderstood me...
>
> what i'm talking about is the extend the current admin version, with a
> theme framework.
>
> the theme framework got a default theme, that is the current admin
> theme, but then developers can add their own theme.
>
>
now making a theme for django is an hack, and not an hook, because
> some javascript are hard coded inside django admin.
>

So there is a need for code cleanup. I haven't checked if it's possible yet
(no need so far), but I think such split of JS and Python code is possible.


> i'm thinking about jquery, django use 1.4, i need 1.7 for my
> javascript, and i've done a terrbile hack to remove js from admin.
>

The solution is to upgrade jQuery in Django admin. More effort is to be
taken to include the newest jQuery with each Django release. It looks, it
is simpler then themes. I'm using completely different jQuery version in my
sites then what is included in Django admin and I have no problem with
this. I don't need to touch anything in Django admin UI (like about 90% of
regular django users).


>
> what i'm talking about is creating a single place in django to
> register stylesheet and javascripts, and then inject them in every
> context with an optional context processor.
>


Currently there is django-sekizai used e.g. by django-cms project.
Introduction of another media handling framework would complicate things.
To be honest I hate using this framework because it makes a lot of mess in
my templates. After all I have my CSS and JavaScript placed in static files
served from different web server. Using jQuery it is easy to hook to HTML
to fire some js function etc. and it should be equally easy to do it with
Django admin.


>
> using a request.media attr, would allow admin to add on the fly style
> and js for horizontal filters and fancy widget.
>
> then for developers would be more simple to create and mantain a
> separete bootstrap theme.
>


---
Mateusz Marzantowicz

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

2012-02-04 Thread Karthik Abinav 
@Łukasz : Thanks a lot for the response. But as Henrique mentioned using
the __init__()in the view class and then returning a JSON response would be
server side right ? Or Am i missing something here ?

I was thinking something on the lines of this. Add an
attribute in django.forms.fields which will include the js media having the
client side validation ?

On 4 February 2012 04:47, Henrique Bastos  wrote:

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


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

2012-02-04 Thread Ric 
no no, my point is not to remove admin, you misunderstood me...

what i'm talking about is the extend the current admin version, with a
theme framework.

the theme framework got a default theme, that is the current admin
theme, but then developers can add their own theme.

now making a theme for django is an hack, and not an hook, because
some javascript are hard coded inside django admin.

i'm thinking about jquery, django use 1.4, i need 1.7 for my
javascript, and i've done a terrbile hack to remove js from admin.

what i'm talking about is creating a single place in django to
register stylesheet and javascripts, and then inject them in every
context with an optional context processor.

using a request.media attr, would allow admin to add on the fly style
and js for horizontal filters and fancy widget.

then for developers would be more simple to create and mantain a
separete bootstrap theme.


On 4 Feb, 11:16, Anssi Kääriäinen  wrote:
> On Feb 4, 11:26 am, "Adam \"Cezar\" Jenkins" 
> wrote:
>
> > In this thread. There is a lot of mistaking of an app being installed with
> > Django vs. an app being in the same code repo as Django.
>
> Wouldn't this mean there are all the same dependencies for default
> install? What about backwards compatibility, can Django include
> something by default which has its own versioning policy? How does
> this even work with regards to tarball downloads, which is probably
> still the most common way to install Django in the new users category.
> That happens to be the category who are most hit by removal of Django
> from contrib.
>
> If this would be done, it would mean a radical sift in the way Django
> is distributed. Tutorial step 3 should be changed from talking about
> the admin to talking about how to use PIP, virtualenv and where to
> find nice packages. Using django-admin2 as an example. Maybe this
> could work and would actually benefit Django development. But this is
> a radical change from "download this tarball and off you go, batteries
> included, backwards compatibility for 2 releases guaranteed"
> philosophy.
>
>  - 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: start using less (and bootstrap!)

2012-02-04 Thread Anssi Kääriäinen 
On Feb 4, 11:26 am, "Adam \"Cezar\" Jenkins" 
wrote:
> In this thread. There is a lot of mistaking of an app being installed with
> Django vs. an app being in the same code repo as Django.

Wouldn't this mean there are all the same dependencies for default
install? What about backwards compatibility, can Django include
something by default which has its own versioning policy? How does
this even work with regards to tarball downloads, which is probably
still the most common way to install Django in the new users category.
That happens to be the category who are most hit by removal of Django
from contrib.

If this would be done, it would mean a radical sift in the way Django
is distributed. Tutorial step 3 should be changed from talking about
the admin to talking about how to use PIP, virtualenv and where to
find nice packages. Using django-admin2 as an example. Maybe this
could work and would actually benefit Django development. But this is
a radical change from "download this tarball and off you go, batteries
included, backwards compatibility for 2 releases guaranteed"
philosophy.

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

2012-02-04 Thread Adam "Cezar" Jenkins 
In this thread. There is a lot of mistaking of an app being installed with
Django vs. an app being in the same code repo as Django.

Don't worry people. I don't think anyone is seriously considering throwing
away the admin.

On Fri, Feb 3, 2012 at 6:55 PM, Joe & Anne Tennies wrote:

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

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