On Mon, 2006-09-11 at 22:09 -0700, Gary Wilson wrote:
> Other open source projects seem to have success with Bug Days. Anyone
> have experiences with bug days?
I have quite a lot of experience with them in the GNOME project and have
dropped in on a couple of the Mozilla ones. Whether or not they
I'll take a look at it today.
Chris
--~--~-~--~~~---~--~~
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,
On 9/12/06, Chris Long <[EMAIL PROTECTED]> wrote:
>
> I'll take a look at it today.
>
> Chris
>
Thanks. Let me know if you need any more details on anything, I'll be
around most of the day.
Jay P.
--~--~-~--~~~---~--~~
You received this message because you are su
Nope, not a correct assumption.
Fixed in the latest version, I did try it with the model you have given
and it does work, but the test was not as indepth (lack of time this
week). So please give it a try and see if it fixes this problem.
Chris
--~--~-~--~~~---~--~--
On 9/12/06, Chris Long <[EMAIL PROTECTED]> wrote:
>
> Nope, not a correct assumption.
>
> Fixed in the latest version, I did try it with the model you have given
> and it does work, but the test was not as indepth (lack of time this
> week). So please give it a try and see if it fixes this problem
Latest changeset should fix it.
Chris
--~--~-~--~~~---~--~~
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 grou
On 9/12/06, Chris Long <[EMAIL PROTECTED]> wrote:
>
> Latest changeset should fix it.
>
> Chris
Worked like a charm!
I've got pretty minimal needs right now, when it comes to the
row-level permissions, but I'll keep working with it and let you know
if anything else happens.
My entire site right
Another problem along the same vein just popped up.
I was trying to add a "change user profile" row level permission for a
user, and I got this:
Traceback (most recent call last):
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/core/handlers/base.py"
in get_response
74. response
I've been slowly trying to work my way into helping out with Django,
but mostly at the outset I'm reading all the docs, reading the source,
and trying to figure out how it all ticks. Some areas are easier to
get than others. But as an interested person who'd love to contribute,
what's the best a
And another one. This time I'm trying to delete a row level
permission. Not sure what the correct fix for this one is.
Traceback (most recent call last):
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/core/handlers/base.py"
in get_response
74. response = callback(request, *call
Normally I wouldn't post here since I just posted to the ticket, but
since it's marked "closed" I didn't want it to be lost in the ether.
I've added a patch for ticket #648 and recommend reconsidering the
validity of the original point... Personally, I think that it would be
great to have {# comm
On Tuesday 12 September 2006 18:37, Hawkeye wrote:
> Normally I wouldn't post here since I just posted to the ticket, but
> since it's marked "closed" I didn't want it to be lost in the ether.
>
> I've added a patch for ticket #648 and recommend reconsidering the
> validity of the original point.
I've put together the beginnings of the manipulator framework
replacement, using ideas from the various proposals we've had, plus
inspiration from some prior art (the previous Django form/manipulator
system, plus some ideas from FormEncode).
For those of you arriving late, note that the three mai
On Sep 12, 2006, at 2:35 PM, Adrian Holovaty wrote:
> I've put together the beginnings of the manipulator framework
> replacement, using ideas from the various proposals we've had, plus
> inspiration from some prior art (the previous Django form/manipulator
> system, plus some ideas from FormEncod
Jacob Kaplan-Moss wrote:
> Out of curiosity, did you consider having a single ``Form`` object
> that may be bound or unbound? It seems like most of ``BoundForm``
> simply delegates down to the enclosed ``Form``, so perhaps ``Form.bind
> ()`` should store the data internally and just behave di
Adrian Holovaty wrote:
> The template would look like this:
>
>
> {% if form.sendername.errors %}{{ form.sendername.errors.as_ul }}{% endif
> %}
> Your name: {{ form.sendername.as_text }}
Does this 'as_text' mean that template will be the only place where an
actual form control
> Some tests for
> your patch wouldn't go amiss, though I realise it's a pain writing
> tests for code when you don't know if it's going to be used.
Unfortunately, I don't think I'll be able to find the time to write
tests.
Realistically, no external functionality should be impacted. Because
the
Hi guys,
I've been thinking about auto-escaping (due to another app I was having
issues with, and read the various auto-escaping proposals here on
Django-dev. I realise that this is largely solved by [1] and [2], but
just thought of another solution which might be easier than explicitly
turning
it looks good Adrian.
the only thing I could complain about it is not having a way to
replace the HTML input fields with something in the form itself.
eg.. I might want to use dojo's textedit stuff (which has custom html
it needs to generate) instead of a regular textfield.
also.. it would b
I've been working on the same thing, but my ideas differ slightly from
Adrian's. In a lot of way we're on the same page though, so that much
is encouraging :) I've liberally stolen ideas from both FormEncode and
a version of Zope 3's formlib.
There are four main classes the mostly correspond to A
On 9/12/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Out of curiosity, did you consider having a single ``Form`` object
> that may be bound or unbound? It seems like most of ``BoundForm``
> simply delegates down to the enclosed ``Form``, so perhaps ``Form.bind
> ()`` should store the data in
This suggestion was dismissed pretty fast last time it brought up. I
don't think this is the direction that the Django developers want to go
down.
Have you checked out my AutoEscaping alternative?
(http://code.djangoproject.com/wiki/AutoEscape%20alternative#SuggestedSolution)
It's simple and effe
On 9/13/06, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> This suggestion was dismissed pretty fast last time it brought up. I
> don't think this is the direction that the Django developers want to go
> down.
>
You can find that discussion here:
http://groups.google.com/group/django-developers/brow
Right. I somehow missed that entire conversation!
Thanks guys - I'm going back to bed :-)
--Simon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dj
I agree with some opions of Joseph Kocherhans:
1) The form name should be more clearly, Joseph named it Fields, maybe
I named it DataSet
2) There should be some validator that is not tied to a particular
field, how to include them and how to show the errors
3) 3 types of validation exceptions(don
> class Form(object):
> fields = {} # This gets filled with field names and data types.
> def bind(self, **kwargs):
> "Returns a BoundForm instance for the given kwargs."
> return BoundForm(self, kwargs)
What's the rationale for using **kwargs instead of a single data
para
On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote:
>
> > Some tests for
> > your patch wouldn't go amiss, though I realise it's a pain writing
> > tests for code when you don't know if it's going to be used.
>
> Unfortunately, I don't think I'll be able to find the time to write
> tests.
Side note, a
On 9/12/06, JP <[EMAIL PROTECTED]> wrote:
> > class Form(object):
> > fields = {} # This gets filled with field names and data types.
> > def bind(self, **kwargs):
> > "Returns a BoundForm instance for the given kwargs."
> > return BoundForm(self, kwargs)
>
> What's the rat
On 9/12/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Out of curiosity, did you consider having a single ``Form`` object
> that may be bound or unbound? It seems like most of ``BoundForm``
> simply delegates down to the enclosed ``Form``, so perhaps ``Form.bind
> ()`` should store the data in
Russell Keith-Magee wrote:
> On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote:
>>> Some tests for
>>> your patch wouldn't go amiss, though I realise it's a pain writing
>>> tests for code when you don't know if it's going to be used.
>> Unfortunately, I don't think I'll be able to find the time to wr
30 matches
Mail list logo
