Re: Single Table Inheritance

2011-03-30 Thread Alex Robbins
If you need to be able to filter and search across models, you could
try haystack.

http://docs.haystacksearch.org/dev/searchqueryset_api.html#filter

I've setup a site with a real base class, done queries on that and
then returned the child classes. It worked, but it felt pretty hacky
all the way through. (You solution has a much nicer interface than
mine, so your's wouldn't feel as bad I'm guessing.)

If you go ahead and make the switch to haystack you'll be able to
search across any and all of your models, without worrying about
inheritance. I've been very happy with haystack since switching to it.

Alex

On Mar 29, 3:20 pm, Johannes Dollinger 
wrote:
> Am 29.03.2011 um 20:46 schrieb Shawn Milochik:
>
> > They can create a custom manager on the abstract class that would
> > return an iterable, perhaps using itertools.chain() of the querysets.
>
> > It depends on what they expect to do with the output of this custom
> > manager, and they'd obviously lose the ability to treat this output as
> > a queryset by using additional sorts & filters and such. But if the
> > goal is to be able to get instances from all subclasses at once then
> > this is a viable solution, FWIW.
>
> FWIW, here is an implementation that does just 
> that:https://github.com/emulbreh/shrubbery/blob/master/shrubbery/db/union.py
>
> __
> Johannes

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



Re: Feature request - set variables in template

2010-08-27 Thread Alex Robbins
I think the thread Brian is thinking of is this one:

http://groups.google.com/group/django-developers/browse_thread/thread/31f0d2302c07a75b/1c41d02147316f3e?lnk=gst&q=New+context#1c41d02147316f3e

If everyone can agree on the tag's syntax, I'd definitely work on
writing the patch.

Alex

On Aug 26, 8:36 pm, Russell Keith-Magee 
wrote:
> On Fri, Aug 27, 2010 at 9:27 AM, Brian O'Connor  wrote:
> > I think this got brought up in the forums a month or so ago, but I'd like to
> > see a 'shortcut' for setting variables much like we have a shortcut for
> > registering inclusion templatetags.  Having to write a full fledged
> > templatetag to set a variable is a bit much.
>
> Sounds like a reasonable suggestion to me. Who's going to writing the patch 
> :-)
>
> Russ %-)

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



Re: New context template tag

2010-07-22 Thread Alex Robbins
Eric,

Thanks for the reply! django-template-utils does help some but, like
you say, you still end up writing a function and a custom node.

Is there a reason we couldn't add another template tag helper like
simple_tag or inclusion_tag? (I'll write the code and tests) Adding to
context seems (to me) to be a very common use case. With a helper like
this, I'd be able to write most of my template tags without needing to
drop down into the function/node paradigm. Maybe django does
eventually need to incorporate one of the third party solutions to
making template tags nice, but this could be a quick win that would
address a lot of the pain now.

Or maybe most people don't write lots of add_to_context type tags, or
the current third-party solutions are sufficient. If it isn't a common
problem for people, then it definitely doesn't belong in the core.

Thanks,
Alex


On Thu, Jul 22, 2010 at 10:23 AM, Eric Holscher  wrote:
> I usually use James Bennett's django-template-utils for this purpose. It has
> a nice, simple implementation:
> http://bitbucket.org/ubernostrum/django-template-utils/src/tip/template_utils/nodes.py#cl-11
> It still requires the annoying Node/function split though.
> I know there have been a multitude of third party attempts at improving
> Django's template tags, and I think it's commonly agreed that they are one
> of the more boilerplatey bits. Sadly none of the third party libraries have
> really become defacto, so it's hard to think about including any of them in
> core. It does seem like a place that could use some expose either in the
> docs or in the general community though.
> Cheers,
> Eric
>
> On Thu, Jul 22, 2010 at 9:26 AM, Alex Robbins
>  wrote:
>>
>> I am a huge fan of simple_tag and inclusion_tag. They take a common
>> template tag use case and make it very easy to write. It seems like a
>> common use case that isn't represented is adding a value to context. I
>> find myself writing tags to add a variable to context very often and
>> it seems like we should be able to abstract this out.
>>
>> I'm thinking it would work like this, but would love to get feedback
>>
>> @register.add_to_context_tag
>> def tag_name():
>>    do_some_python()
>>    return context_value
>>
>> This would turn into a tag that worked like this:
>>
>> {% tag_name as variable %}
>>
>> Which puts context_value into the context as variable.
>> 
>>
>> It could optionally take takes_context, and work like this. This would
>> make context the required first argument to the function, like
>> inclusion_tag.
>>
>> @register.add_to_context_tag(takes_context=True)
>> def tag_name(context):
>>    do_some_python_that_needs_context(context)
>>    return context_value
>> --
>>
>> Finally, it could take arguments like simple_tag or inclusion tag.
>>
>> @register.add_to_context_tag
>> def tag_name(some, arguments, it, takes):
>>    some_func(some, arguments)
>>    return context_value
>>
>> which would yield a tag that worked like this:
>>
>> {% tag_name some arguments it takes as variable %}
>>
>> -
>> Is this a use case other people have? Can anyone think of a better
>> name than add_to_context_tag?
>>
>> Thanks,
>> Alex
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
>
>
> --
> Eric Holscher
> Web Developer at The World Company in Lawrence, Ks
> http://ericholscher.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

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



New context template tag

2010-07-22 Thread Alex Robbins
I am a huge fan of simple_tag and inclusion_tag. They take a common
template tag use case and make it very easy to write. It seems like a
common use case that isn't represented is adding a value to context. I
find myself writing tags to add a variable to context very often and
it seems like we should be able to abstract this out.

I'm thinking it would work like this, but would love to get feedback

@register.add_to_context_tag
def tag_name():
do_some_python()
return context_value

This would turn into a tag that worked like this:

{% tag_name as variable %}

Which puts context_value into the context as variable.


It could optionally take takes_context, and work like this. This would
make context the required first argument to the function, like
inclusion_tag.

@register.add_to_context_tag(takes_context=True)
def tag_name(context):
do_some_python_that_needs_context(context)
return context_value
--

Finally, it could take arguments like simple_tag or inclusion tag.

@register.add_to_context_tag
def tag_name(some, arguments, it, takes):
some_func(some, arguments)
return context_value

which would yield a tag that worked like this:

{% tag_name some arguments it takes as variable %}

-
Is this a use case other people have? Can anyone think of a better
name than add_to_context_tag?

Thanks,
Alex

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



Any change this could make it in for 1.2?

2010-01-27 Thread Alex Robbins
This ticket adds label and verbose_name to apps. I know this would be
very useful for lots of people.
http://code.djangoproject.com/ticket/3591

Is it too late for it to make it into 1.2? What can we do to make sure
it makes it in for 1.3?

Thanks,
Alex

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



Django test runner

2009-05-28 Thread Alex Robbins

It would be really great if the test runner had an excludes option. I
would like to run tests from all apps, except for a couple I know are
bad. Should I just make my own custom test runner or is this something
others would like also?

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



Re: Dallas 1.1 sprint - dates?

2009-04-03 Thread Alex Robbins

I live in the Dallas area and would be interested in coming, whenever
it happens.

On Apr 2, 12:45 pm, Jeremy Dunck  wrote:
> Hey all, I was considering putting on a Dallas sprint for 1.1.  I'm
> not sure exactly when 1.1 will ship, but soon-ish, so I was thinking
> about trying to make the sprint the weekend of 4/10 (Easter weeked) or
> 4/17.
>
> Any preference?  Who can make it or will consider making it?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---