Re: Problems with DatabaseCreation, table names, and index names

[adball]

On Mar 10, 6:55 pm, Andrew Godwin  wrote:
> Hi all,
>
> I'm posting this here, not as a ticket, as I'm not entirely sure it's
> Django's problem, and so would like some input*.
>
> [Base]DatabaseCreation has a method sql_indexes_for_field, which,
> handily, returns the SQL indexes for a field. Less usefully, both
> PostgreSQL and MySQL have limits on the length of table/index names (63
> and 50 bytes by default, respectively).
>
> Firstly, this means that if you have a very long model (table) name
> (say, 64 characters), Django's syncdb thinks it's not in the database
> (since your database has truncated the table name, and they now don't
> match), and tries to add it every time you run syncdb. This is an issue
> to itself, and should probably have either a more useful error or be
> fixed, although it's not easy to detect this has happened.
>
> Secondly, if you have an indexed field on that same model, or two
> indexed fields with common prefixes on a model with a slightly shorter
> name, the method will happily spit out SQL with index names that are
> identical to the table/other index name when truncated to 63 characters,
> meaning the indices aren't added.
>
> The reason I came across this is because a South user has filed a
> similar bug against South that I traced back to this behaviour (South
> uses sql_indexes_for_field, as it means special GeoDjango indexes get
> created as well). I have, however, replicated the bug with plain syncdb,
> using the following Django model:
>
> class
> VeryLongModelNameThatHappensToBeOverSixtyThreeCharsLongEventually(models.Model):
>
>      my_slightly_less_long_field_name = models.IntegerField(db_index=True)
>      my_slightly_more_long_field_name = models.IntegerField(db_index=True)
>
> The question is, is it even worth fixing? I'm tempted to conclude that
> you're limited to shorter model/field names by your database (or use
> db_table/db_column), but there's also the possibility of that method
> using a much shorter way of generating the names (i.e. using the first
> 40 bytes or so, then appending an 8-byte hash of the rest). I can easily
> write and submit a patch to change the function to use this behaviour -
> we used to do it in South, before I started using the ``creation``
> methods - but it's catering to such a small audience I'm not sure it's
> worth it, and documenting this behaviour might be a better solution.
>

Like this?  It's a bit ugly with the hardcoded 50, but if the database
backends would implement the max_name_length() method in their
DatabaseWrapper classes, it could be made smarter.

Index: django/db/backends/creation.py
===
--- django/db/backends/creation.py  (revision 7107)
+++ django/db/backends/creation.py  (working copy)
@@ -256,8 +256,14 @@
 tablespace_sql = ''
 else:
 tablespace_sql = ''
+
+pristine_index_name = '%s_%s' % (model._meta.db_table,
f.column)
+index_name = pristine_index_name
+if len(pristine_index_name) >= 50:
+index_name = pristine_index_name[:40] +
self._digest(pristine_index_name)
+
 output = [style.SQL_KEYWORD('CREATE INDEX') + ' ' +
-style.SQL_TABLE(qn('%s_%s' % (model._meta.db_table,
f.column))) + ' ' +
+style.SQL_TABLE(qn(index_name)) + ' ' +
 style.SQL_KEYWORD('ON') + ' ' +
 style.SQL_TABLE(qn(model._meta.db_table)) + ' ' +
 "(%s)" % style.SQL_FIELD(qn(f.column)) +


> Andrew
>
> * Providing it doesn't significantly impact fixing of actual Django
> bugs, that affect more than 0.01% of the users.

-- 
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: Process discussion: reboot

[Jeremy Dunck]

On Thu, Apr 22, 2010 at 4:36 PM, Adam Nelson  wrote:
> I guess I'll jump in and start triaging.  What about a ticket like
> this:
>
> http://code.djangoproject.com/ticket/2284
>
> Super-ambiguous.  There are dozens of tickets like this that are
> frozen in time with no way for anybody to know what's going on.  Maybe
> there just needs to be a better way to handle this type of ticket?
>

First, thanks for taking the time to look with triaging in mind.

There may be dozens of tickets like this, but that's a small portion
of 900.  :-)

In any case, yes, very old tickets may be inadvertently fixed or left
open, or they may still be accurate, but have bad patches on them.

In this specific case, I think the current status is captured in
comments 11 through 14 -- that the logic for executing initial SQL
breaks in cases where extended SQL syntax (such as pgsql's DECLARE)
includes quoted text, etc.

You can see the Malcolm objected to the latest patch in 11, and
ScottAnderson objected to it in 13.

Certainly, the patch needs improvement because it doesn't include any
test cases.  Possibly, the patch as-is isn't good for the reasons
Malcolm listed, but it's hard for me to tell without doing my own
testing.  I'd mark patch-needs-improvement.  If you're feeling more
ambitious, I'd suggest coming up with a set of initial SQL files that
exercise the assumptions of the loading code.

If it's helpful, I like this summary of unit testing points:
http://media.pragprog.com/titles/utj/StandaloneSummary.pdf

-- 
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: Process discussion: reboot

[Adam Nelson]

I guess I'll jump in and start triaging.  What about a ticket like
this:

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

Super-ambiguous.  There are dozens of tickets like this that are
frozen in time with no way for anybody to know what's going on.  Maybe
there just needs to be a better way to handle this type of ticket?

Regards,
Adam

On Apr 22, 4:33 pm, Jeremy Dunck  wrote:
> On Thu, Apr 22, 2010 at 3:26 PM, Gabriel Hurley  wrote:
> > On Apr 22, 1:21 pm, Adam Nelson  wrote:
>
> >> 2. Assign all of these tickets to 1.3 and nothing else:
>
> >>http://code.djangoproject.com/query?status=new=assigned...
>
> > A, only 900 tickets to work through for 1.3? Don't go too easy on
> > the core team! ;-)
>
> To be clear, this is why the triage process exists.  We need more
> people to look at tickets, review them for the standards that Django
> has set (good code, test coverage, documentation for any new features)
> and mark them "ready for checkin".
>
> The subset of tickets that achieve "ready for checkin" then take a
> commiter's time for final review and merge.
>
> --
> 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 
> 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-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: Process discussion: reboot

[Jeremy Dunck]

On Thu, Apr 22, 2010 at 3:26 PM, Gabriel Hurley  wrote:
> On Apr 22, 1:21 pm, Adam Nelson  wrote:
>
>> 2. Assign all of these tickets to 1.3 and nothing else:
>>
>> http://code.djangoproject.com/query?status=new=assigned...
>
> A, only 900 tickets to work through for 1.3? Don't go too easy on
> the core team! ;-)

To be clear, this is why the triage process exists.  We need more
people to look at tickets, review them for the standards that Django
has set (good code, test coverage, documentation for any new features)
and mark them "ready for checkin".

The subset of tickets that achieve "ready for checkin" then take a
commiter's time for final review and merge.

-- 
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: Process discussion: reboot

[Gabriel Hurley]

On Apr 22, 1:21 pm, Adam Nelson  wrote:

> 2. Assign all of these tickets to 1.3 and nothing else:
>
> http://code.djangoproject.com/query?status=new=assigned...

A, only 900 tickets to work through for 1.3? Don't go too easy on
the core team! ;-)

All the best,
- Gabriel

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

[Adam Nelson]

After reading through this entire thread it seems that there are a few
points to be consolidated:

1. DVCS concerns should be pushed to 1.4+ and in the meantime, mirrors
are fine.
2. The management of the current Trac system has organizational issues
- i.e. many people don't know who committers are and whether they
should aggressively manage tickets since they have alot of power.
Nonetheless, these are manageable for now.
3. Version 1.3 should be feature-light

I would propose the following:

1. Finish version 1.2
2. Assign all of these tickets to 1.3 and nothing else:

http://code.djangoproject.com/query?status=new=assigned=reopened=_patch=1=priority

These all have a patch and no milestone.

3. Go through all of the newly assigned 'milestone 1.3' tickets and
either close them as wontfix, apply the patch, or move them to a new
milestone called 'Next Major Release'.
4. Release version 1.3
5. Evaluate other stuff like major DVCS changes, Trac changes, etc...

I think this would be the best timeline for the community and is the
best way to maintain a good relationship with the people who have had
patches waiting for over a year.  Marking them as wontfix is fine, as
long as some movement is made.

Cheers,
Adam



On Apr 22, 2:37 am, Thomas Guettler  wrote:
> The plan to make 1.3 a feature light release with focus on
> fixing old bugs and tickets, was a good one.
>
> I have some tickets in trac which are quite old, too. But it has been
> a very long time, since I reviewed tickets of other people, too.
>
> Sometimes I think the development process is slow. But that's wrong.
> The development is just in parts I don't need up to now (for example multi db 
> support).
>
>   Thomas
>
>
>
>
>
> Jacob Kaplan-Moss wrote:
> > Hi folks --
>
> > I'd like to try to reboot the discussion that's been going on about
> > Django's development process.
>
> > I'm finding the current thread incredibly demoralizing: there's a
> > bunch of frustration being expressed, and I hear that, but I'm having
> > trouble finding any concrete suggestions. Instead, the thread has
> > devolved into just going around in circles on the same small handful
> > of issues.
>
> > So: here's your chance. You have suggestions about Django's
> > development process? Make them. I'm listening.
>
> > Jacob
>
> --
> Thomas Guettler,http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
>
> --
> 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 
> 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-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: managing javascript and css resources

[Kevin Howerton]

>Nothing I've seen so far solves, or even addresses the original need for
>_not_ sourcing the same script numerous times (thanks to widgets with
>their own media)

The widget and admin media system needs to be re-evaluated IMO
none of these solutions are going to address the flaws you are
referring to.

What we need is an API for form actions, and a standard set of drivers
(reference implementation included in "your favorite js framework").

Once you have that, you can have your widgets know what js-driver-set
you are using and avoid duplicate importation of the core framework
components.

-- 
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: managing javascript and css resources

[Kevin Howerton]

The django-compress looks a bit better as it has the option to do the
versioning (based on a file hash), compression, and concatenization
with a management command.
Django_compressor does this all on page load, which is not production
worthy IMO.

Generating an MD5 hash on page load is un-needed overhead as well.  In
order to do this you are loading each js/css file into memory as you
render your templates. If you are using either of these tools in
production I highly recommend that you have those template fragments
cached.

Our compression scripts rely on the git-hash.  The negative to this is
that when you increase your version you expire every css/js file,
though I feel this might be a benefit in some ways (we can alter all
of our JS based by changing a version number in our settings file).
The real positive to this is that you don't even touch the filesystem
in production, let alone have to generate an md5 hash.

As far as concatenization goes, I really believe that this at least
should be separated out from the templates, if not just simply done by
hand.  Having random different concatenization of css/js littered
throughout 100+ templates can be a bit daunting to maintain.  Doing
the concat in a python file would work very well though

global = ('carousel.js', 'menu-bar.js', 'modal.js')
newspage = ('widgets.js', 'calendar.js', 'weather.js')

I've always just achieved the same effect by just throwing all the
different little files that are required for each page type ... into
one file, though that's probably due to a lack of an acceptable
alternative solution rather than anything else.

-k

-- 
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: managing javascript and css resources

[Ulrich Petri]

Am 22.04.2010 um 20:28 schrieb Ned Batchelder:

FWIW, I just started using django-compress (http://code.google.com/p/django-compress/ 
) which works precisely this way.  It has pluggable compressors,  
control over the versioning of the combined files, and so on.


Also worth noting is django_compressor *) (http://github.com/mintchaos/django_compressor 
) which works similar but uses template tags to define bundles (which  
IMHO is way more natural than defining them in settings)


*) not to be confused with django-compressor (_ vs -)

Bye,
Ulrich



--Ned.

Gabriel Hurley wrote:


I like the idea of having these "bundles" or "stacks" for media. Just
thinking out loud here, if there were a compression engine in play
that could do concatenation as well as minification you could have a
useful syntax for ordered combinations of scripts similar to how
ModelAdmin's fieldsets work (using a dictionary of nested tuples).

A quick example:

scripts = {
"head": (
"media/js/script_to_be_loaded_first.js",
),
"tail": (
"media/js/script_that_shouldn't_be_concatenated.js", ("media/
js/concatenate_me_1.js", "media/js/concatenate_me_2.js"),
)
}

That would give you the benefit of automated concatenation while
somewhat alleviating the problem Kevin Howerton pointed out about it
best being done by hand.

That's my thought for the moment.

- Gabriel

On Apr 21, 9:18 am, Owen Nelson  wrote:

I've been thinking about this ever since I learned that django's  
admin
was going to be using jQuery, but I admit I didn't really consider  
it

that important until recently (building sites against 1.2-beta).

I know now is not a fantastic time to be talking about features, but
this is something I'd enjoy working on (personally), and I am just
hoping to get a little feedback regarding the design, and how it  
might

fit in with everything else going on in django's guts
(philosophically).  I also understand that this isn't something  
for near

versions of django, but rather the distant future.

Here's where the pin dropped:
* The jQuery used by the admin site is conjured using the no  
conflict

option and is relegated/isolated to it's own namespace (excellent).
* There are many projects/apps out there that also rely on jQuery  
- they
also "bundle" the framework, but may not be quite so quick to play  
nice.


In my case, I noticed that when I added a few jQuery-enhanced form
widgets to a form in my admin site, it resulted in 3 instances of  
the

framework being sourced in the document head.  Although, this is
actually ok for the most part in terms of operation (so long as the
scripted events that come with each widget are bound to the dom  
before
the plugin of origin gets wiped by the next sourcing of jQuery),  
it's

far from ideal.

There are a myriad of ways to skin this cat, be it a simple
recommendation to adopt  the use of  django's jQuery and a  
template tag

to provide access to the appropriate script tag, or something more
structured/engineered/formal 

My goal would be to provide app developers with scaffolding to add
javascript/css resources to the rendered view in a non-competitive  
way.
I'm thinking in terms of a template tag that works along the lines  
of {%
include %}, but for script and link tags, allowing folks to add  
scripts

with an optional way to influence the position in the "stack".  A
similar interface would also be provided for form media, and perhaps
some kind of helper or shortcut for ease the addition of these  
scripts

from our view functions.

I understand that Django has historically been
anti-javascript-framework-blessing, and I'm wondering if opening  
this
can of worms would mean having to incorporate some kind of a  
pluggable

backend system (for working with different frameworks, or multiple
frameworks at a time) - something I've briefly considered, but  
started

foaming at the mouth as a result.
I've also considered the fact that the reaction here might be, "just
don't - leave it all in the individual's hands".

In closing... don't hit me!

Regards,
Owen Nelson

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


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, 

Re: managing javascript and css resources

[Ned Batchelder]

FWIW, I just started using django-compress 
(http://code.google.com/p/django-compress/) which works precisely this 
way.  It has pluggable compressors, control over the versioning of the 
combined files, and so on.


--Ned.

Gabriel Hurley wrote:

I like the idea of having these "bundles" or "stacks" for media. Just
thinking out loud here, if there were a compression engine in play
that could do concatenation as well as minification you could have a
useful syntax for ordered combinations of scripts similar to how
ModelAdmin's fieldsets work (using a dictionary of nested tuples).

A quick example:

scripts = {
"head": (
"media/js/script_to_be_loaded_first.js",
),
"tail": (
"media/js/script_that_shouldn't_be_concatenated.js", ("media/
js/concatenate_me_1.js", "media/js/concatenate_me_2.js"),
)
}

That would give you the benefit of automated concatenation while
somewhat alleviating the problem Kevin Howerton pointed out about it
best being done by hand.

That's my thought for the moment.

- Gabriel

On Apr 21, 9:18 am, Owen Nelson  wrote:
  

I've been thinking about this ever since I learned that django's admin
was going to be using jQuery, but I admit I didn't really consider it
that important until recently (building sites against 1.2-beta).

I know now is not a fantastic time to be talking about features, but
this is something I'd enjoy working on (personally), and I am just
hoping to get a little feedback regarding the design, and how it might
fit in with everything else going on in django's guts
(philosophically).  I also understand that this isn't something for near
versions of django, but rather the distant future.

Here's where the pin dropped:
* The jQuery used by the admin site is conjured using the no conflict
option and is relegated/isolated to it's own namespace (excellent).
* There are many projects/apps out there that also rely on jQuery - they
also "bundle" the framework, but may not be quite so quick to play nice.

In my case, I noticed that when I added a few jQuery-enhanced form
widgets to a form in my admin site, it resulted in 3 instances of the
framework being sourced in the document head.  Although, this is
actually ok for the most part in terms of operation (so long as the
scripted events that come with each widget are bound to the dom before
the plugin of origin gets wiped by the next sourcing of jQuery), it's
far from ideal.

There are a myriad of ways to skin this cat, be it a simple
recommendation to adopt  the use of  django's jQuery and a template tag
to provide access to the appropriate script tag, or something more
structured/engineered/formal 

My goal would be to provide app developers with scaffolding to add
javascript/css resources to the rendered view in a non-competitive way.
I'm thinking in terms of a template tag that works along the lines of {%
include %}, but for script and link tags, allowing folks to add scripts
with an optional way to influence the position in the "stack".  A
similar interface would also be provided for form media, and perhaps
some kind of helper or shortcut for ease the addition of these scripts
from our view functions.

I understand that Django has historically been
anti-javascript-framework-blessing, and I'm wondering if opening this
can of worms would mean having to incorporate some kind of a pluggable
backend system (for working with different frameworks, or multiple
frameworks at a time) - something I've briefly considered, but started
foaming at the mouth as a result.
I've also considered the fact that the reaction here might be, "just
don't - leave it all in the individual's hands".

In closing... don't hit me!

Regards,
Owen Nelson

--
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 
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-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: Advice on #13260 - '%' in args to urlresolvers.reverse()

[Thomas Guettler]

 reverse('special', args=[r'+\$*'])
> '/special_chars/+%5C$*/'
> 
> It would have to output:
> 
> '/special_chars/%2B%5C%24%2A/'

Hi,

I think the current test case is broken. All args/kwargs should
be quoted.


-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

-- 
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: Process discussion: reboot

[Thomas Guettler]

The plan to make 1.3 a feature light release with focus on
fixing old bugs and tickets, was a good one.

I have some tickets in trac which are quite old, too. But it has been
a very long time, since I reviewed tickets of other people, too.

Sometimes I think the development process is slow. But that's wrong.
The development is just in parts I don't need up to now (for example multi db 
support).

  Thomas

Jacob Kaplan-Moss wrote:
> Hi folks --
> 
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
> 
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
> 
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
> 
> Jacob
> 

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

-- 
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: How to set the sucess message after inserting values to db indjango admin site

[skylar . saveland]

Ask on django-users.  This list is for the discussion of developing django 
itself.
sent from my baz foone

-Original Message-
From: Radhikavk 
Date: Wed, 21 Apr 2010 22:55:03 
To: 
Subject: How to set the sucess message after inserting values to db in
 django admin site


How to set the sucess message after inserting values to db in django admin
site
like message department added sucessfully

model:

class departmentForm(forms.ModelForm):
model=mdldepartments

def clean(self):
dept_msg = u"Department name allows only characters."
cleaned_data = self.cleaned_data
dept = cleaned_data.get("dept_name")
pattern = re.compile("([A-Z,a-z])")
if not pattern.match(dept):
self._errors["dept_name"] = ErrorList([dept_msg])
#else:
#self.
return cleaned_data

class mdldepartmentsAdmin(admin.ModelAdmin): 
   form=departmentForm
   list_display = ('dept_name','status')
   search_fields = ['dept_name']
   list_filter = ['status'] 
admin.site.register(mdldepartments,mdldepartmentsAdmin)



And i tried to enable the messaging module in django but in django.contrib
messages folder is missing
my django version is 1.1


Thaks
Radhika

-- 
View this message in context: 
http://old.nabble.com/How-to-set-the-sucess-message-after-inserting-values-to-db-in-django-admin-site-tp28324413p28324413.html
Sent from the django-developers mailing list archive at Nabble.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-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.

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