django admin missing meta tag for charcter encoding in the head

[Ric]

hi,

the default django template need a meta tag for character encoding in
the head



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

Jquery library update in django 1.4

[Ric]

hi, is it possibile to upgrade the jquery library in admin to the
lastest version with the now django 1.4?

for what i've seen there is just one little bug when you use the
select all checkbox in admin changelist, all other javascript works
out of the box

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

django.contrib.gis.measure

[Ric]

i've opened a ticket for a small issue in module
django.contrib.gis.measure

the MeasureBase class cannot be subclassed easily, so i've write a new
MeasureBase class to allow developers to implement other Measure class
(like weight, currency and so on)

the code it's here

https://code.djangoproject.com/ticket/17754

with this class you can do some stuffs like this

class Weight(MeasureBase):
UNITS = {
}

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

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

[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 

start using less (and bootstrap!)

[Ric]

hi, i want to propose a long term idea.

start using a less framework inside django.

i'm using bootstrap for my django app. it's really cool.

what i'am doing now is writing with less a new css to style django
admin.

my idea is that django should provide a faster way to write an app,
and while django is absolutely awesome for writing server side code,
it does nothing to speed up css/html.

my idea is to write an app, with a setting object containing variables
for less (colors and so on, font style ecc) and then compile a less
for your current app.

a command like manage.py compileless could do the trick, and compile
css code for your app.

django should provide an html base template (used in admin too) that
is styled with a customizable less app.

it would be a great thing for django to give developers a fast start
for new apps with a built in less framework.

i'm using bootstrap, and it's great, with a few settings an user could
customize a base css, and do very cool things with few line of code.

i'm actually working to make it work with django, i hope it will be a
cool app.

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

ModelBackend should have a get_anonymous_user method

[Ric]

ModelBackend should provide a method to get a fresh instance of
AnonymousUser, and use this method to set a new instance of
AnonymousUser in

django.contrib.auth.get_user and django.contrib.auth.logout

i've created a ticket
https://code.djangoproject.com/ticket/17254

-- 
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: add view_permission

[Ric]

ok this is my last message, i swear!

i've created a new options.py file and a .diff, and i've attached it
to the ticket you send to me.



i've tested it and it works, it's pretty basic and there is more work
to do.

what i've done is to add a method has_view_permission, and check a
view permission in every view

i also created a get_list_editable, and i add in get_list_editable and
in get_readonly_fields a check, and it returns original read_only and
list_editable only if user has got a change_pemission

i also raise a permission error every time there is a post request and
user do not have a change_permission

a also ask for view_permission in history_view.

todo:

fix inlines fix submit_row

add a opts.has_view_permission()

-- 
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: add view_permission

[Ric]

fine i'll keep in mind.

On 16 Nov, 22:17, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> Hi Ric,
>
> I've noticed that you're posting a lot on this mailing list. Please remember 
> that each email sent here is broadcasted to around 7000 people, each of whom 
> will need a few seconds to decide if it's interesting.
>
> You're expected to do some research and to structure your thoughts and 
> questions before posting. From my own experience, it's unusual to write an 
> email for django-developers in less than an hour, and it can even take 
> several days. "Stream of thought" messages aren't appropriate; if you want to 
> chat, please join the #django-dev on FreeNode.
>
> Thanks for your understanding!
>
> --
> Aymeric Augustin.
>
> On 16 nov. 2011, at 20:51, Ric wrote:
>
>
>
>
>
>
>
> > at a first look, the big file to patch is django.contrib.admin.options
>
> > i need also to add a method to django.db.models.options
>
> > def get_view_permission(self):
> >    return 'view_%s' % self.object_name.lower()
>
> > so maybe it's better to work only on options.py and make a .diff,
> > right?
>
> > On 16 Nov, 20:43, Ric <riccardodivirgi...@gmail.com> wrote:
> >> ok i can give a try...
>
> >> maybe it's difficult, not to much. i have to see inline models, and
> >> give the right behavior
>
> >> so from github i can fork django 1.3.1, but actually i'm working with
> >> the latest version.
>
> >> should i fork the lastest?
>
> >> On 16 Nov, 20:21, Aymeric Augustin
>
> >> <aymeric.augus...@polytechnique.org> wrote:
> >>> Hi Ric,
>
> >>> This feature request is quite common, and it's tracked 
> >>> here:https://code.djangoproject.com/ticket/8936
>
> >>> A few people talked to me since I wrote the GSoC project description 
> >>> linked in comment #5, but I don't think anyone is actively working on 
> >>> this.
>
> >>> Since we deprecated databrowse, the problem is much simpler than what I 
> >>> described. It's probably still more complicated than what a patch can 
> >>> handle.
>
> >>> If you want to work on this ticket, I suggest to:
> >>> a) read the contributing guide in the docs (if you haven't yet),
> >>> b) review related discussions on this mailing list, and search for 
> >>> related tickets in Trac,
> >>> c) post a more detailed proposal here,
> >>> d) fork the bitbucket or github mirror and work on your clone,
> >>> e) track your progress by commenting on the ticket or on the mailing list.
>
> >>> Be aware that this isn't an easy ticket — you may prefer to start with 
> >>> smaller issues and tackle this when you're more at ease with our 
> >>> development process.
>
> >>> Best regards,
>
> >>> --
> >>> Aymeric Augustin.
>
> >>> On 16 nov. 2011, at 17:47, Ric wrote:
>
> >>>> i've been thinking about a new django admin feature, that could be
> >>>> backward implemented
>
> >>>> it's about adding a view permission for models
>
> >>>> so we can have
>
> >>>> 1.change_permission
> >>>> 2.delete_permission
> >>>> 3.add_permission
> >>>> and
> >>>> 4.view_permission
>
> >>>> in the changelist_view view_permission allow user to see the
> >>>> changelist, but user still need a change_permission to use the
> >>>> list_editable.
> >>>> in the change_view, having a view_permission allow to see the object,
> >>>> but the method get_read_only_fields returns all the fields.
>
> >>>> in every case a POST request raise a PermissionDenied if the user do
> >>>> not have a change_permission, but allows GET request if user got a
> >>>> view_permission
>
> >>>> view_permission could be added on the next syncdb...
>
> >>>> --
> >>>> 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 
> >>>> athttp://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 
> > athttp://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: add view_permission

[Ric]

at a first look, the big file to patch is django.contrib.admin.options

i need also to add a method to django.db.models.options

def get_view_permission(self):
return 'view_%s' % self.object_name.lower()

so maybe it's better to work only on options.py and make a .diff,
right?

On 16 Nov, 20:43, Ric <riccardodivirgi...@gmail.com> wrote:
> ok i can give a try...
>
> maybe it's difficult, not to much. i have to see inline models, and
> give the right behavior
>
> so from github i can fork django 1.3.1, but actually i'm working with
> the latest version.
>
> should i fork the lastest?
>
> On 16 Nov, 20:21, Aymeric Augustin
>
>
>
>
>
>
>
> <aymeric.augus...@polytechnique.org> wrote:
> > Hi Ric,
>
> > This feature request is quite common, and it's tracked 
> > here:https://code.djangoproject.com/ticket/8936
>
> > A few people talked to me since I wrote the GSoC project description linked 
> > in comment #5, but I don't think anyone is actively working on this.
>
> > Since we deprecated databrowse, the problem is much simpler than what I 
> > described. It's probably still more complicated than what a patch can 
> > handle.
>
> > If you want to work on this ticket, I suggest to:
> > a) read the contributing guide in the docs (if you haven't yet),
> > b) review related discussions on this mailing list, and search for related 
> > tickets in Trac,
> > c) post a more detailed proposal here,
> > d) fork the bitbucket or github mirror and work on your clone,
> > e) track your progress by commenting on the ticket or on the mailing list.
>
> > Be aware that this isn't an easy ticket — you may prefer to start with 
> > smaller issues and tackle this when you're more at ease with our 
> > development process.
>
> > Best regards,
>
> > --
> > Aymeric Augustin.
>
> > On 16 nov. 2011, at 17:47, Ric wrote:
>
> > > i've been thinking about a new django admin feature, that could be
> > > backward implemented
>
> > > it's about adding a view permission for models
>
> > > so we can have
>
> > > 1.change_permission
> > > 2.delete_permission
> > > 3.add_permission
> > > and
> > > 4.view_permission
>
> > > in the changelist_view view_permission allow user to see the
> > > changelist, but user still need a change_permission to use the
> > > list_editable.
> > > in the change_view, having a view_permission allow to see the object,
> > > but the method get_read_only_fields returns all the fields.
>
> > > in every case a POST request raise a PermissionDenied if the user do
> > > not have a change_permission, but allows GET request if user got a
> > > view_permission
>
> > > view_permission could be added on the next syncdb...
>
> > > --
> > > 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 
> > > athttp://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: add view_permission

[Ric]

ok i can give a try...

maybe it's difficult, not to much. i have to see inline models, and
give the right behavior

so from github i can fork django 1.3.1, but actually i'm working with
the latest version.

should i fork the lastest?

On 16 Nov, 20:21, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> Hi Ric,
>
> This feature request is quite common, and it's tracked 
> here:https://code.djangoproject.com/ticket/8936
>
> A few people talked to me since I wrote the GSoC project description linked 
> in comment #5, but I don't think anyone is actively working on this.
>
> Since we deprecated databrowse, the problem is much simpler than what I 
> described. It's probably still more complicated than what a patch can handle.
>
> If you want to work on this ticket, I suggest to:
> a) read the contributing guide in the docs (if you haven't yet),
> b) review related discussions on this mailing list, and search for related 
> tickets in Trac,
> c) post a more detailed proposal here,
> d) fork the bitbucket or github mirror and work on your clone,
> e) track your progress by commenting on the ticket or on the mailing list.
>
> Be aware that this isn't an easy ticket — you may prefer to start with 
> smaller issues and tackle this when you're more at ease with our development 
> process.
>
> Best regards,
>
> --
> Aymeric Augustin.
>
> On 16 nov. 2011, at 17:47, Ric wrote:
>
>
>
>
>
>
>
> > i've been thinking about a new django admin feature, that could be
> > backward implemented
>
> > it's about adding a view permission for models
>
> > so we can have
>
> > 1.change_permission
> > 2.delete_permission
> > 3.add_permission
> > and
> > 4.view_permission
>
> > in the changelist_view view_permission allow user to see the
> > changelist, but user still need a change_permission to use the
> > list_editable.
> > in the change_view, having a view_permission allow to see the object,
> > but the method get_read_only_fields returns all the fields.
>
> > in every case a POST request raise a PermissionDenied if the user do
> > not have a change_permission, but allows GET request if user got a
> > view_permission
>
> > view_permission could be added on the next syncdb...
>
> > --
> > 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 
> > athttp://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: Error in formfield in django.db.models.field

[Ric]

should i have to open a ticket?

On 14 Nov, 23:19, Ric <riccardodivirgi...@gmail.com> wrote:
> form_class is not in kwargs if the method is declared like this
>
> def formfield(self, form_class=forms.CharField, **kwargs):
>
> a possible solution is to use a code like this
>
> def formfield(self, **kwargs):
>     form_class = kwargs.pop("form_class", self.choices and
> forms.TypedChoiceField or forms.CharField)
>
> in that way is no form_class is passed, a default form_class is
> defined (TypedChoiceField or CharField)
>
> On 14 Nov, 21:22, Ric <riccardodivirgi...@gmail.com> wrote:
>
>
>
>
>
>
>
> > yes but definitely not the current code, because i cannot subclass
> > with super
>
> > On 14 Nov, 15:46, ptone <pres...@ptone.com> wrote:
>
> > > On Nov 13, 11:55 pm, Ric <riccardodivirgi...@gmail.com> wrote:
>
> > > > the field class define this code
>
> > > >     def formfield(self, form_class=forms.CharField, **kwargs):
> > > >         """
> > > >         Returns a django.forms.Field instance for this database Field.
> > > >         """
> > > >         defaults = {'required': not self.blank,
> > > >                     'label': capfirst(self.verbose_name),
> > > >                     'help_text': self.help_text}
> > > >         if self.has_default():
> > > >             if callable(self.default):
> > > >                 defaults['initial'] = self.default
> > > >                 defaults['show_hidden_initial'] = True
> > > >             else:
> > > >                 defaults['initial'] = self.get_default()
> > > >         if self.choices:
> > > >             # Fields with choices get special treatment.
> > > >             include_blank = (self.blank or
> > > >                              not (self.has_default() or 'initial' in
> > > > kwargs))
> > > >             defaults['choices'] =
> > > > self.get_choices(include_blank=include_blank)
> > > >             defaults['coerce'] = self.to_python
> > > >             if self.null:
> > > >                 defaults['empty_value'] = None
> > > >             form_class = forms.TypedChoiceField
> > > >             # Many of the subclass-specific formfield arguments
> > > > (min_value,
> > > >             # max_value) don't apply for choice fields, so be sure to
> > > > only pass
> > > >             # the values that TypedChoiceField will understand.
> > > >             for k in kwargs.keys():
> > > >                 if k not in ('coerce', 'empty_value', 'choices',
> > > > 'required',
> > > >                              'widget', 'label', 'initial',
> > > > 'help_text',
> > > >                              'error_messages', 'show_hidden_initial'):
> > > >                     del kwargs[k]
> > > >         defaults.update(kwargs)
> > > >         return form_class(**defaults)
>
> > > > this code says
> > > > if self.choices:
> > > >     form_class = forms.TypedChoiceField
>
> > > > this means that if you have a field that got choices, even if you pass
> > > > during the super an argument different than forms.TypedChoiceField,
> > > > you'll always get forms.TypedChoiceField
>
> > > > must be defaults["form_class"] = forms.TypedChoiceField
>
> > > do you mean something like:
>
> > > if self.choices:
> > >     if 'form_class' in defaults:
> > >         form_class = defaults['form_class']
> > >     else:
> > >         form_class = forms.TypedChoiceField
>
> > > -Preston
> > > form_class =

-- 
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: add view_permission

[Ric]

yes i would use it too, because i've got a lot of models with a view
permission to the final user but with no change permission.

it could be archived with backward compatibility, because by default a
user has got no view permission
view permission can be added with a syncdb, and user must add them
from the admin panel

don't see backward issue, it would be a nice feature.

On 16 Nov, 19:47, Bradley Ayers <bradley.ay...@gmail.com> wrote:
> I would benefit from this. With administration systems I build with Django I 
> generally have to add my own 'view_foo' permission to each model. +1
>
> On 17/11/2011, at 2:47 AM, Ric wrote:
>
>
>
>
>
>
>
> > i've been thinking about a new django admin feature, that could be
> > backward implemented
>
> > it's about adding a view permission for models
>
> > so we can have
>
> > 1.change_permission
> > 2.delete_permission
> > 3.add_permission
> > and
> > 4.view_permission
>
> > in the changelist_view view_permission allow user to see the
> > changelist, but user still need a change_permission to use the
> > list_editable.
> > in the change_view, having a view_permission allow to see the object,
> > but the method get_read_only_fields returns all the fields.
>
> > in every case a POST request raise a PermissionDenied if the user do
> > not have a change_permission, but allows GET request if user got a
> > view_permission
>
> > view_permission could be added on the next syncdb...
>
> > --
> > 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 
> > athttp://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.

add view_permission

[Ric]

i've been thinking about a new django admin feature, that could be
backward implemented

it's about adding a view permission for models

so we can have

1.change_permission
2.delete_permission
3.add_permission
and
4.view_permission

in the changelist_view view_permission allow user to see the
changelist, but user still need a change_permission to use the
list_editable.
in the change_view, having a view_permission allow to see the object,
but the method get_read_only_fields returns all the fields.

in every case a POST request raise a PermissionDenied if the user do
not have a change_permission, but allows GET request if user got a
view_permission

view_permission could be added on the next syncdb...

-- 
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: mark_safe(media) in django admin

[Ric]

i've created a ticket
https://code.djangoproject.com/ticket/17239

sorry but i'm new, i'would like to contribute.

let me know if it's fine.

On 15 Nov, 07:02, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> On 14 nov. 2011, at 23:15, Ric wrote:
>
> > a minor bug in django admin.
>
> Could you open a ticket in our bug tracker?
>
> https://code.djangoproject.com/newticket
>
> Thanks,
>
> --
> Aymeric Augustin.

-- 
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: Error in formfield in django.db.models.field

[Ric]

form_class is not in kwargs if the method is declared like this

def formfield(self, form_class=forms.CharField, **kwargs):

a possible solution is to use a code like this

def formfield(self, **kwargs):
form_class = kwargs.pop("form_class", self.choices and
forms.TypedChoiceField or forms.CharField)

in that way is no form_class is passed, a default form_class is
defined (TypedChoiceField or CharField)

On 14 Nov, 21:22, Ric <riccardodivirgi...@gmail.com> wrote:
> yes but definitely not the current code, because i cannot subclass
> with super
>
> On 14 Nov, 15:46, ptone <pres...@ptone.com> wrote:
>
>
>
>
>
>
>
> > On Nov 13, 11:55 pm, Ric <riccardodivirgi...@gmail.com> wrote:
>
> > > the field class define this code
>
> > >     def formfield(self, form_class=forms.CharField, **kwargs):
> > >         """
> > >         Returns a django.forms.Field instance for this database Field.
> > >         """
> > >         defaults = {'required': not self.blank,
> > >                     'label': capfirst(self.verbose_name),
> > >                     'help_text': self.help_text}
> > >         if self.has_default():
> > >             if callable(self.default):
> > >                 defaults['initial'] = self.default
> > >                 defaults['show_hidden_initial'] = True
> > >             else:
> > >                 defaults['initial'] = self.get_default()
> > >         if self.choices:
> > >             # Fields with choices get special treatment.
> > >             include_blank = (self.blank or
> > >                              not (self.has_default() or 'initial' in
> > > kwargs))
> > >             defaults['choices'] =
> > > self.get_choices(include_blank=include_blank)
> > >             defaults['coerce'] = self.to_python
> > >             if self.null:
> > >                 defaults['empty_value'] = None
> > >             form_class = forms.TypedChoiceField
> > >             # Many of the subclass-specific formfield arguments
> > > (min_value,
> > >             # max_value) don't apply for choice fields, so be sure to
> > > only pass
> > >             # the values that TypedChoiceField will understand.
> > >             for k in kwargs.keys():
> > >                 if k not in ('coerce', 'empty_value', 'choices',
> > > 'required',
> > >                              'widget', 'label', 'initial',
> > > 'help_text',
> > >                              'error_messages', 'show_hidden_initial'):
> > >                     del kwargs[k]
> > >         defaults.update(kwargs)
> > >         return form_class(**defaults)
>
> > > this code says
> > > if self.choices:
> > >     form_class = forms.TypedChoiceField
>
> > > this means that if you have a field that got choices, even if you pass
> > > during the super an argument different than forms.TypedChoiceField,
> > > you'll always get forms.TypedChoiceField
>
> > > must be defaults["form_class"] = forms.TypedChoiceField
>
> > do you mean something like:
>
> > if self.choices:
> >     if 'form_class' in defaults:
> >         form_class = defaults['form_class']
> >     else:
> >         form_class = forms.TypedChoiceField
>
> > -Preston
> > form_class =

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

mark_safe(media) in django admin

[Ric]

a minor bug in django admin.
in django.contrib.admin.options mark_safe is called to render media.

in add_view and change_view we can find mark_safe(media)

in changelist_view media is injected as an object (without mark_safe)

i propose to pass the media object to the template (without
mark_safe), because i use a context_processor that adds media.

so i check in the context if there is 'media' key, and then merge my
own list of javascript and css with the existing django media.

but i cannot do this if the media object is rendered before it is
passed to the context processor.

-- 
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: Error in formfield in django.db.models.field

[Ric]

yes but definitely not the current code, because i cannot subclass
with super

On 14 Nov, 15:46, ptone <pres...@ptone.com> wrote:
> On Nov 13, 11:55 pm, Ric <riccardodivirgi...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > the field class define this code
>
> >     def formfield(self, form_class=forms.CharField, **kwargs):
> >         """
> >         Returns a django.forms.Field instance for this database Field.
> >         """
> >         defaults = {'required': not self.blank,
> >                     'label': capfirst(self.verbose_name),
> >                     'help_text': self.help_text}
> >         if self.has_default():
> >             if callable(self.default):
> >                 defaults['initial'] = self.default
> >                 defaults['show_hidden_initial'] = True
> >             else:
> >                 defaults['initial'] = self.get_default()
> >         if self.choices:
> >             # Fields with choices get special treatment.
> >             include_blank = (self.blank or
> >                              not (self.has_default() or 'initial' in
> > kwargs))
> >             defaults['choices'] =
> > self.get_choices(include_blank=include_blank)
> >             defaults['coerce'] = self.to_python
> >             if self.null:
> >                 defaults['empty_value'] = None
> >             form_class = forms.TypedChoiceField
> >             # Many of the subclass-specific formfield arguments
> > (min_value,
> >             # max_value) don't apply for choice fields, so be sure to
> > only pass
> >             # the values that TypedChoiceField will understand.
> >             for k in kwargs.keys():
> >                 if k not in ('coerce', 'empty_value', 'choices',
> > 'required',
> >                              'widget', 'label', 'initial',
> > 'help_text',
> >                              'error_messages', 'show_hidden_initial'):
> >                     del kwargs[k]
> >         defaults.update(kwargs)
> >         return form_class(**defaults)
>
> > this code says
> > if self.choices:
> >     form_class = forms.TypedChoiceField
>
> > this means that if you have a field that got choices, even if you pass
> > during the super an argument different than forms.TypedChoiceField,
> > you'll always get forms.TypedChoiceField
>
> > must be defaults["form_class"] = forms.TypedChoiceField
>
> do you mean something like:
>
> if self.choices:
>     if 'form_class' in defaults:
>         form_class = defaults['form_class']
>     else:
>         form_class = forms.TypedChoiceField
>
> -Preston
> form_class =

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

Error in formfield in django.db.models.field

[Ric]

the field class define this code

def formfield(self, form_class=forms.CharField, **kwargs):
"""
Returns a django.forms.Field instance for this database Field.
"""
defaults = {'required': not self.blank,
'label': capfirst(self.verbose_name),
'help_text': self.help_text}
if self.has_default():
if callable(self.default):
defaults['initial'] = self.default
defaults['show_hidden_initial'] = True
else:
defaults['initial'] = self.get_default()
if self.choices:
# Fields with choices get special treatment.
include_blank = (self.blank or
 not (self.has_default() or 'initial' in
kwargs))
defaults['choices'] =
self.get_choices(include_blank=include_blank)
defaults['coerce'] = self.to_python
if self.null:
defaults['empty_value'] = None
form_class = forms.TypedChoiceField
# Many of the subclass-specific formfield arguments
(min_value,
# max_value) don't apply for choice fields, so be sure to
only pass
# the values that TypedChoiceField will understand.
for k in kwargs.keys():
if k not in ('coerce', 'empty_value', 'choices',
'required',
 'widget', 'label', 'initial',
'help_text',
 'error_messages', 'show_hidden_initial'):
del kwargs[k]
defaults.update(kwargs)
return form_class(**defaults)


this code says
if self.choices:
form_class = forms.TypedChoiceField

this means that if you have a field that got choices, even if you pass
during the super an argument different than forms.TypedChoiceField,
you'll always get forms.TypedChoiceField

must be defaults["form_class"] = forms.TypedChoiceField

-- 
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: Attach a technincal html response to email on server error

[Ric]

yes of course i've read it in the documentation... i'v snv the code
right now!
sorry, i missed it.

On 13 Nov, 15:03, Benjamin Wohlwend <piquad...@gmail.com> wrote:
> Hi Riccardo,
>
> On Sun, Nov 13, 2011 at 2:51 PM, Ric <riccardodivirgi...@gmail.com> wrote:
>
> > and what about create a model, save the traceback in the db, and
> > reopen it from the admin?
>
> You should have a look at Sentry[1]. It does exactly what you want,
> and much more. Easily one of the best tools to monitor errors of your
> webapp.
>
> [1]:http://sentry.readthedocs.org/en/latest/index.html

-- 
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: Attach a technincal html response to email on server error

[Ric]

oh fantastic... but i read about security issue...

and what about create a model, save the traceback in the db, and
reopen it from the admin?

On 12 Nov, 03:39, Karen Tracey <kmtra...@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 9:35 PM, Ric <riccardodivirgi...@gmail.com> wrote:
> > yeah i know it can be done...
>
> > i can try to write it in future... it can be a subclass of something,
> > i have to open the code.
>
> You don't have to write anything, you just have to set include_html=True in
> the config for the Django-provided admin email handler. See:
>
> https://docs.djangoproject.com/en/1.3/topics/logging/#django.utils.lo...
>
> Karen

-- 
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: Attach a technincal html response to email on server error

[Ric]

yeah i know it can be done...

i can try to write it in future... it can be a subclass of something,
i have to open the code.

could be an interesting contribute?

-- 
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: Attach a technincal html response to email on server error

[Ric]

not a lot of javascript, really. just a script to expand the local
vars...
but make a an alternative content it's not easy.

attach the html response it's pretty easy, maybe just a few line of
code and some import

-- 
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: Attach a technincal html response to email on server error

[Ric]

i don't think so...

the debug response have got a lot of javascript... and a lot of email
client (gmail, outlook) escape javascript and could brake some
functionality of the web page... the safest way, in my opinion, is to
leave the content of email as plain text and to attach the html file
to the mail.

in that way you gat a plain text version and a rich version as
attachment that can be opened with any browser.

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

Attach a technincal html response to email on server error

[Ric]

hi, i receive django email on 500 error.

with that kind of mail is difficult to debug, because i don't have a
lot of informations.

it's much more simple to debug when i set DEBUG = True and i receive
an html technical response.
with that response i can read a lot of informations (like vars,
request information, server settings and so on)

my idea is to attach an html file, that is the very same response you
got on error with DEBUG = True.

this response has got no external dependencies (css and js are inline
in the html), so it can be attached as a file in the email that is
sended on server error.

this is very simple to archieve, and developers can open it with the
browser and see a lot of information.

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

[Ric]

i'm reading other post on this forum
django use pickle to store non relational data with session...

-- 
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: TemplateResponse and loader should handle request

[Ric]

maybe even a simple request.template_folders could do the job...
but it would work only with the new templateresponse class...

On 10 Nov, 21:23, Ric <riccardodivirgi...@gmail.com> wrote:
> i agree with nan, it would be a nice feature.
>
> On 10 Nov, 21:12, Ric <riccardodivirgi...@gmail.com> wrote:
>
>
>
>
>
>
>
> > > If you're using class-based views, override get_templates to provide the 
> > > right templates for the request.
>
> > i would like a django-wide feature, to customize admin folder and
> > third party app.

-- 
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: TemplateResponse and loader should handle request

[Ric]

i agree with nan, it would be a nice feature.

On 10 Nov, 21:12, Ric <riccardodivirgi...@gmail.com> wrote:
> > If you're using class-based views, override get_templates to provide the 
> > right templates for the request.
>
> i would like a django-wide feature, to customize admin folder and
> third party app.

-- 
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: TemplateResponse and loader should handle request

[Ric]

> If you're using class-based views, override get_templates to provide the 
> right templates for the request.

i would like a django-wide feature, to customize admin folder and
third party app.

-- 
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: TemplateResponse and loader should handle request

[Ric]

the first thing i have thought was that "loader shouldn't care about
the request"

but, request could be an optional argument, that can be none, with
this simple thing i can create a custom template loader, and add
whatever folder i want, based on request.

it's a way to customize a Site. i manage different site and i would
like to have a different template folder for each site, template
folder that can be different even for country or language, a lot of
things that can be extracted from request.

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

[Ric]

it was just an idea, Russel... maybe too hard to accomplish in the
right way.

i can use json field in my trunk and that's good for me.

i thought maybe, with validators, django could be be able to
accomplish some of the features of a non relational data store,
without messing up with low lowel database api, and use the powerful
model and queryset django api.

forget about it.

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

[Ric]

django could archive to manage non-relational data on relational db.

i don't want to use a non relational db, because i need foreign key
and i need non relational data.

read the couchdb guide, i think that you can find inspiration to
create powerful things.
i think that some ability of non relational data store can be archived
on any datastore, with a framework.

validation of non relational data and creation of indexes
we can validate data on save, and we can create index of non
relational data on save.

that is just my opinion, but maybe i'm not a programmer, i'm just an
hacker!

On 10 Nov, 20:20, Ric <riccardodivirgi...@gmail.com> wrote:
> that is just a proposition, i know that if you need a non relation db
> the best thing to do is to have a non relational data store.
>
> but you need a relational data store only if you need to query non
> relational data, in the other cases you can use a relational db,
> because relational db got foreign keys, a things that rocks!
>
> i need to handle documents (real documents, paper), and what i have
> done is to store cleaned_data inside a model and give to that a
> number.
>
> i need to do a lot of different documents (iso 9000 sheet, ddt,
> invoices, quotations), and i don't need to query non relational data
> that are inside (not all of them, of course).
>
> what i need, instead, is to have some common field for all my document
> (document date, document number, document prefix, document owner, and
> maybe a content type field) to query and order them, and store them in
> an unique db table.
>
> that kind of schema is better than a non relational database, because
> i can use foreign keys and index for fast query the things i need to
> query, and create different kind of classes to handle different kind
> of documents.
>
> to archive that kind of job, a json field is great. and i dont't whink
> i'm the only django user that needs stuff like that (business staff).
>
> sometimes you might need to save raw html inside db, and sometimes you
> may need to store raw json to db.
>
> that's all.
>
> On 8 Nov, 19:47, diogobaeder <diogobae...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi, guys,
>
> > I agree that we should use the right tool for the job; But even a
> > relational database can be used for semi-structured data when it's not
> > going to be directly queried. Matter of fact, there's even a design
> > pattern recognized for 
> > that:http://martinfowler.com/eaaCatalog/serializedLOB.html
>
> > Example of use: think of a semi-structured data store (in a relational
> > database) that is going to be read through a search engine (think
> > about ElasticSearch of Solr, here).
>
> > But yes, if you're going to need to query for this data by parts of
> > the JSON field, then you're shooting your own foot. So, in the end, we
> > have to think a lot about what's the problem we're trying to solve -
> > it's not as simple as "don't use RDBMS for non-relational data" -,
> > IMHO.
>
> > Well, at least here's my 2 cents.
>
> > Cheers,
>
> > Diogo
>
> > On 8 nov, 08:34, Tom Evans <tevans...@googlemail.com> wrote:
>
> > > On Mon, Nov 7, 2011 at 11:48 PM, Torsten Bronger
>
> > > <bron...@physik.rwth-aachen.de> wrote:
>
> > > > While I appreciate that Django core is supposed to enforce good
> > > > design practices, one must be careful with that if some practice may
> > > > have valid use cases.  You cannot prevent the user from shooting in
> > > > the foot anyway.
>
> > > > While we make extensive use of the relational model in our project,
> > > > I remembered to have a couple of JSON fields (though we don't have a
> > > > field class them them so far), so I skimmed through our code to see
> > > > why we did this.
>
> > > And so do I - the main point here is that we have both successfully
> > > loaded the gun and aimed it at our foot without this field existing in
> > > core. I think it's important to have that distinction between things
> > > you can do and things you should do, in order to make you think
> > > "should I really be doing this".
>
> > > Cheers
>
> > > Tom

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

[Ric]

that is just a proposition, i know that if you need a non relation db
the best thing to do is to have a non relational data store.

but you need a relational data store only if you need to query non
relational data, in the other cases you can use a relational db,
because relational db got foreign keys, a things that rocks!

i need to handle documents (real documents, paper), and what i have
done is to store cleaned_data inside a model and give to that a
number.

i need to do a lot of different documents (iso 9000 sheet, ddt,
invoices, quotations), and i don't need to query non relational data
that are inside (not all of them, of course).

what i need, instead, is to have some common field for all my document
(document date, document number, document prefix, document owner, and
maybe a content type field) to query and order them, and store them in
an unique db table.

that kind of schema is better than a non relational database, because
i can use foreign keys and index for fast query the things i need to
query, and create different kind of classes to handle different kind
of documents.

to archive that kind of job, a json field is great. and i dont't whink
i'm the only django user that needs stuff like that (business staff).

sometimes you might need to save raw html inside db, and sometimes you
may need to store raw json to db.

that's all.

On 8 Nov, 19:47, diogobaeder  wrote:
> Hi, guys,
>
> I agree that we should use the right tool for the job; But even a
> relational database can be used for semi-structured data when it's not
> going to be directly queried. Matter of fact, there's even a design
> pattern recognized for 
> that:http://martinfowler.com/eaaCatalog/serializedLOB.html
>
> Example of use: think of a semi-structured data store (in a relational
> database) that is going to be read through a search engine (think
> about ElasticSearch of Solr, here).
>
> But yes, if you're going to need to query for this data by parts of
> the JSON field, then you're shooting your own foot. So, in the end, we
> have to think a lot about what's the problem we're trying to solve -
> it's not as simple as "don't use RDBMS for non-relational data" -,
> IMHO.
>
> Well, at least here's my 2 cents.
>
> Cheers,
>
> Diogo
>
> On 8 nov, 08:34, Tom Evans  wrote:
>
>
>
>
>
>
>
> > On Mon, Nov 7, 2011 at 11:48 PM, Torsten Bronger
>
> >  wrote:
>
> > > While I appreciate that Django core is supposed to enforce good
> > > design practices, one must be careful with that if some practice may
> > > have valid use cases.  You cannot prevent the user from shooting in
> > > the foot anyway.
>
> > > While we make extensive use of the relational model in our project,
> > > I remembered to have a couple of JSON fields (though we don't have a
> > > field class them them so far), so I skimmed through our code to see
> > > why we did this.
>
> > And so do I - the main point here is that we have both successfully
> > loaded the gun and aimed it at our foot without this field existing in
> > core. I think it's important to have that distinction between things
> > you can do and things you should do, in order to make you think
> > "should I really be doing this".
>
> > Cheers
>
> > Tom

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

[Ric]

you say "is rarely a good idea", and that it is the only thing true.

when, like my app, you need to handle document, real documents (like
invoice, ddt, quotations) and other stuffs, it's a good practice to
keep all in one table, separating only the things that you need to
query, and leave a non relational field to handle evreything else.

read http://guide.couchdb.org/ there are a lot of ideas that are
simply brillant.

one of this is the validation of the non relational data, and django
has got a fantastic framework to validate data, so it would be grat to
implement a custom non relational field that can be validated, and
it's stored in one place, because for some applications the best
design practice is to put all the data in one place, because the date
is simply non relational.

django should be able to handle this kind of situation, and please
don't be arrogant.

you don't like non relational data, but non relational db are growing,
and maybe there is a reason.

the reason is that relational data not always is the best answer.

non relational data it's a tool, and in some situation it's the best
practice.

for me the first step it's to create a JsonField, than we can use
validators to let the developers validate non relational data.

On 7 Nov, 12:45, Tom Evans <tevans...@googlemail.com> wrote:
> On Sat, Nov 5, 2011 at 11:48 AM, Ric <riccardodivirgi...@gmail.com> wrote:
> > this is my proposition to have custom data inside a model field
>
> > a json data field, the code is simple as this, and it works with
> > lastest django release
>
> The problem with something like this is that it is rarely a good idea
> to stick opaque data into the database that cannot then be queried
> upon. You may have a very good reason for doing this, but most of the
> time that it happens it ends up being a bad design choice.
>
> Adding this to core would suggest that bad design choices are a-ok in
> Django, which is why I expect many people are -0/-1 on this. If I had
> a vote, I'd be -1.
>
> Cheers
>
> Tom

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

[Ric]

it's a good code.

you wrote:
# TODO: Look for date/time/datetime objects within the structure?

and there is no need, because it's handled by djangojsonencoder

On 7 Nov, 07:06, schinckel  wrote:
> I'm doing just this in several cases: I packaged up a JSONField into a
> re-usable
> application:https://bitbucket.org/schinckel/django-jsonfield/overview

-- 
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: I want to pass the Exception info from Http404 to handler404 view and consequently the 404.html

[Ric]

for me a simple solution to this is issue, is that django should be
able to recognize an HttpResponse as error and return it

like:

raise HttpResponseRedirect(url)
or
raise HttpResponse(render_to_template("errors/user_not_logged"),
context = RequestContext(context), status_code = 401)

with this approch a view can raise an HttpResponse and interrupt the
view process

django should simply check if the exception is an HttpResponse class
and simply returns it.

with the new TemplateResponse, everything is made mode customizable,
because the TemplateResponse should implement a render method that
checks is settings.DEBUG is true and then return a technical response,
or return template response.

On 31 Ott, 08:08, Mateusz Marzantowicz 
wrote:
> On Sun, Oct 30, 2011 at 8:38 PM, Kiril  wrote:
> > Hello guys,
>
> > in the past few months I have been developing a simple web site using
> > Django. I found Django amazing and mature framework for my needs. I am
> > now about to publish it in public hosting.
>
> > To my dismay the erro info I have included in Http404 calls is wasted
> > by Django and cannot make it's way ot the handler404 and consequently
> > to the 404.html template.
>
> > Here is example code from my views.py:
>
> >    #is user logged in
> >  if not request.user.is_authenticated():
> >    raise Http404(_("It is not allowed to post anonymous comments"))
>
> > Now I want to display the localized message in the 404.html but it
> > seems this does not make it to the handler404 view.
>
> > Here is what I found in the Django sources -
> > django.core.handlers.base.get_response:
>
> >            except http.Http404, e:
> >                logger.warning('Not Found: %s' % request.path,
> >                            extra={
> >                                'status_code': 404,
> >                                'request': request
> >                            })
> >                if settings.DEBUG:
> >                    from django.views import debug
> >                    response = debug.technical_404_response(request,
> > e)
> >                else:
> >                    try:
> >                        callback, param_dict = resolver.resolve404()
> >                        response = callback(request, **param_dict)
> >                    except:
>
> > As can be clealry seen the exception "e" is only passed ot the DEBUG
> > handler but no to the production one "callback".
>
> > My feature request is to add keyword argument param_dict "exception"
> > with the value of the Http404 exception "e" that is passed over to the
> > handler404 code. I can make this fix in my local deployment but it is
> > not possible to edit my hodting provider Django instance.
>
> > This will help communicate the details of the 404 errors to end users.
> > Same could be applied few lines below in the handler for
> > exceptions.PermissionDenied.
>
> > I hope this resonates with the development concepts of Django and this
> > small fix can make its way in to follow on release.
>
> > -Kiril K
>
> But why you return HTTP 404 (Not found) error in case your user is not
> authenticated? Not found errors are designed to handle situations where
> document or page is not present on the server. It has nothing to do with
> user authentication.
>
> Please also see:https://docs.djangoproject.com/en/dev/topics/auth/for
> django and authentication usage patterns.
>
> Also note that one line below that block you've cited is code path for
> handling PermissionDenied exception.
>
> 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.

TemplateResponse and loader should handle request

[Ric]

request.url_conf has been added with django 1.3.

in my opinion, the loader object should handle the request, so that
can be sublassed to pass different template folder based on request
params.

i need this feature for my app, is it possible to have different
template folder based on request params with the current django
release?

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

[Ric]

i'm posting this comment into the ticket.

On 6 Nov, 20:14, Ric <riccardodivirgi...@gmail.com> wrote:
> i'm watching the ticket right now.
> maybe there is no need to to create a class
> JSONDateEncoder(json.JSONEncoder) because there is DjangoJSONEncoder
> already.
> then it would be great to implement a lazy translation object for
> DjangoJSONEncoder to store ugettext_lazy objects.
>
> for me there is no need to create set_%s_json and get_%s_json method
> because the field should handle it directly, and we should use the
> to_python method, like all other fields in django.
>
> for example the datetime field directly push a datetime object to the
> model (using to_python) and transform it to a string when we call save
> method.
>
> we should use the same logic here and encode a json object to string
> only when we call the save method, no need for a get_%s_json in the
> field api.
>
> On 6 Nov, 01:36, Russell Keith-Magee <russ...@keith-magee.com> wrote:
>
>
>
>
>
>
>
> > On Sat, Nov 5, 2011 at 7:48 PM, Ric <riccardodivirgi...@gmail.com> wrote:
> > > this is my proposition to have custom data inside a model field
>
> > > a json data field, the code is simple as this, and it works with
> > > lastest django release
>
> > See #12990 -- this is a ticket that has requested exactly this feature.
>
> > You'll also see that with one exception, the core team have all been
> > -1 or -0 on this idea.
>
> > Yours,
> > Russ Magee %-)

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

[Ric]

i'm watching the ticket right now.
maybe there is no need to to create a class
JSONDateEncoder(json.JSONEncoder) because there is DjangoJSONEncoder
already.
then it would be great to implement a lazy translation object for
DjangoJSONEncoder to store ugettext_lazy objects.

for me there is no need to create set_%s_json and get_%s_json method
because the field should handle it directly, and we should use the
to_python method, like all other fields in django.

for example the datetime field directly push a datetime object to the
model (using to_python) and transform it to a string when we call save
method.

we should use the same logic here and encode a json object to string
only when we call the save method, no need for a get_%s_json in the
field api.

On 6 Nov, 01:36, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> On Sat, Nov 5, 2011 at 7:48 PM, Ric <riccardodivirgi...@gmail.com> wrote:
> > this is my proposition to have custom data inside a model field
>
> > a json data field, the code is simple as this, and it works with
> > lastest django release
>
> See #12990 -- this is a ticket that has requested exactly this feature.
>
> You'll also see that with one exception, the core team have all been
> -1 or -0 on this idea.
>
> Yours,
> Russ Magee %-)

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

JsonField

[Ric]

this is my proposition to have custom data inside a model field

a json data field, the code is simple as this, and it works with
lastest django release

from django.db import models
from django.core.serializers.json import simplejson, DjangoJSONEncoder
import StringIO

class JsonField(models.Field):
__metaclass__ = models.SubfieldBase

serialize_to_string = True

def get_internal_type(self):
return "TextField"

def value_to_string(self, obj):
return self.get_prep_value(self._get_val_from_obj(obj))

def get_prep_value(self, value):
if value:
stream = StringIO.StringIO()
simplejson.dump(value, stream, cls=DjangoJSONEncoder)
value = stream.getvalue()
stream.close()
return value
return None

def to_python(self, value):
if isinstance(value, (str, unicode)):
value = StringIO.StringIO(value)
return simplejson.load(value)
return value

you can set a standard json object as data for a field, and the field
encode this as a json object when you save the model

example

obj.shopping_list = {"fruit":["apple", "banana"]}

it is also possibile to pass an ugettext_lazy object inside the
encoder, if we put a method to encode/decode lazy objects inside
DjangoJSONEncoder

-- 
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 admin feature: Delete and replace with existing object

[Ric]

hi russ i have been on a wedding!

ok, now i see the point.

but what i was tring to say is that adding a simple version of this
feature would be a plus to the actual version of django, with hooks it
would be a great plus.

i think that definition of public API is something that should be done
after implementing this feature.

we'll see how django comunity will react to such feature and then
we'll project hooks based on feedbacks and suggestions.

so i propose to develep this feature in two step:
 - add a method, something like pre_deletion_cleanup(request, object,
deleted_object)
   this must return the deleted_objects var

 - add hooks and document them. hooks will be triggered inside this
function

take in mind one thing:

one hook of that kind, in not so easy to implement for some django
design principles.

1.
in the template admin/delete_confirmation.html the deleted_objects as
rendered in this way

{{ deleted_objects|unordered_list }}

so it is not easy to mantain this template, we should add two list of
objects: a deleted object list and a replaced object list.

2.
adding such a hook needs to write a differente admin_log, adding a
note on what has been replaced.




my proposal :

 for now we could add some one simple hook: defining a new var inside
the admin class,
something like on_delete_replace = True, that allows this feature.

then we add a method inside the admin_class, this method wille takes
those objects:
pre_deletion_cleanup(request, object, deleted_objects)

it takes a form (with another subclassable method) and cycle throught
objects to replace Fk and ManyTomanyFields.

inside the template two simple change
1.
{% if deleting %} All of the following related items will be deleted:
{% else %} All of the following related items will be replaced with
"{{ replace_object_name }}":{% endif %}
2.
form rendering


what do you think? am i missing something?

how can i do such a prototype? i mean, how i propose to django
comunity such a prototype?

thanks



On Jul 10, 8:27 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Fri, Jul 9, 2010 at 10:37 PM, Ric <riccardodivirgi...@gmail.com> wrote:
> > i'll reply one by one
>
> >  * What if you have multiple models referring to Author? Do you
> > assume
> > that every related model will be updated the same way?
>
> >  * What if you have multiple foreign keys from Blog to Author? Do you
> > assume that every foreign key on a single model will be updated in
> > the
> > same way?
>
> > i dont' think this is an issue, we do not need to reinvent the wheel.
> > django uses get_deleted_objects to retrieve all related objects
>
> > (deleted_objects, perms_needed) = get_deleted_objects((obj,), opts,
> > request.user, self.admin_site)
>
> > we can use this feature, and then do a function that cycle and update,
> > or for a more efficient alghoritm we can use a queryset update.
>
> > but maybe it's better to call method save on every single object
> > beacause the save method could be customized.
>
> >  * What if you use admin actions to delete N authors? Do we assume
> > that every one of the authors will be replaced with the same single
> > substitute?
>
> > I think yes, beacuse as you said before, a mutiple user choose would
> > be not so user friendly.
>
> > but we can define an attr, something like
> > admin.ModelAdmin.replace_multiple_objects = True
> > if True, for every object will be created a replacer field... but i
> > think this is difficult to archive, and not so smart...
>
> > I think that this behaviour is indipendent from the model. and i don't
> > think there are different interpretations of this feature.
>
> > let me explain:
> > you are going to delete an object.
> > django is saying to you: "in order to preserve database integrity, i
> > have to delete all this object."
>
> > do you want to delete them or you want to substitute with another one?
>
> I understand this. What you seem to be missing is that in the general
> case, there isn't a single, canonical answer that will *always* be
> correct.
>
> If you are deleting 1 object, there are O(N*M) objects that need to be
> updated, where N is the number of models X that have a relation to the
> object being deleted, and M is the number of instances of X that have
> a relation to the object being deleted.
>
> As an example: I have an Author, Article and Address record. Article
> and Address both have a FK on Author. If I delete Author "John", I
> need to do something to any Article and Address record that points at
> John. In my business logic, I want to update all Articles to point at
> a dummy author, but I want to cascade delete all the Address records.
>
> To 

Re: New admin feature: Delete and replace with existing object

[Ric]

i'll reply one by one

 * What if you have multiple models referring to Author? Do you
assume
that every related model will be updated the same way?

 * What if you have multiple foreign keys from Blog to Author? Do you
assume that every foreign key on a single model will be updated in
the
same way?

i dont' think this is an issue, we do not need to reinvent the wheel.
django uses get_deleted_objects to retrieve all related objects

(deleted_objects, perms_needed) = get_deleted_objects((obj,), opts,
request.user, self.admin_site)

we can use this feature, and then do a function that cycle and update,
or for a more efficient alghoritm we can use a queryset update.

but maybe it's better to call method save on every single object
beacause the save method could be customized.

 * What if you use admin actions to delete N authors? Do we assume
that every one of the authors will be replaced with the same single
substitute?

I think yes, beacuse as you said before, a mutiple user choose would
be not so user friendly.

but we can define an attr, something like
admin.ModelAdmin.replace_multiple_objects = True
if True, for every object will be created a replacer field... but i
think this is difficult to archive, and not so smart...


I think that this behaviour is indipendent from the model. and i don't
think there are different interpretations of this feature.

let me explain:
you are going to delete an object.
django is saying to you: "in order to preserve database integrity, i
have to delete all this object."

do you want to delete them or you want to substitute with another one?

replacing the object anywhere in the db keeps the database integrity
safe.


i don't see  many hooks here...
what kind of hooks do you have in mind? like define a list of models
in the admin class that will be substituted?


---
i also realized that we can handle this with a single field

replace = forms.ModelChoiceField(queryset = qs, empty_label =
ugettext("Do not substitute, delete all related objects"))

if no object is selected, django deletes all the related objects,
otherwise it will'substitute them.

thanks Russ, but how to involve more people in this discussion, and
take the discussion to a next step?


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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 admin feature: Delete and replace with existing object

[Ric]

i took this idea from wordpress. in wordpress when you delete an user
instead of deleting all related posts you can choose to assign them to
another user.

we can extend this system on every model class, i think.

whatch here, sorry wordpress is in italian (hope u understand a
little)
http://grab.by/5kn6

we can use a radio field to choose the mode (or we can choose the mode
with a GET param, or with two different urls  ^delete/ and
^substitute/), and then a combobox to select the instance...

not too difficult, and it would be a fancy feature.

On Jul 7, 3:20 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Wed, Jul 7, 2010 at 3:41 PM, Ric <riccardodivirgi...@gmail.com> wrote:
> > Hello i opened a ticket, but somone suggest me to discuss this new
> > feature here.
>
> >http://code.djangoproject.com/ticket/13900
> > 
> > i would like to edit
> > django.contrib.admin.options.ModelAdmin?.delete_view and add a helpful
> > feature.
>
> > Instead of deleting all the nested objects, the delete_view could
> > handle 3 options:
>
> > 1. delete all the related objects (current option)
> > 2. where the foreign key to the current instance is nullable, null or
> > delete
>
> These first two options are really a duplicate of ticket #7539; it
> isn't something that should be handled at the admin level, but at the
> model level. The broad ideas behind #7539 are well established; the
> patch just needs to be carried the last few steps to trunk.
>
> > 3. replace all the related objects with an other model instance (we
> > can make a user choose it with a forms.ModelChoiceField?)
> > i really would like to contribute to this feature, because i need to
> > do this in my admin site, but i'm new, so please help me :)
>
> This is an interesting idea. At a raw technical level, introducing a
> 'pre-deletion cleanup' stage for admin deletions shouldn't be too
> difficult -- the current deletion confirmation view provides a
> convenient place in the workflow that could be replaced with a view
> that provides options to nominate how relations should be cleaned up.
>
> However, my concern is whether this could be made a generic
> capability. If this is to become a configurable capability of the
> admin interface, it needs to work with every possible model, not just
> a subset of models. It isn't immediately obvious to me how you could
> specify a relation substitution scheme in a completely generic way.
>
> There's also the issue of how to handle this sort of substitution on a
> bulk delete - if you're deleting a group of 50 objects using an admin
> bulk action or as a result of a cascaded deletion, you don't want to
> be presented with an auto-generated dialog of 50 pulldown/raw_id_admin
> widgets.
>
> I suspect the best course of action for trunk will be to make it
> *possible* to easily introduce a pre-deletion stage, but not actually
> provide that capability as part of core admin functionality (i.e.,
> cleanup and document the mechanism by which you can define a
> pre-delete view, but not actually provide a "cleanup= ('field',
> 'field')" definition on ModelAdmin that automatically turns into a
> pre-configured deletion view.
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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 admin feature: Delete and replace with existing object

[Ric]

Hi Russ, nice to talk with u,

i think that we can focus only on substitute feature,
to archive it we have 2 options:

simply upgrade the current delete_view or make a new view, something
like
url(r'^(.+)/substitute/$',
wrap(self.substitute_view),
name='%s_%s_substitute' % info),


to make it work for every model we need to build form with one
ModelChoiceField.
this field will be initialized with a queryset of the model_admin
(queryset method), and then call the queryset exclude method to remove
from the field the instance/s that will be deleted.

field = forms.ModelChoiceField(queryset =
self.queryset(request).exclude(**{"%s__in" %
self.model._meta.pk.attname: objects_to_delete})

so imagine that we have 10 object

1 Banana
2 Apple
3 Tree
4 ...
10 Stick

we mark for deletion object 1 and 2, in the view the form will make us
choose objects from 3 to 10, the use choose to substitute with object
3 and all Banana and Apple in the database will be replaced with a
Tree, using the queryset update method.

is it clear?



On 7 Lug, 15:20, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> On Wed, Jul 7, 2010 at 3:41 PM, Ric <riccardodivirgi...@gmail.com> wrote:
> > Hello i opened a ticket, but somone suggest me to discuss this new
> > feature here.
>
> >http://code.djangoproject.com/ticket/13900
> > 
> > i would like to edit
> > django.contrib.admin.options.ModelAdmin?.delete_view and add a helpful
> > feature.
>
> > Instead of deleting all the nested objects, the delete_view could
> > handle 3 options:
>
> > 1. delete all the related objects (current option)
> > 2. where the foreign key to the current instance is nullable, null or
> > delete
>
> These first two options are really a duplicate of ticket #7539; it
> isn't something that should be handled at the admin level, but at the
> model level. The broad ideas behind #7539 are well established; the
> patch just needs to be carried the last few steps to trunk.
>
> > 3. replace all the related objects with an other model instance (we
> > can make a user choose it with a forms.ModelChoiceField?)
> > i really would like to contribute to this feature, because i need to
> > do this in my admin site, but i'm new, so please help me :)
>
> This is an interesting idea. At a raw technical level, introducing a
> 'pre-deletion cleanup' stage for admin deletions shouldn't be too
> difficult -- the current deletion confirmation view provides a
> convenient place in the workflow that could be replaced with a view
> that provides options to nominate how relations should be cleaned up.
>
> However, my concern is whether this could be made a generic
> capability. If this is to become a configurable capability of the
> admin interface, it needs to work with every possible model, not just
> a subset of models. It isn't immediately obvious to me how you could
> specify a relation substitution scheme in a completely generic way.
>
> There's also the issue of how to handle this sort of substitution on a
> bulk delete - if you're deleting a group of 50 objects using an admin
> bulk action or as a result of a cascaded deletion, you don't want to
> be presented with an auto-generated dialog of 50 pulldown/raw_id_admin
> widgets.
>
> I suspect the best course of action for trunk will be to make it
> *possible* to easily introduce a pre-deletion stage, but not actually
> provide that capability as part of core admin functionality (i.e.,
> cleanup and document the mechanism by which you can define a
> pre-delete view, but not actually provide a "cleanup= ('field',
> 'field')" definition on ModelAdmin that automatically turns into a
> pre-configured deletion view.
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

New admin feature: Delete and replace with existing object

[Ric]

Hello i opened a ticket, but somone suggest me to discuss this new
feature here.

http://code.djangoproject.com/ticket/13900

i would like to edit
django.contrib.admin.options.ModelAdmin?.delete_view and add a helpful
feature.

Instead of deleting all the nested objects, the delete_view could
handle 3 options:

1. delete all the related objects (current option)
2. where the foreign key to the current instance is nullable, null or
delete
3. replace all the related objects with an other model instance (we
can make a user choose it with a forms.ModelChoiceField?)
i really would like to contribute to this feature, because i need to
do this in my admin site, but i'm new, so please help me :)

bye bye

about me: i'm riccardo di virgilio, i have programmed sprint24.com
with django. i have learn a lot of things and i think i'm ready to
contribute.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.