Websites mit HT(C): Template-Logik (Perl/CGI)

[thread]786[/thread]

Websites mit HT(C): Template-Logik

MartinR

2006-07-21 12:20

User since
2004-06-17
305 Artikel
BenutzerIn
[default_avatar]

Hi,

leider ist meine Frage in
diesem Thread wohl untergegangen.

Daher hier nochmal. Wo bzw. wie speichert Ihr die *Logik* für die Templateanzeige?

Es reicht ja nicht aus tmpl-files über include in ein anderes einzubinden. Diese müssen ja auch noch befüllt werden. Wenn ich also z.B. <TMPL_INLCUDE neuigkeiten.htm> schreibe muss mein Script ja auch wissen, dass es nun auch die Neuigkeiten aus der DB auslesen soll, was es in anderen Fällen natürlich nicht braucht.

Bisher (HT) hatte ich dies ebenso in der DB gespeichert. Also so: Zum Navigationspunkt "Startseite" gehört das Template "start.htm". Dies stand in der DB-Tabelle "navigation". Nun hatte ich noch ein DB-Tabelle "module". In der stand, dass im Template "start.htm" u.a. das Modul "Neuigkeiten" includiert ist. Somit wusste das Script bescheid dass es die Neuigkeiten aus der DB holen soll. Dieses Vorgehen bedeutet aber, dass ich die Zuordnungsinfo Template zu Inhalt immer an zwei Stellen pflegen muss, Nämlich im tmpl-file und in der DB.

Zwischendurch hatte ich dann auch noch den parameter "query" des tmpl ausgelesen um zu erfahren welche includes vorkommen um auch wirklich nur die benötigten Inhalte aus der DB zu ermitteln.

Mit HTC löse ich das nun so:




D.h. dass die Befüllung eines includierten tmpl nun durch das tmpl-file gesteuert wird, welches dieses beinhaltet. Die Zuordnung welches tmpl includiert werden soll, und die Info dass auch die Inhalte für dieses tmpl benötigt werden brauche ich so nur noch einmal, nämlich im tmpl-file, festzulegen.

Oder habt Ihr andere Lösungsansätze?

2006-07-21 12:32

User since
2003-08-04
12208 Artikel
Admin1

deine frage ist nicht untergegangen. jeder thread mit eine neuen frage
wird an den anfang gestellt.
mir ging es so, dass ich deine frage nicht verstanden habe.
bzw. habe ich den ansatz nie nachvollziehen können, über das template
zu entscheiden, welche db-queries gemacht werden. *brrr*

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:

Wie frage ich & perlintro Wiki:

brian's Leitfaden für jedes Perl-Problem

renee

2006-07-21 12:43

User since
2003-08-04
14371 Artikel
ModeratorIn

Ich verwende meistens CPAN:

CGI::Application

Das Skript sieht dann so aus:

Code: (dl )

#!/usr/bin/perl

use strict;
use warnings;
use MyWebapp;

my $webapp = MyWebapp->new();
$webapp->run();

MyWebapp.pm:

Code: (dl )

package MyWebapp;

use base qw(CGI::Application::Plugin::HTCompiled CGI::Application);

sub setup{
    my ($self) = @_;
    $self->{template} = '/path/to/template.tmpl';
    $self->mode_param('rm');
    $self->start_mode('show_site');
    $self->run_modes(show_site      => \&_show_site,
                        AUTORUN        => \&_show_site,
                  login          => \&_admin_login,
           );
}# setup

sub _show_site{
   my ($self) = @_;
   my $tmpl = $self->load_tmpl($self->{template});
   $tmpl->param(body_tmpl => 'show_site.tmpl');

   # hole die Sachen für das Haupttempalte und das Seitenspezifische Template
   return $tmpl->output();
}

sub _admin_login{
   my ($self) = @_;
   my $tmpl = $self->load_tmpl($self->{template});
   $tmpl->param(body_tmpl => 'admin_login.tmpl');

   # hole die Sachen für das Haupttempalte und das Seitenspezifische Template
   return $tmpl->output();
}

1;

OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/

MartinR

2006-07-21 13:27

User since
2004-06-17
305 Artikel
BenutzerIn
[default_avatar]

@pq

Mein Ansatz hier war, dass der "Programmierer" die Funktionen bereitstellen soll egal wie die tmpl-files aussehen. Der "Designer" soll dann aber ohne hinzuziehen des Programmiers entscheiden können welche Inhalte er in den tmpl darstellen möchte. Wäre ja nun ein Unding, wenn das Skript immer alle möglichen Ausgaben erstellt, egal ob es dann tatsächlich im tmpl benötigt wird. Also muss es ja irgendwo eine Logik geben, die dem Skript sagt welche Inhalte im tmpl dargestellt werden sollen.

@ reneee

Du bist schuld, dass ich mich seit kurzem auch mit cgi-app beschäftige :)

Aber auch hier habe ich das Problem, dass der Designer nicht irgendwann spontan entscheiden kann in ein tmpl einfach mal einen Container einzusetzen der z.B. alle z.Zt. angemeldeten User anzeigt. Also bei Änderungen am tmpl muss er auch dem Programmierer sagen, dass bei diesem runmode nun auch der entsprechende Containerinhalt zu erzeugen ist.

renee

2006-07-21 14:40

User since
2003-08-04
14371 Artikel
ModeratorIn

Dann würde ich es so machen, dass ich dem Designer einen "Pool" an Ausgaben zusammenstelle. Und dann musst Du halt mit param() abfragen, was der Designer auch tatsächlich verwendet.

MartinR

2006-07-21 15:12

User since
2004-06-17
305 Artikel
BenutzerIn
[default_avatar]

Hi, Danke schon mal. Genau diesen Ansatz hatte ich mit HT auch schon verfolgt (s.o.). Aber mit HTC bin ich dann umgestiegen auf <TMPL_VAR NAME="OBJECT.fullname">

2006-07-21 15:26

User since
2003-08-04
12208 Artikel
Admin1

also ich möchte den designern nicht die entscheidung überlassen,
was für datenbankabfragen gemacht werden.
das kann böse ausgehen. solche abfragen können unterschiedlich
komplex sein.
wenn bei uns die designer entscheiden könnten, was sie alles für
daten im template haben und das ohne mitarbeit eines entwicklers
machen könnten, würde unsere webseite wohl nicht so performen
wie sie es tut. ganz klar, weil die designer nicht wissen können
und müssen, wie eine abfrage letztendlich implementiert ist.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:

Wie frage ich & perlintro Wiki:

brian's Leitfaden für jedes Perl-Problem

MartinR

2006-07-21 17:26

User since
2004-06-17
305 Artikel
BenutzerIn
[default_avatar]

[quote=pq,21.07.2006, 13:26]also ich möchte den designern nicht die entscheidung überlassen,
was für datenbankabfragen gemacht werden..[/quote]
Hi,

da hast Du mich aber falsch verstanden.

Natürlich darf der Designer keine SQL-Statements eingeben oder eigene SQL-strings ausführen lassen.

Ich meinte damit, dass der Designer entscheiden soll, ob auf der Seite z.B. eine Liste mit den Usern erscheinen soll. Dann schreibt er eben ins Template ein <TMPL_VAR USERLISTE>. Nur kommt diese Userliste aber aus der DB. Also muss der Programmierer ein script erstellen. dass dieser Liste (bei Bedarf) ausgibt.

Aber dieses Skript soll eben nur dann laufen wenn die Liste auch im Template benötigt wird. Ansonsten nicht.

2006-07-21 17:51

User since
2003-08-04
12208 Artikel
Admin1

ich habe dich nicht falsch verstanden.
selbstverständlich habe ich nicht geglaubt, dass du SQL in templates
hast. hast du ja auch in deinem beispiel nicht. das wäre ja auch wirklich
schlimm.

wie gesagt, ich möchte dem designer nicht überlassen, welche abfragen
ausgeführt werden. die können unterschiedlich komplex sein.
ja, ich weiß, dass der designer sie nicht selbst schreibt.
trotzdem möchte ich im skript die kontrolle darüber haben, was
ausgeführt wird.
ich sage nochmal: könnte man bei uns als designer bestimmen,
welche abfragen (nein, nochmal, nicht explizites sql) gemacht werden,
würde unsere seite nicht so performen wie sie es tut.
ein template, welches eine datenbankabfrage auslösen kann (mit auslösen
meine ich nicht ein explizites sql selbst schreiben), ist meiner
meinung nach kein gutes template. ich denke da auch an transaktionen.
natürlich kommt es immer darauf an, wieviel last du generell hast,
was für statements, wie komplex deine anwendung ist.

edit: es gibt genug leute, die anderer meinung sind. meine
philosophie von templates ist jedenfalls, dass es keine aktionen
auslösen soll.\n\n

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:

Wie frage ich & perlintro Wiki:

brian's Leitfaden für jedes Perl-Problem

MartinR

2006-07-24 15:14

User since
2004-06-17
305 Artikel
BenutzerIn
[default_avatar]

[quote=pq,21.07.2006, 15:51]... wie gesagt, ich möchte dem designer nicht überlassen, welche abfragen ausgeführt werden. ...[/quote]
Aber wie reagierst Du dann wenn der "Kunde" den Designer anruft und sagt er möchte noch eine kleine Tabelle mit den zur Zeit angebotenen Artikeln. Diese soll aber nur auf der Startseite, der Seite X und Seite Y erscheinen und wird nur für ca. 4 Wochen benötigt, kann aber sein, dass er kurzfristig vor Weihnachten das selbe nochmal haben will, dann aber auf Seite M und N.

Da finde ich doch renees Idee nicht schlecht einen Pool an möglichen Ausgaben programmieren zu lassen und dem Designer an die Hand zu geben. Dann kann er diese in die tmpl einbauen und auch wieder rausnehmen wann und wie er will. Eben durch einfaches einfügen des <TMPL_VAR ...>

View all threads created 2006-07-21 12:20.