Re: extends headaches
On Feb 7, 2:14 pm, AmanKow <[EMAIL PROTECTED]> wrote: > I've reopenedhttp://code.djangoproject.com/ticket/5124. > 'contains_nontext' must be an instance attribute, not a class > attribute in 'NodeList'. There is a patch attached. Arrggh... my humble apologies... been following the template code, just got back from a three day crash business trip, and wasn't thinking clearly when I started looking at the recent changes. Sometimes my poor old brain still wanders down old c++ pathways, especially when I'm dog tired! Please ignore the previous message re instance vs class attribute! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: extends headaches
On Feb 7, 2:26 pm, AmanKow <[EMAIL PROTECTED]> wrote:
> BTW, do I understand this correctly...
> {# comment #} is alright, but {% comment %} ... {% endcomment %} is
> not? I don't see anything in the code that would allow block
> comments. Would be nice if it did...
This could be implemented easily by having the comment() function in
defauttags.py return an empty TextNode and doing away with the
CommentNode class entirely.
Thoughts?
Wayne
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: extends headaches
BTW, do I understand this correctly...
{# comment #} is alright, but {% comment %} ... {% endcomment %} is
not? I don't see anything in the code that would allow block
comments. Would be nice if it did...
Wayne
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: extends headaches
I've reopened http://code.djangoproject.com/ticket/5124. 'contains_nontext' must be an instance attribute, not a class attribute in 'NodeList'. There is a patch attached. Wayne --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Enhancement to edit_inline
On Feb 7, 2008 8:29 AM, MikeH <[EMAIL PROTECTED]> wrote: > So I modified the admin app to let you override the edit inline templates in > your own applications, > using the admin/app_name/model_name/edit_inline_(stacked|tabular).html > convention that the other admin templates use. > > The diff is below. Hope it's useful to someone, it's extremely useful for > me! 1. Django has a ticket tracker which accepts uploaded patches for review. Posting a patch to the mailing list is the best way to ensure it will get lost over time. 2. Django's admin is in the process of being completely rewritten, and the edit_inline functionality is being made much more robust; consider looking at the newforms-admin branch of Django to see if this is already available, or rewriting the patch against that branch if it's not. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: extends headaches
Thanks, I try to do my best and five mistakes in the same sentence is not that bad ;) Cheers, David Le 7 févr. 08 à 15:31, J. Cliff Dyer a écrit : > > I made a couple of minor grammatical changes for clarity, but your > english was pretty good, David. > > Cheers, > Cliff > > On Thu, 2008-02-07 at 15:06 +0100, David Larlet wrote: >> >> Le 6 f�vr. 08 � 21:01, SmileyChris a �crit : >> >>> >>> On Feb 6, 9:43 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> >>> wrote: It already results in a broken site, we're now just being a lot clearer about that. >>> >>> Actually, it only resulted previously in a broken site if the >>> extended >>> template was being used in more than one depth of inheritance. >>> Still, it's a wiki, feel free to update it if you like. >>> >>> Yea, go ahead and update it David, I think it's fair enough. >>> >> >> I'd tried to use my best english but corrections are welcome :) >> http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Raiseerrorsifextendsisnotthefirsttagofatemplate >> >> Best, >> David >> >> >>> > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: extends headaches
I made a couple of minor grammatical changes for clarity, but your english was pretty good, David. Cheers, Cliff On Thu, 2008-02-07 at 15:06 +0100, David Larlet wrote: > > Le 6 f�vr. 08 � 21:01, SmileyChris a �crit : > > > > > On Feb 6, 9:43 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > > wrote: > >> It already results in a broken site, we're now just being a lot > >> clearer > >> about that. > > > > Actually, it only resulted previously in a broken site if the extended > > template was being used in more than one depth of inheritance. > > > >> > >> Still, it's a wiki, feel free to update it if you like. > > > > Yea, go ahead and update it David, I think it's fair enough. > > > > I'd tried to use my best english but corrections are welcome :) > http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Raiseerrorsifextendsisnotthefirsttagofatemplate > > Best, > David > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Enhancement to edit_inline
Hi all,
I wanted to use edit_inline for some of my models, but wanted to customise
the templates that were used.
So I modified the admin app to let you override the edit inline templates in
your own applications,
using the admin/app_name/model_name/edit_inline_(stacked|tabular).html
convention that the other admin templates use.
The diff is below. Hope it's useful to someone, it's extremely useful for
me!
Cheers,
MikeH
Index: django/contrib/admin/templatetags/admin_modify.py
===
--- django/contrib/admin/templatetags/admin_modify.py (revision 7092)
+++ django/contrib/admin/templatetags/admin_modify.py (working copy)
@@ -145,7 +145,9 @@
self.show_url = original and hasattr(self.relation.opts,
'get_absolute_url')
def template_name(self):
-return "admin/edit_inline_tabular.html"
+model_name = self.relation.model._meta.object_name.lower()
+app_name = self.relation.model.__module__.split('.')[-2].lower()
+return ["admin/%s/%s/edit_inline_tabular.html" % (app_name,
model_name), "admin/edit_inline_tabular.html"]
class StackedBoundRelatedObject(BoundRelatedObject):
def __init__(self, related_object, field_mapping, original):
@@ -157,7 +159,9 @@
self.show_url = original and hasattr(self.relation.opts,
'get_absolute_url')
def template_name(self):
-return "admin/edit_inline_stacked.html"
+model_name = self.relation.model._meta.object_name.lower()
+app_name = self.relation.model.__module__.split('.')[-2].lower()
+return ["admin/%s/%s/edit_inline_stacked.html" % (app_name,
model_name), "admin/edit_inline_stacked.html"]
class EditInlineNode(template.Node):
def __init__(self, rel_var):
@@ -175,7 +179,7 @@
original = context.get('original', None)
bound_related_object = relation.bind(context['form'], original,
bound_related_object_class)
context['bound_related_object'] = bound_related_object
-t = loader.get_template(bound_related_object.template_name())
+t = loader.select_template(bound_related_object.template_name())
output = t.render(context)
context.pop()
return output
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: extends headaches
Le 6 févr. 08 à 21:01, SmileyChris a écrit : > > On Feb 6, 9:43 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: >> It already results in a broken site, we're now just being a lot >> clearer >> about that. > > Actually, it only resulted previously in a broken site if the extended > template was being used in more than one depth of inheritance. > >> >> Still, it's a wiki, feel free to update it if you like. > > Yea, go ahead and update it David, I think it's fair enough. > I'd tried to use my best english but corrections are welcome :) http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Raiseerrorsifextendsisnotthefirsttagofatemplate Best, David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
EARNING for reading SMS
Hello, I found few genuine sites for earning through your mobile. 1. http://www.sms2india.co.in/?user=patrapb 2. http://www.youmint.com/network-patrapb 3. http://www.mginger.com/index.jsp?inviteId=115252 Earning Highlights: = Earning for receiving SMS in your Mobile. = Earning for receiving SMS by your network upto three levels. = Earning for every member you created under your network. = Free SMS sending options. Visit and calculate how much can you make through SMS or Email. HAPPY MOBILE EARNING. Apart from the above, I found a lot of GENUINE earning sites in Internet for clicking advertisements. If you are really interested, contact me in my id "patra_pb" (Yahoo Messenger) or mail me at [EMAIL PROTECTED] or [EMAIL PROTECTED] to know the details. BEST OF LUCK. Regards, Priyabrata Patra --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Bug saving NUL character?
On Feb 7, 2008 4:15 AM, Alexandre Martani <[EMAIL PROTECTED]> wrote: > Hi, > When I try to save a string containing NUL character (\x00), only the > part before the character is saved. I have created a simple model: > > class Test(models.Model): >content = models.TextField() Text fields are not meant to store binary data. This might as well be the underlying RDBMS limitation. > Since python supports NUL character in strings, Django should support > them too, or at least raise an error, or just drop it, but not losing > all the end of the string. Have you confirmed that the SQL generated by Django does not contain the null character? > Also, it is possible to send a NUL > character through GET or POST, so I think this bug could lead to a SQL > Injection. What kind of injection? It did not terminate the SQL query, just the contents of one field. SQL termination in the middle of a quoted string would result in a failed transaction. Also, AFAIR Django uses prepared statements so there's no possibility to execute code from a bound variable. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: custom model field validation
On Feb 7, 2008 5:57 PM, Mackenzie Kearl <[EMAIL PROTECTED]> wrote: > > I am having trouble finding documentation on how to add custom > validation to a custom model field. Please don't cross post messages between django-users and django-developers. In addition to the general impoliteness of cross-posting, django-developers is a mailing list for discussing the development of Django itself. If you have a 'how do I do this query', django-users is the right mailing list for the job. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
custom model field validation
I am having trouble finding documentation on how to add custom
validation to a custom model field.
example:
class PostalField(models.CharField):
def __init__(self,*args,**kwargs):
kwargs['max_length']= 6
super(PostalField, self).__init__(*args, **kwargs)
def get_internal_type(self):
return "CharField"
now when I save from the admin with this field it only validates like
a CharField.
How do I fix this to use some function like below.
def validate(self):
pattern = re.compile("([A-Z,a-z][0-9]){3}")
if not pattern.match(value):
raise forms.ValidationError('Not A valid Postal Code')
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
