Re: Custom transform in django docs
On Tue, Oct 11, 2011 at 9:37 PM, Luke Plant wrote: > > Ah, well that explains it! It's gone now :-) Belated +1 to this -- Great finding and fix Luke. But it seems this is affecting styling of locally generated builds of the HTML version of the docs. Fon an example see (from tutorial part #1) http://i.imgur.com/CQrjo.png Compare that with: https://docs.djangoproject.com/en/dev/intro/tutorial01/ There are a lot of other bulleted (and numbered?) lists in our docs that sport the same green vertical bar at the left as the two-elements one at the top of that page. Looking at the ReST documentation[1] it seems the indentation we use for such lists are non-conventional and would explain this. Can anybody confirm this?. If so, we have a bunch of documentation .txt files to tweak. (also, if/when we fix this we should verify that we don't break the stylin of the affected parts in the docs.djangoproject.com) Regards, -- Ramiro Morales 1. http://docutils.sourceforge.net/docs/user/rst/quickstart.html#lists -- 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: Proposal for a new templatetag definition syntax
Not sure if this is still an ongoing discussion, but I prefer to write
all new tags with a simple syntax that matches Python. There's no
real advantage in defining a unique, custom syntax for a template
tag.
All HTML authors are already familiar with Python's kwargs syntax,
since it exactly matches how HTML tags and attributes themselves
work. There's no great leap of difficulty going from:
to
{% tag foo="something" bar="something" %}
Allowing for arbitrary custom syntax makes tags harder for HTML
coders, since they have to remember these special custom syntaxes
which they're not used to.
On Sep 12, 7:51 am, Donald Stufft wrote:
> I'll +1 the restriction of template tags to being arg/kwarg like. I see no
> reason, other then porting already written tags, to worry about the ability
> to do ``{% mytag foo as bar %}``. Personally I would think it would be
> desirable to make this match python as much as possible. Python programmers
> will find it more familiar then attempting to turn parameter passing into a
> parsing situation, and non python programmers will find it simple enough
> learn quickly. Being a restricted grammar, it also has the benefit to have
> less surprises, you don't have to worry about how this random tag works,
> there's one (obvious) way of doing it.
>
> Something like
>
> class MyTag(tags.Tag):
> width = tag.IntegerArgument()
> height = tag.IntegerArgument()
> using = tag.StringArgument(required=False)
> as = tag.StringArgument(required=False, default=None)
>
> which would translate to:
>
> ``{% mytag 600 700 %}``
> ``{% mytag 600 700 as="mytag_return" %}``
> ``{% mytag 600 700 "template_name.html" %}``
> ``{% mytag 600 600 using="template_name.html" as="mytag_return" %}``
>
> The only thing I really don't like about this is the ``as`` kwarg. We could
> stuff a boolean into a Meta class that is something like ``allow_assignment``
> which will support something more like what we have now…
>
> ``{% mytag 600 700 as "mytag_return" %}``
> ``{% mytag 600 700 "template_name.html" as "mytag_return" %}``
> ``{% mytag 600 700 using="template_name.html" as "mytag_return" %}``
>
> With the stipulation that the as [keyword] must appear as the last item in
> the tag.
>
>
>
>
>
>
>
> On Monday, September 12, 2011 at 7:17 AM, Jannis Leidel wrote:
> > Hi all,
>
> > > For many years, writing templatetags has been among the most hilariously
> > > complicated things we Django developers did. Anyone who has written
> > > parsing for
> > > templatetags, over and over, shares this pain. Further, the current syntax
> > > present a tremendous problem for Armin Ronacher's GSOC towards template
> > > compilation: template tags define a ``render()`` method, which takes the
> > > current context (a stack of dictionaries) and perform some behavior which
> > > is
> > > opaque to the caller. This is a problem because one of the core
> > > objectives of
> > > the template compilation infrastructure is to store the template context
> > > in
> > > Python local variables, rather than in dictionaries. For all these
> > > reasons,
> > > several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas
> > > Obrist,
> > > Chris Beaven) just sat down (we actually stood, mostly) and tried to iron
> > > out a
> > > proposal that solves these problems, taking inspiration from the plethora
> > > of
> > > libraries that exist today.
>
> > > We ultimately created two possible solutions, one inspired primarily by
> > > django-classy-tags and django-templatetag-sugar, the other mostly
> > > inspired by
> > > django-ttags.
>
> > FTR, the app is called django-ttag, not django-ttags.
>
> > > We came to a fragile agreement on the first. We primarily
> > > evaluated two cases for these, one very simple, the other more complex,
> > > and
> > > compared the resulting implementations.
>
> > > The first case we considered was a templatetag which takes two, required,
> > > arguments. Invocation looks like ``{% mytag foo bar %}``. The two
> > > definitions
> > > look like:
>
> > > class MyTag(Tag):
> > > args = [
> > > Argument("foo"),
> > > Argument("bar"),
> > > ]
>
> > > class MyTag(Tag):
> > > foo = Argument()
> > > bar = Argument()
>
> > > the second case we considered was a tag which has one required,
> > > positional,
> > > argument, and two optional, keyword arguments, which can occur in any
> > > order,
> > > followed by a final, optional keyword argument, meaning any of the
> > > following
> > > invocations are valid:
>
> > > {% mytag src limit 1 offset 10 %}
> > > {% mytag src limit 1 offset 10 with foo %}
> > > {% mytag src limit 1 %}
> > > {% mytag src offset 10 limit 1 %}
> > > {% mytag src %}
>
> > > and the two implementations were:
>
> > > class MyTag(Tag):
> > > args = [
> > > Argument("source"),
> > > Unordered(
> > > NamedArgument("limit", required=False),
> > > NamedArgument("offset", required=False),
> > > ),
> > > NamedArgument("as", required=False, resolve=Fal
Re: Towards a more friendly NoReverseMatch
+1 on this, been bitten repeatedly.
I assume the url parser already "knows" this so this is mostly a
matter of raising the appropriate exception.
Bien cordialement,
Philippe
On 12 October 2011 17:13, Wilfred Hughes wrote:
>> > >>> reverse('i_dont_exist')
>> > NoReverseMatch: Reverse for 'i_dont_exist' with arguments '()' and
>> > keyword arguments '{}' not found.
>>
>> > In this case, it would be nicer to have something like:
>>
>> > NoURLPattern: No patterns specified for 'i_dont_exist'.
>>
>> Just on this point, I must disagree. For instance, consider if you
>> have a URL named 'i_dont_exist', and the URL pattern has two
>> positional arguments.
>
> Ah, sorry. I've been unclear. My point here is that when there /isn't/
> a URL with that name. It would be good to distinguish between having
> no regexes and not being able to reverse the regex.
>
> So, if I have an URL:
>
> url(r'^fruit/(bananas|apples)$', some_view, name='fruit'),
>
> And I make a spelling mistake:
>
> >>> reverse('rfuit', args=['bananas'])
>
> I would like some hint that the problem isn't in my regex. The two
> options I'm proposing are:
>
> NoURLPattern: No patterns specified for 'rfuit'.
>
> Or:
>
> NoReverseMatch: Reverse for 'rfuit' with arguments '()' and
> keyword arguments '{}' not found (patterns tried: []).
>
> --
> 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.
>
>
--
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: Custom transform in django docs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ramiro, On 10/13/2011 05:35 AM, Ramiro Morales wrote: > Belated +1 to this -- Great finding and fix Luke. Indeed. > But it seems this is affecting styling of locally generated builds of > the HTML version of the docs. > > Fon an example see (from tutorial part #1) http://i.imgur.com/CQrjo.png > > Compare that with: > > https://docs.djangoproject.com/en/dev/intro/tutorial01/ > > There are a lot of other bulleted (and numbered?) lists in our docs that sport > the same green vertical bar at the left as the two-elements one at the top > of that page. > > Looking at the ReST documentation[1] it seems the indentation we use for > such lists are non-conventional and would explain this. > > Can anybody confirm this?. If so, we have a bunch of documentation > .txt files to tweak. > > (also, if/when we fix this we should verify that we don't break the stylin > of the affected parts in the docs.djangoproject.com) I ran into the same problem on the "These files are:" list further down that same page when working on #15372. I checked the standard ReST syntax, de-indented the list as part of my patch, and it fixed the problem locally. It also doesn't seem to have caused any problem on docs.djangoproject.com. If you view source on docs.djangoproject.com, that two-element list up top is in fact wrapped in a blockquote, it's just that apparently the dp.com styles don't style blockquotes. The blockquote doesn't make any sense semantically, so I vote we do fix the list indentation throughout the docs to get rid of the spurious blockquotes. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6XFDcACgkQ8W4rlRKtE2cOBgCggSK/h7vYlqw5uQnh9zxT4ZVX 9i8AnAxsx7/UxrS65COC8llUuTN0ypdZ =dgJo -END PGP SIGNATURE- -- 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: Proposal for a new templatetag definition syntax
On 13 October 2011 15:30, LeeS wrote:
> Not sure if this is still an ongoing discussion, but I prefer to write
> all new tags with a simple syntax that matches Python. There's no
> real advantage in defining a unique, custom syntax for a template
> tag.
>
> All HTML authors are already familiar with Python's kwargs syntax,
> since it exactly matches how HTML tags and attributes themselves
> work. There's no great leap of difficulty going from:
>
>
> to
> {% tag foo="something" bar="something" %}
>
> Allowing for arbitrary custom syntax makes tags harder for HTML
> coders, since they have to remember these special custom syntaxes
> which they're not used to.
Note that since the recent r16908 [1], this is easily achievable with
simple_tag, include_tag or assignment_tag, which now replicate the Python
way of handling *args and **kwargs.
The only thing that's still not possible with these is to define a complex
or custom syntax, e.g.: {% mytag with myvar using "blah" %}
However, if one is OK to not have a custom syntax, then the following is now
dead-easy:
{% mytag with=myvar using="blah" %}
@simple_tag
def mytag(with=None, using="Yadi Yada"):
...
Cheers,
Julien
[1] https://code.djangoproject.com/changeset/16908
--
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: Custom transform in django docs
Hi Ramiro, > Belated +1 to this -- Great finding and fix Luke. > > But it seems this is affecting styling of locally generated builds of > the HTML version of the docs. > > Fon an example see (from tutorial part #1) http://i.imgur.com/CQrjo.png > > Compare that with: > > https://docs.djangoproject.com/en/dev/intro/tutorial01/ > > There are a lot of other bulleted (and numbered?) lists in our docs that sport > the same green vertical bar at the left as the two-elements one at the top > of that page. > > Looking at the ReST documentation[1] it seems the indentation we use for > such lists are non-conventional and would explain this. > > Can anybody confirm this?. If so, we have a bunch of documentation > .txt files to tweak. As Carl pointed out, these are caused by the blockquote element inserted whenever the list is indented by 1 or more characters (as per ReST specification). It also applied to other things. I thought I had fixed all the instances of this when I committed my patch. However, I'm not sure exactly how, but I think I must have been caught out by cached Sphinx build files, as I only got a minority of them when I grepped for them - there were several hundreds more! I might not have attempted this if I had correctly counted at the beginning... but anyway, I've fixed them all now (hopefully!). It seems we were relying on this hack in *lots* of places, not just in the docs that originated from Jacob's import of docs. > (also, if/when we fix this we should verify that we don't break the stylin > of the affected parts in the docs.djangoproject.com) There is currently a problem with docs.djangoproject.com in that it doesn't display blockquotes visibly at all. There are 4 places in our docs that have genuine blockquotes, but you can't see where the quotation finishes due to lack of styling. I've sent Jacob a pull request for this already, to bring it inline with offline docs. (This is also the reason why we didn't see the hundreds of instances of blockquote in the docs on docs.djangoproject.com). Luke -- O'REILLY'S LAW OF THE KITCHEN Cleanliness is next to impossible. Luke Plant || http://lukeplant.me.uk/ -- 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: Update on Ticket #16891: Delete/update should return number of rows modified
On Thu, Oct 13, 2011 at 1:06 AM, Anssi Kääriäinen wrote: > > Now I have the feeling that I have gone through this exact same > discussion before, and have had the exact same misunderstanding, too, > before. So, sorry for that... > It's cool. Better to make sure we're all clear here on the different opinions and options. > > I think a reasonable option to discuss might be leaving the save() API as > it > > is and rolling this enhancement back to the internal code (i.e., > > UpdateQuery, DeleteQuery) returning counts to support the prospective > > enhancements I've alluded to, and/or overrides of save(). Until there are > > any changes to save(), I agree it is not going to be useful info. However > > for delete it seems immediately usable (and then we're left with the > debate > > of counting immediate-only or including related objects). > > I would go with immediate only, with the ability to get the counts for > cascaded deletes per object type as a kwarg option. The kwarg option > could be left for later implementation. One reason for immediate only > is that at least PostgreSQL and MySQL does it that way for ON DELETE > CASCADE foreign keys. So, if you are getting the value from the cursor > and using ON DELETE CASCADE instead of doing the cascade in Django, > you will not get the cascade counts anyways. And even if you do the > cascade in Django, then it would be consistent with what a SQL > database would report. Well, by those conventions and all of the feedback I've gotten so far, counting only immediate objects in a delete seems like the best way. Are there other opinions on this issue or the return value of save? Do any core devs have insight into any potential changes in the ORM that would be affected by this decision? Thanks. -- 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.
