Perl port of the django template system.
Marc Lucksch
It is going to be called Django::Template, and it is almost finished, some filters missing, cleaning up the documentation and writing tests.
My problem is now:
By calling it Django::Template I'm using your name "Django" to promote my work, which I cannot under the terms of the 3 clause BSD license which you are using:
> 3. Neither the name of Django nor the names of its contributors may be used
> to endorse or promote products derived from this software without
> specific prior written permission.
I'm not sure if I work is derived from yours, since I only used the documentation (http://docs.djangoproject.com/en/dev/ref/templates/builtins/) for my work, but I thougt I would better just ask:
Would you please allow me to use the name Django for my project?
The Django::Template module will be under the MIT license btw.
About the module:
I had the idea last Sunday to port the Django templates to perl:
1. I like perl
2. I like your template engine
3. Nobody else has done it.
The second idea I had was: Why not translate the Django sources to perl for faster execution, so that's exactly what it does.
It either runs Django templates or compiles and runs them. It supports already all tags in the documentation and will support all filters.
(Execpt {% url %} which I can't support and {% load %} which is not needed for now)
The goal is: Templates run by Django::Template should look the same as those run by Django.
P.S.: Since I haven't look at the Django source yet: What the hell does "iriencode" do?
Marc "Maluku" Lucksch
Malcolm Tredinnick
On Wed, 2008-12-17 at 01:49 +0100, Marc Lucksch wrote:
> I'm currently working on a port of the django template system to perl.
> It is going to be called Django::Template, and it is almost finished,
> some filters missing, cleaning up the documentation and writing tests.
>
> My problem is now:
> By calling it Django::Template I'm using your name "Django" to promote
> my work, which I cannot under the terms of the 3 clause BSD license
> which you are using:
> > 3. Neither the name of Django nor the names of its contributors may
> be used
> > to endorse or promote products derived from this software without
> > specific prior written permission.
>
> I'm not sure if I work is derived from yours, since I only used the
> documentation
> (http://docs.djangoproject.com/en/dev/ref/templates/builtins/) for my
> work, but I thougt I would better just ask:
Legalities aside, I'd prefer this wasn't done. It will induce confusion
as there will be some people who think it's associated with the Django
project. Having a description that says it implements the same
templating language as XYZ is simply descriptive, but making it clear in
the name that it's a different project would sit more comfortably with
me.
(Note: I have no actual say here, but that's my opinion as a reasonable
human being.)
[...]
> P.S.: Since I haven't look at the Django source yet: What the hell
> does "iriencode" do?
Encodes IRI's, obviously. As documented. :-)
Seriously, it implements section 3.1 of RFC 3987, with the exception of
international domain name handling (which is consistently not part of
Django yet, but most likely will be before 1.1).
Regards,
Malcolm
Maluku
On 17 Dez., 03:15, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> as there will be some people who think it's associated with the Django
> project. Having a description that says it implements the same
> templating language as XYZ is simply descriptive, but making it clear in
> the name that it's a different project would sit more comfortably with
> me.
statement that this has nothing to do with the Djangoproject into the
namespace description. That one can be seen everywhere the name is
displayed.
It would be annoying for any user to write
use
Django::Templates::which::do::not::have::anything::to::do::with::djangoproject
into every script :)
I wanted to call it Template::Django or Template::Like::Django, but
Template::Toolkit blocks the whole Template:: namespace. So the perl
list gurus told me to call it Django::Template
> > P.S.: Since I haven't look at the Django source yet: What the hell
> > does "iriencode" do?
>
> Encodes IRI's, obviously. As documented. :-)
>
> Seriously, it implements section 3.1 of RFC 3987, with the exception of
> international domain name handling (which is consistently not part of
> Django yet, but most likely will be before 1.1).
Yours,
Maluku (Marc Lucksch)
Justin Bronn
> documentation (http://docs.djangoproject.com/en/dev/ref/templates/builtins/)
> for my work, but I thougt I would better just ask:
>
> Would you please allow me to use the name Django for my project?
come up with a new name for your module. The jazz meme (e.g., [Duke]
'Ellington', 'Ella' [Fitzgerald]) is what others have done if you're
looking for a suggestion.
The BSD license is not the issue, it's that Django is a registered
trademark assigned to the Django Software Foundation (DSF). Having a
Perl module of the same name may cause confusion of our customers
(users), a circumstance that trademark law gives the DSF the legal
right to prevent. If we allow every language a 'Django' template
module, the DSF risks losing the trademark rights, and thus we won't
be able to wield the legal sword against the real bad actors out
there.
Regards,
-Justin
Malcolm Tredinnick
On Tue, 2008-12-16 at 18:28 -0800, Maluku wrote:
>
>
> On 17 Dez., 03:15, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
> > Legalities aside, I'd prefer this wasn't done. It will induce confusion
> > as there will be some people who think it's associated with the Django
> > project. Having a description that says it implements the same
> > templating language as XYZ is simply descriptive, but making it clear in
> > the name that it's a different project would sit more comfortably with
> > me.
> Changing the namespace is not that easy, sadly.
It's very easy: you just don't call it that. Why does it require
"change"?
> But I can make a
> statement that this has nothing to do with the Djangoproject into the
> namespace description. That one can be seen everywhere the name is
> displayed.
> It would be annoying for any user to write
> use
> Django::Templates::which::do::not::have::anything::to::do::with::djangoproject
> into every script :)
> I wanted to call it Template::Django or Template::Like::Django, but
> Template::Toolkit blocks the whole Template:: namespace. So the perl
> list gurus told me to call it Django::Template
All of this is predicated on using the word "Django" in the name, which
is the bit I have a problem with. Choose a different name for it. If you
implement a web server in Perl are you going to call it "Apache::*", if
it does some of the same things as Apache (e.g. using the HTTP
protocol)? No, you're going to find a proper name and then mention in
the docs that it does some of the same things as Apache, or in similar
ways to Apache. That avoids any confusion between your product and the
actual Apache product.
Malcolm
Mike Axiak
> Changing the namespace is not that easy, sadly. But I can make a
> statement that this has nothing to do with the Djangoproject into the
> namespace description. That one can be seen everywhere the name is
> displayed.
Um... I know you registered your namespace with CPAN, but as far as I
can tell, CPAN *really* doesn't care if you call it something else
(you don't even need to register a module to have it working on
CPAN...).
> I wanted to call it Template::Django or Template::Like::Django, but
> Template::Toolkit blocks the whole Template:: namespace. So the perl
> list gurus told me to call it Django::Template
Now this is just wrong. If you call it Template::WhateverIWant and
create the write Makefile.PL, the Makefile will install it into the
right place. There is no place that states A owns A::*.
PERL and CPAN can be accused of many things, but being strict---
especially w.r.t. naming ---is not one of them.
Cheers,
Mike
Maluku
wrote:
> "change"?
http://www.nntp.perl.org/group/perl.modules/2008/12/msg63533.html
> Choose a different name for it. If you
> implement a web server in Perl are you going to call it "Apache::*", if
> it does some of the same things as Apache (e.g. using the HTTP
> protocol)? No, you're going to find a proper name and then mention in
> the docs that it does some of the same things as Apache, or in similar
> ways to Apache. That avoids any confusion between your product and the
> actual Apache product.
Django, but if this is a problem I will call it something else.
Apache is a bad example, since many modules that _use_ Apache are also
in the Apache:: Namespace, like Apache::Template and such.
So where would you look for a template system to work with your
existing Django templates?
On 17 Dez., 03:49, "Mike Axiak" <mcax...@gmail.com> wrote:
> Hi,
>
> > Changing the namespace is not that easy, sadly. But I can make a
> > namespace description. That one can be seen everywhere the name is
> > displayed.
>
> can tell, CPAN *really* doesn't care if you call it something else
> (you don't even need to register a module to have it working on
> CPAN...).
>
> > Template::Toolkit blocks the whole Template:: namespace. So the perl
> > list gurus told me to call it Django::Template
>
> create the write Makefile.PL, the Makefile will install it into the
> right place. There is no place that states A owns A::*.
>
has to be the same as the module name, otherwise it won't be found (in
the list, not in the search). And in that list there is somewhat of a
rule that states A owns A::*
https://pause.perl.org/pause/authenquery?ACTION=apply_mod:
> Please use this form to apply for the registration of a namespace for a module you have written or are going to write. The request will be sent off to the mod...@perl.org people who are maintaining the Modules List. A registration is not a prerequisite for uploading. It is just recommended for better searchability of the CPAN and to avoid namespace clashes. You will be notified when the registration is approved but you can upload immediately, there's no need to wait for an approval. On the contrary, you are encouraged to upload immediately.
Arien
<mal...@pointy-stick.com> wrote:
>
> All of this is predicated on using the word "Django" in the name, which
> is the bit I have a problem with.
How is this different from, e.g., any of these?
http://code.google.com/hosting/search?q=django-
> Choose a different name for it. If you implement a web server in Perl
> are you going to call it "Apache::*", if it does some of the same things
> as Apache (e.g. using the HTTP protocol)? No, you're going to find a
> proper name and then mention in the docs that it does some of the same
> things as Apache, or in similar ways to Apache. That avoids any
> confusion between your product and the actual Apache product.
http://search.cpan.org/search?query=Apache&mode=module
Arien
alvaro
Malcolm Tredinnick
On Tue, 2008-12-16 at 19:11 -0800, Maluku wrote:
> On 17 Dez., 03:36, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
> > It's very easy: you just don't call it that. Why does it require
> > "change"?
>
> I have discussed this with the perl naming people here:
> http://www.nntp.perl.org/group/perl.modules/2008/12/msg63533.html
So the problem that you are now mentioning is that you registered the
name first and decided to ask check if there might be a problem only
afterwards. I'm really not trying to be a hard-ass here, but that's not
a motivating factor. The solution is still simple. You just don't upload
anything. You pick a better, different name and use that. You tell the
CPAN guys you made a mistake in registering the original name. What
happens if somebody makes a typo in the name of their package, for
example? There must be plenty of cases of accidental registration.
> > Choose a different name for it. If you
> > implement a web server in Perl are you going to call it "Apache::*", if
> > it does some of the same things as Apache (e.g. using the HTTP
> > protocol)? No, you're going to find a proper name and then mention in
> > the docs that it does some of the same things as Apache, or in similar
> > ways to Apache. That avoids any confusion between your product and the
> > actual Apache product.
> It called it that, because it provides a template language like
> Django, but if this is a problem I will call it something else.
> Apache is a bad example, since many modules that _use_ Apache are also
> in the Apache:: Namespace, like Apache::Template and such.
No, Apache is a good example and I chose it with good reason. You are
not writing something that uses Django or wraps Django to provide a Perl
interface or is used in conjunction to extend Django. You are
reimplementing it entirely independently, just as if you writing a
different webserver. It just happens to use the same syntax.
> So where would you look for a template system to work with your
> existing Django templates?
In Django. Why would I have Django templates and then want to switch to
Perl, would be the more relevant question. I doubt the cross-over
audience is you primary base here.
Not having Django in the name is not the show-stopper for searches in
any case. Any decent search engine is going to index the description
that will include sentences like "uses a syntax similar to Django
templates".
As I said, I don't really have any power of decision here. I'd be
disappointed if the name Django was used in the Perl module name and
there are precisely no technical reasons why it's required.
Malcolm
Malcolm Tredinnick
On Tue, 2008-12-16 at 21:18 -0600, Arien wrote:
> On Tue, Dec 16, 2008 at 8:36 PM, Malcolm Tredinnick
> <mal...@pointy-stick.com> wrote:
> >
> > All of this is predicated on using the word "Django" in the name, which
> > is the bit I have a problem with.
>
> How is this different from, e.g., any of these?
>
> http://code.google.com/hosting/search?q=django-
Take your pick:
(a) It's not, really. People could do a much better job of naming their
packages.
(b) All of those packages are designed to run using Django, the Python
web framework.
>
> > Choose a different name for it. If you implement a web server in Perl
> > are you going to call it "Apache::*", if it does some of the same things
> > as Apache (e.g. using the HTTP protocol)? No, you're going to find a
> > proper name and then mention in the docs that it does some of the same
> > things as Apache, or in similar ways to Apache. That avoids any
> > confusion between your product and the actual Apache product.
>
> http://search.cpan.org/search?query=Apache&mode=module
Already answered in early mails.
Malcolm
Jeremy Sandell
however, since he's porting it in a different language (and thus, for
a different community) that might be confusing to those unfamiliar
with Django. For example, say someone's fed up with Template::Toolkit
and is looking for a different syntax that fits their wants and/or
needs better.
I'm *not* a legal beagle, but would something like
"Djangoize::Template" or what-have-you work for this? I know I've seen
plenty of derivatives out there thus far in the Django community
itself, e.g., django-hotclub, but not for use outside of the
framework.
Just looking for some clarification. The idea of a similar syntax
being available to other languages sounds nice, but I have a pretty
strong bias. (:
Thanks,
- Jeremy
Justin Lilly
something that follows django's template syntax, and have still built
up a community. There is also the ruby version which is called liquid
iirc that borrows heavily from django's syntax. Basically, it doesn't
need django in it's proper name to become popular.
I'm personally against django being in the name for the same reasons I
don't think people should put 3rd party modules under their django
install because from django.template import perl_stuff just makes
things confusing, both for newbies looking for documentation as well
as switchers.
+1 for reindhart though :)
-justin
On Dec 16, 2008, at 10:33 PM, Jeremy Sandell <jlsa...@gmail.com>
wrote:
Maluku
On 17 Dez., 04:23, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> name first and decided to ask check if there might be a problem only
> afterwards. I'm really not trying to be a hard-ass here, but that's not
> a motivating factor. The solution is still simple. You just don't upload
> anything. You pick a better, different name and use that. You tell the
> CPAN guys you made a mistake in registering the original name. What
> happens if somebody makes a typo in the name of their package, for
> example? There must be plenty of cases of accidental registration.
Still I would prefer it to be called Django::Template and stay very
close to the Django specification.
In my view Djangos templates are pretty much a defined file format and
the Django::Template module provides an interface for those files.
That's why I think it is a fitting name.
Like for example YAML files, which has a lot of parsers. And in every
language I want to use it, I just google for YAML and language name
and there I go. Given the choice between YAML::Syck or
Data::File::Structured I go for the YAML::Syck module first and might
have overlooked the other one. And all search engines I know treat the
title as special. http://search.cpan.org/search?m=all&q=YAML is not
showing Activator::Registry first but behind all the other module with
YAML in the title.
>As I said, I don't really have any power of decision here.
This is really a matter of opinion, some say that people who provide
an interface to their files are are infringing their copyright and
others think that having the ability to access those files in other
languages might strengthen their format and benefit their users and
maybe even themselves.
I personaly don't like that with switching a framework, or being
forced to switch by an employer, you have to learn a new programming
language, a new template language and maybe a new database. This takes
a lot of time and effort. If you could use the old templates in the
new language you might have some less work to do. Just as a general
concept. There are like a gazillion template languages out there, and
I like Djangos the best, but I have to work in Perl for my current
project (because I spent like a year of code in perl in it)
alex....@gmail.com
precedent for a derivative template language going by the same name,
Dojo also implements the Django template language and calls it just
that. That being said, that, amongst other things preceded the
existence of the DSF.
Alex
On Dec 16, 9:55 pm, Maluku <marc.luck...@googlemail.com> wrote:
> On 17 Dez., 04:23, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
>
> > So the problem that you are now mentioning is that you registered the
> > name first and decided to ask check if there might be a problem only
> > afterwards. I'm really not trying to be a hard-ass here, but that's not
> > a motivating factor. The solution is still simple. You just don't upload
> > anything. You pick a better, different name and use that. You tell the
> > CPAN guys you made a mistake in registering the original name. What
> > happens if somebody makes a typo in the name of their package, for
> > example? There must be plenty of cases of accidental registration.
>
> I probably will have to do that then :(
> Still I would prefer it to be called Django::Template and stay very
> close to the Django specification.
> In my view Djangos templates are pretty much a defined file format and
> the Django::Template module provides an interface for those files.
> That's why I think it is a fitting name.
>
> Like for example YAML files, which has a lot of parsers. And in every
> language I want to use it, I just google for YAML and language name
> and there I go. Given the choice between YAML::Syck or
> Data::File::Structured I go for the YAML::Syck module first and might
> have overlooked the other one. And all search engines I know treat the
James Bennett
<alex....@gmail.com> wrote:
> I am not a legal expert(that's Justin's job ;-) ), but there is a
> precedent for a derivative template language going by the same name,
> Dojo also implements the Django template language and calls it just
> that. That being said, that, amongst other things preceded the
> existence of the DSF.
Actually, they call their package "dojox.dtl". Their documentation
explains that it implements the Django template language.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
flo...@gmail.com
> explains that it implements the Django template language.
someone raised their hand and asked a question that went something
like this: "I saw that Django switched over to being JavaScript now,
and is part of Dojo. Why would they do that?" The fact that it even
referenced the name Django confused more than zero people.
Thanks,
Eric Florenzano
On Dec 16, 8:39 pm, "James Bennett" <ubernost...@gmail.com> wrote:
> On Tue, Dec 16, 2008 at 10:32 PM, alex.gay...@gmail.com
Jannis Leidel
Am 17.12.2008 um 04:11 schrieb Maluku:
> It called it that, because it provides a template language like
> Django, but if this is a problem I will call it something else.
> Apache is a bad example, since many modules that _use_ Apache are also
> in the Apache:: Namespace, like Apache::Template and such.
>
> So where would you look for a template system to work with your
> existing Django templates?
Just for the sake of completeness, there is a PHP5 clone of the Django
template system called "Calypso DTL":
http://www.beberlei.de/calypso/
--
Jannis Leidel
jezdez.com
Maluku
On 17 Dez., 05:46, "flo...@gmail.com" <flo...@gmail.com> wrote:
> > Actually, they call their package "dojox.dtl". Their documentation
> > explains that it implements the Django template language.
>
> Even still, at a local Python meetup a little over a month ago,
> someone raised their hand and asked a question that went something
> like this: "I saw that Django switched over to being JavaScript now,
> and is part of Dojo. Why would they do that?" The fact that it even
> referenced the name Django confused more than zero people.
public, which is kinda sad, even if it was only a week, it was still a
big amount of work.
Well it's still the question: Are Dajngo Templates a file format or
not? Atleast VIM thinks so (It is in the filetypes menu in Vim :) )
What would you guys think an appropriate name there is?
Eugene Lazutkin
>> Actually, they call their package "dojox.dtl". Their documentation
>> explains that it implements the Django template language.
Yep: http://dojotoolkit.org/book/dojo-book-0-9/part-5-dojox/dojox-dtl
> Even still, at a local Python meetup a little over a month ago,
> someone raised their hand and asked a question that went something
> like this: "I saw that Django switched over to being JavaScript now,
> and is part of Dojo. Why would they do that?" The fact that it even
> referenced the name Django confused more than zero people.
Some people are blessed with being naturally confused without external
factors.
Personally I like DTL --- it is a short memorable to-the-point acronym
that pays homage to Django, yet distinctive enough from everything else.
It doesn't play on subtle associations nor obscure music trivia, yet it
doesn't hide its heritage.
If I was to do a Perl port of DTL, I'll choose ... the DTL namespace, if
it is not taken yet.
Thanks,
Eugene
James Bennett
<eugene....@gmail.com> wrote:
> Some people are blessed with being naturally confused without external
> factors.
Indeed. Documenting that something implements the same format as
Django templates will only confuse people who were already going to be
confused anyway (e.g., showing them a Python implementation of
Markdown or Textile would have the same effect). So I don't see any
problem there.
> Personally I like DTL --- it is a short memorable to-the-point acronym
> that pays homage to Django, yet distinctive enough from everything else.
> It doesn't play on subtle associations nor obscure music trivia, yet it
> doesn't hide its heritage.
I like it, especially since there's prior art.
Maluku
wikipedia has entry for DTL that comes close.
I have requested to rename the module to DTL or DTL::Template, will
tell you what happens after I hear back.
So how about the legal side of it? Do I have to include the source
code for Django in every distribution, since my work is derived from
your documentation or is just a link enough?
Yours,
Marc "Maluku" Lucksch
Jacob Kaplan-Moss
> So how about the legal side of it? Do I have to include the source
> code for Django in every distribution, since my work is derived from
> your documentation or is just a link enough?
A link is fine.
Jacob
Maluku
What about "Dotiac" (DjangO Template Interpreter And Compiler), which
works as a name and an abbreviation.
Maluku
Eric Holscher
Eric
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com
er...@ericholscher.com
Barry Pederson
> DTL seems to be too short...
In addition to DojoX DTL, there's an Erlang library: ErlyDTL (
http://code.google.com/p/erlydtl/ ), and a PHP library: Calypso DTL
just an FYI that there are at least three other "DTL"s out there, so
<something>DTL would have some company.
Barry
Maluku
> In addition to DojoX DTL, there's an Erlang library: ErlyDTL (http://code.google.com/p/erlydtl/), and a PHP library: Calypso DTL
> just an FYI that there are at least three other "DTL"s out there, so
> <something>DTL would have some company.
>
Well till this name thing is cleared up, I'm going to write some more
documentation.
perlDTL, malukuDTL, has not yet the right ring to it...
Adam Findley
The real tragedy here is that the Django Template system is great, but
it's name is "tightly coupled" to the Django Project.
I think DTL is a great and common standard and what people will be looking for.
What's wrong with template::dtl or template::perlDTL? People are
going to recognize it for what it is now that DTL is the common name
for the django template library.
This should be easier than naming a kid.
Adam
Maluku
On 26 Dez., 08:54, "Adam Findley" <drfind...@gmail.com> wrote:
> The real tragedy here is that the Django Template system is great, but
> it's name is "tightly coupled" to the Django Project.
>
> I think DTL is a great and common standard and what people will be looking for.
>
> What's wrong with template::dtl or template::perlDTL? People are
> going to recognize it for what it is now that DTL is the common name
> for the django template library.
that and I won't impose on their namespace. DTL alone is too short and
perlDTL sounds kind of redundent.
I'm kind of thinking about Dotiac::DTL for now and just treating
Dotiac as a name, cause I like it. Can't decide if the "o" is spoken
short or long..
> This should be easier than naming a kid.
Kind of different question: Why is there no {% else %} in {% ifchanged
%}, I think it might be a help to some people.
James Bennett
> Kind of different question: Why is there no {% else %} in {% ifchanged
> %}, I think it might be a help to some people.
Because it wouldn't make any sense; the point of 'ifchanged' is to say
"I have a special thing which only needs to happen when this other
thing changes", not to set up complex chains of conditionals.
Dave Smith
Because it wouldn't make any sense; the point of 'ifchanged' is to say
On Fri, Dec 26, 2008 at 11:36 AM, Maluku <marc.l...@googlemail.com> wrote:
> Kind of different question: Why is there no {% else %} in {% ifchanged
> %}, I think it might be a help to some people.
"I have a special thing which only needs to happen when this other
thing changes", not to set up complex chains of conditionals.
There are several use cases that an 'else' simplifies. See http://code.djangoproject.com/ticket/4534
and http://code.djangoproject.com/changeset/8095 for the patch.
Dave
Maluku
On 26 Dez., 19:10, "Dave Smith" <davewsm...@gmail.com> wrote:
> There are several use cases that an 'else' simplifies. Seehttp://code.djangoproject.com/ticket/4534
> andhttp://code.djangoproject.com/changeset/8095for the patch.
I just saw:
{% cycle "foo","bar" as foocyle %}
{{ foocycle }}
works too, this is documentented nowhere in
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#cycle
Is this supposed to work? or not?
Maluku