Gábor Farkas wrote:
> - search-api
> - i could not find any documentation about it
search-api has a wiki page here:
http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer
There is currently one supported indexer (Lucene) and a couple
experimental (Xapian). It needs polish. I blog
t state of search-api, experimentation is definitely
the best way towards progress.
--
Brian Beck
Adventurer of the First Order
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
T
> The ticket itself is the best guide to any knowledge about the problem; in
> this case, I'm guessing that the answer is no - there isn't a patch or
> workaround. Any help you can provide in tracking the problem (and/or fixing
> it) would be greatfully accepted.
Here's a more complete traceback:
(Tried submitting a ticket, blocked by Akismet.)
When creating users with User.objects.create_user, email is a required
parameter and fails when None is passed because create_user assumes it
will be a string by calling .strip.lower(). However, email is an
optional attribute on User. Passing the e
This concerns an addition/patch idea, so I'm forwarding it here...
-- Forwarded message --
From: Brian Beck
Date: Wed, 03 Jan 2007 22:56:42 -
Subject: Unpacking in template loops
To: "Django users"
Sorry if this has been brought up before, I tried searching.
Tim Keating wrote:
Looks like this hasn't been touched much since SoC work got checked in.
Is there a timeline for getting it merged up into trunk?
There have been a couple patches submitted to improve Xapian support,
but for the most part it's on the backburner until I get more time (or
someo
in my template
files. Maybe a template solution would be more work (probably some
repetition, I haven't really thought about how to combine both some
automation and custom template files), but it would also be less
surprising for me.
--
Brian Beck
Adve
, semantics
documented in that ticket.
--
Brian Beck
Adventurer of the First Order
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-
y
extra GET parameter... or is something else happening? Any ideas?
--
Brian Beck
Adventurer of the First Order
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gro
Nicola Larosa (tekNico) wrote:
> "Stateless session" is an oxymoron, there's no such thing. You're
> talking about *cookieless* sessions.
Of course :) I was using them synonymously, i.e. the *browser* has no
means of storing state.
--~--~-~--~~~---~--~~
You rece
Am I being boneheaded, or should ManyToManyFields support to_field and
from_field attributes with the semantics of ForeignKey's to_field? It
seems like if ForeignKey supports it then it should be possible in
ManyToManyFields as well...
--~--~-~--~~~---~--~~
You
Jacob Kaplan-Moss wrote:
> * The real thing we've been discussing, though, is a way for apps to get ahold
> of users after they've been created by a third-party authenticator. For
> example, on my sites I'm gonna want everyone to have a username whether they
> use OpenID, LDAP, or whatever.
>
>
Jeremy Bowers wrote:
> I've also discovered that even relatively skilled developers can have a
> lot of trouble catching every case that needs to be escaped, whereas
> almost any developer can correctly determine when *not* to escape
> something. The "it didn't work, I'll do X" algorithm that is s
Brian Beck wrote:
> +1 on a noescape "filter" (I'm not too familiar with the template code
> but it seems like it would have to be a special case rather than a real
> filter). The reason given above sounds right to me: people know when
> they don't want somethin
e; if your app isn't using the bundled ContentType, why should Django
complain if you make your own?
--
Brian Beck
Adventurer of the First Order
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Djang
jango.db.models.loading from the shell and it's keeping everything
> straight and tidy as a list of:
>
> {'app': 'model1', 'model2', ... }
I was under this impression as well; I would have expected it to still work.
--
Brian Beck
Adventurer of the Fi
On Mar 24, 3:01 pm, "Baptiste" <[EMAIL PROTECTED]> wrote:
> For me, yes, but I miss the "and" :
> {% with article.name as name and article.title as title %}
> But it is an useful tag.
If this were to go in, I think comma-delimiting multiple "assignments"
would make more sense than using 'and':
{
On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote:
> It could be just me, but although i don't mind losing auto_*, it don't
> look very DRY in save.
>
> I know it's only a few lines (like 4 ? for both options, not using
> default= for sake of keeping the logic together) but when lots of
> model
Did people feel that save() was a better solution because it's already
a place where you have to put equivalent functionality for other
fields? I don't know why, but defining my own save() always seems like
a "big deal" that should be reserved for more complex stuff.
What about a new attribute fo
On Apr 9, 9:02 am, "Gulopine" <[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 ther
I consider this a wart and it's been bugging me for a while. So,
sparked by some discussion in #django, here goes...
I'd like it if template filters supported multiple arguments for real.
Currently filters that need multiple arguments just have to come up
with a delimiter and then do string parsi
I didn't see anything about aggregate support in
VersionOneFeatures[1], are people still hung up about the syntax, or
is anyone hacking on this? It's been mentioned a couple times since
PyCon, but what's the status?
[1] http://code.djangoproject.com/wiki/VersionOneFeatures
--~--~-~--~--
On Apr 15, 2:53 pm, "ludvig.ericson" <[EMAIL PROTECTED]> wrote:
> works better since it doesn't return the data if it exists, or am I
> missing something with name lookups?
The getattr version handles the case where new_class._meta.app_label
does exist, but is None.
--~--~-~--~~
On Apr 15, 3:00 pm, tsuraan <[EMAIL PROTECTED]> wrote:
> So {{my_dict | objIndex:Value}} will evaluate Value in the context of
> the current Context, and then pass it to the filter? The HTML
> Template guide says that the argument must be in double quotes, so I
> assume it has to be a literal, ra
Distributing media with apps could be a lot easier. Currently this
requires copying or linking files manually (possibly each time the app
is updated), and this encourages developers to put CSS and JavaScript
inline in their templates. I propose a management command to make
this easier:
$ python
On Sep 16, 8:37 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote:
> I don't think anyone will complain that they have to type less, as its
> still understandable. +1 for allow_override.
Changed to allow_override. See patch #4 at:
http://code.djangoproject.com/ticket/9093
--~--~-~--~~---
On Sep 16, 2:36 pm, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> Why should django.template be refactored? Filter and Variable parsing
> is inconsistent. Many ad hoc parsers in defaulttags are fragile.
> Whitespace handling is ungraceful.
>
> The patch provided in #7806[1] splits __init__.py in
On Sep 16, 6:29 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> > Could it be a little smarter, and in the absence of specific apps, iterate
> > over all INSTALLED_APPS, and install their media automagically?
>
> +1 for some sort of media.autodiscover().
> It would have to be optional though, as th
On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> Serving is totally orthogonal -- everyone is already serving up
> MEDIA_ROOT in their projects somehow anyway, and this just copies
> files to MEDIA_ROOT.
Sorry, I guess that's not totally true -- everyone who use
On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I really like the idea. However, I think there should also be a way to
> configure it to not copy to MEDIA_ROOT but to somewhere else.
Sure - a --destination flag, defaulting to MEDIA_ROOT, would work.
> Also, instead of just copying
On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
wrote:
> A problem would be referencing images, and media in css/js files.
> Currently, in all our projects we use /site_media/ as the MEDIA_URL,
> so this not a problem. But for a true solution, there should be a
> preprocessor for css
I noticed that elwaywitvac just posted this management command here:
http://www.djangosnippets.org/snippets/1066/
I also have an implementation that I'll post when I get home.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
On Sep 19, 4:26 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> I also have an implementation that I'll post when I get home.
I just posted my collectmedia (I liked the name Rajeev used) command
here: http://www.djangosnippets.org/snippets/1068/
It's a long snippet bec
On Sep 20, 6:58 am, Erik Allik <[EMAIL PROTECTED]> wrote:
> Has anyone got some good use cases where the template-loaded mimicking
> behavior would be desired? Otherwise it's just needless complexity in
> my opinion.
Well, first of all, it's not really complexity at all. If it were to
just c
On Sep 15, 8:50 am, "Eduardo O. Padoan" <[EMAIL PROTECTED]>
wrote:
> On Mon, Sep 15, 2008 at 9:39 AM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> > That's a good point. Mixing {% include %} and {% with %} is both more
> > verbose and less flexible than if using a custom tag. In this case,
> > using
On Sep 22, 4:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF[1] is one of the most common web application vulnerabilities, but
> continues to have very poor awareness in the developer community.
> Django ships with CSRF protection in the form of middleware, but it's
> off by default. I'm w
On Sep 22, 4:55 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> > -- What about third-party app forms that aren't SafeForms, but need to
> > be? The situation dictates this, not the form author.
> I think we keep CSRF middleware around to deal with that. We also very
> actively encourage third pa
On Sep 22, 5:01 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> But still, the situation dictates the need for SafeForm, not the form
> author. If this becomes best practice, essentially *every* form will
> need to be initialized with a request.
What about something like:
d
On Sep 22, 5:16 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> One thing that might help out in this case would be the ability to
> create a SafeForm from a regular Form (which might be an argument for
> csrf protection as a feature of django.forms.Form rather than a
> subclass). If the third par
On Sep 23, 10:56 am, oggie rob <[EMAIL PROTECTED]> wrote:
> I'm sorry, I used the wrong term here. I didn't mean that CSRF
> protection isn't worthwhile, just that going the route of an extended
> form might not be the best way to do it.
> As for suggestions, I'm not sure I have one exactly, but I
On Sep 23, 12:13 pm, oggy <[EMAIL PROTECTED]> wrote:
> Could we just include something like a signed salt+timestamp
> +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because
> of the possibility of a same-IP-CSRF (affecting people behind
> proxies), but it's dead simple and doesn't re
On Sep 23, 3:40 pm, "Adam J. Forster" <[EMAIL PROTECTED]> wrote:
> Hi Eric,
>
> That's what I have done at the moment, but as you say it's a bit of a
> hack and I'm not sure that I'm happy with it.
I ran across this bug the other day too; quite annoying. It's ticket
#3310 and there appears to be
On Sep 25, 2:54 am, Rudolph <[EMAIL PROTECTED]> wrote:
> I like Luke's arguments.
>
> A middleware seems like the right place because CSRF protection is
> about requests and responses. CSRF protection is more about POST
> requests in generic, with HTML forms being a very common type of POST
> requ
On Sep 29, 10:37 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Full customization already can be done by specifying fields directly in
> a form class. In my experience widgets are just very common case.
I think your model_field helper being built-in (short for
x._meta.get_field(y).formfield(**pa
On Oct 13, 8:38 am, "Mike Scott" <[EMAIL PROTECTED]> wrote:
> Secondly this question has been asked, and solved many times. If you search
> through the django-users archives I'm sure you'll find plenty of solutions.
> There are solutions out and about in the blogosphere too.
Actually I think this
On Oct 13, 11:15 am, Brian Beck <[EMAIL PROTECTED]> wrote:
> The only action was three months ago with a DeprecationWarning patch that
> isn't checked in.
...and probably shouldn't be, since it still doesn't update the docs.
--~--~-~--~~~--
On Oct 21, 7:27 am, mrts <[EMAIL PROTECTED]> wrote:
> It seems that current DB lock management doesn't play nice with the
> new Python 2.6 multiprocessing package and SQLite. See [1]. The same
> error also popped up in Google search under mod_python [2].
As others have pointed out, this isn't an
On Oct 27, 1:46 pm, mrts <[EMAIL PROTECTED]> wrote:
> > IMHO this should be documented, so I
> > reopenedhttp://code.djangoproject.com/ticket/9409
> > and changed the component to Documentation.
>
> I've attached the explanation
> tohttp://code.djangoproject.com/attachment/ticket/9409/database_i
On Apr 11, 2:51 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Fri, Apr 11, 2008 at 11:34 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> > 404_HANDLER = 'django.generic.views.errors.404'
> > 500_HANDLER = 'django.generic.views.errors.500'
>
> /me jumps in time machine:
>
> http://www.dja
On Apr 11, 4:26 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> Just a documentation note -- I can't really tell how to use those
> features from this page. Are those keyword arguments to urlpatterns?
> Functions I call in the pattern list? An example would be helpful.
On Mar 18, 5:45 pm, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote:
> I have been pretty unhappy about the way html has been generated from
> newforms for awhile now. I think we've come up with a good design that
> makes form rendering a lot easier, and a lot more modular. The basic
> idea is to r
On Apr 12, 9:42 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 11, 2008 at 3:29 PM, Brian Beck <[EMAIL PROTECTED]> wrote:
> > (Replying to myself.) Looking at the code I see they're just urlconf
> > module globals. I as
52 matches
Mail list logo
