Re: Django 1.7.4, PostgreSQL: Migrate FK to M2M?

[Micky Hulse]

Hi Andrew, many thanks for the quick reply and help! :)

On Wed, Feb 18, 2015 at 8:56 PM, Andrew Pinkham  wrote:
> When I had to migrate FK->M2M, I found that hand-hacking a migration file was 
> the way to go. I wrote a multiple operation migration class that did the 
> following:
> ..
> Hope that's helpful,

Yes, very helpful! Thanks for the tips. That gives me a great outline
and starting/ending points to shoot for.

I'll post back my code to the group if all works out and I have
something worth sharing. ;)

Thanks again Andrew!

Cheers,
Micky

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAKzdcNk7TEH-VX%2BMN4nxgtgmBrti%2Bq7CENvVPdKCZTbxR6aT%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django 1.7.4, PostgreSQL: Migrate FK to M2M?

[Micky Hulse]

Hi,

I was just curious if anyone could give me tips on how to migrate an
FK to M2M whist retaining the FK selected data?

Long story short, I've played around with adding adding a M2M field
with a `related_name`, migrating, deleting FK, then re-naming the M2M
and removing `related_name`, but I eventually lose the data towards
the end of the hoop jumping. I think I need to get my hands dirty and
modify the schema migrations.

I've found a few (older) posts detailing the steps using South (for
example, [1]), but I'm using Django's built-in migration tools …

Questions:

Should South tutorials directly relate to Django's schema migrations?

Anyone out there have a step-by-step for Django 1.7.x (using native
schema migrations) that I could follow? :)

Thanks in advance!

Cheers,
M

[1] 


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAKzdcNmfMXTP4S1OYPEXFvnJE30cNhLFvZdPgv2DwHrmafrHdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best way to test handle optional FKs in model __str__?

[Micky Hulse]

On Sat, Jan 17, 2015 at 8:09 PM, James Schneider
 wrote:
> You can definitely do it that way if all you need to do is check if values
> exist and provide a default if they don't. I do this all the time for my
> __str__() methods as well.
> You also mentioned similar situations that may require more logic checks
> (variables depending on each other or printing computed values), then the
> try/except strategy is likely more flexible.

Thanks for reply and advice James, I really appreciate it. :)

It's funny that I haven't had this problem before … Either I've never
gone too far down the __str__() FK chain and avoided AttributeErrors
or I've always had FKs so that were required (so, no error on save).

Anyway, I really appreciate the reply and tips/advice.

Thanks everyone! Django sure does have an awesome open source community.

Cheers,
m

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAKzdcNkU-ouU8kDc32wpKBraqDJyTdQwnaHD6hJ1afSyjk31yg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best way to test handle optional FKs in model __str__?

[Micky Hulse]

On Sat, Jan 17, 2015 at 6:15 PM, Tim Chase
 wrote:
> I'm pretty sure that getattr() takes an optional 3rd field for the
> default, so you could use

Great point, that's very useful. Thanks for clarifying!

It looks like attrgetter doesn't have similar functionality, but
there's this (found after a quick Google search):



Thanks for example code Tim!

Cheers,
m

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAKzdcN%3Dr9gA3diGW0t8tu0z03CoUp%2BhZOm3rfaog35X5rxX5MA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best way to test handle optional FKs in model __str__?

[Micky Hulse]

On Sat, Jan 17, 2015 at 3:00 PM, James Schneider
 wrote:
> Yes, it's a bit more verbose, but much easier to follow. Hope it helps.

Definitely! Thanks again!

Python rocks. :)

Cheers,
M

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAKzdcNnMcEjaNktEREH5FEGCJvExsPShfQFN74CPctH0JXKV9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best way to test handle optional FKs in model __str__?

[Micky Hulse]

Hi James! Thank you for the reply and for the example code!

On Sat, Jan 17, 2015 at 2:52 PM, James Schneider
 wrote:
> You can reroll your original example like this:
> Much more pythonic, IMO.

Ah, that's great! I was actually wondering what the pythonic way of
doing this might be. While it's more lines, I like that it is more
readable/understandable. Much easier to pick up the code later on.

Much appreciated!

Cheers,
M

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAKzdcNkP-3JrfgQJ70g4Dj6Wd-LAc6Rxcy0MHxJrqbKiRK2pyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best way to test handle optional FKs in model __str__?

[Micky Hulse]

On Sat, Jan 17, 2015 at 12:58 PM, Micky Hulse <mickyhu...@gmail.com> wrote:
> Great, that's what I wanted to know. Thank you for pushing me in the
> right direction and for the sample code.

Thanks again Vijay! After doing a bit of research, I slightly modified
your code (I needed an easy way to check nested attributes):

from operator import attrgetter
def get_fk_field(obj, path):
'''
Returns (nested) attribute if it exists.
Examples:
get_fk(self, 'vehicle.manufacturer.title')
get_fk(self, 'vehicle.model')
'''
try:
attr = attrgetter(path)
return attr(obj)
except AttributeError:
return None

>From what I know, operator.attrgetter works in Python 2.7 and above.

Anyone, pease let me know if the above code could be optimized.

Thanks again!
M

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAKzdcNn%3D8VobxFyh-wVzt5_Wjf%3DGTip0YOzy96SdBSNrPXv-aQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best way to test handle optional FKs in model __str__?

[Micky Hulse]

Hi Vijay!

Thank you so much for the reply/help, I really appreciate it. :)

On Sat, Jan 17, 2015 at 7:01 AM, Vijay Khemlani  wrote:
> I don't think there is a way in Python to do that directly
> you could have a utility method that catches the exception, for example

Great, that's what I wanted to know. Thank you for pushing me in the
right direction and for the sample code.

Have a great day!

Cheers,
M

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAKzdcNk5j0aaPehjLupy8XVEicZB2_z4HQzsC-i3FttCME2xwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2 projects, 2 apps, bad templates ...

[Micky Hulse]

On Thu, Jan 24, 2013 at 7:38 PM, Tomas Neme  wrote:
> just to clarify:
> 

Whoa, that really helps clarify the setup!!! Very helpful! Thank you Tomas!!!

Until we can convert to virtual envs, your suggested solution(s) and
fixes should make me sleep easier at night.

Have an awesome day! :)

Cheers,
M

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

Re: 2 projects, 2 apps, bad templates ...

[Micky Hulse]

Hi Tomas! A million thanks for you help!

On Thu, Jan 24, 2013 at 7:34 PM, Tomas Neme  wrote:
> really, it should be your SHORT term goal.

Without airing our dirty laundry, I can't argue with that. I will push
a little harder to get us to convert our projects to envs sooner than
later. :)

> As for your problem, you can't expect to install FOOAPP in two
> different directories on the same environment (system global, in this
> case) and expect that to work OK.

I was worried about that. The decision to install the app in the other
project was the Django noob in me shinning through. :D

> You're supposed to install that just once, and USE it from different
> projects, if that's what you want to do. Also, if you're installing in
> the global system python installation, you should not put them under
> any single project's directory, but rather somewhere outside them,
> because otherwise you'll end up with modules that can be reached from
> two different paths (FOOAPP and ProjectA.FOOAPP) and that's bad.

Excellent tip. Thank you for giving me a fix. :)

To be honest, this was the first time I've used one app in multiple
projects, so we've never run into this problem before.

> Now for the templates. If you're making a reusable app and providing
> templates with it, you should do your best to make the templates
> reusable as well. The standard procedure is to have them under an
>  directory like this:
> AppDir/templates/appname/TemplateFiles.html
> so the idea is that if you need special modifications for a project,
> you can put your special templates in your project's
> templates/appname/ directory, and the template loader will find your
> local templates before it falls back to the app's directory.
> I hope that's clear enough.

Definitely! In fact, that's probably the one thing that I was doing right. :D

Only, in the case of DjangoProjectB.FOOAPP, we put new templates in
DjangoProjectB/templates/FOOAPP/TemplateFiles.html.

> Also, make sure your app has a MANIFEST for setup.py to be able to
> install non-python files (e.g.: your templates) when you install it
> without the -e option. Look at the distutils docs for more details

Interesting! Thanks for that tip as well!

I do have a MANIFEST.in file which has:

include *.md
+include LICENSE

(I think the pip installer did not like the +)

I did not realize that I should account for templates like you say! I
appreciate the advice.

Thanks again Tomas! I owe you one! :)

Cheers,
M

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

Re: 2 projects, 2 apps, bad templates ...

[Micky Hulse]

Hi Tomas! Thank you for your reply, I really appreciate it. :)

On Thu, Jan 24, 2013 at 6:12 PM, Tomas Neme  wrote:
> Use virtualenvs. That's basic for any serious python development
> you'll want to do.

Totally agree. Setting up virtualenv's are our long term goal.

> Besides that, you might add DjangoProjectA to sys.path on ProjectA
> (and add DjangoProjectB to sys.path on ProjectB) in their respective
> manage.py files.

I'll look into that, thanks for the tip! :)

> On the other hand, why does pip install -e install it under ProjectA's
> directories? that shouldn't happen, you should end up with a SINGLE

Doh, I probably did not explain things clearly. Sorry about that.

I installed FOOAPP from DjangoProjectB's root project directory; the
pip -e installation put FOOAPP into:

DjangoProjectB/src/FOOAPP/...

Just to clarify further, I ran the pip install from DjangoProjectB/--->here<---

> FOOAPP package, probably in /usr/local/lib or something. Try removing
> (or renaming so it's not there under that name, anyways)
> ProjectA/FOOAPP and see if adding FOOAPP to INSTALLED_APPS uses the
> global version (the one you installed with `sudo pip`)

Thanks for tips Tomas! I will experiment with the things you
suggested. I really appreciate it.

I'm hoping we can convert everything to virtualenvs sooner than later.
The side-by-side projects with a pip installed app that has the same
name in both projects is probably what's weird about our install (and
no virtualenvs, like you've pointed out).

A part of me wonders if it would have been best to just import FOOAPP
from DjangoProjectA into DjangoProjectB and syncdb (wouldn't that give
me separate databases, but they would share the same Python code,
right?)

Well, anyway, many thanks again for the help and tips, I appreciate it! :)

Cheers,
M

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

2 projects, 2 apps, bad templates ...

[Micky Hulse]

Noob alert! :D

I work on a server where we have multiple Django projects that all
share one Django installation.

Each project has it's own subdomain.

At this time, we aren't using virtual envs.

Situation:

1. I built a basic application (let's call it FOOAPP) inside of
DjangoProjectA; after using it for a while, I decided to put the app
on GitHub.

2. One of my co-workers wanted to use the same app, but he needed it
on DjangoProjectB; I installed FOOAPP using PIP from GitHub:

$ sudo pip install -e git+https://github.com/user/FOOAPP.git#egg=FOOAPP

... which put it in a "src" folder at the root level of the
DjangoProjectB project directory.

3. DjangoProjectB's FOOAPP now works great.

4. DjangoProjectA's FOOAPP templates all broke.

>From what we could tell, FOOAPP from DjangoProjectA was looking at the
template folder from DjangoProjectB.

We fixed the problem by being more explicit in DjangoProjectA's
settings.py file. In other words, we changed this:

INSTALLED_APPS = (
# ...
'FOOAPP',
# ...
)

... to this:

INSTALLED_APPS = (
# ...
'DjangoProjectA.FOOAPP',
# ...
)

And all of our templates came back to life.

Other than setting up virtual environments, is there a better way to
fix the problem? Being more explicit for this one particular app is
fine, bu I think it kinda feels like a dirty patch.

What did we do wrong? Why would Django look in a different project's
app for templates before looking in its own? Tips on how to avoid this
in the future?

Thanks!
M

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

Re: Model's optional __unicode__() return values?

[Micky Hulse]

Hi Chris! Thanks so much for your quick reply, I really appreciate it.

On Fri, Dec 14, 2012 at 3:41 PM, Chris Cogdon  wrote:
> oops... that should be "if x is not None", not "where x is not None"...
> Clearly I am still half in SQL mode :)

Sweet!!! Works perfectly:

return ' | '.join ([unicode(x) for x in (self.target, getattr(self,
'page_type', None)) if x is not None])

Much appreciated. :)

Have a nice holiday.

Cheers,
Micky

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

Model's optional __unicode__() return values?

[Micky Hulse]

Hello,

This is probably a dumb question, but...

What's the best way to handle optional __unicode__() return values?

In this situation, I'm wanting to return the __unicode__ values from
other models.

I've found myself doing a lot of this:

def __unicode__(self):
return _(u'%s%s%s') % (self.target, (' | ' if self.page_type else
''), (self.page_type if self.page_type else ''))

Which works, but seems clunky.

I've tried:

return _(u'%s') % ' | '.join(filter(None, (self.target, getattr(self,
'page_type', None

But that gives me:

Caught TypeError while rendering: sequence item 0: expected string, Target found

Tips would be appreciated. :)

Thank you!

Cheers,
M

-- 
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: JSONResponseMixin: Best handle "context" before dumping it to JSON?

[Micky Hulse]

Hi Russ! Wow, thanks so much for the quick reply and additional details! :)

On Wed, Dec 12, 2012 at 7:12 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> Can you use a try-catch to flag encoding problems? Sure - that's a
> completely reasonable solution.
> Is a blanket try-catch a bad idea? Yes, because it hides all sins. The
> exceptions you're expecting are quite predictable -- if dumps() can't encode
> the object, you're going to get a TypeError. Therefore it makes sense to
> catch the TypeError, and provide a response that indicates that encoding was
> the problem. If you catch *all* exceptions, and just assume that encoding
> was the problem, then the "once in a million that happens 9 times out of 10"
> will be some other error generated by the serialisation of the object that
> *isn't* a type encoding error (an attribute error in your serializer, for
> example). If you're masking those errors, they're much harder to find.

Awesome! That makes total sense!

For now, I think I'll add a try/catch TypeError check and then test
thoroughly for corner cases to see if I need further data-type
handling.

Thanks again for the pro help an assistance! I owe you one! ;)

Have a nice night.

Cheers,
Micky

-- 
Micky Hulse
Web Content Editor
The Register-Guard
3500 Chad Drive
Eugene, OR 97408
Phone: (541) 338-2621
Fax: (541) 683-7631
Web: <http://www.registerguard.com>

-- 
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: JSONResponseMixin: Best handle "context" before dumping it to JSON?

[Micky Hulse]

Hello Russ! Thank you so much for your pro help and informative reply.
I really appreciate it. :)

Sorry for my late reply... A few non-Django projects jumped in the way
of me tending to my list e-mails.

See my replies, inline, below:

On Tue, Dec 11, 2012 at 3:51 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> It's a little hard to provide an example here without knowing exactly what
> is being serialised -- that's why the example in the docs is deliberately
> naive.
> json.dumps() will handle almost all the datatypes that come out of the box
> with Python. However, as soon as you have non-default types -- querysets,
> models, or anything else -- the default handling falls over. Exactly what
> handling is required depends on what non-default types exist in the content
> you want to serialize.

Ah, I see. Now that you point it out, I understand now why the docs
left out those details.

Not sure if this will help, but here's the code that creates the data
I end up dumping to JSON:

<https://github.com/registerguard/django-ad-manager/blob/master/ad_manager/views.py#L148-L180>

(Note to future readers: those lines may move in a few days as I tweak
the code.)

Basically, I'm just getting string values from my table and not doing
anything special and/or handling any non-default types.

And just for completeness' sake, the JSON mixin is here:

<https://github.com/registerguard/django-ad-manager/blob/master/ad_manager/mixins.py>

... specifically, this line:

<https://github.com/registerguard/django-ad-manager/blob/master/ad_manager/mixins.py#L84>

(IBID)

... it's pretty much straight from the docs.

> Error handling really doesn't require anything more than catching the
> exception if the encoder fails.

I've been wondering if I could just add a simple try/catch, like this code here:

<https://github.com/registerguard/django-ad-manager/blob/57f77dd0b5b59351ad50629f72c9fbb2083b1dd7/ad_manager/decorators.py#L37-L44>



try:
data = simplejson.dumps(objects)
except:
data = simplejson.dumps(str(objects))



Note where str() is being used... Though, my co-worker has told me
that using "except" without an argument is bad style and frowned upon.

I'm sure once I've read through the links you've provided, I'll be on
the right track... The above try/catch solution seems a little too
simple.

> The solution will usually come in the form of a custom encoder class.
> Python's docs provide an example of how this can be done [1]; obviously,
> you'll need to adapt this to whatever data types you need to serialize.
> The other option is to use Django's serializers [2]; this mechanism includes
> built-in support for serialising querysets and objects, which removes the
> need for a lot of special handling.

Ah, great info! Thank you for pointing me in the right direction. I
plan on reading through these docs tonight.

Much appreciated and have a great night!

Cheers,
Micky

-- 
Micky Hulse
Web Content Editor
The Register-Guard
3500 Chad Drive
Eugene, OR 97408
Phone: (541) 338-2621
Fax: (541) 683-7631
Web: <http://www.registerguard.com>

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

JSONResponseMixin: Best handle "context" before dumping it to JSON?

[Micky Hulse]

Hello,

I'm modifying a version of this code (JSONResponseMixin):



... so it can handle jsonp and caching (so far so good)... I was just
curious, the comments say:



# Note: This is *EXTREMELY* naive; in reality, you'll need
# to do much more complex handling to ensure that arbitrary
# objects -- such as Django model instances or querysets
# -- can be serialized as JSON.
return json.dumps(context)



Question: I'm just wondering if anyone could provide some examples of
non-naive handling?

Should I iterate over the context and check the type to make sure it's
serialize (if not, try to serialize or throw an error)?

So far, I've found that I do most of my checking in my view (not the mixin):



class Api(JSONResponseMixin, BaseDetailView):

def get(self, request, *args, **kwargs):
# Basic checking here, before rendering "data" list to response...
return self.render_to_response(data)



Going back to my question: I can live with what I have now, but I'd
like to make my code as robust as possible... If someone could give me
some pointers on how to best handle "context" before dumping it to
JSON, I'd appreciate it. :)

Have a nice day!

Cheers,
M

-- 
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 1.3] list_display, __unicode__ and sorting

[Micky Hulse]

Hello,

Would the below be an OK way to sort __unicode__ in the admin list_display?

Model:

def uni_sort(self):

return self.__unicode__()

uni_sort.admin_order_field = 'sort'
uni_sort.short_description = _(u'name')

Admin:

list_display = ('uni_sort', 'parent', 'name', 'slug',)

...

To save ya'll some time, the docs say:

[[

The __str__() and __unicode__() methods are just as valid in
list_display as any other model method, so it's perfectly OK to do
this:

list_display = ('__unicode__', 'some_other_field')

Usually, elements of list_display that aren't actual database fields
can't be used in sorting (because Django does all the sorting at the
database level).

However, if an element of list_display represents a certain database
field, you can indicate this fact by setting the admin_order_field
attribute of the item.

]]

Unless I'm mistaken, this does not work:

__unicode__.admin_order_field = 'sort'

Otherwise I could just do this:

list_display = ('__unicode__', 'parent', 'name', 'slug',)

My question:

Is it overkill to create a method, that returns the __unicode__ value,
just for the sake of being able to order on the "sort" field?

Thanks!

Cheers,
M

-- 
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: What does this code do? Also, testing decorator via terminal?

[Micky Hulse]

On Sat, Sep 1, 2012 at 10:47 PM, Melvyn Sopacua  wrote:
> More precise, if it's an object instance that has HttpResponse as a
> class in it's inheritance chain.
> 

Thanks Melvyn! I really appreciate the help and description/clarification. :)

-- 
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: What does this code do? Also, testing decorator via terminal?

[Micky Hulse]

Hi Kurtis! Many thanks for your reply, I really appreciate the help! :)

On Fri, Aug 31, 2012 at 11:38 PM, Kurtis Mullins
 wrote:
> All that is doing is checking to see if the object named "objects" is an
> HttpResponse object.

Ah, ok! I think you've kicked me in the right direction here.

> that the objects.status_code *should* work, although I'm not sure if it
> returns a number or a string. I'm not sure why this isn't working for you,
> though.

I think it's not working for me because, in my view, I'm not returning:

return HTTPResponse(json.dumps(d), content_type='application/json')

... instead, I'm returning:

return {'this will be': 'JSON'}

Based on your reply, I think I now understand why the original author is using:

if isinstance(objects, HttpResponse):

... meaning, "don't do anything with `objects` if the view is already
passing an HTTPResponse". Essentially, that logic is just trying to
make sure that the view passes the right type of object to the
decorator... Correct? If so, then that's lesson learned for me: Never
try to combine two decorators before fully understanding how the code
works! :D

I thought I was being cool by trying to combine the two... But now I'd
rather spend my time learning how to convert this decorator so that it
works on CBVs.

Thanks again for the help Kurtis, I really appreciate it

Cheers,
Micky

-- 
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: What does this code do? Also, testing decorator via terminal?

[Micky Hulse]

On Fri, Aug 31, 2012 at 9:17 PM, Micky Hulse <rgmi...@gmail.com> wrote:
> I'd like to add:
> if objects.status_code != 200:
> return objects
> ... which is found via this code:
> <https://gist.github.com/871954>

Doh! After a bit of trial and error, I given up on trying to merge
those two code snippets.

I'd still like to know what `if isinstance(objects, HttpResponse)` is doing?

I've RTM'd:

<http://docs.python.org/library/functions.html#isinstance>

and

<https://code.djangoproject.com/wiki/HttpResponse>

... but what doe these bits of code accomplish when working together?

Thanks for listening. :)

M

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

What does this code do? Also, testing decorator via terminal?

[Micky Hulse]

Hello,

Silly question, but...

What does this code do:

if isinstance(objects, HttpResponse):
return objects

... full code found here:



I'd like to add:

if objects.status_code != 200:
return objects

... which is found via this code:



In other words, the final code would look like so (untested):



I just don't fully understand what the `isinstance()` bit is doing. :(

Also, how can I test decorators via the python shell?

Sorry if noob questions.

Thanks!
M

-- 
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: html compress advice

[Micky Hulse]

Hi,

On Thu, Jul 26, 2012 at 2:29 PM, Phil  wrote:
> Just looking for some advice/ wisdom really.

While not a direct answer to your question, there was a discussion on
the group recently on the topic of the spaceless tag:

"{% spaceless %} abuse (?)"


You might find some wisdom there. :)

-- 
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: Problem on 'if' on templates

[Micky Hulse]

On Jul 25, 2012, at 3:11 PM, fnando  wrote:

> Hello, beginner here. I'm getting an error at the IF statement, line 2 of 
> this snippet:


Could it be that you're using object as the loop variable, and object is also 
the global var? I might change it to:

for item in object.list

And use {{ item }}, for example, in place of your "object" var inside the for 
loop. 

-- 
Sent from my Macbook Wheel

-- 
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: {% spaceless %} abuse (?)

[Micky Hulse]

On Thu, Jul 5, 2012 at 5:00 PM, Russell Keith-Magee
 wrote:
> Good question. I'm not really sure *what* it's supposed to be used
> for. Trimming whitespace to reduce page size is one possible use; the

If you develop for IE6, there's the IE6 whitespace bug. One fix, that
I know of, is to remove all whitespace around the HTML.

I never use the spaceless tag myself, but just thought I would mention
another way one could utilize the tag.

-- 
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: Does adding editable=False to model require a data migration?

[Micky Hulse]

Hi Jerome! Thanks for your help, I really appreciate it. :)

On Apr 28, 2012, at 7:59 AM, Jerome Baum  wrote:
> Sounds like it. If you are using South then you can also run
> "manage.py schemamigration  --auto" and South will tell you
> whether it thinks a schema migration is required. If it isn't an

Great! I'm not using south currently. I have used it for another project and it 
sure did make life easier. 

I'm currently doing my schema/data migrations by hand (update model manually, 
create fixture (if needed, modify fixture data to meet schema changes), 
cleardata, drop tables via the sql shell, load fixture and do a syncdb. It can 
be a tedious process... :)

> nothing about the semantics of your data has changed, then you also
> don't need a data migration.

Sounds good to me! Thanks so much for your help!

Have an awesome weekend!

Cheers,
M

-- 
Sent from my Macbook Wheel

-- 
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: Does adding editable=False to model require a data migration?

[Micky Hulse]

>From the docs:

editable
Field.editable
If False, the field will not be editable in the admin or via forms
automatically generated from the model class. Default is True.

So, it reads like I can add the editable argument to the field without
having to migrate my data?

Thank you.

Cheers,
M

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

Does adding editable=False to model require a data migration?

[Micky Hulse]

Quick question:

Does adding editable=False to an existing model field require a data migration?

Thanks!
M

-- 
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: myproject/wsgi.py vs. myproject.wsgi?

[Micky Hulse]

On Mon, Mar 26, 2012 at 5:14 AM, Reinout van Rees  wrote:
> In 1.3, there was no wsgi file. So either you added it yourself or
> webfaction automatically adds it.
> 1.4 started adding that wsgi.py file. It should be a drop-in replacement for
> the one you have now, basically.
> (Only thing to watch out for: wsgi.py hardcodes settings.py, so if you want
> to use a productionsettings.py or so you should take a good hard look).

Thank you Reinout! I really appreciate the explanation. :)

I will use the wsgi.py as a replacement and see how it goes.

Much appreciated. Have a great day!

Cheers,
Micky

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

myproject/wsgi.py vs. myproject.wsgi?

[Micky Hulse]

Hello,

This is is probably a silly question, but...

I just installed a fresh copy ofDjango 1.4 (mod_wsgi 3.3/Python 2.7)
on my WebFaction server.

In 1.3, the command startproject (IIRC) generated a myproject.wsgi
that lived next to myporject folder.

In the 1.4 installer, the wsgi file is no longer generated and there's
the new myproject/wsgi.py file.

I have read the docs (and Googled around a little bit) but I don't
fully understand wsgi.py does.

..

Stupid questions:

1.

How are these two related (myproject.wsgi and wsgi.py)?

2.

Does one replace the other?

3.

Do I still need a myproject.wsgi? If yes: How do, or should, I
"connect" the two file so that they work together?

..

I think I just need a more simple explanation of how to utilize one,
or both, files (well, I already have an OK understanding of
myproject.wsgi, but myproject/wsgi.py confuses me).

Many thanks in advance, I really appreciate the help. :)

M

-- 
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: [1.4c2] The storage backend of the staticfiles finder doesn't have a valid location.

[Micky Hulse]

Hi Bill, thanks so much for you pro help and quick reply, I really
appreciate it! :)

On Thu, Mar 22, 2012 at 4:32 AM, Bill Freeman  wrote:
> Just a shot in the dark, but you probably want to leave DefaultStorageFinder
> commented out ...

That did the trick! Thank you so much, I owe you one. :)

Have an awesome day!

Cheers,
M

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

[1.4c2] The storage backend of the staticfiles finder doesn't have a valid location.

[Micky Hulse]

I must be overlooking something obvious. My error:



The static files collect just fine (currently, I just have admin files
to collect); the above error just shows up every time I run
collectstatic.

Settings:

STATIC_ROOT = '/home/billy/webapps/xyz_static/'
STATIC_URL = '/static/'
STATICFILES_DIRS = ()
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
'django.contrib.staticfiles.finders.DefaultStorageFinder',
)
INSTALLED_APPS = (
'django.contrib.staticfiles',
)

Sorry if this is an obvious one... I could not find anything useful
via a Google search.

Many thanks in advance!

Cheers,
M

-- 
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: dropdown select box in django

[Micky Hulse]

Your code looks good to me.

Maybe you need to restart apache (or similar)?

This is typically the format I use for choice fields:

LIVE_STATUS = 1
DRAFT_STATUS = 2
HIDDEN_STATUS = 3
STATUS_CHOICES = (
(LIVE_STATUS, u'Live'),
(DRAFT_STATUS, u'Draft'),
(HIDDEN_STATUS, u'Hidden'),
)
status = models.IntegerField(_(u'status'), choices=STATUS_CHOICES,
default=LIVE_STATUS)

Which is a technique taken from:



Maybe that article will help?

-- 
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: Generating a list of available templates

[Micky Hulse]

On Fri, Feb 10, 2012 at 6:40 AM, Patrick Wellever  wrote:
> I guess the main question is, is there some function I can use to return a
> directory on the template path?

I'm interested in this also.

I too have my own static pages app and have always thought it would be
easier for folks to choose from a list of files rather than have to
remember what's there on the file system.

I suppose one way to do it would be to create an FK to another model
what someone has entered the paths to available templates... But, I do
like the idea of reading the contents of a folder and having a
dropdown that updates dynamically (with code portability in mind).

Patrick, if you find a solution please post it back here to the list.
I will do the same.

Thanks!
M

-- 
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: admin list_filter: limit choices to model values?

[Micky Hulse]

On Wed, Feb 1, 2012 at 1:59 PM, Micky Hulse <rgmi...@gmail.com> wrote:
> Anywho... Anyone know when Django 1.4 is scheduled to be released?

<http://bit.ly/zEbdFW>

[quote]

The Django 1.4 roadmap

Before the final Django 1.4 release, several other preview/development
releases will be made available. The current schedule consists of at
least the following:

* Week of January 30, 2012: First Django 1.4 beta release; final
feature freeze for Django 1.4.

* Week of February 27, 2012: First Django 1.4 release candidate;
string freeze for translations.

* Week of March 5, 2012: Django 1.4 final release.

If necessary, additional alpha, beta or release-candidate packages
will be issued prior to the final 1.4 release. Django 1.4 will be
released approximately one week after the final release candidate.

[/quote]

--<https://docs.djangoproject.com/en/dev/releases/1.4-alpha-1/#the-django-1-4-roadmap>

-- 
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: admin list_filter: limit choices to model values?

[Micky Hulse]

Related to my original question:

On top of needing to limit list_filter in the admin, I also needed to
limit the user choices in my FK to auth.user. This bit of code does
just that:



Just thought I would share the code to help others.

I am wondering if I can apply the same logic, as a method, to list_filter?

list_filter = SomeMethod()

(probably not, but that would be nice)

Anywho... Anyone know when Django 1.4 is scheduled to be released?

-- 
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: admin list_filter: limit choices to model values?

[Micky Hulse]

On Fri, Jan 13, 2012 at 3:35 PM, Micky Hulse <rgmi...@gmail.com> wrote:
> Would it be possible for me to setup my list_filter to only show
> author names that have been assigned to my flat pages? For example,
> let's say I have 10 pages, and two of those pages have the been FK'd
> to "bjohnson" and "fjackson"... In my list_filter view, I would like
> to only see "bjohnson" and "fjackson".

Just as an update, I found this:

<https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_filter>

... and it looks like what I need... Unfortunately, it's new in trunk
(I'm on 1.3).

I am hoping there's something similar to SimpleListFilter in 1.3.

I'm now trying to figure out how to browse Django source for version 1.3. :)

I will post back with more info if I figure something out.

Thanks!
Micky

-- 
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: admin list_filter: limit choices to model values?

[Micky Hulse]

Maybe simpler: Is there an easy way to limit the list_filter to folks
with "Superuser status"?

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

admin list_filter: limit choices to model values?

[Micky Hulse]

Hi.

Not sure where to start... Just hoping someone can give me a kick in
the right direction.

I have built a flat page app that allows for an author FK (optional field).

When I setup the admin to allow author as a list_filter, the actual
filter list of authors is way to long to be useful.

Would it be possible for me to setup my list_filter to only show
author names that have been assigned to my flat pages? For example,
let's say I have 10 pages, and two of those pages have the been FK'd
to "bjohnson" and "fjackson"... In my list_filter view, I would like
to only see "bjohnson" and "fjackson".

Does any of this make sense? :D

Any tips and/or advice would be awesome.

Thanks!
Micky

-- 
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: Treebeard admin issues: Fieldsets break code...

[Micky Hulse]

On Tue, Dec 20, 2011 at 5:42 PM, Micky Hulse <rgmi...@gmail.com> wrote:
> Traceback:
> <http://dpaste.com/675982/>

Sorry, moved here:

<http://dpaste.com/675984/>

Let me know if I can provide more trace info.

Thanks!

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

Treebeard admin issues: Fieldsets break code...

[Micky Hulse]

Hello,

I am building a simple flat pages app and I am running into problems
using Treebeard.

For those not familiar with Treebeard:



Treebeard example app:



Ok, here's my code:



Traceback:



Everything works great when I remove the "filedsets" from the admin.

I don't understand why having fieldsets would break things...
Everything was working before adding Treebeard.

Just wondering if this is a Treebeard bug, or am I missing something
obvious here?

Note: Unfortunately, I have not found any Treebeard examples that use
fieldsets in the admin. :(

Any tips/help/advice would be spectacular! :)

Thanks!
Micky

-- 
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: Need help upgrading old view/url to new syntax...

[Micky Hulse]

On Thu, Nov 10, 2011 at 3:47 PM, Micky Hulse <rgmi...@gmail.com> wrote:
> Whoa! That works perfectly!

Ack! I spoke too soon.

My context variable name of "user" conflicted with the current
logged-in user (looks like there's already a "user" variable floating
around at the template level... I assume this variable comes from the
"django.contrib.auth.context_processors.auth" middleware?)

Quick fix was to set context_object_name = 'member' and update my
template code to match the variable name change
{{member.get_user_profile}} and everything is working perfectly!

I am not sure why the old functional view did not exhibit the same
variable name conflict.

Anyway, thanks again Andres!

Cheers,
M

-- 
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: Need help upgrading old view/url to new syntax...

[Micky Hulse]

Hi Andres, thanks so much for the quick reply, I really appreciate it.

On Thu, Nov 10, 2011 at 1:00 PM, Andres Reyes  wrote:
> See https://gist.github.com/1356199/bd1af5e81d51ef32a3f4aa29a7a9120c9a8ffe85
> The problem is that you're overriding get_queryset when you should be
> overriding get_object

Whoa! That works perfectly!

Looks like I was missing "return context" as well.

Thank you so much Andres!!! I owe you one. :)

Have a nice day.

Cheers,
Micky

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

Need help upgrading old view/url to new syntax...

[Micky Hulse]

Hello,

I am in the process of upgrading this "old" functional code:

urls_old.py:


views_old.py:


Here's what I have so far:

urls.py:


views.py:


-

I just have a few questions:

1.

How can I access kwargs from the URL?

When I try self.kwargs['username'] I get this error:

"Generic detail view UserDetail must be called with either an object
pk or a slug."

2.

All I want to do is pass "user" and "profile" to my template...
Looking at my class-based view/url, am I going about this right (other
than the error)?

As it stands now, my "new" code seems kinda convoluted; having to say
"self.profile" and then call get_context_data just to pass "profile"
seems like a lot of extra work when compared to the older
function-based view.

-

Any tips ya'll could provide would be extremely helpful! :)

Thanks in advance!

Cheers,
M

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

[1.3] get_FOO_display() and prepopulated_fields?

[Micky Hulse]

Hello,

Are there any tricks to getting the display value of a choice field to
work with prepopulated_fields slug creation in the admin?



class Team(Base):

MALE = 1
FEMALE = 2
GENDER_CHOICES = (
(MALE, u'Men'),
(FEMALE, u'Women'),
)

slug = models.SlugField(_(u'slug'), max_length=100, unique=True,
db_index=True)
gender = models.IntegerField(_(u'gender'), choices=GENDER_CHOICES)

class TeamAdmin(admin.ModelAdmin):

prepopulated_fields = {
'slug': (
'title',
'gender',
)
}



The above (kinda) works, but it returns:

oregon-1
oregon-2

I would prefer if it returned:

oregon-men
oregon-women

Is there anyway for me to use get_gender_display in the admin's
prepopulated_fields?

Thanks!
Micky

-- 
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: Ajax replacement in django

[Micky Hulse]

On Wed, Oct 12, 2011 at 9:54 AM, Chandrakant Kumar
 wrote:
> But, isn't HTML5 is still work in progress? I mean, how will it behave on
> older browsers?

Good point. I guess it depends on the requirements of the project.

>From what I read, this sounds like a school project, so why not take
the time to explore state of the art web technologies?

Cheers,
Micky

-- 
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: Ajax replacement in django

[Micky Hulse]

On Wed, Oct 12, 2011 at 7:39 AM, lankesh87  wrote:
> Actually my project guide is asking me to search for ajax replacement
> in django. So that way we dont have to use ajax.

Perhaps it's a trick question?

Maybe you project guide does not like the "Ajax" buzzword? :)

Just call it XHR:




On a more serious note...

I have never used, and this might be a wild goose chase, but what
about html5 WebSockets?




The first answer here does a nice job at explaining the difference
between XMLHttpRequest and WebSocket technology:



Good luck!

Cheers,
M

-- 
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 1.3] django.views.generic.TemplateView example

[Micky Hulse]

Ack! Russ, I missed this e-mail! I am so sorry for the late reply!

Thanks so much for helping me out, I really appreciate it. :)

On Fri, Sep 30, 2011 at 9:08 PM, Russell Keith-Magee
 wrote:
> There's no need to subclass TemplateView and provide your own implementation
> of get_context_data() - the default TemplateView implementation does exactly
> (and I mean character-for-character exactly) what you've defined. So, you
> just need to deploy a default TemplateView in your urls.py:

Hehe! Thanks so much for pointing that out! I should have visited the
source code before posting my question. :(

It's funny, I was just going to reply to the list with my latest
solution... Long story short, my co-worker shared this code:

urlpatterns = patterns('',
   (r'^phone-list/$', ListView.as_view(
   queryset=Staffer.objects.filter(active=True).order_by('last_name'),
   )),
)

... and that motivated me to read the source code [1] and write this
in my urls.py:

from django.views import generic
...
(r'^(?P[a-zA-Z0-9]{32})/$', generic.TemplateView.as_view(
template_name='wire/feed.html',
)),
...

Exactly what you suggested that I do!

That's great though. Thank you for taking the time to help me out, I
really appreciate it. :)

> I know the class-based views docs aren't as good as they could be - thats
> mostly my fault. I also know that "read the source" isn't a real
> documentation answer. However, the CBV code is quite well documented
> internally, and isn't all that complex at the end of the day - if you've got
> questions about how to do something obscure with CBVs, a quick peruse of the
> source is well worth your time.

That works for me! Like I said above, I should have read the source
code before bugging the group. It's amazing how clear things can be
when reading the Django source code.

>From now on, I will be sure to go to the code before asking questions. :D

Thanks again! Have an awesome day.

[1] 
https://code.djangoproject.com/browser/django/trunk/django/views/generic/base.py#L114

-- 
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: What is the right way to use S3 as a storage backend?

[Micky Hulse]

Not sure if this will be of any help, but I switched from
django-storages to this:



I switched mostly because SORL was not working well with my S3
buckets... CuddlyBuddly has this:



Not sure if CuddlyBuddly has more features... I have been very satisfied.

Anyway, just FYI.

-- 
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 1.3] django.views.generic.TemplateView example

[Micky Hulse]

Code:



When using the new class-based generic views, is there a faster way
for me to pass URL params to the template?

Thanks!
Micky

-- 
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: Dealing with misc parts of a project

[Micky Hulse]

On Thu, Sep 22, 2011 at 8:54 AM, Simon Connah  wrote:
> So do you just tend to create a new misc app to hold all these little bits 
> and pieces or is there a convention for such things?

I asked a similar question here:



For a few projects at work, we use a "global" app that contains code
for use in other apps.

I am looking forward to hear what others have to say. :)

Thanks!
Micky

-- 
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: Custom model field/form: __init__() got multiple values for keyword argument 'baz'

[Micky Hulse]

On Wed, Sep 21, 2011 at 6:08 AM, Michal Petrucha  wrote:
> The remedy is simple, instead of kwargs.get use kwargs.pop.

Ahhh, I see! Thanks so much for the explanation and clarification.

Much appreciated.

Have an excellent day!

Cheers,
Micky

-- 
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: Custom model field/form: __init__() got multiple values for keyword argument 'baz'

[Micky Hulse]

On Tue, Sep 20, 2011 at 3:36 PM, Michal Petrucha  wrote:
> Well, the problem is that your defined fields.TestField.__init__ takes
> baz as either a keyword argument, or as the first positional arg. As
> with related fields, to pass the verbose name in this case you have to
> specify it as a keyword argument as well or specify your custom
> argument first and shift all other positional arguments. So, to fix
> your issue, choose either of the two following::

Ahhh, thank you for the clarification and for providing me with a
solution!!! I really appreciate it. :)

For some reason, I never thought to re-arrange the order of the
args/kwargs in the model TestField().

Optimally, I think I would prefer to keep the verbose name in the
first position (as an arg, not kwarg) in order to keep things
consistent.

If you look at fields.py:



Line #s 13 and 16, I do this:

def __init__(self, *args, **kwargs):
self._baz = kwargs.get('baz', None)

But when I do that, I get this error:

File "/.../test/fields.py", line 19, in __init__
TypeError: __init__() got an unexpected keyword argument 'baz'

Is there a way to pass around keyword arguments (from the model
TestField()) without having to be explicit?

Sorry if noob questions. I still consider myself a Python/Django noobie :)

A billion thanks for all of your help! I really appreciate it.

Have a nice day!

Cheers
Micky

-- 
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: Admin coding guidelines order?

[Micky Hulse]

On Sat, Sep 17, 2011 at 7:14 PM, Micky Hulse <rgmi...@gmail.com> wrote:
> How's this for organization(?):

Bare bones example:

<https://gist.github.com/1224591#file_admin_template.py>

Note on comments:

Trying to follow similar guidelines for comments as found here:

<http://tinyurl.com/9qc29u>

I have always liked that style of "Section separators".

-- 
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: Admin coding guidelines order?

[Micky Hulse]

On Sat, Sep 17, 2011 at 4:10 PM, Micky Hulse <rgmi...@gmail.com> wrote:
> But are what about the admin.py file?

How's this for organization(?):

<https://gist.github.com/1224591>

I guess I am curious how other folks would go about organizing things. :)

Thanks!
Micky

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

Admin coding guidelines order?

[Micky Hulse]

Hello,

I follow the rules on this page for my models (and other files/code):



But are what about the admin.py file?

Sometimes my admin classes can get pretty cluttery (form,
display_on_top, prepopulated_fields, filter_horizontal, fieldsets,
methods, other).

Do any of ya'll have any tips on keeping the admin classes organized
and readable?

Thanks!
Micky

-- 
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: When is a good time to use db_index? Rule of thumb?

[Micky Hulse]

Thank you Micah, Donald and Doug! I really appreciate the help! :)

That really helps to clear things up for me.

Have a great weekend.

Cheers,
Micky

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

When is a good time to use db_index? Rule of thumb?

[Micky Hulse]

Hello,

I have been using this great category/tag model:

https://github.com/praekelt/django-category/blob/master/category/models.py

... and I noticed that the author added a db_index on the SlugField of
the Category model.

I hate to admit it, but I don't think I have ever explicitly used
db_index parameter on any of my models.

When's a good time to use db_index? Is there a general rule of thumb
when coding Django models?

Sorry if silly question.

Thanks so much!

Cheers,
Micky

-- 
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: Static images for use in admin widget

[Micky Hulse]

Hi Tomas,

Thanks again for your tips and code samples, I really appreciate it.

I really liked that technique of using __init__.py to add a constant
to the settings.py file. Very cool!

I get what you mean now when you say "I think hardcoding the 'app/'
directory is the usual way to do this, you should be the one naming
your /static/app/ directory anyways"... Here's my current solution:

Top of my widgets.py file:

from django.conf import settings

(I removed the crosshair function and put it in a JS file in my apps'
static folder)

class Media:
js = (
'%smy_app/my_app.js' % settings.STATIC_URL,
)

In my_app.js, I link to crosshair.gif using a root-relative URI:

div.innerHTML = '';

(sometimes I wish JS could link to things relatively from the JS file
like css files do... Oh well, no harm in linking from the root path
here.)

With all that said, I did experiment with your suggestions. One
problem I ran into, was that os.path.dirname(__file__) returned a
server path to my apps' static folder (which is what I originally
asked for)... I soon remembered/realized that I needed a path to the
static collected folder, hence the use of the settings.STATIC_URL in
my widgets.py file.

Well, long story short (too late), as you can see, I did end up
hard-coding my app name into the widget file.

Like I said, I do like your technique of using __init__.py to add
vars/constants to the settings file. At one point, I was considering
doing something like this:

# __init__.py
settings.APP_NAME = 'my_app'
# Widget media JS:
'%s%s/location.js' % (settings.STATIC_URL, settings.APP_NAME),

But maybe that's serious overkill?

Anyway, many thanks for the inspiration and kick in the right direction. :)

Have an excellent night!

Cheers,
Micky

-- 
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: Static images for use in admin widget

[Micky Hulse]

On Tue, Sep 6, 2011 at 10:54 PM, Tomas Neme  wrote:
> this looks awful to me. Can't you stick that into a .js file and include
> that?

Doh, yah... If my django-fu skills were better, then maybe I could! :)

I should have posted the original code:



I am modifying to include a crosshair on the map by adding a simple JS
(non-dynamic) function.

Hrmm, now you got me thinking.

Maybe I could put the non-dynamic JS in an external file and then link
to it using "class Media:" (js), and from there, all I would need to
do is link to the image using a relative path (all within my apps'
static folder)? I will have to give this a whirl. :)

> With that over, you can use djangodocs-Form Widget Media and you can define
> a js-script somewhere inside your app/static/js/ directory. I think
> .
> I'm pulling this up pretty straight out of my.. the blue, and it's really
> too late, but I think this or something along this lines would work

Hehe!

Well, even if you are pulling things out of the "blue", you still ROCK!!! :D

Those are awesome tips/ideas/snippets! Thank you so much for helping
me out, I really appreciate it.

Thanks for giving me a huge kick in the right direction!

Have an awesome night.

Cheers,
Micky

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

Static images for use in admin widget

[Micky Hulse]

Hello,

Within an admin field widget that I am developing, I need to access a
static image from my app.

For example, I have a Google map and I would like to access
"crosshair.gif" from the apps' static folder (er, the collectstatic
folder).

Inside the widget's render() function, I have a formatted string that
contains embedded JS, and within that string I have a JS function that
looks like:

function showCrossHair(divId) {
...
div.innerHTML = '';
...
};

Just wondering what the best way to generically access my app's media is?

Currently, my app has static files collected to this location:

site.com/static/app/...

Just curious of the best way to handle linking of images within
widgets whilst keeping things modular?

I was thinking that I could import STATIC_URL from settings and then
do something like this:

div.innerHTML = '';

... where "%(static)s" is a reference to my STATIC_URL constant.

I don't really like the above solution because "app" is hard-coded
into the path.

Another solution might be to have a constant at the top of the widget
file that contains the path to a crosshair image:

CROSSHAIR_FROM_STATIC = 'app/crosshair.gif'

But that seems kinda funky too.

Am I making any sense here? :D

Any tips would be greatly appreciated.

Thanks!

Cheers,
Micky

-- 
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: CSS question

[Micky Hulse]

Hi Cal,

On Mon, Aug 22, 2011 at 12:49 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> OP - let me know if you resolved your issue. If not, ill show you the
> standard way of doing it.

I have always considered vertical-align pretty standard. ;)

> For the record - vertical align in some usages isnt going to work very
> nicely cross browser/versions.

I get pretty good results for the major browsers plus IE going back to
version 6.

Demo:



CSS/HTML tested via:

MAC:
Firefox 5.0.1, Safari 5.1, Opera 11.50, Chrome 13.0.x

PC:
Firefox 6.0, Firefox 5.0, Firefox 3.6.18, Safari 5.1, Opera 11.50,
Chrome 13.0.x,
IE 9.0.x, IE 8.0.x, IE 7.0.x, IE 6.0.x

Of course, that's just OS X and Vista/XP... I don't have an easy way
to quickly/directly test other platforms.

Cheers,
Micky

-- 
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: CSS question

[Micky Hulse]

P.S.

There's a great CSS listserv here:



-- 
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: CSS question

[Micky Hulse]

Hello,

[ot]

One way to do it...

You could make all of your elements (label/input) inside of your block
container display "inline" and then use something like this:

#someContainer * {
...
vertical-align: middle !important;
...
}

The "!important" (what I call "not important") is optional, depending
on your setup.

You might also play around with line-height and font-size (i.e. apply
the same sizes to labels and input fields) in order to tame things
down.

line-height: 1;

Remember that you should omit the unit for line-height property values.
Here's one reference for that:

<http://www.456bereastreet.com/archive/200603/css_lineheight_does_not_need_a_unit/>

I also use a reset/base/fonts css (I prefer YUI) in order to
reset/normalize my global styles... That might also help you.

Hope that helps.

[/ot]

Cheers,
Micky

On Sun, Aug 21, 2011 at 2:47 PM, Joshua Russo <josh.r.ru...@gmail.com> wrote:
> I know this is a bit off topic but I know this place is full of very
> helpful intelligent people. :o)
> Ok so I have an html block (div, p, doesn't matter what kind), and I fill it
> with a label and an input text field. The input is always larger than the
> label (rightly so), but the label is always aligned to the top of the block.
> I want to center the label in the block but for the life of me, I can't
> figure out how.
> Any ideas on how to fix it or where to go to get an answer?
>
> --
> 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/-/-6G_bvvoyM0J.
> 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.
>



-- 
Micky Hulse
Web Content Editor
The Register-Guard
3500 Chad Drive
Eugene, OR 97408
Phone: (541) 338-2621
Fax: (541) 683-7631
Web: <http://www.registerguard.com>

-- 
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: Re: Fieldsets in Admin Inline

[Micky Hulse]

Awesome! Glad that helped and thanks for the warning. One of these
days I will need this functionality myself. :)

Have a great day!

Cheers,
Micky

-- 
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: Fieldsets in Admin Inline

[Micky Hulse]

On Mon, Jul 25, 2011 at 2:57 PM, Juergen Schackmann
 wrote:
> is there a way to define fieldsets in the Inline?
> If could not find anything in the docs, but to me the idea sounds quite
> reasonable; so I am wondering if I just dont find it?!?!?!

Not tested myself, but have you tried the normal fieldsets = () in a
standard admin.StackedInline class?

Found this via a quick Goog search:

http://www.softwarematrix.cn/blog/django/add-fieldsets-with-admin-stackedinline

Seems like that should work... I normally don't used the "Stacked"
look for my inlines, so hopefully I don't send you down the wrong
path.

-- 
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: Simple example of custom user profile fields?

[Micky Hulse]

On Tue, Jul 12, 2011 at 7:57 PM, Brent  wrote:
> Unfortunately, no matter what kind of path I put for
> AUTH_PROFILE_MODULE, the same error appears.

I don't know your setup, but have your tried restating Apache? That's
probably a stupid question/suggestion, but maybe worth a shot?

-- 
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: Simple example of custom user profile fields?

[Micky Hulse]

This tutorial helped me:

http://www.turnkeylinux.org/blog/django-profile

Note: The above tutorial uses an FK to User model... The Django docs
suggest a OneToOne field.

Hope that helps.

Micky

-- 
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: Getting a subclass from an abstract Model

[Micky Hulse]

Try adding the below to your base class:


objects = models.Manager() # Admin uses this manager.

Sent from my iPhone

-- 
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 use the django-users mailing list properly and doing your homework..

[Micky Hulse]

I personally have a dedicated gMail account for lists, which forwards
everything to my main gMail account, and then all list e-mails get
filtered into a "lists" label/folder.



Here's some (random) thoughts from a (self proclaimed) listserv
veteran and Django/Python noob:

1.

Am I the only one that likes to read list e-mails via his smartphone?

Does SO have an app?

I love SO when I am using my desktop, but I don't think I have ever
visited that site on my iPhone. Granted, all my coding is done on my
desktop, so surfing/searching the net is easier, but still... Mail.app
is just easy. :)

2.

I work at a company where my computer monitor is visible to anyone
walking by... Having my e-mail client open (Gmail) is much less risky
than having to constantly surf SO (or other forums) to keep updated.

3.

Related to above, having to dedicate yet another browser "app" tab to
another site does not sound optimal.

4.

Folks interested in improving existing Django resources might contact
Charles Leifer:

http://charlesleifer.com/blog/django-snippets-site-improvements-what-would-you-see/

Looks like he is open to suggestions.

5.

I think the former jQuery Google group is a prime example of what I
would /not/ like to see:

https://groups.google.com/forum/#!forum/jquery-en

They moved the Google group to a dedicated forum:

http://forum.jquery.com/

Personally, I am not a fan of the jQuery forum software; if I have to
use a forum, I much prefer the standard vBulletin software.

What frustrated me most about the jQuery move is that they turned off
the Google Group list... I just don't visit the jQuery forum unless I
have an urgent question. I hate to admit it, but I never hang out to
help.

It makes me wonder how many folks left the jQuery scene because of the
move to forums?

6.

As I said above, I think SO is great, but is it just me, or has anyone
else found the barrier to participation an annoyance?

I can't count the number of times I could have "chipped in" to help
out, but because I did not have a "reputation" or "points", I moved on
with my life without sharing an answer.

I  personally don't have time to worry about gaining points and/or
voting for things (see #2 above).

.

For me, I think the moral of the story is this: The more resources the
merrier



Thanks for listening.

Micky

-- 
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: Global generic files? Best practice(s)?

[Micky Hulse]

Hello again Andre!

On Fri, Jul 1, 2011 at 7:58 AM, Andre Terra <andrete...@gmail.com> wrote:
> The standard really seems to be having a 'templates' folder for each app,
> but I think I did the same in my first 'hello world' project.

That's good to hear! :)

That's what I have been doing for all of my recent apps:

app/
templates/
base.html
app/
base.html
foo.html

One of the things I love about the Django templating language is that
I can then put a templates folder at the root level of my project:

project/
templates/
base.html
app/
base.html
foo.html

And, for example, the "new guy" can trump my app-specific templates...
Which means I always have a base look/feel tied to my app (sorry to
state the obvious here.)

Django rocks. :)

> I usually put that at the *bottom* of the settings.py file, and give each
> app's settings file a different name which usually follows an
> app_settings.py format.
> So basically something like this should work:

That's cool!

So, putting it at the bottom allows you to trump any setting already
defined in the main settings file... Nice.

I should search DjangoSnippets for a snippet that would dynamically
import any app/appname_settings.py files... Seems like a piece of code
like that would be pretty handy.

> Which brings us to my next point. I recently decided (out of the blue,
> haven't seen anyone else do it) to use the same solution to differentiate
> ..
> to the repo, ssh into the server, pull from the repo, kill python and reload
> the production page.

Oooh, now that's cool!!!

At my work, we normally just develop on a dedicated testing server and
then copy/paste code over to our live server...

I really need to start testing on my local machine... Seems like most
people do as you say, and pull/push from GitHub or BitBucket, work
locally, and then push things back up to the main repo.

Ok, so, here's my weekend todo list:

1. Hone Python skills:

* Google's Python Class
http://code.google.com/edu/languages/google-python-class/

* Dive Into Python
http://diveintopython.org/

2. Install (on my local machine)/update/learn more about Macports and VirtualEnv

* Practice using github to push/pull projects/apps.

> Sounds like you might be on your way to writing a truly reusable app, nice!
> I need to do that one of these days. I've never packaged anything for pip,
> but I promise to give it a try next month.

It's nice to have had the experience... Not that I have, or will,
build anything worth sharing (outside of my work)... It's just nice to
know how it's done. Thanks for the inspiration!

> Again, congrats and best of luck!

You too! Thanks again Andre, I really appreciate the help and advice. :)

Cheers,
Micky

-- 
Micky Hulse
Web Content Editor
The Register-Guard
3500 Chad Drive
Eugene, OR 97408
Phone: (541) 338-2621
Fax: (541) 683-7631
Web: <http://www.registerguard.com>

-- 
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 use the django-users mailing list properly and doing your homework..

[Micky Hulse]

Don't forget about GitHub Gists!

https://gist.github.com/

Considering a lot of Django projects are already hosted there... Seems
like a natural fit to me. :)

Also, Gist has the "fork" feature.

-- 
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: Global generic files? Best practice(s)?

[Micky Hulse]

Hello Andre! Thanks so much for your help, I really appreciate the pro
advice!!! :)

On Thu, Jun 30, 2011 at 6:01 AM, Andre Terra <andrete...@gmail.com> wrote:
> __init__.py
> app1/
> app2/
> appN/
>    __init__.py
>    models.py
>    views.py
>    urls.py
>    forms.py
>    templates/
>    utils.py
> project/
>    __init__.py
>    forms.py
>    settings.py
>    urls.py
>    utils.py
>    views.py
>    templates/
>    static/
>    (etc.)


Oooh, I really like the above setup!

That's similar to how I setup my very first Django project/app (sorry,
poorly packaged... er, not packaged at all!):

https://github.com/mhulse/code.hulse.me/tree/master/webapps

project/
__init__.py
manage.py
settings.py
urls.py
views.py
apps/
app1/
app2/
templates/
app1/
app2/

That layout seemed to work well for that particular project.

At work, we use a more out-of-the-box setup:

project/
__init__.py
manage.py
settings.py
urls.py
views.py
app1/
__init__.py
views.py
models.py
admin.py
helpers.py
managers.py
validators.py
widgets/
urls.py
forms.py
fields.py
utils.py
templates/
app1/
app2/
app3/
templates/
app1/
app2/
app2/

I really like your suggested setup though! Putting the apps at the
same level as the project seem to make a lot of sense.

Using the project as a container for utils.py is a great idea also. :)

> Which basically means my project is just another app. Nothing is
> preventing you from creating utils.py files in your apps, or even
> settings.py that get loaded from an import in your project's settings.

Yes! That sounds like an optimal setup! :)

When you talk about an app's settings.py file, do you just put
something like this:

from app import settings

... at the top of the project's settings.py file?

I had never considered doing that before... I will have to experiment.
Thanks for tip!

> I find this arrangement to be the best for my development workflow
> after many other attempts. This also helps newcomers avoid the often
> made mistake of referencing their apps in relation to the project like
> from project.app1 import views
> which would prevent the code from being reused in other projects.

Hehe, I can relate. Been there, done that. :)

> About your Place model, my recommendation/guess would be to abstract
> it one more time so that you could have a global BasePlace class which
> gets subclassed in an app-specific Place model.

That's an interesting idea!

I actually have several (abstract) models similar to "Place" that I
could use in my various apps/projects... I have found myself
duplicating the code for these various apps... It would be great to
put them at a higher level and import/sub-class as they are needed.

> Or at least that's what I thought last nignt before going to sleep. As
> I write this, I realize that a BasePlace would have no place (pun not
> intended) in your project, so maybe what you need is a package for
> your multiple apps which in turn gets imported into your project.

That's a great idea/tip!

You inspired me to create my first pip-installable package:

https://github.com/mhulse/django-goodies

Not much there at the moment, but I plan on adding more code at a later date.

The instructions found below were very helpful:

http://guide.python-distribute.org/creation.html

On my testing server, I was able to pip install django-goodies without
a hitch (I have yet to actually import and utilize the Place model in
a project/app though... It's getting late.) :(

> I'm pretty much guessing at this point, but in doing so, I have
> hopefully given you food for thought while also bumping the thread so
> that other developers will weigh in.

Definitely! Thanks so much I really appreciate it! :)

Have a great day.

Cheers,
Micky

-- 
Micky Hulse
Web Content Editor
The Register-Guard
3500 Chad Drive
Eugene, OR 97408
Phone: (541) 338-2621
Fax: (541) 683-7631
Web: <http://www.registerguard.com>

-- 
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: Global generic files? Best practice(s)?

[Micky Hulse]

Hi Andre!

Thanks so much for the reply, I really appreciate the help! :)

On Wed, Jun 29, 2011 at 9:51 AM, Andre Terra  wrote:
> If you're using it for multiple apps, but just one project and the apps are
> project-specific, then this code could very well lie in your project's
> utils.py or any other module.

Doh, sorry, I should have been more clear...

This code would be for one project. We do have multiple projects
installed... I had not considered sharing between projects! :)

I like your suggestion of using a utils.py file! I assume this would
exist at the same level as the apps? For example:

/my_project:

__init__.py
app1
app2
app3
manage.py
settings.py
templates/
urls.py
utils.py

This would be one example of code functionality that I would like to
share between my various apps:

https://gist.github.com/1027898

...

Just thinking out loud here... Bear with me for a moment.

Is it best to just copy code (like above) and duplicate it for each
app, or is it better to share one piece of code between apps?

Pros/cons of sharing code (like above) between apps:

PRO:

1. Following DRY principle.
2. Faster development times (common code in one place)?
3. Other?

CON:

1. When connected to many apps, the code becomes more risky if/when
re-factoring is needed.
2. Not self-contained to application.
3. Things become more splintered/abstracted/other?
4. Other?

> If you're writing code that's meant to be reused by third-parties, then the
> picture is rather different. I recently had a similar problem and I thought
> about writing a try/except block that tries to imports your global module
> with the necessary utilities and if it fails, it defines the functions
> itself. This way you allow for an easy global override of the needed
> utilities in case your needs vary.

Ooh, I like that idea! I think I have seen similar things in other
programming languages myself.

That's a great suggestion, thanks! :)

> I'm not sure this is the standard/best practice, but I believe I've seen
> similar bits of code in django core. A more experienced developer's point of
> view is most welcome here!

That's actually a great tip... I should probably browse through the
Django source code to find working examples. :)

Thanks so much for the informative and helpful reply Andre, I greatly
appreciate the help.

Have a great day!

Cheers,
Micky

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

Global generic files? Best practice(s)?

[Micky Hulse]

Hello,

I was going to start a "global" app for a generic "helpers.py" file; I
plan on using this code in multiple apps.

Question: Is creating a generic app a standard approach to storing
"global" code?

...

If the answer to the above question is "yes":

What's your preferred approach to handling generic/global code?

When using a "global" app how do you package apps that have files that
are not inside app structure? Would you change re-factor/re-arrange
your code/files or would you include the "global" app in your
package/packaging?

TIA!

Cheers,
Micky

-- 
Micky Hulse
Web Content Editor
The Register-Guard
3500 Chad Drive
Eugene, OR 97408
Phone: (541) 338-2621
Fax: (541) 683-7631
Web: <http://www.registerguard.com>

-- 
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: What are the advantages of Model inheritance?

[Micky Hulse]

On Thu, Jun 23, 2011 at 2:17 PM, bruno desthuilliers
 wrote:
> FWIW, I have been using model inheritance - abstract and concrete - in
> half a dozen projects, with about 30 model subclasses in one of them,
> and it JustWorks(tm).

That sounds pretty sweet! :D

I would love to see some examples.

I have been using abstract models for some of my projects... I find
them extremely useful:

https://gist.github.com/1043698

It works for me... Of course, I am still a noobie to Python/Django, so
may the feedback be kind. :: crosses fingers :: :D

-- 
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: WMD-editor: Where's wmd/urls.py?

[Micky Hulse]

On Wed, Jun 22, 2011 at 1:20 AM, Kevin Renskers  wrote:
> I think it's an error in the documentation. Since there are no views, it's
> probable that there are no urls as well.

Everything works perfectly if I ignore the part about the urls.py file. :D

Thanks Kevin!

Have a great day.

Cheers,
Micky

-- 
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: WMD-editor: Where's wmd/urls.py?

[Micky Hulse]

On Wed, Jun 22, 2011 at 1:20 AM, Kevin Renskers  wrote:
> I think it's an error in the documentation. Since there are no views, it's
> probable that there are no urls as well.

Hehe, that's a great point!

I did not think about looking inside the views.py file. :(

Thanks Kevin!

Cheers,
Micky

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

WMD-editor: Where's wmd/urls.py?

[Micky Hulse]

Anyone here using django-wmd-editor?

https://github.com/jpartogi/django-wmd-editor

If so, could you tell me what its url.py file is supposed to look like? :D

Maybe I am missing something obvious here, but wmd/urls.py does not
exist... What am I missing?

Thanks so much!
Micky

-- 
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: When to use a model property vs. method?

[Micky Hulse]

Thanks to everyone (Bruno, Tom, Ethan and Masklinn) for the extremely
informative and very helpful replies.

I really appreciate all of the professional help.

I have a lot to research and need to practice some of these newly
learned techniques/concepts... I may be back with more (this time,
Django-centric) questions. :D

Thanks! Have a great week!

Cheers,
Micky

-- 
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: When to use a model property vs. method?

[Micky Hulse]

Hi Tom and Bruno! Thank you so much for your pro help and assistance.
I really appreciate it. :)

Replying to both of you in this one e-mail... See inline replies below.

On Fri, Jun 17, 2011 at 1:42 AM, Tom Evans  wrote:
> Access it with MyModel.SEPARATOR or my_model_instance.SEPARATOR

Ahhh, I see now. Thanks for the clarification!

I now plan on re-factoring my simple "category/sub-category" model:

https://gist.github.com/1031882

> ..
> list of proper objects in every different place. Instead, I supply a
> property that serializes/deserializes the data as needed.

Awesome. That's a good description.

I have a few spots in my latest app that needs this type of
functionality, I will be sure to use property().

Not to state the obvious, but I just learned/realized that the
property decorator is Python 2.4's version of foo =
property(get_foo)... For some reason, up until now, I was under the
assumption that the property decorator was a Django thing! :D

> ..
> The behaviour is now dynamic, but any old code using
> instance.SEPARATOR will get still work, and use the new dynamic
> definition.

Ooh, that is interesting too! Thank you for the explanations and code
examples, that really helps clear things up for me. :)

On Fri, Jun 17, 2011 at 3:18 AM, bruno desthuilliers
 wrote:
> Python's object model is a bit peculiar (wrt/ most OOPLs at least),
> and I won't start to explain it here (this would require a full book
> FWIW).

Hehe!

Yah, you know, I am one of those few folks that learned (er, is
learning) Django before getting to know Python...

:: hangs head in shame ::

I am planning on spending a few upcoming weekends reading through the
online version of Dive into Python. :)

> To make a long story short, you have class and instance
> attributes, and since a small code snippet can say more than a
> thousand words:
> ..
>   # this is a class method
>   @classmethod
>   def yuu(cls):
>   print "%s.yuu" % cls

Oh, perfect! That really helps clarify things! Thanks for the code example. :)

I have never used the @classmethod decorator before. I will have to
read up on that one.

Looks like there's also @staticmethod... Interesting stuff! Thanks!

>> I am guessing that attribute = property
> Nope. "property" is a builtin Python class that implements the
> descriptor protocol and give support for simple computed attributes.

Ahh, I see now! Thanks for the clarification.

> ..
> you can transparently turn it
> into a computed one later if needed so no need to waste time with
> getters/setters.

Awesome! I get it now. :)

> ..
> wrt/ "public/private", there's no such thing in Python anyway. The
> (*very* strong) convention is to prefix implementation stuff with a
> single leading underscore which means "don't touch or your on your own
> if something breaks", but nothing prevents client code to mess with
> some object's internals.

I am reminded of a sidebar that I read in the Dive Into Python book:

"There are no constants in Python. Everything can be changed if you
try hard enough. This fits with one of the core principles of Python:
bad behavior should be discouraged but not banned. If you really want
to change the value of None, you can do it, but don't come running to
me when your code is impossible to debug."
-- 

... specifically, that last two sentences! :)

> Mostly, yes - with the exception that since Python can let you turn a
> plain attribute into a computed one without breaking client code, you
> don't have to use getters / setters "just in case" - you only use them
> if and when needed, and encapsulate them into a property (or a custom
> descriptor) so the client code don't have to care.

That's a great explanation. Thanks!

> Well, I usually redirect this kind of questions to c.l.py, since it's
> about Python and not Django...

I have not hear of c.l.py... I assume that it is a Python listserv?
Googling now. :)

I am a member of the Google Python group, but I am not a huge fan of
digest e-mails... I would love to find a python list that allowed for
e-mail for every message.

> Warning: this (and metaclasses) can be a bit mind-bending at first,
> and tend to become highly addictive once you get it ;)
> If I may suggest another related reading:
> http://wiki.python.org/moin/FromFunctionToMethod

Ooooh, interesting! Thanks for the linkage! Much appreciated.

Looks like my weekend is going to be full of pure python coding!

Also, thanks for pointing towards the wiki:

http://wiki.python.org/

That site looks useful.

> FWIW, Django relies quite a lot on metaclasses and descriptors for the
> ORM part.

Good to know. All of this information will give me stuff to research
over then next several weeks.

Thanks again Tom and Bruno! You folks ROCK! :D

I owe you one.

Have a nice day.

Cheers,
Micky

-- 
You received this message because you are 

Re: When to use a model property vs. method?

[Micky Hulse]

I am reading through Chapter5+ of Dive Into Python now... Seems like
that should cover all of my questions! :D

Sorry to bug the list with my ramblings.

Thanks again Bruno!

Have a great day all!
Cheers,
Micky

-- 
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: When to use a model property vs. method?

[Micky Hulse]

How's this for a rule-of-thumb(?):

1. Use a property (class/instance attribute) when an argument(s) is not needed.

2. If an argument(s) is needed (for runtime(?) calculations and/or
class/instance attributes need to be sanitized/checked/other), then
use a method (or getter/setter/descriptor).

No?

Hehe, thanks again!!!

Cheers,
Micky

-- 
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: When to use a model property vs. method?

[Micky Hulse]

Hi Bruno! Thank you so much for your help. I really appreciate the pro
assistance. :)

On Thu, Jun 16, 2011 at 1:42 PM, bruno desthuilliers
 wrote:
> 
> This could be written much more simply as "return self.modified >
> self.created"
> 

Omg, thanks! That's way better. :D

>> def get_separator(self):
>>     return ' :: '
> In this case (returning a constant), it would be much simpler to make
> it a class (or instance) attribute.

Ah, I think I get it.

Just to clarify things for me, does attribute equal a property or method? :D

I am guessing that attribute = property, so you're saying that I
could/should do this:

@property
def separator(self):
return ' :: '

> Properties are for computed attributes - that is, things that are the
> semantically (conceptually, whatever) attributes, but requires any
> computation, either on get, set or del.

Ah, interesting... I think I need to let this all sink in a little. :)

> But well, if you prefer java-
> like getters/setters, then choice is yours... Depends on the
> programmer's background,

I have a little experience with Actionscipt 3 and PHP5 OOP... I guess
I am used to the concept/practice of getters/setters,
(public/private/other) class methods and properties.

Are you saying that a non-property model class method is equivalent to
getter/setter? Or, maybe you are saying that the "lat =
property(_get_lat)" python property syntax is like
getters/setters/accessors in other programming langs?

Again, sorry if stupid questions... sorry if this is getting OT for
the Django list.

> and of course of whether the code was written
> before new-style classes and the descriptor protocol

I have not heard of this before. Googling "new-style classes and the
descriptor protocol" now. ;)

Looks like I have a lot of learning to do! :D

Thanks again, I greatly appreciate your time and assistance.

Have a great day.

Cheers,
Micky

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

When to use a model property vs. method?

[Micky Hulse]

Hello,

Just curious what the rule-of-thumb is for when it comes to using
model methods vs. properties. For example:

[code]

@property
def is_modified(self):
if self.modified > self.created:
return True
return False

def get_separator(self):
return ' :: '

[/code]

I feel like I have seen so many examples of methods and properties
that return the same type of stuff, I am just confused about when to
use one over the other.

Just hoping some of the pro Django/Python users on this list could
school me on this one. :D

Thanks so much!

Cheers,
Micky

-- 
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: When to use a model property vs. method?

[Micky Hulse]

On Thu, Jun 16, 2011 at 11:07 AM, Micky Hulse <rgmi...@gmail.com> wrote:
> Just hoping some of the pro Django/Python users on this list could
> school me on this one. :D

Actually, here's an example that I am working on now.

In my model, I have a CharField that holds the latitude/longitude with
values that look like:

44.08577787869324,-123.052459359169

I would like to write model methods to return latitude and longitude.

[code]

def lat(self):
# ...

def lng(self):
# ...

[code]

Should I use a property decorator?

Also, what is the difference between this:

[code]

def _get_lat(self):
# ...
lat = property(_get_lat)

[/code]

... and this:

[code]

@property
def lat(self):
# ...

[/code]

Sorry if stupid questions.

Thanks!
Micky

-- 
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: __unicode__() addition not working in basic poll application.

[Micky Hulse]

On Tue, Jun 14, 2011 at 11:01 AM, Kyle Latham  wrote:
 Poll.objects.all()
> []

What do you get when you try:

>>> p = Poll.objects.all()[0]
>>> p
>>> type(p)
>>> dir(p)

Try this too:

>>> p = Poll.objects.all()
>>> for x in p:
. . .print x (indent this line four spaces, hit return key once)
. . . (hit return key again)

Does any of that help?

Good luck!

Cheers,
Micky

-- 
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: Need help getting this snippet to work in Django 1.2...

[Micky Hulse]

On Mon, Jun 13, 2011 at 9:44 AM, Micky Hulse <rgmi...@gmail.com> wrote:
> Ooh, great tip! That looks very useful and possibly a little more
> simple/straight-forward than using a form field.

Too easy!

https://gist.github.com/1023327

Thanks for the help Martin and Alex, I really appreciate it! :)

Have an awesome day.

Cheers,
Micky

-- 
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: Need help getting this snippet to work in Django 1.2...

[Micky Hulse]

Hi Alex! Thanks for the reply, I really appreciate it. :)

On Sun, Jun 12, 2011 at 9:01 PM, Alex Kamedov  wrote:
> It'll be better to use validators with IntegerField
> In this case you can specify allowed year range.

Ooh, great tip! That looks very useful and possibly a little more
simple/straight-forward than using a form field.

Much appreciated.

Have a great day!

Cheers,
Micky

-- 
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 1.2] Admin ForeignKey edit link?

[Micky Hulse]

On Wed, Jun 8, 2011 at 12:51 PM, Micky Hulse <rgmi...@gmail.com> wrote:
> Looks like ticket #13165 is the way to go, but I thought I would ask
> the group before I consider applying the patch.

Ooops, here's the link to the ticket:

<https://code.djangoproject.com/ticket/13165>

-- 
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 1.2] Admin ForeignKey edit link?

[Micky Hulse]

Hi,

Looks like ticket #13165 is the way to go, but I thought I would ask
the group before I consider applying the patch.

I would love to have an "edit" pencil link for my model's FKs.

Other than applying the patch, are there any good work-arounds out there?

I was considering extending/overriding the Django admin templates, but
that just seems like overkill (I don't have a lot of time to spend on
this).

Could I somehow get the model PK and insert that into my FK's
"help_text" as an href?

Anyone out there been in a similar predicament? Did you apply the #13165 patch?

Does 1.3 have this feature (looking at the ticket, I assume the answer is "no")?

Any tips?

Thanks so much!

Cheers,
Micky

-- 
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: ManyToManyField limit_choices_to that instance via Django admin.

[Micky Hulse]

Hi Ryan! Thanks so much for the reply, I really appreciate the help. :)

On Tue, Jun 7, 2011 at 12:17 PM, Ryan  wrote:
> This is possible, but I'm not sure if you could do it via limit_choices_to.
> The admin docs shows how to accomplish this here:

Oooh, interesting. I will experiment with that solution. Thanks for
pointing me in the right direction.

I will post back here if I code something worth sharing. :D

Thanks again!

Cheers,
Micky

-- 
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: Custom select_related()

[Micky Hulse]

Hi Martin! Thanks so much for the quick reply, I really appreciate your help. :)

On Tue, Jun 7, 2011 at 1:48 AM, Martin  wrote:
> Why not create a Manager?
> Give it a method foo1_related() which then returns something like
> self.foo1_set.filter( your filters ) and a similar method foo2_related (if
> needed).
> You can then call A.foo1_related() and get what you need.

That sounds good to me! I will definitely head that route.

The primary thing I like about select_related is that I can do this on
the template level (for example):

{% with object.file1.select_related as foo %}
...
{% endwith %}

Where the context of the field has already been accounted for.

This might sound silly, my goal is to:

1. Get the first related file in the related files M2M
2. Get everything but the first file in the related files M2M

For #1, I could use {% with object.file1.select_related|first as foo
%}... and for #2 I could say {% for ... %}{% if not forloop.first
%}... But I thought it would be nice to have a couple of functions
that I could call, from the template, that behaved like select_related
and worked on either file1/file2 without having to hard-code
file1/file2 into the methods.

But I think I just have very little experience with
managers/django/python, and I am betting that your suggestion of using
managers will end up being the optimal route for this situation. :)

Thanks for the kick, I really appreciate it!!!

Have an awesome day.

Cheers,
Micky

-- 
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: Admin: Model ordering and relationship conditional __unicode__ return values?

[Micky Hulse]

Hello,

On Tue, Apr 19, 2011 at 1:28 PM, Micky Hulse <rgmi...@gmail.com> wrote:
> 1.
> Is it possible to order the models of my app manually (vs.
> alphabetically) when viewing the app page?
> 2.
> Relationship models: How can I return different __unicode__ values
> based on the relationship that I am viewing.

I think I got everything figured out. I am going to keep the current
ordering of the models and I don't plan on trying to do any sort of
conditional checking in the relationship's __unicode__ return values.
:)

Cheers,
Micky

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

Admin: Model ordering and relationship conditional __unicode__ return values?

[Micky Hulse]

Hello,

Couple of noob questions:

1.

Is it possible to order the models of my app manually (vs.
alphabetically) when viewing the app page?

See attached "ordering.png".

2.

Relationship models: How can I return different __unicode__ values
based on the relationship that I am viewing.

[code]

class SeasonPlayerRelationship(models.Model):

season = models.ForeignKey('Season')
player = models.ForeignKey('Player')

...

def __unicode__(self):
if self.season:
return 'Season'
else:
return 'Player'

[/code]

See attached "relationship.png".

In the screenshot above, just as an example, I would like "Player" to
get returned, and not "Season".

Optimally, I would like to return nothing for the relationship's
__unicode__, but when I do this:

[code]

def __unicode__(self):
return ''

[/code]

There is just a big gap where a __unicode__ label would appear (I
assume it's because the admin is spitting out an empty  or
).

Thanks!
Micky

-- 
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: Template tag does not like parameters with filters ({% with foo as bar %} question)

[Micky Hulse]

Hi,

> Is my above assumption correct? If so, is there an easy fix?

Someone else asked the same question a few hours after I posted my question:



They were much more to the point. :)

I need to train myself to look at the django source before asking for help here.

Thanks,
Micky

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: custom tag and filtered value

[Micky Hulse]

> The django sources for the standard tags show the method, make
> sure you are calling parser.compile_filter() on the relevant arg.

Thanks David!

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

Template tag does not like parameters with filters ({% with foo as bar %} question)

[Micky Hulse]

Hello,

I am using this Djangosnippet:



==

{% with my_date|date:"Y" as year %}
...
{% with my_date|date:"m" as month %}
...
{% get_calendar for month year as calendar %}
...
...

==

The above works, but when I try this:

==

{% get_calendar for my_date|date:"m" my_date|date:"Y" as calendar %}
...

==

I get this template syntax error:

[[

Caught an exception while rendering: Failed lookup for key
[my_date|date:"Y"] in u"[{u'month': u'08'}, {u'year': u'2011'},
{'my_date': datetime.datetime(2011, 8, 1, 0, 0)}]"

]]

I assume that this code is the culprit:

==

m = re.search(r'for (.*?) (.*?) as (\w+)', arg)

==

Questions:

1.

Is my above assumption correct? If so, is there an easy fix?

2.

This does not work:

==

{% with foo as bar and baz as x %}
{{ bar }}, {{ x }}
{% endwith %}

==

Is there something similar that does work? I don't mind using multiple
{% with %}s, but it seems like it would be cleaner as a one-liner. :)

A billion thanks in advance! I really appreciate it. :)

Cheers,
Micky

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Question regarding subdomains of a single project

[Micky Hulse]

> Check out this from djangosnippets: http://djangosnippets.org/snippets/1509/
> It allows you to specify multiple URLconfs and then choose which you
> ..

Anyone know if the ticket mentioned in the comments (#5034) of the
above djangosnippet has been resolved?

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