Adrian Holovaty wrote:
> Some of these ideas sound really cool! I'd suggest focusing on one or
> two of them rather than attempting to do the whole shebang. In my
> opinion, the Python Imaging Library functions as generic views would
> be a really useful thing to have.
If such a Interface is
Matthew Flanagan wrote:
> In one project I know of that uses trac they just have a single login
> for users to create tickets and submit patches rather than requiring
> every user to register. This eliminated 99% of their trac spam. They
> just documented the login/password in their
Martin Glueck wrote:
> Be careful ... in one of the next releases of python, support for
> relative import will be dropped! So I would suggest that you don't
> rely on relative import in new written code and change it whenever you
> find it in old code.
It will not be droped in 2.5 but it will
jrs wrote:
> What would the result be if multiple fields were selected? or should
> this be valid only when a single field is requested?
>
> NetworkState.objects.all().order_by("-stopdate")[:5].values("id",
> "name")
I couldn't think of a nice solution at first, so i said for one key only.
Malcolm Tredinnick wrote:
> Damn. Your phrasing tipped me off to a case we need this more: RSS feeds
> and Atom content elements with type="html". :-(
>
> We might need a "mark as unsafe" filter for these cases (so that {{ var|
> escape|unsafe|escape }}) works (or just make "escape" not mark
> OK, thoughts, anyone?
When i first heard of multi-db i more thought about support for
clustering then moving some apps/models to other databases, which is
great, too of course.
for example: having one master db and some slave dbs that mirror the
master db. requests should go to slaves in some
[EMAIL PROTECTED] wrote:
> I've been using Django for a project, and one thing I have sorely
> missed is having an ifless and ifgreater template tag. Other internal
> projects have had similar problems, and made at best hacks to work
> around this missing feature. I understand however that there
Adrian Holovaty wrote:
> Thanks for the comments. I'd like to restructure our Trac installation
> into more useful categories, such as: "Still thinking about it,"
> "Patch is good and should be committed with caveats," "Patch isn't
> good enough," and stuff like that. I think more granular
Simon Willison wrote:
>
> On 19 Jun 2006, at 21:00, [EMAIL PROTECTED] wrote:
>
>> anyway, i suppose i will wait for you to elaborate on your
>> reasoning in
>> the wiki this evening. :)
>
> I've written up a proposal for how we can implement auto escaping
> while hopefully keeping most
Andreas Neumeier wrote:
> It looks like RequestContext just dies silently, but I couldn't tell
> you for sure.
>
> I also figured out, there is another installation (rev. 2893 on Ubuntu
> Dapper), which looks that it works perfectly. rev 2917 on Breezy seams
> to fail for some reason i cannot
Adrian Holovaty wrote:
> Yes, I realize __name__ + '.views' will result in something like
> 'myproject.polls.urls.views' -- some extra string mangling would have
> to be done.
how about using the python 2.5 relative import syntax and emulating it
accoringly.
urlpatterns = patterns('.views',
Adrian Holovaty wrote:
> django-admin.py startproject foo
>
> # generated settings file contains INSTALLED_APPS with the basics,
> # such as sessions, auth, etc.. Advanced users can remove any or all of
> that
> # if they don't want to use it.
>
> python foo/manage.py
Hi,
I think it has become to much spam in django trac. I suggest to use
http://trac-hacks.org/wiki/AccountManagerPlugin so only registered users
can change stuff and comment bugs. I think this would prevent much of
the spam currently comming in, or at least allows to ban those accounts.
Maybe
Jeremy Dunck wrote:
> This makes me think the world needs a wiki whose wikitext syntax is
> restructured text.
In general ?
At least trac has a macro for restructured text I think.
kindly regards
daniel
Amit Upadhyay wrote:
> This makes clear on what to do incase there are different subdomains, we
> can just add other subdomains specific setting files blog_settings.py
> and so on, which point to different ROOT_URLCONF and so on [we can
> overwrite other things too if required].
Look at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ivan Fedorov wrote:
>>URL_RESOLVER = "django.core.urlresolvers.RegexURLResolver"
>
> +1
>
>>You could do very nice things with this approach, like using a database
>>to resolve the url, or even change the other settings depending on the
>>hostname
plisk wrote:
> Yeah, its OK to have more than one value of the same param and wrap all
> of them in the list. But when you have only one parameter value passed
> making a list for it is at least inconsistent with the value you get
> from request.GET['param'] which is just a scalar and this also
17 matches
Mail list logo
