Re: Djangopeople.net status

[Will Hardy]

Seeing as we have to deal with a stale data issue anyway, I thought I
would throw an idea into the mix.

I think it'd be nice to have something where the data is a little more
open, allowing anyone to create an index of developers. For example,
each developer who wants to be index sticks a json file somewhere
online with loosely standard information: who they are, whether or not
they are currently available, where they are happy to work, what their
relevant interests are, some experience and links to
github/twitter/etc accounts.

This way, a developer would need only update the file and the changes
would propagate to whatever index others have built. For employers, it
means the index only contains people clever enough to put a json file
on their website/github/etc :-)

There are of course no doubt issues with this (verification etc), but
I thought I would mention a worthy goal. At the very least,
people.djangoproject.com could provide a simple API, in effect hosting
such information and letting others build fancy indicies. As someone
who is looking for competent developers, I'd be happy to work on this
if others find it useful.

Cheers,

Will

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: End-user defined fields, how would you approach it?

[Will Hardy]

In the interests of the thousands of developers on this list and their
valuable time, I have to agree that this thread is very off topic.
I'll focus on the original question, below is a quick justification
for anyone who is interested.

I can't see a reason to build anything into Django core to support
dynamic models, as it can be done reasonably well in a third party
app. The amount of extra tests that would be written to ensure that it
works as advertised would be nontrivial, and only worth considering if
there were a third party app with an appropriate level of abstraction
(ie flexibility).

There are some areas that require hacks, for example getting Django's
Admin to update its cached models/admin definitions when needed. But
in the end, core support of a feature like this would distract the
core developers from more important tasks. If there is anything that
doesn't work with Django, it would be more productive to open a ticket
to make that component more flexible.

I would also like to dissuade anyone from taking this road unless they
are *certain* that they need it, that all the other approaches are
insufficient. It makes a number of things much more complicated, makes
your test suite slower and slows down development of a number of
things that Django normally gives you for free.

Cheers,

Will

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: pb with search on website

[Will Hardy]

In case there's any confusion in the question, it appears as if adding
a period or braces to a word makes it impossible to be found, even
when the exact string exists in the documentation:

* http://docs.djangoproject.com/search/?q=get=4
* http://docs.djangoproject.com/search/?q=get()=4
* http://docs.djangoproject.com/search/?q=get(=4

I know nothing about your search system, but perhaps there's some
inconsistent tokenising going on?

Cheers,

Will

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Using asserts in test code

[Will Hardy]

It's true that there isn't any rich API for the Error/Fail distinction. The
best I can think of would be to create a custom exception eg
FailedAssumption, which is raised when the TestCase.failedException (same as
AssertionError) is caught while testing an assumption.

Here are four ways I can think of implementing the above, each with varying
convenience/aesthetics. A few of these can be added to
django.utils.unittest.TestCase for convenience, or provided as separate
functions/classes to prevent any potential backwards incompatibility or to
just keep TestCase clean.


1. plain old try/except in the test code:

try:
self.assertEqual(2,3)
except self.failedException, e:
raise FailedAssumption(e.message)


2. wrap tests self.assert* in a special function/method

self.assumption(self.assertEqual, 2, 3)


where the "method looks something like this:

def assumption(self, func, *args, **kwargs):
try:
func(*args, **kwargs)
except self.failureException, e:
raise FailedAssumption(e.message)


3. wrap a series of test assumptions with state changing methods:

self.start_assumption_tests()
self.assertEqual(2, 3)
self.finish_assumption_tests()


where the methods look something like this:

def start_assumption_tests(self):
self._failureException = self.failureException
self.failureException = FailedAssumption
def finish_assumption_tests(self):
self.failureException = self._failureException


4. use a fancy py2.5 "with" syntax:

with self.assumptions():
self.assertEqual(2,3)


where the start_ and finish_ methods in the previous incarnation are
__enter__ and __exit__



(NB none of these actually have to be in the TestCase class)

Cheers,

Will

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Using asserts in test code

[Will Hardy]

Maybe we could add a keyword argument to Django's TestCase.assert*() methods
that raises an AssertionError instead of failing the test when the method's
condition is not met (I assume that the test should error instead of
failing).

eg:

self.assertEqual(1, 1, test_assumption=True)

Cheers,

Will

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: custom function for autoescape

[Will Hardy]

Hi Luke,

> First, you depend only on the name of the function - so one that shadows
> a builtin filter won't be treated correctly (as you noted on the
> ticket).

This is true, I really hated this bit. The only thing that might work
is "libraryname.filtername" if it's possible to identify exactly which
filter was meant at runtime (the libraryname would be the same as that
used in {% load %} ). Even then it's functionality could depend on
the installed apps, which is just wrong.

> Second, when you are defining an autoescape function you have to know
> all the filters it will ever be used with. This is just as ugly a
> constraint as the problem it is trying to fix.

Not quite. The 'proper' way to do this is to have the filter define a
matching "autoescape context". The whitelist is only really there for
convenience, to let you use filters from other contexts (ie the
default django ones, external ones), without writing new ones.

If you wrote the filter, you can define the "autoescape context". If
you only wrote the escape function, you can define the whitelist. If
you wrote neither and they are for different "autoescape contexts",
you can use the "|safe" filter in the template.

> Third, although we can fix the filters in your 'group 2', you can't fix
> 3rd party filters like this. If we don't fix them, we still have caveats
> that we have to add to the docs - "Be aware that any filters/tag not
> bundled with Django may be broken with respect to autoescape" etc.

This is true, I don't see any way around this.

> Overall, with this addition, the whole thing actually gets harder to
> understand and document, and just feels like a hack. That kind of thing
> is acceptable to fix existing bugs, but not for new features IMO.

Agreed. I'll leave the ticket be for now, I don't really want to
distract anyone from 1.3 work. If I can think of a cleaner way of
doing this, I'll have another look at it after 1.3 is out.

Cheers and thanks for your time,

Will

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: custom function for autoescape

[Will Hardy]

> Reading over the discussion, I'm in the same camp as Luke. I can see
> the use case, but I see a bunch of sharp edges that will end up biting
> the user in unexpected ways.

Thanks for dropping by :-) I think I've managed to remove the sharp edges.

The main problem in this thread is that the default filters were
written in the html context and their interaction with autoescaping
breaks down when a different escaping context is required.

I believe the solution would be to simply declare the html filters as
"unsafe" and I've uploaded a patch [1] to the ticket that would do
that. I've included a detailed description of the approach on the
ticket [2]. All filters appear to be correctly handled in the new
approach described there.

If you think this approach is sensible, I'll edit the group 2 filters
to use the custom escape function (they mostly take the autoescape
argument anyway). There are a small number of tests on the ticket, but
if this is something that might be in core, then I'll write some more
comprehensive tests and documentation.

Cheers,

Will

[1] 

[2] 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: custom function for autoescape

[Will Hardy]

Thanks for the explanation and perfect example Luke.

I thought I would try to be helpful and went through the source code
for all the filters and categorised them (see below). There are 12
filters that can't be used (8 are for html only anyway), 24 filters
may fail unpredictably (like your example did), 2 of those can be
easily rewritten to avoid that and 23 filters that should be fine with
custom escape functions.

I'm personally happy with the "all bets are off" disclaimer, as it
should be clear that the default filters are generally HTML-oriented.
Many other filters are still useful, so developers will be fine as
long as they know which ones to avoid. I guess adding a list of
working/not working/incompatible filters may be "documentation noise"
for those that don't need it, but it could have its own home somewhere
else.

I don't imagine the default tags will pose any problems, as they have
access to Context.autoescape. In any case, it seems that only {%
csrf_token %} marks its (HTML) output as safe, and the {% filter %}
tag would of course behave like the filters it uses.

Cheers,

Will


DIFFICULT FILTERS (4+8)
These would be difficult to make work with custom escape, because the
escaping needs to be handled by the filter itself:
* cut (marks safe when change won't create new HTML tags)
* force_escape (unlike escape, it won't use the custom escape function)
* join (escapes each joined item individually)
* linenumbers (but autoescape argument, allowing it to be turned off)

These have the same problem, but they would probably only be used in
HTML documents.
* unordered_list
* linebreaks
* linebreaksbr
* urlize (but takes autoescape argument)
* urlizetrunc (but takes autoescape argument)
* markup.textile
* markup.markdown
* markup.restructuredtext


FILTERS THAT DON'T TAINT/UNSAFE DATA (24)
These could be potentially dangerous, when they alter the "safe" data
in a way that would make it unsafe for a given context (like Luke's
example). Many however have a clear functionality, but the problem
might be so subtle that the developer wouldn't think of it. I imagine
that they don't taint the output because someone has carefully
analysed their behaviour in the HTML context.
* addslashes
* capfirst
* iri_to_uri
* lower
* stringformat
* title
* truncatewords
* truncatewords_html
* wordwrap
* ljust
* rjust
* center
* removetags
* striptags
* last (oddly, the "first" filter does taint/unsafe the data, but this doesn't)
* random (ditto, the "first" filter does taint/unsafe the data, but
this doesn't)
* slice
* filesizeformat
* phone2numeric
* pprint
* fix_ampersands
* humanize: ordinal
* humanize: intcomma
* humanize: apnumber


FILTERS UNNECESSARILY MARKED SAFE (2)
These filters are marked as safe although there is apparently no need
to do so. It does however save a bit of processing. Removing
mark_safe() shouldn't have an effect on their operation, other than
being less efficient.
* slugify (output can't contain &, <, >, " or ' anyway)
* floatformat (marks format output as safe, none of the default
formats would be affected by escaping (I checked). This would however
prevent developers from writing formats with html markup, ie
DECIMAL_SEPARATOR = '.', which might be
very useful for some)


SAFE FILTERS (23)
The following filters should be ok, as they don't prevent the custom
escape from being run
* escape
* urlencode
* wordcount
* escapejs
* safe (well it does prevent custom escape, but that's the idea)
* safeseq
* dictsort
* dictsortreversed
* first
* length_is
* add
* get_digit
* date
* time
* timesince
* timeuntil
* default
* default_if_none
* divisibleby
* yesno
* pluralize
* humanize: intword
* humanize: naturalday

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

custom function for autoescape

[Will Hardy]

Hi all,

While using templates to produce something other than HTML (latex by
the way), I wanted to use my own escape function, instead of the
HTML-oriented default in autoescape.

This is of course not too difficult with filters and turning of
autoescape, but it would be very nice if I could get the autoescape
framework to use my own custom escape function. I found a ticket
(#14057, [1]) that was requesting the same thing, but was closed as
wontfix. A reason for doing this was that the change would a) require
lots of difficult changes and b) not be backwards compatible. Luke
left the door open for a "beautiful patch" to rescue the ticket and I
wonder if what I'm about to suggest would be enough.

Could a callable be passed to Context() in the autoescape parameter,
in order to define a custom escape function?

I've attached a simple patch to the ticket [2] and would be happy to
write tests and documentation if this approach is enough to overcome
the "wontfix". Have I overlooked something?

Cheers,

Will

[1] http://code.djangoproject.com/ticket/14057
[2] 
http://code.djangoproject.com/attachment/ticket/14057/14057-context-parameter.diff

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: dates postgres django trunk

[Will Hardy]

Thank you for your email.

This is not a bug in Django, it is the correct output when you set
DATE_FORMAT = "%m/%d/%Y". Your desired output will come if you set
DATE_FORMAT = 'm/d/Y'.

The documentation [1] may not be too clear on what formatting is
required, but does give an example which hints at leaving the % signs
out. What might be confusing for some is that the documentation for
DATE_INPUT_FORMATS directly below it, shows an example with lots of %
sign formats. It also seems that the reference to "allowed date format
strings" isn't a working link, is that a bug in the documentation?

Cheers,

Will

[1] http://docs.djangoproject.com/en/dev/ref/settings/#date-format

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 'User' object has no attribute 'backend' - issue with using auth.login()

[Will Hardy]

I hope I understand your problem correctly, but authentication is
handled by your authentication backend, not your model. Your backend
can return anything you like (eg Foo) and that is what you'll get when
you call authenticate(). This object is given a .backend attribute by
django.contrib.auth, which is then used when you use
django.contrib.auth to login.


Django's auth design is fine for a huge number of django developers, I
get the feeling that people here are skeptical that you have found an
architectural/design bug. If you're absolutely certain this isn't
possible for you, then keep pursuing this. But be wary that doing so
might distract a lot of people from other tasks, I hope it's worth it!

I like the idea of improving the exception raised when .backend is
missing. I think working on a patch to improve the exception raised
would be a perfectly sensible improvement to django.

Cheers,

Will

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: memcached-based-cache - timeout=0 does not work as intended by memcached

[Will Hardy]

I thought this was familiar too: <http://code.djangoproject.com/ticket/6988>

Is this the ticket you were thinking of? It seems to have been reopened.

Cheers,

Will Hardy

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

[Will Hardy]

> Does this proposal add any functionality that fixtures do not already
> provide?

Convenience. It moves the definition of the site away from the
database, and away from fixtures files and into the settings.
Personally, I am yet to need multiple sites for a single database, and
would much prefer being able to set the domain using settings files
(eg host="localhost:8000" for my settings/local.py on my dev,
host="production.com.au" for settings/__init__.py etc).

For my needs, being able to define the domain in the settings is much
more powerful and convenient than storing it in the database and an
initial_data fixture isn't going to be able to play very cleanly with
my settings configuration.

Just adding my +1 vote for a standard,
Site.objects.get_current()-compatible way to set the domain name in
django.conf.settings.  Bonus points if no site table is created and no
ModelAdmin turns up in admin on auto_discover.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: proposal: ask a queryset to not raise exceptions

[Will Hardy]

I'm not sure what reception you'll get for this suggestion (also given
that all attention is currently on Django 1.2), but I think eventually
problems like these may be best addressed by allowing you as the
developer to write your own customised helper functions/methods to
deal with things the way you want them to.

In this case, it would mean a custom (subclassed) QuerySet.

You can do this already by subclassing models.query.QuerySet, adding
your own customisations and returning your queryset from the model
manager's .get_query_set() method. It would however be nice if this
were a little more obvious, simpler and explicit and by that I mean
maybe removing the Manager/QuerySet distinction.

Until then (and such a big change wont happen any time soon), you can
use a number of snippets around that let you pass a custom queryset to
the manager on instantiation, which isn't too difficult. I could also
be wrong in that this might be the sort of feature a whole lot of
people want baked in.

Cheers,

Will

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Refining Django admin look proposal

[Will Hardy]

> That seems reasonable to me, but I'll add the stipulation that any
> design proposal must include a commitment to do the implementation,
> and must include all of the admin's pages.

Why? Not all designers can do cross browser xhtml/css (html5?) or even
django's template language, let alone the admin's unique template
environment.

I'm sure there are a number of CSS gurus in the community who can then
take over, and if there isn't, I'm certain the Django Foundation could
afford to hire one for a reasonable price. I think requiring
implementation would reduce the quality of the submissions.

If there is a competition (which I hope there is!), it would be good
if the submissions were to a clear set of requirements; eg a graphical
design in illustrator/inkscape format of:

* Base template (branding, header, footer, layout etc)
* Login box
* Home page (list of apps and models)
* Change list
* Change detail
* Random content, elements (change password, delete confirmation,
object history, invalid setup, 404 etc)

If backwards compatibility is required, add to that a list of elements
required for each page, based on the existing templates. But then
again, any radically new design can live alongside the old admin for a
time, to allow people to keep their customisations.

Cheers,

Will

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Will Hardy]

> Deprecate slice, move it to "truncate" and add the ellipsis for consistency.

Slice has other uses, please don't deprecate it :-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Admin interface not preventing simultaneous editing of the same record

[Will Hardy]

A quick note on your approach: What if the user isn't supposed to have
access to certain fields in a customised form?

You probably want to take a checksum as Russell suggested earlier and
put that in the hidden field. Of course, dealing with conflicts will
be harder if you can't show the user which fields have changed, but
I'm sure there's a usable way around this.

Cheers,

Will

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Fwd: Oldforms-admin to Newforms-Admin helper script

[Will Hardy]

Thanks for the links, I was sure someone had done this before. Looks
like they're scanning the models.py source code and finding the
information there. I think it would be easier and cleaner to generate
it dynamically.

@oggie rob, @russ magee
Yep, it would only ever be needed once, and cluttering the management
is not the best idea. In any case, it would be added to
django.contrib.admin.management, but the effect is the same. Maybe
some people might think its global usefulness overcomes its
contribution to clutter.

Also, I wasn't thinking of a complete conversion tool, just something
to get people started, as simple as possible. What people do with the
results is up to them, the file just gets generated, porting the old
commands to the new one and they are free to edit it how they wish.

I'll write it up quickly, as it doesn't seem to be too difficult at
all and see what everyone thinks.

Cheers,

-- 
Will Hardy
w: http://www.willhardy.com.au

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Oldforms-admin to Newforms-Admin helper script

[Will Hardy]

Hi all,

is anyone planning to write, or has anyone already written a script to
help people convert their oldforms-admin to newforms-admin?

If not, I was thinking of writing a little script (mangement comand)
that would find all the oldforms-admin definitions in installed models
and output a newforms-admin module that could be saved to e.g.
"admin.py". This could of course help people port their apps more
quickly and painlessly.

Would this be useful enough to include in django itself?

Cheers,

Will

-- 
Will Hardy
w: http://www.willhardy.com.au

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: {GSoC 2008}Django-Newcomments : A preview

[Will Hardy]

> Any reasons for having CommentFlag.flag being a string, and not a
> foreign key to a FlagType model ? Having them as strings makes it
> easier to end up with bad data (misspelling and so forth). Of course
> there is always the performance penalty, but it seems worth it.

You can do both :-)

Have a FlagType model with a string as a primary key, so you only need
to set flag_id if you already know what string you want. I have to
say, I don't usually mess with custom primary keys in django, and have
no idea if there are downsides in using them. Feel free to correct me
if this isn't a good idea for whatever reason.

Having said that I like the flexible approach of just having a string;
unless you need to store other attributes, there are no great
benefits. Bad data could be seen as more of a usability problem than a
technical one.

Cheers,

-- 
Will Hardy
w: http://www.willhardy.com.au

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: i18n missing feature ... continued (proposed solution for the upcoming sprint)

[Will Hardy]

Hi all,

This is a really impressive solution. An extra idea:

 adding a {% as variable_name %}{% endas %} or {% as variable %}{%
endas variable_name %}

Example:

{% blocktrans %}
Received on {{ message.created|date as date }}
from
{% as link_open %}{% endas link_open }}
 {{ user.name as username }}
 (married since {{ user.married|year as married_since }})
{{ '' as link_close }}
{% endblocktrans %}


PROS:
 * keep things clean if the tag code gets complicated, long or quotey.
 * all the same benefits that """ provides in python

CON:
 * adding unnecessary tags is a distraction

Cheers,

-- 
Will Hardy
m: +49 177 392 89 26
e: [EMAIL PROTECTED]
w: http://www.willhardy.com.au

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: one django command (was: Re: django-admin.py can't access user-supplied commands, even if --settings option is provided)

[Will Hardy]

#!/bin/sh

if [ -e "./manage.py" ] ; then
  ./manage.py $@
else
  django-admin.py $@
fi

That way, new users can simply learn the mighty django command, trendy
users can switch over to the mighty django command and old users can
hang onto their habits and let their fingers type what they always
type.

Some time in the future, when the older users have died out, you can
unify the three commands, removing or renaming ./manage.py in the
project directory.

I think the new command makes a lot of sense to new users, and it's
much easier for them to remember.

Cheers,

Will

-- 
Will Hardy
http://www.willhardy.com.au

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---