Re: Can a template extend a template?

[Ian Clelland]

On Tue, Dec 13, 2011 at 2:21 PM, Jason <1jason.whatf...@gmail.com> wrote:

> Hi there,
>
> I love the concept of DRY, and django's enthusiasm for this concept. In
> light of this I have tried to have a template extend a template, but it
> doesn't seem to work. Is there a better way than what I'm currently doing?
>
> The current way
>
> index.html
>
> {% if current_user %}
> {% extends "_logged_out_template.html" %}
>
> {% else %}
> {% extends "_logged_in_template.html" %}
> {% endif %}
>
> contact.html
>
> {% if current_user %}
>
> {% extends "_logged_out_template.html" %}
>
> {% else %}
>
> {% extends "_logged_in_template.html" %}
>
> {% endif %}
>
>
>
> The way I would like it to be (but it didn't work)
>
> index.html
> {% extends "_base_template.html" %}
>
> _base_script.html
>
> {% if current_user %}
>
> {% extends "_logged_out_template.html" %}
>
> {% else %}
>
> {% extends "_logged_in_template.html" %}
>
> {% endif %}
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/8j1xs23yjnAJ.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>


Honestly, I never even realized that you *could* put an {% extends %} node
inside of an {% if %} node like that.

What I find works, if you really do have to dynamically change the base
template that you are inheriting from, is to set a context variable in your
view, and use it in the template. Nobody ever said that the argument to
'extends' has to be a literal string:

View:
def my_view(request):
if request.user.is_authenticated:
base_template = "_logged_in_template.html"
else:
base_template = "_logged_out_template.html"

   ...
   return render("my_template.html", RequestContext({"base_template":
base_template...}))


Template: (my_template.html)

{% extends base_template %}


(In a real app, I would use a base class for the view which would set the
base template for every request automatically, or I would do it in a
context processor, rather than putting those four lines at the top of every
single view)


-- 
Regards,
Ian Clelland


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Newbie question - if I add "on delete cascade" to a foreign key on my MySQL db

[Mike]

Many thanks Jacob!

On Dec 13, 8:57 pm, Jacob Kaplan-Moss  wrote:
> On Tue, Dec 13, 2011 at 7:22 PM, Mike  wrote:
> > will I still be able to use Django's ORM?
>
> Yes, please 
> seehttps://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.mo...
> and in particular DO_NOTHING.
>
> Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Newbie question - if I add "on delete cascade" to a foreign key on my MySQL db

[Jacob Kaplan-Moss]

On Tue, Dec 13, 2011 at 7:22 PM, Mike  wrote:
> will I still be able to use Django's ORM?

Yes, please see
https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.on_delete
and in particular DO_NOTHING.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Newbie question - if I add "on delete cascade" to a foreign key on my MySQL db

[Mike]

will I still be able to use Django's ORM?

TIA

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Can a template extend a template?

[Furbee]

Brilliant! I wasn't looking an answer to this question, and wasn't all that
aware of how these interacted, but it will sure come in handy. Thanks for
the extremely clear, concise explanation. I don't think the Django docs
make it quite that clear.

Furbee

On Tue, Dec 13, 2011 at 3:49 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Wed, Dec 14, 2011 at 6:21 AM, Jason <1jason.whatf...@gmail.com> wrote:
> > Hi there,
> >
> > I love the concept of DRY, and django's enthusiasm for this concept. In
> > light of this I have tried to have a template extend a template, but it
> > doesn't seem to work. Is there a better way than what I'm currently
> doing?
>
> Yes :-)
>
> > The current way
> >
> > index.html
> >
> > {% if current_user %}
> > {% extends "_logged_out_template.html" %}
> >
> > {% else %}
> > {% extends "_logged_in_template.html" %}
> > {% endif %}
> >
> > contact.html
> >
> > {% if current_user %}
> >
> > {% extends "_logged_out_template.html" %}
> >
> > {% else %}
> >
> > {% extends "_logged_in_template.html" %}
> >
> > {% endif %}
> >
> >
> >
> > The way I would like it to be (but it didn't work)
> >
> > index.html
> > {% extends "_base_template.html" %}
> >
> > _base_script.html
> >
> > {% if current_user %}
> >
> > {% extends "_logged_out_template.html" %}
> >
> > {% else %}
> >
> > {% extends "_logged_in_template.html" %}
> >
> > {% endif %}
>
> This sample suggests that you may have some misunderstandings about
> how Django's template language -- and the {% extends %} tag in
> particular -- are supposed work.
>
> {% extends %} is *not* the same as {% include %}. A template can only
> *extend* a single other template. The natural partner of {% extends %}
> is the {% block %} tag.
>
> Django also has an {% include %} statement, but {% extends %} and {%
> block %} are generally more efficient (and, in my experience,
> flexible)
>
> {% extends %} is the only special case in Django's template parser.
> The extends tag is parsed separately from the rest of the tags
> (specifically so that it can interact with {% block %} tags), and as a
> result, the {% block %} tag doesn't interact with {% if %} or other
> logical constructs. The Django parser works out what templates are
> being extended, creating a single template, and *then* sorts out the
> page logic.
>
> Working with an {% include %} tag is a bit like a "top down" design --
> you have a final product in mind, which you construct by assembling
> lots of smaller snippets. {% extends %} is more like a bottom up
> design -- you establish a basic structure, and then work out how a
> specific page modifies the basic structure.
>
> Looking at your example, it's not entirely clear what you're trying to
> achieve; hopefully the following example will give you an idea of how
> {% extends %} and {% block %} work together:
>
> base.html:
>
> {% block header %}My Site{% endblock %}
> {% block body %}{% endblock %}
> {% block footer %}Thanks for coming{% endblock %}
>
> index.html
> {% extends "base.html" %}
> {% block body %}
> This is the index
> {% endblock %}
>
> detail.html
> {% extends "base.html" %}
> {% block body %}
> This is the detail
> {% endblock %}
>
> This will result in two pages -- an index and a detail page. Both have
> a header that reads "My Site", and a footer that says "thanks for
> coming"; however, the actual content in the body changes depending on
> the template.
>
> This sort of structure can then be layered -- so, for example, if
> there are many different types of detail page, you can have a "base
> detail" page that defines the blocks that exist on detail pages, and
> then specific detail pages that extend the base detail page.
>
> I hope this makes the design motivation of Django's template language
> a little more clear.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Can a template extend a template?

[Russell Keith-Magee]

On Wed, Dec 14, 2011 at 6:21 AM, Jason <1jason.whatf...@gmail.com> wrote:
> Hi there,
>
> I love the concept of DRY, and django's enthusiasm for this concept. In
> light of this I have tried to have a template extend a template, but it
> doesn't seem to work. Is there a better way than what I'm currently doing?

Yes :-)

> The current way
>
> index.html
>
> {% if current_user %}
>         {% extends "_logged_out_template.html" %}
>
> {% else %}
>         {% extends "_logged_in_template.html" %}
> {% endif %}
>
> contact.html
>
> {% if current_user %}
>
>         {% extends "_logged_out_template.html" %}
>
> {% else %}
>
>         {% extends "_logged_in_template.html" %}
>
> {% endif %}
>
>
>
> The way I would like it to be (but it didn't work)
>
> index.html
>         {% extends "_base_template.html" %}
>
> _base_script.html
>
> {% if current_user %}
>
>         {% extends "_logged_out_template.html" %}
>
> {% else %}
>
>         {% extends "_logged_in_template.html" %}
>
> {% endif %}

This sample suggests that you may have some misunderstandings about
how Django's template language -- and the {% extends %} tag in
particular -- are supposed work.

{% extends %} is *not* the same as {% include %}. A template can only
*extend* a single other template. The natural partner of {% extends %}
is the {% block %} tag.

Django also has an {% include %} statement, but {% extends %} and {%
block %} are generally more efficient (and, in my experience,
flexible)

{% extends %} is the only special case in Django's template parser.
The extends tag is parsed separately from the rest of the tags
(specifically so that it can interact with {% block %} tags), and as a
result, the {% block %} tag doesn't interact with {% if %} or other
logical constructs. The Django parser works out what templates are
being extended, creating a single template, and *then* sorts out the
page logic.

Working with an {% include %} tag is a bit like a "top down" design --
you have a final product in mind, which you construct by assembling
lots of smaller snippets. {% extends %} is more like a bottom up
design -- you establish a basic structure, and then work out how a
specific page modifies the basic structure.

Looking at your example, it's not entirely clear what you're trying to
achieve; hopefully the following example will give you an idea of how
{% extends %} and {% block %} work together:

base.html:

{% block header %}My Site{% endblock %}
{% block body %}{% endblock %}
{% block footer %}Thanks for coming{% endblock %}

index.html
{% extends "base.html" %}
{% block body %}
This is the index
{% endblock %}

detail.html
{% extends "base.html" %}
{% block body %}
This is the detail
{% endblock %}

This will result in two pages -- an index and a detail page. Both have
a header that reads "My Site", and a footer that says "thanks for
coming"; however, the actual content in the body changes depending on
the template.

This sort of structure can then be layered -- so, for example, if
there are many different types of detail page, you can have a "base
detail" page that defines the blocks that exist on detail pages, and
then specific detail pages that extend the base detail page.

I hope this makes the design motivation of Django's template language
a little more clear.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Can a template extend a template?

[Gabriel [SGT]]

On Tue, Dec 13, 2011 at 7:21 PM, Jason <1jason.whatf...@gmail.com> wrote:
> Hi there,
>
> I love the concept of DRY, and django's enthusiasm for this concept. In
> light of this I have tried to have a template extend a template, but it
> doesn't seem to work. Is there a better way than what I'm currently doing?
>
> The current way
>
> index.html
>
> {% if current_user %}
>         {% extends "_logged_out_template.html" %}
>
> {% else %}
>         {% extends "_logged_in_template.html" %}
> {% endif %}
>
> contact.html
>
> {% if current_user %}
>
>         {% extends "_logged_out_template.html" %}
>
> {% else %}
>
>         {% extends "_logged_in_template.html" %}
>
> {% endif %}
>
>
>
> The way I would like it to be (but it didn't work)
>
> index.html
>         {% extends "_base_template.html" %}
>
> _base_script.html
>
> {% if current_user %}
>
>         {% extends "_logged_out_template.html" %}
>
> {% else %}
>
>         {% extends "_logged_in_template.html" %}
>
> {% endif %}
>

I don't see why it doesn't work. Post the errors you are having.

I use templates that extends templates with no issues.

-- 
Kind Regards

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Can a template extend a template?

[Jason]

Hi there,

I love the concept of DRY, and django's enthusiasm for this concept. In 
light of this I have tried to have a template extend a template, but it 
doesn't seem to work. Is there a better way than what I'm currently doing?

The current way

index.html 

{% if current_user %}
{% extends "_logged_out_template.html" %}

{% else %}
{% extends "_logged_in_template.html" %}
{% endif %}

contact.html 

{% if current_user %}

{% extends "_logged_out_template.html" %}

{% else %}

{% extends "_logged_in_template.html" %}

{% endif %}



The way I would like it to be (but it didn't work)

index.html 
{% extends "_base_template.html" %}

_base_script.html

{% if current_user %}

{% extends "_logged_out_template.html" %}

{% else %}

{% extends "_logged_in_template.html" %}

{% endif %}

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/8j1xs23yjnAJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Decorator aware Django

[Bernardo]

Hi Russel,

> Returning HTTPResponse also provides a data formatting constraint that
> your approach doesn't have. At each level of  Django view, you know
> you're going to get a HTTP Response.

Yes, now it makes sense the view working only with HTTP request and
responses and the decorators will only work with some kind of specific
information that will not be the same for each decorator.

Being strict, the view (the decorated function) will always return an
HTTP response, but in another (more abstract) layer... I think I'll
need to find some balance in this technique.

Hi Javier,

> for example, make a (generic) view that simply calls a data gathering
> function (which is not a view) and hands the result to a HTML
> template, and another (generic) view that calls the same function but
> returns a different (XML? JSON? Pickle?) representation.

I don't know if I understand what you're saying but the decorator
approach is working exactly like that but instead of calling these
generic views, I decorate my view with it.
Could you explain me that with a simple snippet?

Regards,
Bernardo

On Dec 13, 12:14 pm, Javier Guerra Giraldez 
wrote:
> hi,
>
> Russel explained the real reasons of why your proposal doesn't fit so
> good in Django.
>
> still, this snippet:
>
> On Mon, Dec 12, 2011 at 7:49 PM, Bernardo  wrote:
> >        - The framework, within reason, should deduce as much as
> > possible from as little as possible.
> >    That last phrase tells everything I'm trying to explain.
>
> for me, is opposed to the "explicit is better than implicit" in the
> Zen of Python.  not a bad thing on itself, but something to be careful
> about.   (and, personally, it's a big part of why i like Django so
> much better than RoR)
>
> now, thinking a little more on what seems to be good: separating the
> 'data gathering' part of a view from the presentation part, I think it
> should be handled at a slightly different level.
>
> for example, make a (generic) view that simply calls a data gathering
> function (which is not a view) and hands the result to a HTML
> template, and another (generic) view that calls the same function but
> returns a different (XML? JSON? Pickle?) representation.
>
> paired with a middleware and some shortcuts in the urls.py, you can
> have nicely separated concerns and DRYness.
>
> --
> Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

foreign key select widget with "add" link

[j_syk]

I have a Model with a ForeignKey and I'm using a vanilla ModelForm, so
it's using the standard ModelChoiceField widget. I'm looking to add a
'+' icon with a link to popup and new window to add a new foreign key
that is not already in the dropdown list. Yes, exactly like the admin
forms.

I've done it in the past by manually laying out the form in the
template (still with {{ field }} and {{ label }} values, just no
looping at all). I don't want to do this again.

I could append the link via javascript. But that's dirty.

I quickly took a stab at extending the ModelChoiceField, but I failed
and moved on.

Searching the web for a solution hasn't been good to me.


What's the easiest way to cleanly add this to a form and get it to
refresh the choices?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to change the representation of newline?

[Furbee]

Yes, it is hard to determine the question. However, a stab in the dark, you
are trying to get a  tag to display a new line in a django template?
If so, any HTML that you want to render on the display needs to be passed
with the mark_safe() function. For example in views.py

from django.utils.safestring import mark_safe

def helloWorld(request):
message = "Hello  
  World!"
return render_to_response('hello_template.htm', {'message':
mark_safe(message)}, context_instance=RequestContext(request))


hello_template.htm:





Hello, World!
 

 
 {% if message %}
  {{ message }}
 {% endif %}
 


Produces a page like:
Hello
  World!

Without mark_safe(message) page just displays HTML not rendered in plain
text:
  Hello   
 World!

Hope that helps. If you are talking about manipulating characters, see
http://stackoverflow.com/questions/227459/ascii-value-of-a-character-in-python.
You can use ord() and chr() to switch carriage return/line feeds using the
ascii ordinal representation and back if you need to.

Furbee

2011/12/13 Tom Evans 

> 2011/12/13 Germán :
> > Has anybody solved this issue?
> >
> > On Dec 14 2006, 2:47 pm, "Aidas Bendoraitis"
> >  wrote:
> >> I ran out of ideas. :) Maybe somebody else has any thoughts regarding
> new lines?
> >>
> >> Good luck with Django!
> >> Aidas Bendoraitis [aka Archatas]
> >>
> >> On 12/14/06, zhongke chen  wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> > firefox shows utf-8
> >>
> >> > my firefox is 2.0
> >>
> >> > On 12/14/06, Aidas Bendoraitis  wrote:
> >> > > And what encoding is showed in the page info? ...when you right
> click
> >> > > somewhere in the page and choose "View Page Info" from the menu.
> Maybe
> >> > > just the default character encoding in your firefox settings is set
> >> > > wrongly?
> >>
> >> > > You can always override admin templates copying them into your
> >> > > custom_templates/admin directory.
> >>
> >> > > Regards,
> >> > > Aidas Bendoraitis
> >>
> >> > > On 12/14/06, zhongke chen  wrote:
> >> > > > It's not my html page, but the django admin page.
> >>
> >> > > > the head of admin page is like this:
> >>
> >> > > >  >> > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> >> > > > http://www.w3.org/1999/xhtml; lang="zh-cn"
> xml:lang="zh-cn" >
> >> > > > 
> >> > > > 站点管理员
> >> > > >  >> > > > href="/oj/adminmedia/css/dashboard.css" />
> >> > > > 
> >>
> >> > > > no encoding here, but lang = 'zh-cn'.
> >>
> >> > > > and all chinese characters in my pages and mysql are encoded in
> UTF-8.
> >> > > > Locale of my server is like this:
> >>
> >> > > > LANG=zh_CN.UTF-8
> >> > > > LANGUAGE=zh_CN:zh:en_US:en
> >> > > > LC_CTYPE="zh_CN.UTF-8"
> >> > > > LC_NUMERIC="zh_CN.UTF-8"
> >> > > > LC_TIME="zh_CN.UTF-8"
> >> > > > LC_COLLATE="zh_CN.UTF-8"
> >> > > > LC_MONETARY="zh_CN.UTF-8"
> >> > > > LC_MESSAGES="zh_CN.UTF-8"
> >> > > > LC_PAPER="zh_CN.UTF-8"
> >> > > > LC_NAME="zh_CN.UTF-8"
> >> > > > LC_ADDRESS="zh_CN.UTF-8"
> >> > > > LC_TELEPHONE="zh_CN.UTF-8"
> >> > > > LC_MEASUREMENT="zh_CN.UTF-8"
> >> > > > LC_IDENTIFICATION="zh_CN.UTF-8"
> >> > > > LC_ALL=
> >>
> >> > > > On 12/13/06, Aidas Bendoraitis 
> wrote:
> >> > > > > It might be that it treats new lines as \r\n when you are using
> some
> >> > > > > windows-* encoding for your html pages. Check the source code.
> I would
> >> > > > > rather use UTF-8 in any case.
> >>
> >> > > > > Regards
> >> > > > > Aidas Bendoraitis [aka Archatas]
> >>
> >> > > > --
> >> > > > Yours, Zhongke Chen 陈忠克
> >>
> >> > --
> >> > Yours, Zhongke Chen 陈忠克
> >>
> >> > 欢迎访问温州本地Linux论坛：http://groups.google.com/group/linux-wz
> >>
> >> > 请用czk19790...@gmail.com
> 与我联系，本人其它的邮箱已不再使用。如果要发word/excel/ppt文件给我，请先转成PDF格式。谢谢！PLEASE
> >> > contact me using czk19790...@gmail.com from now on. Other mail boxes
> >> > have been deprecated. If you want to attach word/excel/powerpoint
> >> > files for me, PLEASE convert them to pdf. Thanks a lot.
> >
>
> If there is a question in that mass of forwarded emails, I could not
> find it. The most important thing when getting help is to precisely
> and concisely state what your problem is. I'd start from there.
>
> Cheers
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 

Re: Is DJango bad for conveying business-logic?

[Tomek Paczkowski]

In my experience the only thing that locks you in Django is 
not realizing it's just Python and it's just programming. 
Use patterns and best practices. Don't think of models as be-all and 
end-all business logic. Plan wisely and you'll be good.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/bAuNdW_0hWkJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Is DJango bad for conveying business-logic?

[Alec Taylor]

Good morning,

I am almost 100% locked in to DJango for the projects I have been planning.

The final "myth" I'd like to "dispel" is that DJango is "mediocre" at
conveying business-logic.

Direct quote by Peter Shangov:

Whatever your choice of framework your real-life needs will very
quickly outgrow the functionality available in the ecommerce modules
that you started with, and you will end up needing to make non-trivial
changes to them or even rewriting from scratch sooner rather than
later. This is because open source has always been exceptional at
building infrastructure tools (think web servers, templating
languages, databases, cacheing, etc.), but relatively mediocre at
implementing business logic. So what I'd be looking for if I were you
is the library that I'd be happiest to hack on rather than the one
that looks most mature.

"Products" which I am putting DJango (with satchmo) up against:
- Ruby on Rails (with spree) [Ruby]
- Catalyst [Perl]
- JadaSite [Java]
- KonaKart [Java]
- Shopizer [Java]

Could you please alleviate (or confirm) my concerns regarding the
aforementioned quote about DJango?

Thanks for all information,

Alec Taylor

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Decorator aware Django

[Javier Guerra Giraldez]

hi,


Russel explained the real reasons of why your proposal doesn't fit so
good in Django.

still, this snippet:

On Mon, Dec 12, 2011 at 7:49 PM, Bernardo  wrote:
>        - The framework, within reason, should deduce as much as
> possible from as little as possible.
>    That last phrase tells everything I'm trying to explain.


for me, is opposed to the "explicit is better than implicit" in the
Zen of Python.  not a bad thing on itself, but something to be careful
about.   (and, personally, it's a big part of why i like Django so
much better than RoR)



now, thinking a little more on what seems to be good: separating the
'data gathering' part of a view from the presentation part, I think it
should be handled at a slightly different level.

for example, make a (generic) view that simply calls a data gathering
function (which is not a view) and hands the result to a HTML
template, and another (generic) view that calls the same function but
returns a different (XML? JSON? Pickle?) representation.

paired with a middleware and some shortcuts in the urls.py, you can
have nicely separated concerns and DRYness.

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django testing and unique=True

[Karen Tracey]

On Tue, Dec 13, 2011 at 8:33 AM, Acruax  wrote:

> Hi,
> I have a problem with model testing. My test fails with error:
>  IntegrityError: duplicate key value violates unique constraint
> "catalog_name_key"
>  DETAIL: Key (name)=(test_catalog1) already exists.
>
> I have unique=True on name field.
>
> class CatalogTestCase(unittest.TestCase):
>def setUp(self):
>self.catalog1 = Catalog.objects.create(name="test_catalog1",
> title_ru="Test Catalog1")
>

For tests that use the database, you need to extend from
django.test.TestCase, not unittest.TestCase. Django's custom TestCase will
ensure that the database is reset to its initial state between tests (see
https://docs.djangoproject.com/en/1.3/topics/testing/#testcase). The need
for using Django's custom TestCase is unfortunately not currently properly
noted in the docs, and there is a ticket open on that (
https://code.djangoproject.com/ticket/17312).

Karen
-- 
http://tracey.org/kmt/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Django testing and unique=True

[Acruax]

Hi,
I have a problem with model testing. My test fails with error:
  IntegrityError: duplicate key value violates unique constraint
"catalog_name_key"
  DETAIL: Key (name)=(test_catalog1) already exists.

I have unique=True on name field.

class CatalogTestCase(unittest.TestCase):
def setUp(self):
self.catalog1 = Catalog.objects.create(name="test_catalog1",
title_ru="Test Catalog1")

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: get_FOO_display

[Mike Dewhirst]

Absolutely. I went back and found where I had made it work previously and that 
is exactly what I did. I just had a (hopefully) temporary blur. 

Thanks

Mike

On 13/12/2011, at 8:47 PM, Ilian Iliev  wrote:

> Or you can change your field to IntegerField instead of CharField if you are 
> planning to have only Integer
> values for the choices.
> 
> 
> -- 
> eng. Ilian Iliev
> Web Software Developer
> 
> Mobile: +359 88 66 08 400
> Website: http://ilian.i-n-i.org
> 
> 
> On Tue, Dec 13, 2011 at 9:53 AM, Mike Dewhirst  wrote:
> On 13/12/2011 5:21pm, kenneth gonsalves wrote:
> On Tue, 2011-12-13 at 17:16 +1100, Mike Dewhirst wrote:
> THINGS = ( (0, 'Thing Zero'),
> (1, 'Thing One'), )
> 
> what happens when you do:
> 
> THINGS = ( ('0', 'Thing Zero'),
> ('1', 'Thing One'), )
> 
> 
> By golly it worked! Must have missed that in the docs.
> 
> Thanks Kenneth
> 
> Mike
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: get_FOO_display

[Ilian Iliev]

Or you can change your field to IntegerField instead of CharField if you
are planning to have only Integer
values for the choices.


-- 
eng. Ilian Iliev
Web Software Developer

Mobile: +359 88 66 08 400
Website: http://ilian.i-n-i.org


On Tue, Dec 13, 2011 at 9:53 AM, Mike Dewhirst wrote:

> On 13/12/2011 5:21pm, kenneth gonsalves wrote:
>
>> On Tue, 2011-12-13 at 17:16 +1100, Mike Dewhirst wrote:
>>
>>> THINGS = ( (0, 'Thing Zero'),
>>> (1, 'Thing One'), )
>>>
>>
>> what happens when you do:
>>
>> THINGS = ( ('0', 'Thing Zero'),
>> ('1', 'Thing One'), )
>>
>
>
> By golly it worked! Must have missed that in the docs.
>
> Thanks Kenneth
>
> Mike
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to django-users+unsubscribe@**
> googlegroups.com .
> For more options, visit this group at http://groups.google.com/**
> group/django-users?hl=en
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to change the representation of newline?

[Tom Evans]

2011/12/13 Germán :
> Has anybody solved this issue?
>
> On Dec 14 2006, 2:47 pm, "Aidas Bendoraitis"
>  wrote:
>> I ran out of ideas. :) Maybe somebody else has any thoughts regarding new 
>> lines?
>>
>> Good luck with Django!
>> Aidas Bendoraitis [aka Archatas]
>>
>> On 12/14/06, zhongke chen  wrote:
>>
>>
>>
>>
>>
>>
>>
>> > firefox shows utf-8
>>
>> > my firefox is 2.0
>>
>> > On 12/14/06, Aidas Bendoraitis  wrote:
>> > > And what encoding is showed in the page info? ...when you right click
>> > > somewhere in the page and choose "View Page Info" from the menu. Maybe
>> > > just the default character encoding in your firefox settings is set
>> > > wrongly?
>>
>> > > You can always override admin templates copying them into your
>> > > custom_templates/admin directory.
>>
>> > > Regards,
>> > > Aidas Bendoraitis
>>
>> > > On 12/14/06, zhongke chen  wrote:
>> > > > It's not my html page, but the django admin page.
>>
>> > > > the head of admin page is like this:
>>
>> > > > > > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>> > > > http://www.w3.org/1999/xhtml; lang="zh-cn" 
>> > > > xml:lang="zh-cn" >
>> > > > 
>> > > > 站点管理员
>> > > > > > > > href="/oj/adminmedia/css/dashboard.css" />
>> > > > 
>>
>> > > > no encoding here, but lang = 'zh-cn'.
>>
>> > > > and all chinese characters in my pages and mysql are encoded in UTF-8.
>> > > > Locale of my server is like this:
>>
>> > > > LANG=zh_CN.UTF-8
>> > > > LANGUAGE=zh_CN:zh:en_US:en
>> > > > LC_CTYPE="zh_CN.UTF-8"
>> > > > LC_NUMERIC="zh_CN.UTF-8"
>> > > > LC_TIME="zh_CN.UTF-8"
>> > > > LC_COLLATE="zh_CN.UTF-8"
>> > > > LC_MONETARY="zh_CN.UTF-8"
>> > > > LC_MESSAGES="zh_CN.UTF-8"
>> > > > LC_PAPER="zh_CN.UTF-8"
>> > > > LC_NAME="zh_CN.UTF-8"
>> > > > LC_ADDRESS="zh_CN.UTF-8"
>> > > > LC_TELEPHONE="zh_CN.UTF-8"
>> > > > LC_MEASUREMENT="zh_CN.UTF-8"
>> > > > LC_IDENTIFICATION="zh_CN.UTF-8"
>> > > > LC_ALL=
>>
>> > > > On 12/13/06, Aidas Bendoraitis  wrote:
>> > > > > It might be that it treats new lines as \r\n when you are using some
>> > > > > windows-* encoding for your html pages. Check the source code. I 
>> > > > > would
>> > > > > rather use UTF-8 in any case.
>>
>> > > > > Regards
>> > > > > Aidas Bendoraitis [aka Archatas]
>>
>> > > > --
>> > > > Yours, Zhongke Chen 陈忠克
>>
>> > --
>> > Yours, Zhongke Chen 陈忠克
>>
>> > 欢迎访问温州本地Linux论坛：http://groups.google.com/group/linux-wz
>>
>> > 请用czk19790...@gmail.com与我联系，本人其它的邮箱已不再使用。如果要发word/excel/ppt文件给我，请先转成PDF格式。谢谢！PLEASE
>> > contact me using czk19790...@gmail.com from now on. Other mail boxes
>> > have been deprecated. If you want to attach word/excel/powerpoint
>> > files for me, PLEASE convert them to pdf. Thanks a lot.
>

If there is a question in that mass of forwarded emails, I could not
find it. The most important thing when getting help is to precisely
and concisely state what your problem is. I'd start from there.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.