What you describe is a ManyToManyField in disguise. A thinly veiled
disguise. Perhaps you might want to rethink what you actually need.
Be carefull not to think too much within the frame of Rational
Databases.
On 5/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I need to be able
+0
I have to agree that using DSN style names is a lot easier when you
aren't using a settings.py file. And the argument of only one way to
do it doesn't exactly work here, in my opinion, as it is a rather
widely used standard.
But, on the other hand, I think a parse_dsn function could easily b
Yeah, I always do that. Sorry.
On 5/29/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> Brant,
>
> On 4/24/06, Brant Harris <[EMAIL PROTECTED]> wrote:
> > I've created a proposal for working all of the Schema Evolution tidbits out:
> > http://code.djangoproject.com/wiki/SchemaEvolu
You got it. I could barely get any feedback on this project anyhow,
and I don't have much time right now to focus on it. So, no problem.
GL
On 5/29/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> jeroen, brant, ilias, etc:
>
> schema evolution was an idea suggested and specifically granted f
Custom manipulators are a pain. Could we think about integrating this
cookbook recipie into Django? Or at least start a dialogue about
improving this process.
http://code.djangoproject.com/wiki/CookBookManipulatorCustomManipulator
--~--~-~--~~~---~--~~
You recei
Mind if I take a shot at it?
On 6/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 6/13/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> > Custom manipulators are a pain. Could we think about integrating this
> > cookbook recipie into Django? Or a
Is there any discussion on the fate of manipulators? I've done a lot
on my own to make it more managable (including making a very cool
'remote manipulator that executes via ajax'), so I'd like to see where
this is all going, a plan or what not.
Thanks.
On 7/10/06, Adrian Holovaty <[EMAIL PROTEC
Being tired of all the craziness and mundane questions of #django, I
created another room on freenode: #django-devel, where we can discuss
the higher level Django related topics.
That's all.
--~--~-~--~~~---~--~~
You received this message because you are subscribe
e that's terribly confusing. Thusly, I am trying to
simplify it, and work it into something manageable. Then I can
release it. Hopefully I can combine this with a simplified
Manipulator system and we're off.
On 7/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Brantley
You keep #django open too and answer questions in there. Therefore
they have no reason to enter #django-devel.
On 7/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
>
>
> On 19-Jul-06, at 1:31 AM, Brantley Harris wrote:
>
> >
> > Being tired of all the craz
ons" wasn't supposed to hold any pejorative. Sorry if I have
offended.
On 7/19/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2006-07-19 at 12:08 +0530, Kenneth Gonsalves wrote:
> >
> > On 19-Jul-06, at 11:46 AM, Brantley Harris wrote:
> >
&
I have built a proposal for a new Manipulator system. Here are some
of the benefits of this new system:
- Custom form views become very simple, and intuitive.
- Validation aware models are harnessed.
- Forms are raised as an exception. This allows the writer to assume
the data is correct the wh
Finally! I've been waiting :)
On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> How To Be Sexy, Rule 1: The word "manipulator" has really got to go.
>
> Thoughts/comments/suggestions on Joseph's plan below, and on Brant's
> plan in Trac?
>
I know you want to get rid of the concept of "
On 8/23/06, James Bennett <[EMAIL PROTECTED]> wrote:
> 1. I'm not sure I like the idea of manipulators having a 'process'
> method which does everything; it would feel more natural to just try
> 'manipulator.save()', have that save if all is well, and catch any
> validation errors.
The problem is
On 8/24/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 8/23/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> > The problem is that to make it usefull to the user (read: api-user /
> > developer), you have to put the model save in a try / except block so
>
On 8/24/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> Brantley Harris wrote:
> > Maybe it's a philosophic question, but I see it best
> > defined in the "model" space because then it provides a modular
> > process for views to leverage.
>
>
On 8/24/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Al-rightly then... thoughts?
>
+1 ValidationErrors with an s, as I've said before: the more errors
returned at once, the better.
My problem with Joseph's proposal is that I believe it to be too tied
to the concept of the Model. Idealy
On 8/24/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>
> I gather this proposal means validation will be highly optimised for web
> forms and available only on POST? I understand that is the mainline use
> case, but I have a preference something that wasn't baked into HTML 'cos
> I'll have to hack
On 8/25/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > The whole raising a Form thing is just a shocking idea.
>
> Which, right there, is what I'm opposed to it. Often there's a reason
> why things are usually done one way, and I don't want to break from
> the standard way of using exception
That's all well and good but there are a few projects going on that
would be rendered useless if Django eventually did adopt SQLAlchemy,
including the Schema Evolution and the multiple DB branch.
Also this puts into question the philosophy of the full-stack, and if
you really want to be tied to S
On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> How To Be Sexy, Rule 1: The word "manipulator" has really got to go.
>
Thinger = "Manipulator" or "Form" # The thing that holds the fields
Bah, I try and try, but I can't figure out how to seperate the
manipulation process from the Thing
On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Hence, with this new API, the above view code would be written like this:
>
> form = ContactForm()
> if request.method == 'POST' and form.is_valid(**request.POST):
> send_email_and_redirect()
> return render_to_response
On 9/13/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> >
> > On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> > > For instance, using the given example:
> > >m
It shouldn't be. You're right.
The problem is the FormFields and Manipulators are in a sort of limbo
right now. And until we hear from the overworked core devs about it,
not much can be done.
On 10/20/06, Max Derkachev <[EMAIL PROTECTED]> wrote:
>
> FormField and its subclasses should define h
It's been noted serveral times that the Template engine is too closely
tied to the settings, which in turn is too closely tied to the core.
No one has offered a well made and clearly defined solution as to how
to really seperate it, to the best of my knowledge.
This should be discussed.
Aside:
I
On 10/26/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I've attached the first draft implementation of the manipulator ...
Yeay! Progress. I'm +1 for progress.
I like the direction towards simplification and separation, but I'm
not sure if the line is drawn at the correct place. Essentiall
Awesome. I approve. I'm warming to the whole "Widget" thing.
Although I hate that name, as it's specifically nondescript, I can't
think of another.
Some comments:
I'd like to see auto_id default to "id_%s" rather than False. Why not
just give it as the default?
I love clean_XXX(), and clean()
Maybe good practice, but not practical. I'd love to not have to use
tables. But practical CSS just isn't there yet. Yes, tables aren't
good for general layout, but they still have their uses, and forms are
a prime example.
On 11/30/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I would say not
Bah. I wish all the browsers supported "display: table-cell", that
would take care of all of this nonsense.
On 12/1/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> Brantley Harris wrote:
> > Maybe good practice, but not practical. I'd love to not have to u
One other thing:
-- newforms/forms.py - line 40 --
def __init__(self, data=None, auto_id=False): # TODO: prefix stuff
self.ignore_errors = data is None
Change to:
def __init__(self, data=None, auto_id=False): # TODO: prefix stuff
self.ignore_errors = not bool(data)
That way yo
Another (sorry, I'm pretty sure this is my last today).
A label keyword would be great for specifying the label for the field.
password2 = CharField(widget=PasswordInput, label="Password (again):")
Would render:
Password (again):
--~--~-~--~~~---~--~~
You recei
Next on the list should be a Login form.
Should be very simple.
On 12/5/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> > Adrian Holovaty wrote:
> > > What other sorts of things can we make abstractions for,
> > > given a Form?
> >
> > Fi
On 12/18/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
What do you think about adding a get_or_none QuerySet method?
+1
On 12/20/06, Joseph Perla <[EMAIL PROTECTED]> wrote:
There should also be an update_or_create() function.
+1
--~--~-~--~~~---~--~~
You recei
I've started to impliment my proposal for schema implementation and
realized that some database-data might need to be distributed along
with updates in the actual application, but there is no mechanism for
it. For instance, if an application requires some sort of seed-data,
but the requirement it
The rollbacks are really only usefull (in my mind) for when you go
forward on an app, and it turns out to break something, so you
"rollback". I do think it is a bit of a fringe-case, and can be
handled by proper database backing up. However, I don't see why we
couldn't support it. Plus, I've fi
May I be the first to say: YEAY!
On 5/1/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Attention all users of the Django development version (a.k.a. trunk)!
>
> We are merging the magic-removal branch to trunk this evening, Monday, May 1.
>
> Do not "svn update" your Django code unless you're
There's a line in the django URL Dispatcher documentation that is pretty
weird:
The URLconf doesn’t look at the request method. In other words, all request
> methods – POST, GET, HEAD, etc. – will be routed to the same function for
> the same URL.
Well, why? Most modern web frameworks allow
On Sun, Apr 14, 2013 at 4:56 AM, Łukasz Langa wrote:
> On 13 kwi 2013, at 23:48, Brantley Harris wrote:
>
> > It would be extremely easy to implement
>
> Such a statement suggests that the you didn't really think the problem
> through. Few things are "extremely ea
On Sun, Apr 14, 2013 at 2:40 PM, Luke Plant wrote:
> One reason for not doing this kind of despatch is that handling for
> different HTTP methods often involves a lot of common code. The classic
> form workflow would become longer, more complicated and/or less DRY if
> it was implemented using tw
Alex, I see http methods as being very basic, a part of the URL itself. In
other words, from the level of the web framework it's pointless to talk
about the URL as anything but a pair of request method and path.
Strangely, I'm not sure I agree with you that intelligent dispatch
decisions shou
On Mon, Apr 15, 2013 at 6:32 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> On Tue, Apr 16, 2013 at 6:12 AM, Brantley Harris wrote:
>
>> Alex, I see http methods as being very basic, a part of the URL itself.
>> In other words, from the level of the web
Having not been content with the state of Django migrations systems,
I've created one of my own:
http://www.bitbucket.org/DeadWisdom/migratory/
The idea is a database migration system that:
* Is simple.
* Doesn't make you use sql. This is an orm, we shouldn't have to use sql.
* Can b
2009 at 2:29 AM, Brantley Harris wrote:
>>
>> Having not been content with the state of Django migrations systems,
>> I've created one of my own:
>>
>> http://www.bitbucket.org/DeadWisdom/migratory/
>>
>> The idea is a database migration system that:
&
On Sat, Jan 3, 2009 at 4:43 AM, Russell Keith-Magee
wrote:
> In the aftermath of DjangoCon [1], Simon Willison, Andrew Godwin and
> myself started the django-migrations SIG [2], with the aim of getting
> a migrations framework into the Django core that draws from the best
> parts of our three res
On Sat, Jan 3, 2009 at 5:25 PM, Russell Keith-Magee
wrote:
>
> On Sun, Jan 4, 2009 at 4:28 AM, Brantley Harris wrote:
>> Ah yes, this is definitely a problem. See, I had to be able to import
>> based on a string (database backend), and I was having problems doing
>>
This really isn't meant to compete with Django, more with SQLAlchemy.
So far it seems like it's main competing feature is handling
multiple-databases easily and joining across them.
Damien Gassart saw these posts on digg, made by zzzeek and niemeyer,
the SQLAlchemy and Storm lead developers, res
Russell is being to harsh, I say great work.
But I don't think he's necessarily incorrect. Basically, the trouble
is that your solution doesn't really solve the bigger problems. Your
philosophy seems to be, "Those problems are spiky edge cases", but I
think the hope was they would be solved as
functions that share a namespace, rather than to allow
arbitrary functions at any point in your transformation sequence.
And testing in this case is simpler, I'd imagine as you don't have to
define all sorts of test for all sorts of mutations.
> ... So, if pre_christmas_2007.py exists,
> .
Er, could you re-factoritize your system into a stand-alone app? Then
it could be added by anyone. That seems like win/win to me.
On 8/9/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
>
> > I thought you were proposing moving away form ordered sequences? Besides:
>
On 8/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> * Every time I have written an API with a pre and post phase, I have
> ended up needing a post-pre and pre-post, and post-post, and pre-pre,
> and really-no-I-mean-it-pre
Well since the user defines the pre and post phases, he can ap
When the hell did "pragmatic" become a buzz-word? Oh god, I must be
behind the times, that's so ilpragmatic of me.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
On 8/15/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Let any (installed) app provide its own manage.py actions in a similar
> way -- something like:
+1. As I was reading Adrian's post, I was thinking the very same thing.
--~--~-~--~~~---~--~~
You received t
Please review ticket #5461, and the given patch. It refactors the
creation and introspection modules of all the backends. I am not able
to test on Oracle, so I need someone's help testing it.
Thanks.
--~--~-~--~~~---~--~~
You received this message because you ar
53 matches
Mail list logo
