It looks like it'd make an excellent submission over at djangosnippets[1].
-Gul
[1] http://www.djangosnippets.org/
On 6/20/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> On Jun 20, 5:03 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
> > My code is below. It wouldn't take too much to
> >
;t be too bad. I'm glad to see 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&#
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
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 hid
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 ne
r field types as well.
-Gul
On May 10, 10:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-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
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 vari
L from django-values, but I can change any of the rest of it once I
settle on a name. Any suggestions?
-Gul
On May 9, 10:48 pm, Gulopine <[EMAIL PROTECTED]> wrote:
> Well, after a long time of work on it, I've committed a new version of
> django-values, incorporating feedback from t
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 interested.
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 o
I'd like to
be able to have Inventory.item_class be an actual class object that
can be instantiated using the parameters found in the related
ItemSettings model.
user = User.objects.get(username='Gulopine')
for item in user.inventory:
item = item.item_class(**dict((s.name, s.value)
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 Py
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 some
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 project)
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 sens
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 an
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 i
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 it'
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 were
nd third points really should be discussed together, because a
decision on one really does 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
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 sepa
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 midd
27 matches
Mail list logo
