someone else is
enjoying it!
-Gul
On May 16, 2:26 am, simonbun <[EMAIL PROTECTED]> wrote:
> Hi Gulopine,
>
> I've been testing your contrib and I'm liking it so far. Finding a
> suitable name is quite difficult...At the moment I'm calling them
> 'presets' in my code, but
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 could definitely see some value in this for the widget I'm designing
for DurationField, as it would give template designers the ability to
display only part of the widget (such as minutes and seconds, for CD
audio information, for instance), while filling the rest in either in
the view or as
This may be better suited for django-users, as it's somewhat a usage
question, but it's for DurationField, which is a proposed addition to
Django itself, and its solution may (I don't know yet, just guessing)
involve some slight code changes.
I'm planning to implement a SplitDurationField, based
On May 11, 10:06 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> My understanding of this whole thread is that the initial resistance was
> because we really do want to understand the use-cases before making any
> architecture change. [...] So if we
> can make that use-case possible without
007-05-10 at 08:14 -0700, Gulopine wrote:
> > I think this discussion could use a bit of revival, as it seems
> > obvious to me that there are groups that could benefit from some sort
> > of field-level coercion. In addition to my DurationField and the
> > various possi
I think this discussion could use a bit of revival, as it seems
obvious to me that there are groups that could benefit from some sort
of field-level coercion. In addition to my DurationField and the
various possibilities available with GeoDjango, there are other things
that would be useful in
Well, after a long time of work on it, I've committed a new version of
django-values, incorporating feedback from the previous discussion on
the topic[1]. There's still a little work I'd like to do on it, but
it's very functional right now, and ready for use and testing by
anyone who's
A little more research shows that I could also accomplish what I'm
looking for by tying into the pre_init or post_init signal, but then
I'd need a customized function for each field that needs processing,
on each model. This could be done, of course, and it would certainly
keep this coercion out
On Apr 17, 9:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Coercion of the type you describe is not required for any field
> currently supported. I would be hesitant to include coercion as a core
> part of the framework unless there is a generic need to coerce
> database values into
Hi all,
I had submitted a patch recently (#3982) that forces Django to use the
to_python method of individual fields when retrieving objects from a
database. I'm not being impatient, but I'd like to get some additional
feedback on this, in case I'm going about it all wrong, or if I'm
missing
I had wondered about something like this myself, actually. The way I
understand it, messages were created for the admin interface, where
they'd always only be successful, since arrors are handled separately.
But, given that messages are available elsewhere (I'm using them
extensively in a
On Apr 11, 8:10 am, "Wolfram Kriesing" <[EMAIL PROTECTED]>
wrote:
> The "add_data" adds the data to the context inside the render()
> function of the tag. Here lies the problem, the scope of the for loop
> gets destroyed when the for loop ends
Well, in a template context, that does make more
On Apr 10, 6:51 pm, Ian Holsman <[EMAIL PROTECTED]> wrote:
> The zyons version allows for:
> - constants at the site level (ie max blog comments can be different
> on different sites)
True, site-awareness would be a definite benefit that I hadn't yet
included.
> - allows users (registered and
On Apr 10, 6:28 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> How would a FileField or an ImageField work? How would the proposed
> CreatedTimestamp/ModifiedTimestamp fields work?
> ForeignKey? yikes.
Very true. I hadn't considered the many fields that wouldn't even make
sense themselves
In working a bit with this, I noticed something. Once these constant
definitions are moved outside the main field namespace, there's no
longer a clash of functionality between standard fields and these
constant values. That clash was the primary reason I had to recreate
the basic functionality of
On 4/10/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> Given that logic (which, as I said, may or may not be a correct
> recollection), I vote for Jacob's solution. In fact, it might be cleaner
> to have CreationTimestamp and ModifiedTimestamp fields (both subclasses
> of DateTimeField) so that
On Apr 8, 11:18 pm, "oggie rob" <[EMAIL PROTECTED]> wrote:
> So, my first question is whether this could be designed to work
> without respect to models. For example, there are a lot of cases where
> views might refer to the same data, but not the same models. It would
> seem cleaner if there
affect the other.
> I'm sure I'll have other opinions on this as I learn more about it
> (and actually *use* the code). But it looks promising so far -- it's a
> good feature addition that would come in handy for many people. Nice
> job, Gulopine!
I'm glad you like it! I really hope i
Hey all,
Many projects require a certain amount of calculations and other
features that are based on organizational (or other) policies, rather
than any technical requirements imposed by Python or Django. As those
policies may change and evolve over time, programmers are often
required to change
On Mar 30, 11:02 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> It seems a general consensus is forming over handling this sorts of
> "contributed" subframeworks: create them as third-party projects -- I
> highly recommend Google's code hosting athttp://code.google.com/--
> develop them
In working on my first major Django project, I've developed a few
subframeworks for Django that are greatly enhancing the project, and I
think many others would get good use out of them. Unlike my only thus-
far submitted app, however, these are considerably complex. In
addition to models.py, one
> Can you explain the reasons why one would want to use signed cookies?
> What (presumably security) issues are they intended to overcome?
Yes, the main concept here is security. Since the signature is based on
name and value of the cookie as well as the project's SECRET_KEY, a
change to any one
I've taken the liberty of writing up a contrib middleware to
transparently implement signed cookies in a Django app. It autmatically
signs and validates all cookies on its own, without any other code
needing to know a thing about it. That is, it cleans up after itself,
so that views and other
24 matches
Mail list logo
