I don't know a lot about the history of Django or its developers, but
the impression I get is that every suggestion must answer the basic
question: "what real-world problem does this solve?"
In this case, I don't see a good answer to that. It's a different
solution, yes, that may have some (minor
On 5/29/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I propose the boring-but-functional "dbsettings" -- settings stored in
> the db -- and unless someone can come up with a REALLY good reason not
> to use that, I'm going to make a dictatorial call to paint the
> bikeshed MY color.
Personal
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> I'm definitely not suggesting a major infrastructure change. I'm just
> suggesting something similar to the passing views as callable objects
> instead of passing them as strings containing the names of those
> objects. It is just more pytho
On 5/29/07, Brian Rosner <[EMAIL PROTECTED]> wrote:
> One thing this makes me think of is allowing custom display names for
> applications. Currently there is no way to mark application names for
> translation (that I know of). This is a solution that can work in a
> more modular way than making
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> Well, it is called INSTALLED_APPS, not MODELS_OF_INSTALLED_APPS,
> right? :)
>
> The only reason that the "models module of the application is what's
> already used internally (in some places anyway) to refer to an
> application" is because
There's a new episode in the contiuing saga of django-values! Per
Jacob's recent dictatorial decision (and given a lack of opposition
thus far), I've renamed it to dbsettings, though the URL remains
unchanged.[1]
Other notable changes in this latest update:
* Removed assumptions of being placed i
I've been giving a bit of thought into many-to-many relationships
lately, and I (once again) ran across the task of creating a
relationship that contained additional information. I know this has
been bounced around before, but I can't seem to find any substantial
discussions on the topic, so I wro
On 5/31/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> However, you're not the first to propose this. In fact, I would doubt
> that you are even the tenth. This is a pretty common request.
Yeah, I know I had seen at least one mention of it before, and I
figured it was fairly common. I was j
On 6/5/07, Ilya Semenov <[EMAIL PROTECTED]> wrote:
> I run into the problem that the module doesn't seem to work well with
> Apache+mod_python. The new values are actually saved to the db, but
> not used until I restart Apache (neither as class members nor in the
> admin settings panel). I think t
On 6/7/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> Another solution is that multiple blocks with the same name inside a
> template are allowed as long as the template doesn't extend that block
> name (raise an error in that case).
>
> This way, it doesn't matter about the "meaningful" block, beca
I should note that I withdraw my +1. Not only does James bring up some
good points, I just realized that Noam's example can be done without
the whole {%block silly %} thing.
Just to test all this out, I just defined {% block title %} in two
different inherited templates and filled it in in the th
On 6/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Those are two I can think of off the
> top of my head; there are other instances, though.
For dbsettings at least, I expect a dynamic settings.SITE_ID would be
even more damaging. It loads settings from the database once during
startup an
On 6/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> No dbsettings depend on SITE_ID, as far as I can see.
The most recent version takes the current Site into account, using a
ForeignKey to contrib.sites.models.Site. It then uses
Site.objects.get_current() to get the Site for its queries, a
On 6/7/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I'm running into this problem/limitation in trying to fix
> http://code.djangoproject.com/ticket/4450 -- the previous (trunk)
> admin overrides the admin URLconf value for "/auth/user/" as a special
> case, and newforms-admin doesn't do that
On 6/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Oh, sorry, you mean dbsettings, the third-party app, not as an
> abbreviation and typo for database settings (internally in Django). My
> error.
Ah! Yes, that's understandable. I've been calling it django-values for
so long, the name "dbs
On 6/8/07, Noam <[EMAIL PROTECTED]> wrote:
> Let me improve my suggestion, so that it mostly solves James' concern
> and can be explained in one sentence:
>
> -
> Multiple blocks with the same name would be allowed, as long as all of
> them have the same content.
> -
I'm not sure
On 6/8/07, Noam <[EMAIL PROTECTED]> wrote:
> I admit that it looks better, because you gave meaning to the blocks,
> but you still have to use two files when one would have sufficed and
> would have stated clearly what you want.
Well, one might suffice for some, but I have a 4-layer inheritance
s
On 6/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Alternatively (and I suspect this is a variation on what Marty is
> suggesting), move all the url processing bit out of __call__() and into
> a function that __call__ calls. Then that function can be overridden in
> th
On 6/11/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Anybody else who isn't James or SmileyChris (since they've spoken in the
> tickets) got a strong opinion either way?
I had a bit of a conversation with SmileyChris about this in IRC
recently, though that was before this use case came up.
Also, consider the semantics of that function call. It's obvious that
the new email would be saved to the database, but it's not obvious
that it would be updated on the object as well. I would personally
expect something like user.save(email='[EMAIL PROTECTED]') to bypass the
current object, inste
On 6/19/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Why is request.session["_messages"] not enough? It can be a list of string
> messages.
Keep in mind how get_and_delete_messages() currently works; it
retrieves the messages and removes them so they won't show up on
subsequent page views. Ther
On 6/19/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Keep in mind how get_and_delete_messages() currently works; it
> retrieves the messages and removes them so they won't show up on
> subsequent page views. There would need to be some mechanism to
> achieve this,
Looks good to me, but I do have one thing to mention (and it's nothing
you did wrong, don't worry):
I'd prefer to be mentioned as Marty Alchin instead of Gulopine R.
Holiture, as that (nade-up) name has a long, strange history[1], and
it would probably just serve to confuse peopl
I expect this isn't the best way to ask this, but this is where the
dbsettings saga has played out so far, and you guys have a good idea
of what I'm trying to do, so I'm asking anyway.
The biggest hurdle to dbsettings at this point is that it caches
settings in a standard Python module, which onl
On 6/26/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> Assuming I've understood the issue, and if you don't expect concurrent
> writes, consider a BDB.
>
> Also, these may or may not be interesting:
> http://www.dekorte.com/projects/opensource/
Well, the dekorte stuff looks interesting, but I'm ce
On 6/26/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
> Forgive my ignorance, but this doesn't seem like a problem that will come up
> too
> often, so the solution is going to be pretty custom.
>
> Why would you be changing db settings on the fly?
I've put together an app called dbsettings[1] that
On 6/26/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> I have not yet used your app (although I had intended to until I read
> this) so I assumed you had worked this out already. The thing is, if
> each process has to look to a central location to retrieve/update, why
> not use the db as that cen
On 6/26/07, David Danier <[EMAIL PROTECTED]> wrote:
> Or why not use a python-file as "cache"? AFAIK Django already reloads
> the settings-file if is has changes. So why not use this and put the
> settings generated from the DB there (or in some file imported in
> settings.py). A post_save-handler
On 6/26/07, Jay Parlar <[EMAIL PROTECTED]> wrote:
> > That said, mod_python does provide its own autoreloading import
> > system[1], which could probably be used for this, I suppose. By doing
> > it that way, it would only reload the one file, which should happen
> > pretty quickly. It's definitel
On 6/26/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Seems to me that this is exactly the problem that Django's cache
> framework was designed to solve. I don't see a reason to reinvent the
> wheel for dbsettings...
>
> It should be extremely simple to invalidate the cache if/when the
> set
On 6/26/07, James Bennett <[EMAIL PROTECTED]> wrote:
> The docs claim the locmem backend is multi-process. Am I misreading that?
Hrm, no, you're not misreading it. I hadn't noticed that line before
you mentioned it, but I didn't see anything in the code that looked
like it handled the multi-proce
On 6/26/07, Thom Linton <[EMAIL PROTECTED]> wrote:
> The method signature changed (slightly) to taste:
>- get_version(obj,rev) -> [Model]/None
>- get_version_by_date(obj,date) -> QuerySet/list()
>- get_history(obj,offset=0) -> QuerySet/list()
>
>- set_version(obj,rev) -> [Model]/No
> > Do NOT do your development under mod_python! That is _NOT_ what it's
> > intended for.
>
> I think you've misunderstood Marty. He is not talking about modifying
> settings.py, he is talking about his dbsettings django app, which stores some
> parameters in t
Thanks to suggestions from this list, I made several updates to
dbsettings[1] so that it uses Django's existing cache framework rather
than trying to invent an alternative. In my limited tests, it seems to
retain existing funcitonality, but I don't have a working installation
of mod_python or Fast
To me, it boils down to something quite simple. Django's built-in auth
system uses usernames for identifying users, and email addresses as a
way to communicate with those users.
Yes, it might well be better for some sites to use email addresses as
the username, but in those cases, you would want
I definitely agree that some additional documentation is in order.
Over the past few months, I've released a couple apps that used to be
tied specifically to a project, and I had quite a bit of
back-and-forth on this list trying to figure out the best practices
for releasing them.
I think the sin
On 7/9/07, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> Messages should be stored with sessions.
>
> I would like to enhance the message system by a loglevel:
>
> debug, info, error.
>
> This way you could display important messages different.
There was some discussion on this a while back, and
On 7/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
> That's pretty much what I've been doing for a good long while now;
> djangosnippets.org, for example, is a project that has a settings
> file, root URLConf and templates, and everything else lives inside the
> apps it uses.
Good to know I was
On 7/9/07, Max Battcher <[EMAIL PROTECTED]> wrote:
> So, basically I'm suggesting adding a tags or labels field rather than
> a debug-style levels field. Then let template writers decide how the
> tags/labels might be used.
That's definitely something I had thought about, and I could stand
behin
It's been a while since I had mentioned much about my signed cookies
app, and I just wanted to check and see if there might be any updates
to the ticket soon. I've set up a Google Code project[1] for it, and
the app itself is quite robust, thanks to the excellent feedback I've
gotten.
I guess now
On 7/10/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> There's already a "copy-and-paste" version of the error traceback, so
> I'd recommend using that as the contents of the pastebin paste. It's
> just the traceback, as plain text, without any local variable values.
>From what I can tell, this
On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> All of this could be fixed by simply changing ModPythonRequest
> (django/core/handlers/modpython.py) to use req.path_info instead of req.uri.
> Is
> there any reason not to do that (aside from breaking backwards compatibility)?
I'm certainly
On 7/11/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
> What is djagoo's approach to passing values to the back end:
>
> A) create a string that is the SQL command and the values, pass that string to
> the db module.
>
> B) create a string that is the SQL command with parameter markers, pass that
>
On 7/11/07, James Bennett <[EMAIL PROTECTED]> wrote:
> No, the question here is whether Django is calling cursor.execute()
> with an empty params list or with a non-empty params list (the answer
> is: the latter, in most cases). Prepared statements are something else
> entirely, and should not be
On 7/11/07, Marc Garcia <[EMAIL PROTECTED]> wrote:
> I haven't seen any post or any ticket that anybody that is working on
> something like that. If anybody does, please let me know.
Check out django-multilingual[1] and its documentation[2]. I can't
guarantee this is exactly what you're looking f
On 7/12/07, James Bennett <[EMAIL PROTECTED]> wrote:
> The other modules you mention are optional to a certain extent (don't
> technically need flup to do Django-as-WSGI, can use Django without a
> database or with your choice of DB adapter), but simplejson is
> absolutely required for the seriali
Oh, I should also clarify something. I don't actually think simplejson
should be removed from Django itself. It's only a few files, and is
certainly worth saving people extra trouble for such a common case. I
just wanted to point out that it seemed strange to me to consider it a
core requrement fo
On 7/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> If you consider the testing framework core, then serialization is,
> because the testing framework uses it for fixtures.
See? I knew I was missing something obvious.
-Gul
--~--~-~--~~~---~--~~
You received thi
On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> As I was writing this, I realized that you can't do this in Python
> because you can't overload function names, but surely somebody smarter
> than me can figure out a clever way that model_instance.form() and
> ModelClass.form() would both do t
Some time ago, I pondered the possibilities for sharing the dbsettings
cache across multiple processes in Apache and elsewhere. I ended up
just using Django's cache framework, and I finally received
confirmation that it does work properly. However, my original
assumption that locmem isn't multi-pr
lective brain
trust has more to say about it than I do.
-Gul
On 7/16/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Some time ago, I pondered the possibilities for sharing the dbsettings
> cache across multiple processes in Apache and elsewhere. I ended up
> just using Django's
On 7/16/07, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> Every process gets an individual instance of the locmem cache. It means
> that it is not shared between processes --- each processes cache their
> own items, you may have duplicates, and items cached by one process do
> not affect other proc
On 7/17/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> b) the new meaning will lead newbies to a wrong understanding of SQL, since
> they will
> assume that 'WHERE col=NULL' means 'WHERE col is NULL', which it does
> not.
I've been avoiding this topic for the most part, but I'd like to put
my
On 7/25/07, z0n3z00t <[EMAIL PROTECTED]> wrote:
> Does anyone have any idea how I could hook into and change the field's
> value as soon as the value gets loaded from the db?
This is something that's been raised before, and there were a few
ideas proposed. Malcolm's looking over a variety of Fiel
On 7/26/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I'm writing the code at the moment, having had a few
> minutes this week to chew over approaches with Jacob and Jeremy Dunck
> whilst we were in the same location.
I would've loved to be there for that conversation, it sounds like a
blas
On 8/2/07, z0n3z00t <[EMAIL PROTECTED]> wrote:
> In the interest of anyone following this issue, I must confess that my
> previous solution broke down the minute I deployed it. What was
> interesting was that the `painful thing` - finding the context from
> which the __set__ is called, proved an
On 8/3/07, Tom Tobin <[EMAIL PROTECTED]> wrote:
> Hmm ... that could work; we'd just need a reasonable whitelist. .txt
> is the obvious case; I'm trying to think of others (typical
> configuration files, etc.). Off the top of my head, I'd add .conf,
> .ini, and the regex ^\..*rc$ -- can anyone c
On 8/3/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Wait - are you using Django templates to generate *Python*?
Actually, no. But since Django uses Django templates to generate (bits
of) Django[1] code, I thought it might be worth specifying.
> That's... just... *sick*.
Ah, but sickness m
This sounds like a far more complicated example than I had considered
when I was doing my work with dynamic models[1], but I did have
success getting syncdb to install dynamic models, provided a few
things are in order. I probably didn't document them well enough on
the wiki, but I could do so if
On 8/14/07, George Vilches <[EMAIL PROTECTED]> wrote:
> Thoughts?
Absolutely! Though I think this thread would get too far off-topic if
I rattle them all off right now. I'll do a little work on the subject
and see what I can come up with. Your approach looks very close to
what I was thinking, but
Okay, I'll post one last time on this subject, then leave you guys to
do what you're supposed to be doing. I'm only posting here in case who
heard me ranting find it interesting. I did manage to come up with a
solution like I mentioned, and I'll be posting it soon. It'd be up
already, but it seems
I don't really have much invested in this topic, but I really think
one of the other topics floating around has a decent approach to this
problem. If FileField and its subclasses had a way to swap out storage
mechanisms, a BLOB could be used internally to store the file data for
a FileField.
This
On 8/15/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I'd like to suggest a (somewhat controversial) extension:
>
> Let any (installed) app provide its own manage.py actions in a similar
> way -- something like::
>
> schema_evolution/
> management/
> __init__.py
>
On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I think it would merely delay the bikeshed discussions. If we don't
> have a required file layout, people will spend long mailing-list
> threads five months from now talking about how *they* do things, and
> how there should be an establishe
On 8/16/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> If you're going to tackle this issue, keep in mind that the
> infrastructure to save files already exists as part of the
> save_FILE_file() implementation in a model. This would need to be
> factored out to avoid duplication.
Of course,
On 8/16/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Yeah, add me to that list...
>
> I've been toying with the idea of file "backends" -- small modules
> responsible for storing and retrieving files (and their URLs). The
> filesystem backend is the most obvious, but this system could allow
On 8/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> The stuff I'm doing can safely be ignored because it's an addition on
> top of existing stuff. The reason for this approach is that it's 100%
> backwards-compatible and it doesn't fall into the trap of prematurely
> limiting options -- if
On 8/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> My preference would be to make a new ticket and reference the other
> ones. The advantage of this is that it keeps comments and retries
> concerning your patch easy to read and not tangled up with comments
> about the original ticket(s).
In trying to refactor FileField into a self-contained entity (and
allow exchangable backends), I ran across something I didn't remotely
expect.
I have a nearly-complete drop-in replacement for the existing
FileField, which works fine as long as leave the instantiation the way
it is currently (usi
On 8/20/07, Etienne Robillard <[EMAIL PROTECTED]> wrote:
> Again, we should probably "see" better your problem with some raw examples. :)
> Why should you need any management-specific methods for doing validation on
> a file field ?
>
> from django.newforms import fields
> class GenericFile(fields
On 8/20/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Now, as you correctly identify, this isn't really the right approach.
> We have been slowly refactoring fields, with the end goal of allow any
> user to define their own fields wrapping whatever database specific
> types may be available
On 8/20/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> There is indeed a reason: model field validation logic is in a
> separate module so that the logic doesn't have to be loaded into
> memory when you're using Django in production. As it stands, the
> validation code is only loaded when you us
On 8/20/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> There is indeed a reason: model field validation logic is in a
> separate module so that the logic doesn't have to be loaded into
> memory when you're using Django in production. As it stands, the
> validation code is only loaded when you us
Oh wow, I hadn't noticed Jython 2.2 yet (I've been out of town)! I'm
wondering this myself, since my employer uses strictly Java, and a
decent Jython might be just what I need to get them to start thinking
about Python. I might be doing some research on this soon, but I make
no guarantees to do so
On 8/25/07, James Bennett <[EMAIL PROTECTED]> wrote:
> The documentation issue is tough, because it really is a RTFM issue:
> all that's needed is some way to make it very clear to users of 0.96
> that they ned to use the 0.96 docs, and I wonder if perhaps changing
> the documentation landing page
This sounds to me like another advantage to having database "modes"
that are being discussed in other threads. Once the debugging view
begins, it could switch the db connection into a non-committal mode,
so the existing QuerySets don't actually touch anything.
-Gul
On 8/29/07, George Vilches <[E
I won't pretend to have tested everything, but it looks like Django on
Jython (Jango? Djython?) should work fairly well once it has a
database backend and a request handler. I have no idea how much it
would take to write a db backend using zxJDBC, but the request handler
should be fairly straightf
On 8/31/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > I won't pretend to have tested everything, but it looks like Django on
> > Jython (Jango? Djython?)
>
> Jyngo? [Not a native speaker, so I really don't know which sounds better]
Sorry, I wasn't very clear that I was joking. I wouldn't really
On 8/31/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I'm *way* to busy to work on this myself, but I wanted to chime in and
> give a big, fat +1 -- Django on Jython would be a *big* win for people
> looking to use Django in Enterprisy situations.
My thoughts exactly. It's something I'll def
I finally have some code to support multiple backends, but I'd like to
ask a question and write some documentation before I create a ticket
for it. I apologize in advance for such a long email, but there's a
bit of backstory necessary to ask the question.
I was wondering about the intended use of
ave a
workaround for pluggable FileField backends, which is what originally
started this discussion, but it'd be good to have this clarified so
that other subclasses can know how best to approach validation.
-Gul
On 8/20/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/
On 9/4/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Some methods that are implemented include get_filename(),
> get_absolute_url() and get_filesize().
Before this sparks any confusion, allow me to correct myself.
get_filename() is not an available method on the special File obje
On 9/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Model validation isn't something that needs to be run constantly.
> Strictly, it only needs to be run once - when syncdb is run - to make
> sure that the model isn't broken. Once the model has been validated,
> there isn't any need to re-
I'd love to participate in a Django sprint, but I don't know how
sprints usually work. It's sounding like it's only available for
people to be present in person, but there's no way I can get to
Chicago for a weekend. If it's available for participation over the
Internet, I'd be very interested in
That is excellent news! I'm especially excited to hear about the
inclusion of pop() on PyStringMap, since that would indeed solve a few
metaclass issues with Django (and perhaps others). It's starting to
sound like with a decent recent Jython SVN, we might be able to have
Django working soon with
On 9/5/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Yes -- I apologize for not explaining things. Anybody, all over the
> world, can participate.
Excellent. I already have the day off from work, so I just have to
decide whether I'd rather be doing a Django sprint or working at a
garage sale.
On 9/6/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Definitely. Before next Friday we'll try to get some ideas up on the
> wiki, too.
Does this mean there will be some sort of agenda planned for the
things we hope to knock out? At least the major stuff anyway?
-Gul
--~--~-~--~---
On 9/6/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Sprints are often a bit ad-hoc in terms of allowing people to work on
> what they want. Adrian posted a few ideas in his original mail.
Okay, that's what I was originally expecting.
> I was actually referring to writing up some things li
On 9/7/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Silicon Valley is *so* overrated. The real action is in Chicago. :)
If only I could justify the 3.5 hour drive it would take to get there.
:( It's so close, yet so far away. I'll most likely be there over IRC
(or whatever) though, so don't c
I probably shouldn't be putting my hat in this ring, but I've never
been a big fan of components and interfaces, so I'll provide some of
my own thoughts on the subject.
On 9/7/07, Joshua 'jag' Ginsberg <[EMAIL PROTECTED]> wrote:
> Problems:
> 1) While there is a good degree of drop-in replacabili
On 9/7/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Now, this point I might not be understanding correctly. Are you asking
> for Django's core to define an interface for each and every potential
> use someone might find for it? While I can understand the marginal
> benefi
On 9/7/07, Joshua 'jag' Ginsberg <[EMAIL PROTECTED]> wrote:
> Sure. Walks, quacks, yep. It's a duck. But if I want my own user model, I
> don't just have to make something that looks and acts like a User from
> django.contrib.auth -- I have to convince everybody else to use my version
> instead of
I don't want to be annoying, but I thought I'd ping this question,
because I'd like to get some feedback in time to have pluggable
FileField backends ready for consideration before (or during) the
sprint next week.
-Gul
On 9/4/07, Marty Alchin <[EMAIL PROTECTED]> wrot
On 9/7/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Could you post your current patch to Trac? I'd find it a lot easier to
> comment if I could look at some code. Using an object to represent the
> file rather than a bunch of special model methods definitely seems
> like the right direction
x27;d much rather encourage people to use that, unless
there's a compelling reason to have filename access, other than that.
I'm heading home now, so I'll have the patch up in an hour or two.
-Gul
On 9/7/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> On 9/7/07
On 9/7/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I think, though, for the sake of backwards-compat we shouldn't remove
> get_FIELD_filename() -- storing files on the filesystem is going to be
> by far the common case; let's not make those doing the common thing
> suffer.
Well, get_FIELD_
On 9/7/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> The patch isn't quite ready yet after all. Once I got the code home
> and started to plug it into a proper trunk checkout, it's taking a bit
> more effort than I expected to get it to work properly. I'd rather
&g
I just thought I'd give a quick heads-up to those few of you who are
paying attention to my dbsettings project[1]. I've finally gotten a
comprehensive test suite written and checked in. So, barring any major
features that are request or bugs reported, it's now as complete as
it'll get.
-Gul
--~-
On 9/8/07, Joshua 'jag' Ginsberg <[EMAIL PROTECTED]> wrote:
> So at my work we developed an app to provide object-level permissions.
> Ideally, we could ask a User object if it has permission on a certain object
> via a method in that User object, but absent hacking the User object, that's
> not g
On 9/7/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> I hope the source makes enough sense to give you guys a decent idea of
> how I'm approaching this. I'm not happy with the organization of it,
> but I'm not sure how best to organize everything. It seems like it&#
101 - 200 of 348 matches
Mail list logo
