Re: NDjango - .Net port of Django template langauage
Michael Feingold wrote:
>
> Thank you for the pointers. You have some pretty interesting test
> cases in your project.
Thanks. Actually most of the credit goes to the django developers, because
most of my tests are just ported versions of the django tests.
> We also have quiet a few test cases in our unit
> tests have a peek if you are interested.
Yes, I will.
> As to the ticket - this is an
> interesting one. The scenario it refers to seems pretty clear to me I
> agree with Karen's judjment on the issue. Nested block definitions and
> block.super variables in itself seem clear to me and it appears to
> work fine in our testing. But here is the scenario I cannot find a
> miningful interpretation for:
>
> === base template ===
> {% block b %}
> whatever
> {% endblock b %}
>
> === child template ===
> {% extends base %}
> {% block new %}
> {% for k in list %}
> {% block b %}
> new value: {{k}}
> {% endblock %}
> {% endfor %}
> {% endblock new %}
The first issue is that the block new is not defined in the base template.
See the unit test inheritance14:
http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/templates/tests.py#L757
That means that the block new will not be rendered, and any variables
created in that context will not be defined. However, as block b is defined
in the base, django searches for b in the child anywhere in its node tree.
It is found and rendered in the right place, but as "k" is undefined, the
output is simply "\nnew value: \n".
If block new was defined in the base template, the situation would be
different, and I think it's covered in the tests I posted before where the
block b would be rendered for each value in the list. I'm not certain
whether that behaviour is desired or undefined.
All the best,
Steve.
>
> assuming that there let's say 6 values in the list what is the
> expected result here? The child template defines 6 different variants
> to be placed in a single hole? which one goes? The first? the last?
> all of them? Nested block definition is ok when we define a 'hole',
> but when we define a new value to be placed in a hole it creates
> ambiguity for which I do not see any real use.
>
> On Sep 23, 2:22 pm, Stephen Kelly
> wrote:
>> Michael Feingold wrote:
>> > On Sep 23, 2:54 am, Pablo Escobar
>> > wrote:
>> >> 1. Django is Open Source. It is not a problem to find the parsing
>> >> algorithm
>>
>> > Of course it is And we did go through the code. But reverse
>> > engineering can show you what happens, not what the intention was
>>
>> Usually the unit tests are the best documentation there. However I
>> noticed that in this case there are no unit tests for blocks being
>> nested.
>>
>> I am also the author of a port of the Django system, to C++/Qt in my
>> case.
>>
>> http://www.gitorious.org/grantlee/pages/Home
>>
>> I wrote some tests for nesting of blocks here:
>>
>> http://www.gitorious.org/grantlee/grantlee/commit/85c47cd951e155008a8...
>>
>> Which I'm sure I'll eventually port back up to django. The end result
>> seems to be that {{ block.super }} can behave in ways that you might not
>> expect when blocks are nested.
>>
>> I also found this ticket which probably explains the behaviour I see in
>> the tests when using block.super:
>>
>> http://code.djangoproject.com/ticket/7324
>>
>> All the best,
>>
>> Steve.
>
--~--~-~--~~~---~--~~
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: NDjango - .Net port of Django template langauage
Thank you for the pointers. You have some pretty interesting test
cases in your project. We also have quiet a few test cases in our unit
tests have a peek if you are interested. As to the ticket - this is an
interesting one. The scenario it refers to seems pretty clear to me I
agree with Karen's judjment on the issue. Nested block definitions and
block.super variables in itself seem clear to me and it appears to
work fine in our testing. But here is the scenario I cannot find a
miningful interpretation for:
=== base template ===
{% block b %}
whatever
{% endblock b %}
=== child template ===
{% extends base %}
{% block new %}
{% for k in list %}
{% block b %}
new value: {{k}}
{% endblock %}
{% endfor %}
{% endblock new %}
assuming that there let's say 6 values in the list what is the
expected result here? The child template defines 6 different variants
to be placed in a single hole? which one goes? The first? the last?
all of them? Nested block definition is ok when we define a 'hole',
but when we define a new value to be placed in a hole it creates
ambiguity for which I do not see any real use.
On Sep 23, 2:22 pm, Stephen Kelly wrote:
> Michael Feingold wrote:
> > On Sep 23, 2:54 am, Pablo Escobar
> > wrote:
> >> 1. Django is Open Source. It is not a problem to find the parsing
> >> algorithm
>
> > Of course it is And we did go through the code. But reverse
> > engineering can show you what happens, not what the intention was
>
> Usually the unit tests are the best documentation there. However I noticed
> that in this case there are no unit tests for blocks being nested.
>
> I am also the author of a port of the Django system, to C++/Qt in my case.
>
> http://www.gitorious.org/grantlee/pages/Home
>
> I wrote some tests for nesting of blocks here:
>
> http://www.gitorious.org/grantlee/grantlee/commit/85c47cd951e155008a8...
>
> Which I'm sure I'll eventually port back up to django. The end result seems
> to be that {{ block.super }} can behave in ways that you might not expect
> when blocks are nested.
>
> I also found this ticket which probably explains the behaviour I see in the
> tests when using block.super:
>
> http://code.djangoproject.com/ticket/7324
>
> All the best,
>
> Steve.
--~--~-~--~~~---~--~~
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: NDjango - .Net port of Django template langauage
Michael Feingold wrote:
> On Sep 23, 2:54 am, Pablo Escobar
> wrote:
>> 1. Django is Open Source. It is not a problem to find the parsing
>> algorithm
>>
> Of course it is And we did go through the code. But reverse
> engineering can show you what happens, not what the intention was
Usually the unit tests are the best documentation there. However I noticed
that in this case there are no unit tests for blocks being nested.
I am also the author of a port of the Django system, to C++/Qt in my case.
http://www.gitorious.org/grantlee/pages/Home
I wrote some tests for nesting of blocks here:
http://www.gitorious.org/grantlee/grantlee/commit/85c47cd951e155008a8a5241a7bb2ef8dd018e82
Which I'm sure I'll eventually port back up to django. The end result seems
to be that {{ block.super }} can behave in ways that you might not expect
when blocks are nested.
I also found this ticket which probably explains the behaviour I see in the
tests when using block.super:
http://code.djangoproject.com/ticket/7324
All the best,
Steve.
--~--~-~--~~~---~--~~
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: NDjango - .Net port of Django template langauage
On Sep 23, 2:54 am, Pablo Escobar wrote: > 1. Django is Open Source. It is not a problem to find the parsing > algorithm > Of course it is And we did go through the code. But reverse engineering can show you what happens, not what the intention was --~--~-~--~~~---~--~~ 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: NDjango - .Net port of Django template langauage
1. Django is Open Source. It is not a problem to find the parsing algorithm PS Anyway. I don't see any advantages of django's templates comparing with ASP.NET MVC Views --~--~-~--~~~---~--~~ 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: NDjango - .Net port of Django template langauage
On Tue, Sep 22, 2009 at 2:20 PM, Michael Feingold wrote: > > That's what we started with. It did not work out. While IronPython (as > well as some other implementations of Python) are available in .Net, > integrating an app written in Python with anything else written in any > other .Net language proved to be a big challenge. You can run a Python > app on .Net platform, but it still lives in its own world > > That is not so much the case any more... you can now call Python functions from other DLR scripting languages. So, you could conceivable run the Django template parser in IronPython from IronRuby, for example. And with the new dynamic syntax in .NET 4, this could work from F# too. In any event, good luck with your project. -Doug > On Sep 22, 1:11 pm, Dj Gilcrease wrote: > > I dont know all that much about .Net but isnt the point of it that all > > the .Net languages can be used together? eg using C#.Net components in > > a VB.Net app and such. > > > > So why not just use the django template language as is via IronPython > > instead of trying to port it to another language? > > > --~--~-~--~~~---~--~~ 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: NDjango - .Net port of Django template langauage
That's what we started with. It did not work out. While IronPython (as well as some other implementations of Python) are available in .Net, integrating an app written in Python with anything else written in any other .Net language proved to be a big challenge. You can run a Python app on .Net platform, but it still lives in its own world On Sep 22, 1:11 pm, Dj Gilcrease wrote: > I dont know all that much about .Net but isnt the point of it that all > the .Net languages can be used together? eg using C#.Net components in > a VB.Net app and such. > > So why not just use the django template language as is via IronPython > instead of trying to port it to another language? --~--~-~--~~~---~--~~ 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: NDjango - .Net port of Django template langauage
I dont know all that much about .Net but isnt the point of it that all the .Net languages can be used together? eg using C#.Net components in a VB.Net app and such. So why not just use the django template language as is via IronPython instead of trying to port it to another language? --~--~-~--~~~---~--~~ 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: NDjango - .Net port of Django template langauage
Well, we liked the language, and it is too late anyway - it is implemented On Sep 22, 12:18 pm, Anton Bessonov wrote: > Hello, > > if you need template engine only, then make more sence to port pure > template engine such as jinja2. IMHO. > > Michael Feingold schrieb: > > > > > I am working on NDjango project. NDjango is a port of Django template > > language to .Net. It is an open source project. If you are curious you > > can get all information about it here:www.ndjango.org. > > > The reason I am posting here is that while one of our design goals is > > to keep ndjango templates compatible with django sometimes we cant > > help it. In such situations even though we cannot follow django > > scripture to the letter we are trying to follow the spirit. > > > The specific question I would love to get some authorative answer to > > has to do with nested blocks. I am talking about block tags defining > > new content for blocks defined in a parent template. The django > > documentation does not asy anything certain about whether is it valid > > to have such blocks nested inside other tags. In my opinion this > > should be disallowed because it creates ambiguity and does not really > > buy anything. > > > I posted the same question with more details on our mailing list: > >http://groups.google.com/group/ndjango-dev/browse_thread/thread/ac776- > >Hide quoted text - > > - Show quoted text - --~--~-~--~~~---~--~~ 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: NDjango - .Net port of Django template langauage
Hello, if you need template engine only, then make more sence to port pure template engine such as jinja2. IMHO. Michael Feingold schrieb: > I am working on NDjango project. NDjango is a port of Django template > language to .Net. It is an open source project. If you are curious you > can get all information about it here: www.ndjango.org. > > The reason I am posting here is that while one of our design goals is > to keep ndjango templates compatible with django sometimes we cant > help it. In such situations even though we cannot follow django > scripture to the letter we are trying to follow the spirit. > > The specific question I would love to get some authorative answer to > has to do with nested blocks. I am talking about block tags defining > new content for blocks defined in a parent template. The django > documentation does not asy anything certain about whether is it valid > to have such blocks nested inside other tags. In my opinion this > should be disallowed because it creates ambiguity and does not really > buy anything. > > I posted the same question with more details on our mailing list: > http://groups.google.com/group/ndjango-dev/browse_thread/thread/ac7762c764519f83. > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
NDjango - .Net port of Django template langauage
I am working on NDjango project. NDjango is a port of Django template language to .Net. It is an open source project. If you are curious you can get all information about it here: www.ndjango.org. The reason I am posting here is that while one of our design goals is to keep ndjango templates compatible with django sometimes we cant help it. In such situations even though we cannot follow django scripture to the letter we are trying to follow the spirit. The specific question I would love to get some authorative answer to has to do with nested blocks. I am talking about block tags defining new content for blocks defined in a parent template. The django documentation does not asy anything certain about whether is it valid to have such blocks nested inside other tags. In my opinion this should be disallowed because it creates ambiguity and does not really buy anything. I posted the same question with more details on our mailing list: http://groups.google.com/group/ndjango-dev/browse_thread/thread/ac7762c764519f83. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
