Sections zufällig auswählen

[doc]

Hi,

Luisehahne hatte das für 2.8 eingeplant. Ein gewisser Jemand hat das aber noch nicht getestet. *hust*

Einen möglichen Ansatz gibt es hier, ein Ticket dafür hier. Einfach öfter mal die für Bugreports vorgesehenen Mittel nutzen 

Doc

[WebBird]

@doc: Es ist ja schon fertig, ich hab's zum Testen bekommen, ich hatte nur noch keine Lu... äh, Zeit.

@Stefek:

Neuer Text in der readme.txt:

STYLES
======

To style your Random Sections, two CSS classes are provided:

div.randomsection

    Each section is wrapped into a <div> of class "randomsection". To
    add a gray border to each section, for example, add this code to
    your frontend.css (of the template you are using):
    
    div.randomsection { border: 1px solid #ccc; }
    
    To add a margin on the bottom of each section, try this:
    
    div.randomsection { margin-bottom: 15px; }

div.randomsectionwr ap

    Wraps the complete RandomSection part. That is, if you include more
    than one section, the complete list of rendered sections is
    wrapped into a <div> of class "randomsectionwrap".
    
    You can use this to "float" the complete RandomSection block:
    
    div.randomsectionwrap { width: 100px; float: right; }
    

<!-- Kommentar --> gibt's nicht, wenn der Benutzer dann die view.htt nicht ändert, steht das in allen Seiten, wo das Snippet benutzt wird. Das gehört sich nicht.

[Stefek]

<!-- Kommentar --> gibt's nicht, wenn der Benutzer dann die view.htt nicht ändert, steht das in allen Seiten, wo das Snippet benutzt wird. Das gehört sich nicht.

Ja, wäre nicht gut.
Ich war mir aber fast sicher, dass phpLib eine eigene Masche für Kommentare hat - ähnlich wie die Smarty Engine das hat; also wenn man dazwischen was reinhaut, wird es nie ausgegeben und verhält sich wie eine Auskommetierung in

<?php
/* php */

Gibts nicht?

Gruß,
Stefek

[WebBird]

Weiß ich nicht. Ich finde aber auch, readme reicht.

[Stefek]

Ja, wäre aber trotzdem interessant zu wissen.

Falls jemand weiß (J/N), bitte hier posten.

Danke,
Gruß,
Stefek

[doc]

Gehn tuts, kann aber sein dass es auch eleganter geht.

Template (htt):

Code:

<!-- BEGIN comment_block -->
blubb blubb blubb ...
<!-- END comment_block -->

In der Datein die das Template verwendet dann:

Code:

$tpl->set_block('page', 'comment_block', 'comment_replace');
$tpl->set_block('comment_replace', '');

Die zwei Zeilen erzeugen einen Handle für den Template block und löscht anschliessend dessen Inhalt. Die Technik wird u.a. im Schritt B5 des Module Primers (Step 2c) beschrieben (delete blocks manually).

Doc

[Stefek]

Danke Christian.

Das ist eine gute Methode.

Ich kann mich erinnern (aber nicht garantieren), dass ich es irgendwo mal anders gesehen habe.

Es kann aber sein, dass es genau das gleiche war, nur dass dann ein <!-- interner kommentar --> auch noch zusätzlich in der HTML Art dazwischen gepackt wurde - etwa so:

Code:

<!-- BEGIN comment_block -->
<!-- interner kommentar -->
<!-- END comment_block -->

Was verwunderlich ist, ist dass diese gesamte Klasse (phpLIB) scheinbar nicht weiter entwickelt wird?
Ist die Popularität nicht so hoch, oder was?

Auf der einen Seite ist es sehr Nutzerfreundlich, auf der anderen Seite wären if/else Abfragen auch ganz nett.
Sonst findet sich der Coder nur zu oft in der Designerrolle wieder und umgekehrt 

Gruß,
Stefek

[doc]

Hi,

PHPLib war eine der ersten PHP Funktionsbibliothek en und wurde mit erscheinen von PHP3 entwickelt (was aber nicht heisst, dass der komplette Code noch auf PHP 3 basiert). Das Projekt selbst wurde 2006 eingestellt. Die Datei template.inc ist nur eine Datei aus dem phplib Packet.

Für template.inc gibt es einen PEAR "Clone" auf aktueller Code Basis mit gleicher Funktionalität, aber leicht anderen Funktionsaufrufen (PHPLib: $tpl->set_file(); PEAR: $tpl->setFile also camelCase). Diese Infos findet man wenn man den Links in der Einleitung des Modulleitfadens (Schritt 2c) folgt  .

Doc

[Stefek]

Für template.inc gibt es einen PEAR "Clone" auf aktueller Code Basis mit gleicher Funktionalität, aber leicht anderen Funktionsaufrufen (PHPLib: $tpl->set_file(); PEAR: $tpl->setFile also camelCase).

Macht es Sinn, es auf PEAR umzustellen?
Solange PEAR nicht im WB Core enthalten ist...

Und die andere Frage ist: ergäben sich dadurch Vorteile?
Oder anders gefragt: welche Nachteile können auftauchen dadurch, dass man diese PHP3 phpLib Klasse nutzt?

Ich finde diese phpLib Geschichte schon seit der Überarbeitung des Guestbook Moduls sehr Sinvoll.
Und anscheinend laufen auch die neuen Backend Themes damit.

Ich muss mich zwar mit PHP auseinander setzen, um HTML aus einigen View.php's rauszufischen, aber einmal gemacht, ist es eine gut investierte Zeit und bringt neue Erfahrungen mit sich.

Gibt es nicht überhaupt irgendwelche Komplikationen damit - wegen PHP3?
Und wäre es nicht möglich, eine eigene Klasse für WB zu schreiben? (Ich frage nur nach Möglichkeiten, soll bitte nicht als Aufforderung verstanden werden )

Gruß,
Stefek

[erpe]

Solange PEAR nicht im WB Core enthalten ist...

Pear steht doch als Modul zur Verfügung, ebenso wie SM2 (ist ja auch kein Core), also warum denn nicht.
Finde es für updates sowieso besser, wenn die Dinge im modules directory angesiedelt wären (auch jquery).
Dann kann das unabhängig vom core aktualisiert werden.

Gruss

erpe

Edit: wäre nur gut, wenn Pear im WB-Package mit ausgeliefert würde. Dann braucht man es nicht nachzuinstallieren.

[Luisehahne]

Wenn Pear fester Bestandteil von WB ist und genutzt werden soll, dann gehört es meiner Meinung nach in den include Ordner um eine saubere Trennung von Modulen zu erreichen.

Dietmar

[Stefek]

Edit: wäre nur gut, wenn Pear im WB-Package mit ausgeliefert würde. Dann braucht man es nicht nachzuinstallieren.

Ja, wäre fatal wenn nicht. Es sei denn, man ließe das olle (originale) phpLib drin, als Fallback.

Ansonsten ja, wieso nicht. Kann gerne nachrüstbar sein.

Nur wenn man das im Pack hat, kriegt man dann mit manchen Server Konfigurationen Probleme, da sie das was über FTP hochgeladen wurde, nicht über das Backend hochladen wollen.
// EDIT: Dann kann man das auch - wenn über FTP - in den include Ordner schieben. Ist sogar noch weniger verwirrung.
Es sei denn, da hat sich was geändert im 2.8.x

War da wegen PEAR nicht auch irgendwo ein Lizenzprobelm?


Gruß,
Stefek

EDIT// oh Dietmar war schneller.
Nun, bei diesen Diskussionen will ich keine Partei ergreifen, schlicht und einfach, weil es mir Wurscht ist.

[doc]

@Stefek:
Mal ne blöde Frage. Warum willst Du nun krampfhaft HTML_Template_PHPLI B verwenden statt der in WB enthaltenen /include/phplib/template.inc, zumal beide den gleichen Funktionsumfang haben??

Die "HTML_Template_PHPLI B" habe ich nur gepostet, da manche Ausschlag bekommen, wenn in der Kommentarzeilen der template.inc sowas wie: " * Session Management for PHP3" zu finden ist (was nicht heisst, dass template.inc auf PHP 3 basiert). Vorteil der "HTML_Template_PHPLI B" ist, dass diese noch gewartet wird und unter LGPL lizenziert ist und vollständig auf preg setzt (include.inc hat noch ein ereg Aufruf).

Ein Upgrade der "template.inc" auf PEAR wäre durch einfaches suchen & ersetzen der Methodennamen möglich. Solange es keinen wirklichen Grund gibt (z.B. Sicherheitsleck, wirkliche Geschwindigkeitsste igerungen ...) macht es für mich wenig Sinn auf HTML_Template_PHPLI B zu wechseln. Ist wohl auch frühestens ein Thema für WB 3.0, sprich wenn fest steht, in welchem Umfang der WB Kern überarbeitet werden soll, welche Techniken und Grundlagen dazu verwendet werden ...

Doc

P.S.: Ach ja, im Pear Modul von Aldus ist das PHPLib Template meines Wissens nach nicht enthalten

[WebBird]

Zur PHPLib: Ich persönlich finde das Template-Handling damit grauenhaft. Ich habe für ein anderes (noch nicht veröffentlichtes) WB-Modul Savant3 benutzt, was ich viel angenehmer finde. Auch das xFastTemplate ist deutlich angenehmer zu verwenden.

Im Grunde braucht man für PHP keine Template-Engine, weil PHP selber eine ist. Deshalb ist Savant3 auch eher eine Abstraktion als eine Template-Engine. Und das wiederum macht es so angenehm zu benutzen, weil man sich nicht eine "Template-Sprache" aneignen muß.

[mr-fan]

Auch das xFastTemplate ist deutlich angenehmer zu verwenden.

ist eine klasse sache - bin in zur zeit wenn ich noch luft hab sehr viel damit am "spielen" - damit kann man gewaltige sachen machen - gibt halt bloß keine doku dazu...sind ja auch schon ihre viele funktionen dabei - die ich eh ned alle check 

aber für die Frontendtemplates geht das echt genial einfach anzuwenden!

werde wenn der neue portable fertig ist - mal ein XFastTemplate2 - Framework Template rausbringen!
(mit YUI GRIDS CSS Framework (verschiedene Basisgrüste=verschiedene .tmpl files aber ein Template) - Menüunterstützung durch EM - und Beispiel Templatefunktionen wie einbindung anynews/Showmenu2/weitere snippets...was ich halt noch so "rausfinde" und mir von aldus erklären lasse ->danke für deine gedult wenn ich da doofe fragen stelle aldus!! )

in wie weit das für das Backend anwendbar ist weis ich nicht...

mfg martin

[Stefek]

@Stefek:
Mal ne blöde Frage. Warum willst Du nun krampfhaft HTML_Template_PHPLI B verwenden statt der in WB enthaltenen /include/phplib/template.inc, zumal beide den gleichen Funktionsumfang haben??

Die Frage ist nur dahingehend "blöd", weil ich es nicht krampfhaft wil. Schon vergessen, Du kamst mit der PEAR Variante hoch. 

Die "HTML_Template_PHPLI B" habe ich nur gepostet, da manche Ausschlag bekommen, wenn in der Kommentarzeilen der template.inc sowas wie: " * Session Management for PHP3" zu finden ist (was nicht heisst, dass template.inc auf PHP 3 basiert).

Ja, das verstehe ich.
Aber wenn es sonst keine Schwierigkeiten gibt, dann ist es ja gut.

Solange es keinen wirklichen Grund gibt (z.B. Sicherheitsleck, wirkliche Geschwindigkeitsste igerungen ...) macht es für mich wenig Sinn auf HTML_Template_PHPLI B zu wechseln. Ist wohl auch frühestens ein Thema für WB 3.0, sprich wenn fest steht, in welchem Umfang der WB Kern überarbeitet werden soll, welche Techniken und Grundlagen dazu verwendet werden ...

Mein Interesse dafür liegt einfach darin, weil ich mir nach und nach einige Module auf PHP Lib umstelle.
Eigentlich vor allem den Teil, der sich mit dem Output im Frontend beschäftigt.
Ein gutes Beispiel ist Bakery. Es ist unzumutbar, jedes mal (bei jeder neuen Version) in die PHP Files gehen zu müßen, um das Template anzupassen. Außerdem hat es den Vorteil, dass man die Templates leichter recyclen kann (z.B. ähnliche Templatestruktur auf einem anderen Projekt).

Es gibt noch viele Module, die wirklich gut sind, die aber das HTML innerhalb von PHP "behandeln". Das ist schade. Beispiele sind:
- Topics (zumindest das "Leave Comment" Teil würde sinvoll sein, es auf phpLIB umzuschreiben)
- Bakery (schon erwähnt)
- viele Snippets

@Savant/Savant3

Im Grunde braucht man für PHP keine Template-Engine, weil PHP selber eine ist. Deshalb ist Savant3 auch eher eine Abstraktion als eine Template-Engine. Und das wiederum macht es so angenehm zu benutzen, weil man sich nicht eine "Template-Sprache" aneignen muß.

Der große Vorteil mag für Programmierer stimmen, ja.
Was ich bei den phpLIB Templates gut finde, ist die Tatsache, dass ein Designer damit auf Anhieb klar kommt.
Und die Templates sind fast identisch mit den Templates in den Loops, womit eine gewiße Einheitlichkeit zustande kommt.

Aber sind die von Savant generierten Templates besser, als bloßes PHP (so muss der Designer nicht zwischen dem PHP fummeln).
http://www.number0.info/public/doc/savant/savant_api.html


Außerdem gibt es noch Smarty, eines der Module verwendet es (ich glaube Multilang Catalogue).

phpLib scheint mir der Quasi Standard zu sein.
Die meisten Module, die ein Template beinhalten (also wo das Template nicht inline im PHP ist) laufen damit, und wie schon gesagt, die Ähnlichkeit mit den Loops.

Man muss "auch" an die Leute denken, die mit WB und den Modulen arbeiten. Und das sind in der Regel Webdesigner.

@xFastTemplate
Ja, keine Doku. Und wenige Beispiele, um sich das in Action anzuschauen.
Martin, cool. Mach mal fertig so ein Beispiel Template. Das macht Sinn.

Im Grunde sieht es auch für den Designer gut verträglich aus.
http://www.websitebakers.com/pages/modules/various/x_fasttemplate2.php?searchresult=1&sstring=xfasttemplate

Da ich aber noch nicht damit gearbeitet habe, kann ich auch nicht viel dazu sagen. Sieht aber gut aus, um WB Templates damit zu erstellen (recyclebar).



Gruß,
Stefek

[Stefek]

Ach ja,

wenn ich mir das richtig überlege, ist es ja auch eine Klasse für sich (xFastTemplate).
Könnte also sogar mal ein Ersatz werden? Das ist aber eher Politik, denke ich mal.
Und PHP5 als Vorraussetzung... na ja, zur Zeit von WB3 dürfte das aber kein Thema mehr sein.

Beherrscht xFastTemplate eigentlich eine if Abfrage in den Templates?
Ähnlich wie bei Smyrty?
Wenn auch nur rudimentär?

Gruß,
Stefek

[mr-fan]

Blocks? Oh Graus ...   

danke * aldus *
hab das beispiel sogar verstanden.. ...werden sich dann anwendungen aus der praxis geben.

in der index.php kann ich da auf alle WB variablen zugreifen sprich auch z.b. checken ob auf einer seite ein block inhalte hat oder nicht? (z.B. wenn block "Bildergalerie" inhalt hat lade galerie.tmpl...?)

die möglichkeiten sind schon enorm! ist ja schon schwierig sich zu entscheiden "wie" man was einbaut.....

mfg "lehrling"

martin

theoretisch schon ... allerdings arbeite ich (noch) nicht mit "Blöcken" im Sinne von WB ... das ist noch zu hoch für mich

Gruß
Aldus

... aber das Monster hat 1200 + x code -> und Funktionen, die bei WB keinen (noch nicht) interressieren -> sequencer zum Beispiel ... oder Blocks (two or more templates in one file)...aldus

wie gesagt - wenn das 2.8er portable projekt steht werd ich da mal was für die öffentlichkeitsarbeit tun - aldus module sind meineserachtens viel zu wenig beachtet weil man sich halt erst durch den code lesen muss und nichts dow-freundlich "aufbereitet" ist - tu mich selber noch mit ',;(){}" schwer mit den kleinen dingen die einem den code versauen können halt...

auf alle fälle wär das echt eine ernstzunehmende alternative template-engine....und als WB-eigene-lösung könnte man das auch wesentlich einfacher und WB-konformer gestalten als mit einem aufgeblähten sm4rty oder anderem zeug das eher für aufgeblähte CMS passt!

 

so viel vorweg man kann inhalte also die {{placeholders}} die man in der index.php setzt folgendermaßen bestücken:
-reines html
-snippetcalls z.b. show_menu2(); oder use_fancy_box();
-php
-arrays & variablen die man vorher setzt z.b. $donatebutton oder $specialform
-get by template funktion in verbindung mit einem array in dem man nur die {{placeholders}} für das "untertemplate" gestalten kann also z.B. aufruf für Anynews usw.
-get by sequence (hab ich noch keine erfahrungen)
-get by blocks (")

=>gibt bestimmt noch mehr optionen im prinzip ist alles html in den .tmpl dateien und die {{}} packen alles genau da hin wo man es braucht!

=> abfragen wie auch immer sind kein problem also if else switch

ich brauch aber noch viel mehr übung damit!

mfg martin

[WebBird]

Hm, sollte man das nicht besser in einem eigenen Thread diskutieren? In diesem würde das sicher keiner vermuten.

[Stefek]

Bianca, Du hast Recht.
Ich mache einen Hinweis für einen Admin, ob er den Thread aufsplittet, von dem Post an, wo es um die HTT Files und andere Template-Engines geht.

@Martin.
Ich bin auch kein Befürworter von Smarty innerhalb von WB. Man kann es machen. Aber ich bin an einer zentralen Lösung interessiert, wie eben phpLib.
Doc hat meine Frage gut beantwortet, sodass klar ist, dass man phpLib noch lange benutzen kann.

Gruß,
Stefek

[mr-fan]

also die wbrandomsection_2.0 geht bei mir nicht er merkert wegen ungültigem .zip file....keine ahnung was nicht passt?

hab entpackt und neugezippt - geht immer noch nicht...kann das jemand bestätigen

mfg martin (mit 2.8 auf XAMP)

[doc]

Hi Martin,

dem Modul fehlt eine index.php im Modulverzeichnis (wird seit WB 2.8 geprüft). Kopiere einfach eine index.php Datei aus einem anderen Modul in das Modulverzeichnis (oder erstelle zur Not eine leere index.php Datei), zippe das Verzeichnis dann nochmals und der Fehler sollte verschwinden. Siehe auch Beiträge von Ruebenwurzel und WebBird hier im Forum.

Eventuell die hier angehängte Datei durch eine bereinigte Datei (mit index.php) ersetzen.

Doc

[WebBird]

Ich behebe das.

[Stefek]

Bianca, Du hast Recht.
Ich mache einen Hinweis für einen Admin, ob er den Thread aufsplittet, von dem Post an, wo es um die HTT Files und andere Template-Engines geht.

So, eine Überraschung in der Template Engine Szene:
http://www.websitebaker2.org/forum/index.php/topic,15260.0.html

Danke Bianca.

Gruß,
Stefek