On 5/18/07, Robert Coup <[EMAIL PROTECTED]> wrote:
> What about having a _first_set attribute on the proxy object that only
> allows laziness for the first time the value is set (ie. when it is set
> from the DB row)? Then any later set()s get live validation and coercion
> to geos objects.
I sub
On 5/18/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Well, I did try something like that at first, but the problem is that
> the proxy object is instantiated once, when assigned to the class. So
> ultimately, all instances of the Model use the same instance of the
> Proxy, which means that any a
On 5/18/07, Robert Coup <[EMAIL PROTECTED]> wrote:
> I think eventually, eliminating all the get_XXX_something() methods for
> fields (perhaps with the exception of display) would be an ideal case.
Yeah, get_FIELD_display would be fine, since that's not really
specific to any field type.
> What
Marty Alchin wrote:
> Well yeah, I didn't mean have it be just a file object with no other
> details. I was meaning it'd be a custom object that would have those
> attributes, but also had standard file methods that lazily called file
> system operations as necessary. Something like this:
>
> my_m
On 5/17/07, Robert Coup <[EMAIL PROTECTED]> wrote:
> Yeah, I just wonder whether for files/images its worth having a python
> object that provides the methods, since there is other metadata besides
> the python file object (like its name!)
>
> eg:
> my_model.attachment.file <- python file object
>
Marty Alchin wrote:
> I like that approach to this rather tricky situation. With all my
> recent work on DurationField, I took a chance at trying to make your
> code into something generic enough to work for both needs, and
> possibly others. I'm imagining a FileField that can act as a file-type
>
I like that approach to this rather tricky situation. With all my
recent work on DurationField, I took a chance at trying to make your
code into something generic enough to work for both needs, and
possibly others. I'm imagining a FileField that can act as a file-type
object, lazily opening the fi
Robert Coup wrote:
> Jeremy Dunck wrote:
>
>> In the gis work, we'd like to contribute a fair bit of additional
>> functionality to GIS fields and models with GIS fields.
>>
>> So far, field contributions seem to be largely done by adding
>> attributes to the model, such as FileField's get_%s_u
Jeremy Dunck wrote:
> In the gis work, we'd like to contribute a fair bit of additional
> functionality to GIS fields and models with GIS fields.
>
> So far, field contributions seem to be largely done by adding
> attributes to the model, such as FileField's get_%s_url.
>
> I think this approach m
On May 15, 11:09 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> It seems to me that keeping such things as attributes of the field
> would be desirable since they're related and since doing so would
> namespace them. Namespaces are good. :)
Agreed. This did cross my mind some time ago actual
Yeah, this then goes along with the topic of coercion on model fields,
since the current structure only allows basic Python types to be
created once the model is done. While working with DurationField, I
did manage to come up with a fairly simple way to do this, and it
seems to pass all the test I
On Tue, 2007-05-15 at 17:09 -0500, Jeremy Dunck wrote:
> In the gis work, we'd like to contribute a fair bit of additional
> functionality to GIS fields and models with GIS fields.
>
> So far, field contributions seem to be largely done by adding
> attributes to the model, such as FileField's get
In the gis work, we'd like to contribute a fair bit of additional
functionality to GIS fields and models with GIS fields.
So far, field contributions seem to be largely done by adding
attributes to the model, such as FileField's get_%s_url.
I think this approach may just be legacy from the old c
13 matches
Mail list logo
