I like it, always wondered if there was a way to do this in the core. Hope
the patch gets through.
J. Leclanche / Adys
On Fri, Dec 25, 2009 at 1:22 AM, Michael P. Jung wrote:
> On 2009-12-24 19:45, Stephen Crosby wrote:
> > In your address example, I'm not sure what advantage this
> > Composit
On Fri, Dec 25, 2009 at 3:55 AM, James Bennett wrote:
> On Thu, Dec 24, 2009 at 5:22 AM, Russell Keith-Magee
> wrote:
>> My concern with having two fields is that it introduces a false
>> dichotomy. There aren't just 2 options here - potentially any
>> permutation of the following list is possibl
On 2009-12-24 19:45, Stephen Crosby wrote:
> In your address example, I'm not sure what advantage this
> CompositeField has over just creating an address model/table and
> using a regular foreign key to reference it. You mentioned the need
> to create a field composed of other fields which to me so
On Thu, Dec 24, 2009 at 5:22 AM, Russell Keith-Magee
wrote:
> My concern with having two fields is that it introduces a false
> dichotomy. There aren't just 2 options here - potentially any
> permutation of the following list is possible:
While this is true, there are three common cases, which ca
Michael,
In your address example, I'm not sure what advantage this CompositeField has
over just creating an address model/table and using a regular foreign key to
reference it. You mentioned the need to create a field composed of other
fields which to me sounds a lot like a regular one-to-many rel
Quite often I find myself in the need of fields composed of other
fields. e.g.
class AddressField(CompositeField):
addressee = models.CharField(max_length=50)
street = models.CharField(max_lenght=50)
zipcode = models.CharField(max_lenght=10)
# ... more fields he
Hi,
I need similar functionality so I develop custom tag "qs" wich is not
tight to paginator (I don't know if it is better or not)
Used that way:
params ... dictionary with query string parameters which was prepared
in view
p ... any amount of other query string parameters as key=value you
want
On Thu, Dec 24, 2009 at 4:49 PM, James Bennett wrote:
> On Wed, Dec 23, 2009 at 9:44 PM, Russell Keith-Magee
> wrote:
>> I could live with either approach existing in the codebase. I won't
>> express a preference, though - I'll leave the decision of which
>> approach is preferable to those that w
On Thu, Dec 24, 2009 at 3:30 PM, Richard Laager wrote:
> On Thu, 2009-12-24 at 11:44 +0800, Russell Keith-Magee wrote:
>> This is completely backwards compatible as long as we keep
>> "STATE_CHOICES" to the same subset that exists today.
>
> Yikes, that's really restrictive. You want that list to
On Wed, Dec 23, 2009 at 9:44 PM, Russell Keith-Magee
wrote:
> I could live with either approach existing in the codebase. I won't
> express a preference, though - I'll leave the decision of which
> approach is preferable to those that will actually have to use it.
Honestly, given both the controv
10 matches
Mail list logo
