On 9/11/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
>
> About validate_exception, this is the signature of the corresponding
> method in unittest:
>
> *assertRaises*( exception, callable, *args, **kw)
> they have removed message, but since args and kw will be passed to
> callable, these are the
I'll chime in just for a few cents here.
First, I think it's worth noting that most Python programmers find
little value in how many characters they have to type. Sure, Python is
generally less verbose than many other languages, but only to the
extent of making it more readable. So kep
I'll be looking into this a bit this week, hopefully I can get
something nailed down before the sprint. It's rearing its ugly head in
one of my projects that really can't afford to have models
disappearing from the admin. I'll post more when I know more.
-Gul
On 9/10/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> Marty's suggestion looks promising and seems to have a good bit of
> support from the core devs. It's been a few months, and I am
> wondering if there has been any movement on this.
This particular item has been low on my list of
On 9/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Valid point - however, in practice, the same context is passed to
> multiple templates. There are some edge cases (e.g., a view with two
> calls to render_to_template) where this isn't the case, but I wouldn't
> consider them to be the
Okay, I guess I'm not much on doing fun stuff with RSS, but I went
ahead and set up a Yahoo Pipe[1] to keep track of the various blogs
that are currently (or will be) dealing with the topic of Django on
Jython. If anybody else is writing on the subject, let me know and
I'll add you to it.
-Gul
On 9/9/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> FYI, in order to "accept" a ticket you need an account and need to be
> logged in. To create an account, go to
> http://djangoproject.com/accounts/register/, and then log into trac
> (using the "login" link at the top right).
So, just so
While not exactly what you're looking at, something I had considered
some time ago was putting together a set of wiki articles that are
geared toward more of a quick-reference documentation. I put together
articles for HttpRequest[1] and HttpRespone[2], but never got any
further than that.
As
On 9/8/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I'd say something like django.core.filesystems would be a good idea
> (though I'd call it django.core.filestorage and paint the bikeshed
> yellow.)
I have pretty much zero preference on what it's called or where it
goes, so yellow sounds
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'd
> be better
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
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/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,
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, Marty Alchin <[
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
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]> wrote:
> On 9/4/
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
> benefit suc
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
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
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
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
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
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
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 o
I have 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/20/07
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
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
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
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
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
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
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
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
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
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).
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 --
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, 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
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
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
>
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.
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
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,
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/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
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
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
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
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
ore 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 cache framework, and I finall
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
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
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
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
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
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
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, 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/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/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,
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
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
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, 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
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
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
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
> > The biggest hurdle to dbsettings at this point is that it caches
> > settings in a standard Python module, which only exists within a
> > single process. This was all well and good while developing it, but
> > people are now starting to try it under mod_python, which (depending
> > on the
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) ->
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
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
>
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
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
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
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]
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
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
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 people. I do sign my
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
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,
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
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
> the subclass. Notice
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
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
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,
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:
> 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
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
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,
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
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
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
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
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
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
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.
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
On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> It seems that "extra" things on a model in whatever form they may take
> are either instance-specific, in which case they are Field sub-classes
> -- for database-backed data -- or methods, or they are model-specific
> (e.g.
On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Aren't you asking the wrong question here? The real issue seems to be
> "how is admin going to handle arbitrary Field classes that it doesn't
> otherwise know about?"
Well, I'm not worried about Field classes. DurationField, for
201 - 300 of 310 matches
Mail list logo
