Seite 1 von 2
recursive Daten in django Templates benutzten...
Verfasst: Montag 26. Februar 2007, 19:10
von jens
Mit Jinja ging das so:
Code: Alles auswählen
<ul id="main_menu">
{% for item in menu_data %}
<li>
<a href="{{ item.href }}" class="level_{{ item.level }}" title="{{ item.title|escape }}">
{% if item.is_current_page %}
<span class="current">{{ item.name|escape }}</span>
{% else %}
{{ item.name|escape }}
{% endif %}
</a>
{% if item.subitems %}
<ul>{% recurse item.subitems %}</ul>
{% endif %}
</li>
{% endfor %}
</ul>
Also mit
recurse konnte ich verschachtelte Daten, wie hier ein Menü aufbauen.
Doch wie macht man das in django? Ich hab in der Doku darüber nichts gefunden...
Verfasst: Montag 26. Februar 2007, 23:44
von Leonidas
Da ich jetzt keine Lust habe mir Jinja zu installieren und es zu testen - kannst du mal schreiben, was der recurse-Tag macht?
Außerdem ist es natürlich ebenso möglich mit Django eigene Templatetags zu schreiben, also falls Django das nicht kann und keinen anderen, angenehmen Weg hat, das zu lösen ist es wahrscheinlich möglich sowas zu implementieren.
Verfasst: Dienstag 27. Februar 2007, 09:35
von jens
Sorry, das war wohl zu wenige Info's...
Hier ein Beispiel:
http://www.python-forum.de/post-39282.html#39282
Die Doku:
http://wsgiarea.pocoo.org/jinja/docs/lo ... #recursion
Irgendwie kann ich mir nicht vorstellen, das man es in django selber Programmieren muß...
Wobei nach
http://jjinux.blogspot.com/2006/02/pyth ... lates.html zu Urteilen muß man es doch selber machen?!?!
Verfasst: Dienstag 27. Februar 2007, 16:38
von Leonidas
Ja, ich würde für so was einen Template-Tag schreiben.
Verfasst: Dienstag 27. Februar 2007, 17:04
von jens
Dann habe ich also keine schon bestehende Möglichkeit übersehen?
Schade.
Verfasst: Dienstag 27. Februar 2007, 17:11
von Leonidas
jens hat geschrieben:Dann habe ich also keine schon bestehende Möglichkeit übersehen?
Kannst ja noch in #django oder djangu-users nachfragen.
Verfasst: Dienstag 27. Februar 2007, 17:24
von jens
Hab auf der Maillingliste gefragt:
http://groups.google.com/group/django-u ... d4348b0471
Bisher keine Antwort...
EDIT: Das gefunden:
http://groups.google.com/group/django-u ... 157491102a
Da hat sich also jemand schon mal die Arbeit gemacht einen {% recurse %} Tag zu schreiben. Leider sind die Sourcen aber nicht mehr online
Verfasst: Dienstag 27. Februar 2007, 17:35
von mitsuhiko
Sind sie. Mit ein wenig Querdenken kommt man ganz leicht an den aktuellen Link:
https://svn.greenpeace.org/projects/cus ... tomtags.py
Verfasst: Donnerstag 1. März 2007, 09:49
von jens
@blackbird: Dank dir, ich hatte es in der zwischenzeit allerdings selbst gefunden.
Allerdings kann ich damit wenig anfangen. Es funktioniert IMHO anders als die jinja Funktion.
Vielleicht werde ich ganz auf die django Templates verzichten und doch wieder auf jinja setzten.
Mir stinkt es z.B. auch das man seine eigene Tags/Filter explizit mit "{% load BlaBla %}" im Template laden muß.
Es gibt nun Antworten in der Maillingliste:
http://groups.google.com/group/django-u ... d4348b0471
Ich frage mich warum das niemand braucht... Ein tree-Menu ist offensichtlich im dollen Web2.0 out, was?
Verfasst: Donnerstag 1. März 2007, 14:14
von Leonidas
jens hat geschrieben:Mir stinkt es z.B. auch das man seine eigene Tags/Filter explizit mit "{% load BlaBla %}" im Template laden muß.
Explicit is better than implicit?
Ich habe alle meine Filter und Tags in einer Datei, dann ist das zu verschmerzen und der Load-Tag kann ja mehrere Dateien gleichzeitig laden.
Verfasst: Freitag 2. März 2007, 09:23
von jens
Ja, hast eigentlich recht... Dennoch bin ich in dem Falle aber für implicit
Auf der Maillinliste hat nun einer sich die mühe gemacht und erklärt wie dieser greenpeace code funktionieren kann:
http://groups.google.com/group/django-u ... 79e0e9fd90
Da der Sourcecode unter GPL steht, versuche ich gerade ihn zu benutzten.
Django mag aber nicht mein Tag-Lib laden:
TemplateSyntaxError: 'pylucid_tags' is not a valid tag library: Could not load template library from django.templatetags.pylucid_tags, No module named template
Die Datei ist auch nicht unter django.templatetags.pylucid_tags zu finden, sondern unter PyLucid.templatetags.pylucid_tags... Keine Ahnung wie ich dem das klar machen soll... naja, schau ich mal...
EDIT: Ha! Bei django Fehler muß man wirklich genau lesen
Die Fehlermeldung ist irreführend. Denn django.templatetags.pylucid_tags ist zwar falsch. Dennoch wurde meine Lib geladen und der eigentliche Fehler steht hinten: "No module named template"
Das ist nämlich ein Import-Fehler in meiner Lib.
Das ganze ist auch bekannt:
http://code.djangoproject.com/ticket/3349
Generell sind einige Fehlermeldungen von django irreführend
Verfasst: Freitag 2. März 2007, 14:53
von jens
Ja, es könnte ja alles so einfach sein... Leider ist der gefundene Code für eine ältere django Version
Spontan hat es nicht funktioniert den anzupassen...
Verfasst: Montag 14. Mai 2007, 13:36
von jens
jens hat geschrieben:Mir stinkt es z.B. auch das man seine eigene Tags/Filter explizit mit "{% load BlaBla %}" im Template laden muß.
Dafür gibt es eine Lösung
Code: Alles auswählen
# <mysite>/globaltags/__init__.py
from django.template import add_to_builtins
add_to_builtins('globaltags.pyif')
add_to_builtins('globaltags.expr')
add_to_builtins('globaltags.dbinfo')
siehe auch:
http://www.djangosnippets.org/snippets/160/
und:
http://groups.google.com/group/django-d ... dc5c3c5821
Dennoch bin ich mit meine Tree-Menü nicht weiter gekommen
Ich generiere einfach den HTML Code im Skript, aber das ist eigentlich dumm. Allerdings super einfach zu realisieren.
Hat jemand eine Idee?
Verfasst: Donnerstag 30. Juli 2009, 08:11
von jens
Ist zwar schon was länger her... Aber zum Thema recursive Daten in django Templates hab ich nun eine Lösung: Mit dem include template tag, kann man das ganz gut Lösen, siehe:
http://www.jensdiemer.de/_command/118/blog/detail/70/
Verfasst: Donnerstag 30. Juli 2009, 08:22
von Defnull
Hätte ich den Thread früher gesehen, hätte ich das selbe geantwortet. Diese "recurse" ist nichts weiter als ein rekursives laden des selben Templates mit anderen Variablen. Mit "include" kann man das gleiche erreichen.
Persönlich halte ich den Einbau einer "recurse" Funktion für eine eher schlechte Design-Entscheidung. "There should be one-- and preferably only one --obvious way to do it."
Verfasst: Donnerstag 30. Juli 2009, 08:25
von jens
Ich halte das nicht für eine schlechte Idee. Denn normalerweise ist include ehr für einmaliges einbinden da.
Mit einer "recurse" Funktion braucht man das Template nicht mehr aufzuteilen. Wäre auch wahrscheinlich schneller.
Im Netz gibt es auch Beispiele. Aber richtig Funktioniert haben die bei mir nicht. So bleib ich lieber bei der include Lösung.
Verfasst: Donnerstag 30. Juli 2009, 08:34
von Defnull
Die "recurse" Funktion ist redundant (also überflüssig), da man exakt das gleiche Verhalten mit "include template_name" erreichen kann. Warum "include" nur für einmaliges Einfügen da sein soll, kann ich nicht nach vollziehen. Besonders nicht im Template-Zusammenhang, wo es doch eher um Textbausteine und weniger um Bibliotheken geht.
Aber im Endeffekt ist und bleibt sowas Geschmackssache. Nicht umsonst gibt es eine so große Auswahl an Template Engines
Ich find meine eigene eh am besten
Verfasst: Donnerstag 30. Juli 2009, 09:09
von jens
Wie ich schon geschrieben hab, include arbeitet halt anders, man muß dazu zwei template dateien anlegen. Mit einer "recurse" Funktion kann man alles in einem Template machen, somit ist es schon was anderes.
Aber egal. Die Django Jungs mögen das wohl nicht oder brauchen es nicht.
Verfasst: Donnerstag 30. Juli 2009, 11:01
von Defnull
Verfasst: Donnerstag 30. Juli 2009, 11:11
von lunar
Wie hast du das denn da raus gelesen?! Er schreibt nur, dass man den Dateinamen der zweiten Daten als Variable übergeben kann, um die Evaluierung bis zur Laufzeit hinauszuzögern.