Neue Version: Content_Dump (mit Pagination) V 0.5

Hilfe zu Modulen und Tags
nhaack

Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nhaack »

Hallo zusammen,

ich habe soeben eine weitere Version meines Plug-Ins veröffentlicht. Ich habe hierzu bereits einen umfassenden Beitrag im englisch-sprachigen Forum geschrieben hier nochmal auf deutsch das Wesentliche :)

Download hier: http://dev.cmsmadesimple.org/frs/?group_id=564&release_id=1544
Neue Version hier: http://dev.cmsmadesimple.org/project/files/564

Jetzt ist es auch möglich mit content_dump durch Ergebnisse zu blättern. Hierzu greifen wir mit Smarty einen bestimmten URL Parameter für die zu zeigende Seite ab und bauen diesen in den plug-in Aufruf ein.

===========
VORBEREITUNG
===========

Code: Select all


{assign var=page_call value=$smarty.get.show_page}
{if $page_call == ""}{assign var=page_call value=1}{/if}

Hiermit weisen wir den Wert des Parameters "show_page" der Variable $page_call zu. Sollte dieser Parameter leer sein, soll Seite 1 angezeigt werden.

In den Plug-In Aufruf setzen wir nun den parameter "page" mit unserer Variablen als Wert.

Code: Select all


{assign var=page_call value=$smarty.get.show_page}
{if $page_call == ""}{assign var=page_call value=1}{/if}

{content_dump block_name="summary" start_id=$content_id 
       first_sort="created" first_sort_order="down" limit_count=5 page=$page_call}

===========
OPTION 1
===========

Jetzt können wir auch auf eine neue Smarty Klasse mit den Elementen &pager_info->current und $pager_info->max zugreifen.

Code: Select all

{if $page_call > 1 }
<a href="blog.htm?show_page={$pager_info->current-1}">newer articles</a>
{/if}

{if $pager_info->max > $page_call}
<a href="blog.htm?show_page={$pager_info->current+1}">older articles</a>
{/if}
Hiermit erzeugen wir auf allen Seiten einen weiter und einen zurück Link. Die If-Statements nutzen wir um die Links auszublenden wenn wir uns auf einer Randseite (1 oder max) befinden.

===========
OPTION 2
===========

Wir können mit der Max Anzahl an Seiten natürlich eine Schleife bauen um eine Liste der Seiten zu erzeugen:

Code: Select all


Pages: 
{section name="i" start=1 loop=$pager_info->max+1 step=1}
  <a href="blog.htm?show_page={$smarty.section.i.index}">{$smarty.section.i.index}</a> 
{/section}

===========
ALLES ZUSAMMEN
===========


Alles zusammen sieht dann z.B. so aus:

Code: Select all

{assign var=page_call value=$smarty.get.show_page}
{if $page_call == ""}{assign var=page_call value=1}{/if}

{content_dump block_name="summary" start_id=$content_id 
       first_sort="created" first_sort_order="down" limit_count=5 page=$page_call}

Page: 
{section name="i" start=1 loop=$pager_info->max+1 step=1}
  <a href="blog.htm?show_page={$smarty.section.i.index}" rel="nofollow">{$smarty.section.i.index}</a> 
{/section}

===========
ZUSAMMEN MIT CONTENT
===========

Wenn wir jetzt noch den Content des Plug-In Ergebnisses mit ausgeben, sieht das ganze so aus:

Code: Select all

{assign var=page_call value=$smarty.get.show_page}
{if $page_call == ""}{assign var=page_call value=1}{/if}

{content_dump block_name="summary" start_id=$content_id 
       first_sort="created" first_sort_order="down" limit_count=5 page=$page_call}

<p>Page: 
{section name="i" start=1 loop=$pager_info->max+1 step=1}
  <a href="blog.htm?show_page={$smarty.section.i.index}">{$smarty.section.i.index}</a> 
{/section}</p>

{foreach from=$dump item=dump}
<a href="{$dump->content->alias}.htm">{$dump->content->title}</a>
<p>{$dump->content->data}</p>
{/foreach}


===========
INFORMATION
===========

Ja, das war jetzt ziemlich lang, aber ich glaube, jetzt solltest ihr wissen wie es geht ;). Version 0.5 ist abwärts-kompatibel, sollte jemand das Plug-in also schon benutzen, muss keine Template Logik umgebaut werden. Mit der aktuellen CMSMS Version läuft das Plug-in recht flüssig.

Da ich den Code sehr detailliert beschrieben habe und die in-CMSMS Hilfe recht umfangreich ist, ist der Tag schon über 40k groß, ohne wären es nur etwa 15-20k, also nicht erschrecken. Hat hier übrigens jemand Erfahrungswerte in Bezug auf Performance und Größe ungenutzte Textmenge in Plug-Ins?

Ich freue mich über Feedback, Kritik und Anmerkungen.

Beste Grüße
Nils
Last edited by nhaack on Thu Dec 04, 2008 1:05 am, edited 1 time in total.
nhaack

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nhaack »

Kleiner Nachtrag, habe nochmal den Code komplett aufgeräumt und noch an vielen Stellen optimiert. Da ich allerdings in der jetzt nachgelegten 0.6 Version auch die Möglichkeit geschaffen habe, eine beliebige Anzahl von weiteren content-props mit auszugeben, habe ich auch gleich die Datenstruktur ein wenig angepasst. Diese ändert sich jetzt auch nicht mehr (versprochen).

Nun ist aber Schluss mit der Funktionsauswucherung - bzw. jetzt kann der Tag alles was ich brauche so flexibel we ich es brauche  ;D . Die Datenstruktur sieht jetzt wie folgt aus:

Code: Select all

$dump = array of classes
n = integer

$dump [ n ] -> item = Counter for items in current list (integer)

$dump [ n ] -> content -> id
$dump [ n ] -> content -> alias
$dump [ n ] -> content -> title
$dump [ n ] -> content -> show
$dump [ n ] -> content -> active
$dump [ n ] -> content -> data

$dump [ n ] -> parents -> id
$dump [ n ] -> parents -> alias
$dump [ n ] -> parents -> title

$dump [ n ] -> created -> date
$dump [ n ] -> created -> by -> username
$dump [ n ] -> created -> by -> last_name
$dump [ n ] -> created -> by -> first_name
$dump [ n ] -> created -> by -> email

$dump [ n ] -> modified -> date
$dump [ n ] -> modified -> by -> username
$dump [ n ] -> modified -> by -> last_name
$dump [ n ] -> modified -> by -> first_name
$dump [ n ] -> modified -> by -> email

$dump [ n ] -> extension

And for each extension you have named, you will get an equally named class element below $dump [ n ] -> extensions

e.g.
$dump [ n ] -> extensions -> summary -> data
$dump [ n ] -> extensions -> summary -> length 
Sowie die Daten für den Pager:

Code: Select all

$pager_info -> current
$pager_info -> max
$pager_info -> size 
Wünsche viel Spaß

Beste Grüße
Nils
User avatar
Amendra
Forum Members
Forum Members
Posts: 21
Joined: Sat Nov 29, 2008 2:59 am

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by Amendra »

Hallo Nils :)

Erst mal lieben Dank für deine viele Mühe mit content_dump - gerade im aktuellen Projekt ist es genau das, was ich brauche. Bis auf eine "winzige" Ausnahme - darf ich das nutzen, um dir einen Erweiterungsvorschlag zu machen?

Das Szenario:
Etwa 20 Produktionen, die in drei Kategorien unterteilt sind. Alle Seiten werden mit dem Content-Typ erstellt und erhalten je ein Extra-Feld für die Einleitung und ein passendes Bild als Thumbnail. Das Ganze soll an zwei Stellen sichtbar werden - einmal auf einer generellen Seite für alle Produktionen und dann auf einer darunterliegenden Seite für je eine Kategorie. Momentan muß ich die Kategorieseiten ausschließen mit exclude="ListeDerKategorieseitenIDs".

Mein größtes Problem ist aber: Die Seiten der einzelnen Produktionen, deren Einleitungen ausgelesen werden sollen, enthalten selbst weitere Unterseiten. Und die werden, sofern sie ebenfalls eine Einleitung haben, mit angezeigt. Das möchte ich nicht.

Während die Kategorien erst einmal feststehen (und das Aussortieren nicht weiter tragisch ist), werden die Produktionen selber immer weiter anwachsen. An eine manuelle Aussortierung der nachfolgenden Unterseiten ist also nicht zu denken.

Was ich also bräuchte, wäre:
Die Einführung eines "start_level", evtl. ein "exclude_level" (und als Gegenstück ein "include_level") sowie die Begrenzung des auszulesenden Levels, also eine Art "limit_level" (z.B. "nicht tiefer als 1 Level ab start_level").

Das Ergebnis wäre dann ein start_level="3" (die Kategorieseite) exclude_level="3" (nicht die jeweilige Kategorieseite anzeigen) limit_level="1" (nur die Produktionsseite ohne deren Unterseiten)

Auf die Art würde es egal sein, wieviele Kategorien bzw. Produktionen der Kunde hat, und vor allem ist es egal, wieviel Unterseiten die jeweilige Produktion hat, denn sie wird gar nicht mit berücksichtigt.

Was meinst du? Wäre das zu machen? Vielleicht sogar in den nächsten - sagen wir - drei Monaten? Das wäre großartig *freu*

Übrigens funktioniert dein Tag auch mit dem Modul "Cataloger" - so lange dessen Feldnamen keine Sonderzeichen beinhalten. Will man mit der extensions-Methode mehrere Felder auf einmal auslesen, werden auch Felder, die Leerzeichen enthalten, nicht mehr dargestellt. In einem Aufruf mit content_name="Feld Leerzeichen" klappt das allerdings. Nur so als Rückmeldung ;)

Ich danke dir ganz herzlich für deine viele Mühe und freu mich auf dein Feedback!
Amendra
nhaack

Re: Neue Version: Content_Dump (mit Pagination) V 0.6.1

Post by nhaack »

Hi Amendra,

vielen dank für das gute ausführliche Feedback. Genau so etwas brauche ich um das Plug-in zu optimieren (bin ja nur Neben-Hobby-Programmierer). Die Idee mit den Leveln finde ich ganz interessant, eine solche Form der Begrenzung ist tatsächlich nicht vorhanden. Wenn ich so darüber nachdenke müsste eine Einbindung nicht all zu kompliziert sein.

Ich würde von relativen Pfad-Tiefen ausgehen. Was meinst du?

Bzgl. des Problems: Es gibt einen Workaround. Ich habe gerade ein sehr ähnliches Konstrukt in der Entwicklung. Ein Blog mit Unterkategorien. Da es sich für mich um konzeptionell unterschiedliche Arten von Content handelt (Index Beschreibung und Artikel Beschreibung) verwende ich auf der Index-Seite zum Beispiel den Block "Index_Summary" und der Artikel hat den Block "Article_Summary". Ich stelle also jedem Feld quasi einen Template prefix voran.

In deinem Fall stelle ich mit etwas wie folgt vor (korrekt?):

Code: Select all

Produktionen (Alle Produktionen, index)
+-Kategorie 1 (Produktionen Kategorie, index)
|  +Item (Produktion)
|  | + Sub-Item (produktion-Unterseite)
|  +Item 2
|
+-Kategorie 2
.
.
Deine Templates würden nach meiner Vorstellung so aussehen:
  • Index mit den Blöcken: kategorie_beschreibung, kategorie_bild, content
  • Produktion mit den Blöcken: produktion_beschreibung, produktion_bild, content
Eine Unterseite einer Produktion würde ich dann mit folgenden Blöcken versehen:
  • Produktion-Unterseite mit den Blöcken: produktion_sub_beschreibung, produktion_sub_bild, content
Der Parameter block_name kann zum filtern des Templates indirekt verwendet werden. Wenn wir als Blocknamen solche verwenden, die nur in bestimmten Templates vorkommmen, fallen alle anderen Seiten aus dem Raster. Ich nutze auch gerne für den eigentlichen Content spezifische Blöcke. Man wird allerdings nicht den standard-content-block (content_en) los (der ist auch immer im Admin Panel sichtbar). Zumindest habe ich dafür noch keinen Weg gefunden.

Diesen nutze ich selbst allerdings zum pflegen der RSS Inhalte der Seiten (auch mit Content-Dump erstellt) - und Frage diesen Block normalerweise nicht ab. Da ich im RSS alles drin haben will, kam es mir ganz gelegen ;)

Ich rufe das Plug-in also so auf (auf den Index Seiten)

Code: Select all


{content_dump start_id=$content block_name="produktion_beschreibung" extensions="produktion_bild"}

Unterseiten die nicht die beiden genannten Blöck besitzen tauchen nicht auf (s.b. Kategorien oder Produktion-Unterseiten)

Nutzt du eigentlich die Pagination für die Hauptseite? Wenn ich dich richtig verstehe, müsste diese ja die etwa 20 Produktionen abbilden.

Ach ja... bezüglich der Benennung der Content-Blöcke: wenn du dich entscheidest mit template-spezifischen Block-Namen zu arbeiten, solltest du dir deine Block-Namen vor der Initialbefüllung gut überlegen... ein Ändern im nachinein nervt einfach nur ;) - DB anpassen oder händisch umkopieren, Templates anpassen etc.

Ich hoffe ich konnte dir bis zum nächsten Entwicklungsschritt eine Lösung anbieten. Ein Update kommt bestimmt... und auch bestimmt in den nächsten 3 Monaten (ich tipp eher auf 1,5 bis 2).

Lass mich wissen ob es so geklappt hat...

edit:

Es klappt wahrscheinlich auch wenn nur der Block der im Parameter block_name genannt wird ein template-spezifischer Block ist (z.b. produktion_summary) - und per Parameter extensions durchaus gemeinsame Blocknamen verwendet werden können ohne eine Vermischung zu haben. Das lässt sich wahrscheinlich schneller als die Idee mit den Blocknamen ausprobieren.

Beste Grüße
Nils
Last edited by nhaack on Thu Dec 04, 2008 1:04 am, edited 1 time in total.
User avatar
Amendra
Forum Members
Forum Members
Posts: 21
Joined: Sat Nov 29, 2008 2:59 am

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by Amendra »

Hallo Nils,
vielen Dank für deine rasche und ausführliche Antwort - das nenne ich Support! *Daumen hoch*
Die Aufgabe, vor der ich stehe, hast du genau erkannt :)

Zu deinem Übergangsvorschlag: Genau so hatte ich es auch schon selbst angedacht - Extrafelder anzulegen (werden sowieso gebraucht)  und nur die Felder abzufragen, die ich für die Zusammenfassungsseite(n) wirklich brauche und den Rest außen vor zu lassen. So ist es jetzt schon machbar, keine Frage ;) Bei deinem Beispiel habe ich auch gleich gelernt, daß man die Abfrage von content_name und extensions kombinieren kann. Das wußte ich bis dahin noch nicht. Prima, sehr nützlich!

Ich dachte mir nur, daß es langfristig interessanter wäre, mit Leveln zu arbeiten, weil der User dann unabhängig ist von seinen Template-Feldern. So kann er seine Felder für viele verschiedene Zwecke nutzen, ohne jedesmal für diesen Zweck ein neues Template zu bauen.

Ich hab jetzt nicht so intensiv die Ahnung von MySQL, aber ich könnte mir vorstellen, daß ein Script deutlich schneller läuft, die Datenbank-Last deutlich geringer ist, je spezifischer die Anfrage ist. Aber vielleicht macht das in der Praxis nicht so den Unterschied :D

Zu deiner Frage, ob relativ oder absolut, was die Levels angeht: Ich denke, in Verbindung mit start_level ist ein relativ sehr nützlich. So muß man sich keine Gedanken machen, auf welcher Ebene ganz konkret der gewünschte Eintrag steht. Das hieße an meinem Beispiel: Starte bei Level 3, nimm nur Level 4 und ignoriere alle nachfolgenden Levels / Unterseiten.

Die Idee mit dem Präfix ließe sich auch noch zu einem anderen Zweck nutzen: Man könnte bestimmte Seiten, die ein Präfix haben, ausgrenzen. Zum Beispiel dann, wenn man das CustomContent mit dem Modul FrontEndUser nutzen möchte. Da wird einem ja schon mal geraten, diese privaten Seiten mit einem Präfix auszustatten und das Menu dann anzuweisen, Seiten mit diesen Präfixes bei der Erstellung des Menus auszuklammern. Das wäre mit Zusammenhang mit ContentDump ebenso nützlich. Nur eine weitere Idee ;)

Die Paginierung habe ich bislang noch nicht ausprobiert. Noch besteht dazu im aktuellen Projekt keine Notwendigkeit, aber wenn du dazu Feedback brauchst, dann bastel ich da was rein und sag dir Bescheid. Brauchst du nur anzufordern ;)

Zwei Ideen habe ich noch generell:
Wie wäre es mit der Möglichkeit, einen Trenner vorzugeben, mit dem der Inhalt des Feldes unterteilt und nur der erste oder letzte Teil angezeigt werden kann? Wie eine Von-Hand-Paginierung des jeweiligen Eintrags? So könnte man innerhalb des Standard-Content-Feldes bestimmen, wieviel Inhalt dargestellt wird. In der derzeitigen Fassung ist ja noch eine Trennung zwischen Teaser und Langtext über zwei verschiedene Template-Felder vorzunehmen. Du könntest einen Standardtrenner vorgeben und diesen als Parameter mit übergeben lassen. Alternativ/ergänzend das truncate, wie ich in einem anderen Beitrag schon mal gelesen habe.

Und die letzte Idee (für heute *hihi*) wäre:
Momentan benutzt du ja bis zu zwei Sortierungskriterien, anzugeben sind dabei die Standard-Felder des Systems, nicht aber die (selbstdefinierten) Content-Blöcke. Klasse wäre folgendes: Man kann ein oder mehrere Felder definieren, deren Inhalte bei einer Sortierung bzw. Ausgrenzung von Inhalten berücksichtigt würden.

Nutzbar für ein Szenario wie dieses: Ein Story-Archiv, in dem in Extrafeldern der Name oder die Namen des Story-Autors / der Autoren gefiltert werden (nicht der Autor des Beitrages!), vielleicht auch noch die Gegend(en), in der die Story spielt. Einzufüllen in selbstdefinierte Textfelder, auszulesen, einzugrenzen und anzuzeigen über content_dump.

Also in diesem Fall: Zeige alle Stories, die der Autor X geschrieben hat, wobei es egal, ist, wieviele Autoren in dem Feld stehen, geschrieben im Jahre Y, die in der Gegend Z spielen. Ein Beispiel, wie dieses mit MODx gelöst wurde, findest du auf meiner Homepage im Story-Archiv - da gibt es einen Pool an Stories, unterteilt in Kategorien und auf separaten Seiten gefiltert nach verschiedenen Kriterien (Autor/Serie/Beteiligter Charakter/Schauplatz).

Realisiert habe ich das mit Templatevariablen (wie unseren content_blocks) und dann mit dem MODx-Modul Ditto gefiltert. Du kommst mit deinem famosen content_dump diesem Modul schon sehr nahe :) Vielleicht regt dich die Dokumentation zu diesem Modul ja zu neuen Funktionen für content_dump an? Hier ist der Link dazu, falls du neugierig bist: http://ditto.modxcms.com/

So, jetzt bin ich aber mal still :D Das ist alles nur Ideen, Nils, keine Eile, sie umzusetzen - lediglich das Level-Design würde mich entzücken. Und natürlich gibt es dazu Feedback, wenn es fertig ist. 1,5 bis 2 Monate Fertigstellungszeit wären toll, keine Frage!

Liebe Grüsse
Amendra
nhaack

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nhaack »

Hallo Amendra,

grundsätzlich lassen sich eigentliche alle Parameter beliebig kombinieren, somit kann ein Plug-In-Aufruf eine Menge Abfrage Möglichkeiten abdecken. Dein Gedankenansatz die Abfrage weitestgehend über mysql zu lösen entspricht der Grundphiliosophie von content_dump. Der Großteil des Codes ist eigentlich das Aufbereiten einer passenden MySQL-Abfrage.

Sofern allerdings User-Daten oder Parent-Informationen angefragt werden, wird dies aktuell über einzelne Queries gelöst. Im komplexesten Fall werden also drei MySQL Abfrage gestartet und die Ergebnisse in Schleifen gegeneinander abgeglichen (Zuweisen der Info zum Dump-Item).

Im Vergleich zu früheren Versionen (die weniger über mysql gelöst haben) habe ich doch einen eindeutigen Geschwindigkeitsvorteil erkennen können. Es müssen halt auch nur die notwendigen Daten prozessiert werden. Zudem habe ich festgestellt, das das plug-in ab den Core 1.4.x Versionen wesentlich zügiger läuft. Mittlerweile ist das Plug-in recht flott... ich denke, da lassen sich aber noch 10-15% rausholen. Mal sehen was mit 1.5.x geht.

Die Idee eines Prefix-Handling auf Alias-basis zu ermöglichen und ein analoges Verhalten zu CustomContent einzuführen gefällt mir.

Ich denke ich werde in der nächsten Version die Parameter level_start und level_depth sowie prefix_exclude und prefix_limit (quasi invertiertes prefix_exclude) einführen.

Gleiches könnte man dann auch auf Block-Ebene realisieren. Das wäre dann aber etwas für die übernächste Version ;)

Wenn du Lust und Zeit hast, würde ich mich über ein Testen der Paginierung freuen. Ich kann gar nicht alle Fälle abtesten auf die Leute kommen können...  ;)

Zu deinen Ideen:

Der Paginierungs-Ansatz ist interessant. Wobei ein Trenner bedingt, das ein Redakteur quasi eine "technische Anweisung" geben müsste und im eigentlichen Content auch eine Form von Code vorkommt. Zudem wäre dies kein automatisiertes Handling, welches ich weitestgehend zu wahren versuche. Das Plug-in müsste auch jeden erfassten Content parsen. Das kostet Performance, wenn viele Seiten Bestandteil der Abfrage sind. Zumindest fällt mir spontan da keine "schnelle" Lösung ein.

Wenn du Seiten direkt selbst paginieren möchtest, da habe ich mal über ein plug-in gelesen, dass dies dediziert macht (weiß nur nicht mehr wie es hieß oder ob es nur ein forum post war). Ich würde da ggf. sonst auf das truncate mit smarty setzen. Man müsste mit Smarty bestimmt auch den An Denn mit content_dump erstelle ich ja "Sammlungen", hier zeige ich ja im besten Fall nur eine Seite.

Wenn man jetzt einen einzelnen Artikel per AJAX laden würde und dann jeweils direkt auf der Startseite blättern könnte, dann sehe ich da schon eher Sinn drinne. Aber in diesem Fall würde ich content_dump nur zum ID sammeln verwenden, da der Rest ja im AJAX Content abläuft. Vielleicht kannst du hier nochmal ein Fallbeispiel liefern - weil im Moment check ich den Sinn noch nicht so ganz. Oder möchtest du content_dump explizit zur Paginierung einzelner Seiten verwenden?

Den zweiten Tipp habe ich teilweise bereits auf der Uhr für die nächste Version (auf/ab natural-sorting der Ergebnisse nach Block-Inhalt). Wenn ich dich richtig verstehe, schwebt dir allerdings eher etwas in der Art einer Such/Match-Funktion vor. Also ich müsste die Felder parsen und gucken ob ein sub-string vorhanden ist. Ich könnte mir vorstellen, dass das vielleicht sogar mit 'ner Query möglich ist, aber im Moment weiß ich noch nicht genau wie. Cool wär's allerdings.

Bei kleineren Felder ist das glaube ich noch ok, doch wenn jemand dies auf größere Content-Blöck bei größeren Sammlungen anwendet, könnte es schnell ziemlich langsam werden (dies kann natürlich mit gutem Caching eingedämmt werden).

Du könntest hier allerdings vorerst mit Smarty und regex weiterkommen. Da müsste ich jetzt aber auch erstmal das Smarty Handbuch konsultieren.

Pseudo Code:

Code: Select all

{content_dump}

    {foreach...}

         {if regex "AUTORNAME"  in $dump->extensions->author_names->data == true}

             Eintrag zeigen

         {/if}

     {/foreach}
Du lädst aber "alle" Einträge und zeigst aus diesen dann die gewünschten Einträge an (allerdings erst nachdem die Datenabgefragt wurden und für Smarty bereit stehen). Wenn die Sammlung nicht all zu groß ist, dürfte das die Site aber nicht über Gebühr verlangsamen. Hier könnten vielleicht irgendwann bei großen Sammlungen mit großen Blöcken Speicher-Probleme auftauchen, da dann ja sehr viel Inhalt aus der Datenbank geladen wird.

Schöne Ideen von dir. Sehr schönes Feedback. Also wenn du ein wenig mit der Paginierung spielen könntest wäre das super, hier wäre ein wenig weiteres Testing sehr hilfreich.

Ich hatte schon keine wirklichen Ideen mehr, also Danke für den Input ;D. Danke übrigens auch für den interessanten Link.

Ich denke level_start, level_depth und eine primitive Block-Sortierung sind auf jeden Fall Bestandteil von Version 0.7. Prefixe mit Glück auch noch. Der Rest (pauschale Block-Inkludierung sowie komplexe Block-Inhalt Sortierung) kommt dann wohl eher in Version 0.8.

Beste Grüße
Nils
User avatar
Amendra
Forum Members
Forum Members
Posts: 21
Joined: Sat Nov 29, 2008 2:59 am

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by Amendra »

Hallo Nils!

Wiederum danke für deine ausführliche Antwort :) - es freut mich, daß dir das Feedback etwas gebracht hat.

Ich bin jetzt nicht so der MySQL-Crack, aber ich kenne zur Abfrage von "ungefähren" Suchergebnissen den Befehl SELECT ... WHERE feldname LIKE "%Suchbegriff%" Auf die Art findet er auf jeden Fall alle Einträge, die die gewünschte Zeichenkette an irgendeiner Stelle im Content-Block enthalten, auch dann, wenn sie Bestandteil größerer Zeichenketten sind.

Die MySQL-Hilfe enhält auch einen interessanten Codeschnipsel (in den Kommentaren), falls man mehrere Suchbegriffe in einer Abfrage bündeln will: http://dev.mysql.com/doc/refman/5.0/en/ ... tions.html
Vielleicht hilft dir das weiter?

Die Paginierung eines einzelnen Beitrags mit einzufügen (etwa durch die Verwendung eines manuell eingefügten Trenners a la "" im Seitentext) wäre insofern interessant, als daß du ja auch die Ansteuerung eines einzelnen Eintrags anbietest und dort u.U. das andere Paginierungsscript nicht mehr greift. Da habe ich aber ehrlich gesagt keine Ahnung von, weil ich diese Funktion noch nicht benutzt habe.

Bei meinem derzeitigen Szenario würde eine Paginierung nur in der Weise zum Tragen kommen, wie die Anzeige aller Einträge einer bestimmten Kategorie auf mehrere Seiten aufgeteilt würden. Ich werde dir davon berichten, wenn ich genug Daten zusammen habe, die ich damit testen kann. Dann melde ich mich wieder ;)

Ansonsten freu ich mich natürlich sehr darüber, daß meine Anregungen in die neue Version Einzug finden :D
Noch einmal herzlichen Dank für deine Mühe und Einsatzfreude!

Liebe Grüsse
Amendra
nhaack

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nhaack »

Hallo Amendra,

das mit dem "LIKE" kannte ich noch gar nicht, bis jetzt wusste ich immer was ich suche :P Bin gespannt wie das so funktioniert. Die Kommentare waren jedenfalls sehr interessant.

Die reguläre content_dump Paginierung bietet lediglich eine Paginierung der Anzahl der Einträge an. Eine eigentliche "content Paginierung" gibt es so gesehen nicht. Je mehr ich aber darüber nachdenke, desto mehr Ideen fallen mir mit einer solchen Funktion ein. Ich denke mit einem Explode könnte man dies ganz gut lösen. Man erhält ein Array vom Content zurück, das an den Page Break Stellen jeweils einen neuen Eintrag besitzt.

Für Smarty wäre jetzt die Größe des Arrays (die Seitenanzahl) bekannt. Mit smarty könnte ich dann auch nur die bestimmte Seite ausgeben. Jetzt kann ich im Index z.B. Links auf die direkten Teilseiten setzen oder nur bestimmte Blöcke anzeigen (und ne Abkürzung vom Folgeblock anzeigen z.B. Der Content würde zwar jedes Mal komplett präsent sein, aber ich denke so hat der Anwender die größtmögliche Flexibilität.

Auf der eigentlichen Content-Seite müsste man dann alle Blöcke Variablen zuordnen, damit sie nicht im Frontend auftauchen. Dann den Content_dump plug-in setzen und mit Smarty auf die Angabe der Seite warten. Mit etwas zusätzlichem Smarty die Ausgabe steuern... Ohne Angabe alles, mit Angabe die gewählte Seite... oder so

Jetzt bräuchte ich nur noch eine gute Rewrite Rule damit das ganze auch noch richtig schick aussieht. Ich habe das mal für einen spezifischen Pfad für einen anderen eigenen Tag gebaut, schöne wäre natürlich eine allgemein gültige Regel, die System-weit greift. Beim URL Rewriting habe ich aber im besten Fall nur leichtes Basiswissen.

Beste Grüße
Nils
User avatar
Amendra
Forum Members
Forum Members
Posts: 21
Joined: Sat Nov 29, 2008 2:59 am

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by Amendra »

Hallo Nils,

mit .htaccess / mod_rewrite kenne ich mich auch nur rudimentär aus :)

Aber mein MODx-Paginierungsmodul (dort Snippet genannt), schreibt - ähnlich wie du es dir selbst schon gedacht hast - den Aufruf so: index.php?id=228&page=2

Mit mod_rewrite sieht das dann so aus: namederseite.html?page=2

Ich benutze dabei keine pretty_urls mit Pfadangaben, sondern lade alle Dateien von der Root aus.
Der entsprechende Abschnitt in der .htaccess sieht systemweit so aus:

Code: Select all

# The Friendly URLs part
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Soweit ich das lesen kann, übergibt er also die gesamte Anfrage an das System und kümmert sich gar nicht weiter um die  angefügten Parameter. Das macht das System dann selber und wertet gemäß den Modulen die Anfrage aus.

Ich habe dir mal das Pagination-Plugin von MODx angehängt, das ein weiterer User ausgebaut bzw. von Fehlern befreit hat, und das ich meinen Bedürfnissen angepaßt habe. Vielleicht inspiriert dich das ja, wie du das Ganze aufbauen kannst. Es arbeitet sicher ähnlich wie deine Idee, müßte also von Nutzen sein.

Viel Erfolg ;)
Amendra
Attachments

[The extension txt has been deactivated and can no longer be displayed.]

nhaack

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nhaack »

Hi Amandra,

da ich für ein eigenes Projekt das Plug-in mit Filter Funktion benötige habe ich mich mal mit dem Thema Suche/Filter auseinander gesetzt. Glücklicherweise habe ich jetzt erstmal richtig lange Urlaub, da ich die Funktion schnell benötigte, habe ich diese bereits in das Plug-in eingebaut (noch nicht released).

Allerdings basiert die Suche nicht auf LIKE sondern auf FULLTEXT, das bedingt, das die entspechenden Datenbank-Tabellen händisch modifiziert werden müssen (prefix_content und prefix_content_props) . Es ist eigentlich ein harmloser Eingriff, bei dem zusätzliche Indices angelegt werden. Ich werde dies mal als Feature Request posten.

Danach kann mit Boolschen Operatoren durch alle ausgewählten Felder ein Filtern vorgenommen werden. Das Plug-in hat einen neuen Parameter, der nun z.B. wie folgt genutzt werden kann filter="+word1 -word2". Ich habe die neue Funktion auf zwei back-ups kleiner Sites getestet und bis jetzt läuft alles ohne Probleme und stabil. Im Grunde wird für den Parameter ein Suchstring übergeben, der der Abfrage in mySQL entspricht.
    * + A leading plus sign indicates that this word must be present in every row returned.
    * - A leading minus sign indicates that this word must not be present in any row returned.
    * By default (when neither plus nor minus is specified) the word is optional, but the rows that contain it will be rated higher. This mimics the behaviour of MATCH() ... AGAINST() without the IN BOOLEAN MODE modifier.
    * These two operators are used to change a word's contribution to the relevance value that is assigned to a row. The operator increases it.
    * ( ) Parentheses are used to group words into sub expressions.
    * ~ A leading tilde acts as a negation operator, causing the word's contribution to the row relevance to be negative. It's useful for marking noise words. A row that contains such a word will be rated lower than others, but will not be excluded altogether, as it would be with the - operator.
    * * An asterisk is the truncation operator. Unlike the other operators, it should be appended to the word, not prepended.
    * " The phrase, that is enclosed in double quotes ", matches only rows that contain this phrase literally, as it was typed.
Hier der Artikel der mich drauf gebracht hat http://www.devarticles.com/c/a/MySQL/Getting-Started-With-MySQLs-Full-Text-Search-Capabilities/. Ist zwar auf English aber super beschrieben.

Bis zu einem 0.7 Release wird es aber noch ein paar Tage dauern.... da wartet ja noch mehr... dann muss dokumentiert werden (ich vergesse mittlerweile selbst manchmal wie welcher Parameter nun genau heißt  :P)

Das Paginierungs-Skript werde ich mir morgen mal in Ruhe anschauen. Danke für den Tipp.

Beste Grüße
Nils
nicmare
Power Poster
Power Poster
Posts: 1150
Joined: Sat Aug 25, 2007 9:55 am

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nicmare »

Hallo Nils,
ich hoffe das "Aufwärmen" des Threads lohnt sich und ich bin hier richtig!
Ich habe vor mit deinem und NaNs Modul (AdvancedContent) ein Art Bewertungssystem für Seiten zu erstellen. Dafür habe ich ein dropdown angelegt:

Code: Select all

{content block="Bewertung" assign="rating" block_type="dropdown" items="1|2|3|4|5|6|7|8|9"}
und möchte nun die Seiten danach sortieren aber laut deiner Dokumentation gehen nur
id, title, created, modified, owner, hierarchy (default), id_hierarchy, lasteditor, active, show
Das ist nicht so gut. Für mein weiteres Vorhaben müsste ich nun wissen ob es grundsätzlich möglich ist, diese Funktion einzubauen. Es ist (noch) nicht dringend. Eine Aussagen ob das nun möglich wäre, würde vorerst weiter. Dann kann ich schon mal den Rest weiterentwickeln!
grüße
nhaack

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nhaack »

Moin Nicmare,

Content_Dump ist dafür gedacht, den Inhalt aus bestimmten Blöcken eines Teils des Content-Baums auszugeben.

Wenn du an den Seiten nun einen Block "Bewertung" hängen hast, kannst du per Content_Dump darauf zugreifen.

Also z.B.

Code: Select all


{content_dump block_name="Bewertung"}

gibt dir alle Seiten zurück, die den Content-Block "Bewertung" beinhalten, strukturiert nach Seiten (je nach Setting mit mehr oder weniger zusätzlichen Daten).

Nun kannst du den Inhalt auch nach bestimmten Kriterien filtern. Dafür gibt es verschiedene Parameter. Denkbar wäre in diesem Fall "filter". Dies auf einer Fulltext Suche in der Datenbank (Stringvergleich). Dafür solltest du noch einen zusätzlichen Index auf deinem Content-Table in der DB legen (steht im Wiki: http://wiki.cmsmadesimple.org/index.php ... ntent_dump). Wenn du ordentliches Hosting hast, funktioniert das auch bei relativ großen Sites noch relativ gut. Da sich die Anfrage eigentlich nicht ändert, kannst du diese sehr gut cachen.

Nun denn, wenn du also bestimmte Seiten mit Block "Bewertung" und dem Inhalt "2" ausgeben willst, würde der Aufruf in etwa so aussehen:

Code: Select all


{content_dump block_name="Bewertung" filter="2"} 

Mhh.. da fällt mir ein, das Fulltext nicht unter 3 Zeichen in der Standard Konfiguration von mysql gehen (oder ... vielleicht geht's trotzdem direkt so?). Könntest aber als Werte "rate_1|rate_2|rate_3|...." eintragen (somit kannst du immer noch halbwegs sortieren). Der Content_Dump Aufruf würde also:

Code: Select all


{content_dump block_name="Bewertung" filter="rate_2"} 

lauten.

In Kombination sähe das dann in etwa so aus:

Code: Select all

{content block="Bewertung" assign="rating" block_type="dropdown" items="rate_1|rate_2|rate_3"}

{content_dump block_name="Bewertung" filter=$rating} 

{foreach ... }
[data]
{/foreach}
Hoffe das reicht dir als Ansatz.

Grüße
Nils
nicmare
Power Poster
Power Poster
Posts: 1150
Joined: Sat Aug 25, 2007 9:55 am

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nicmare »

Hi Nils! Danke für deine schnelle Antwort!

das heißt ich soll den filter 10 mal aufrufen um ne Sortierung der Inhalte von 1(schlecht) bis 10 (sehr gut) darzustellen?
dachte da eher an first_sort="Bewertung" (oder ein anderer block) :)

edit: zur besseren vorstellung mein code

Code: Select all

{content_dump first_sort="title" first_sort_order="up" start_id=$content_id exclude=$content_id extensions="Bewertung"}
 {foreach from=$dump item=dump}
 <strong> {cms_selflink page=$dump->content->alias text=$dump->content->title}
</strong>{if $dump->extensions->Bewertung->data}, Bewertung: {$dump->extensions->Bewertung->data}{/if}
<br/>
 {/foreach}
Nun will ich die Einträge nicht nach Namen sondern nach der Bewertung absteigend (also beste zu erst) auflisten:

Titel1, Bewertung: 10
Titel4, Bewertung: 9
Titel2, Bewertung: 8
Titel9, Bewertung: 7

usw
Last edited by nicmare on Mon Sep 13, 2010 8:48 pm, edited 1 time in total.
nhaack

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nhaack »

Hi Nicmare...

ich glaub jetzt weiß ich was du meinst.

Du hast eine Anzahl von X Seiten unterhalb eines Artikels. Diese sind User generiert und haben jeweils einen befüllten Block "Bewertung" mit einem Wert zwischen 9 und 1. Diese möchtest du der Bewertung nach sortiert ausgeben?

Mhh... da muss ich einen Moment drüber nachdenken, da CD nicht direkt nach Content sortieren kann. CD fackelt das meiste über mysql ab, hier würde ich auch nicht ansetzen wollen. Mit usort() müsste man das relativ einfach lösen können. Dafür müsste ich das Plugin aber weiter entwickeln ... das müsste ich eigentlich eh mal.

Ha... da fällt mir doch dieser Post ein: http://forum.cmsmadesimple.org/index.ph ... #msg188540

Das dürfte dein Problem lösen.

edit: du musst also nur sicherstellen, dass alle Beiträge im Dump enthalten sind. Dann übergibst du das Array an ein UDT. Dieses sortiert die Daten dann.

edit2: um das klicken zu ersparen:

Code: Select all


function cmp_obj($a, $b){
        $al = strtolower($a->extensions->bewertung->data);
        $bl = strtolower($b->extensions->bewertung->data);
		
        if ($al == $bl) {
            return 0;
        }
		
        return ($al > $bl) ? +1 : -1;

}

$data = $params['data'];
usort($data , "cmp_obj");
$smarty->assign('sorted', $data);

Grüße
Nils
Last edited by nhaack on Mon Sep 13, 2010 9:01 pm, edited 1 time in total.
nicmare
Power Poster
Power Poster
Posts: 1150
Joined: Sat Aug 25, 2007 9:55 am

Re: Neue Version: Content_Dump (mit Pagination) V 0.5

Post by nicmare »

so ist es! habe das früher mit company directory gemacht aber da stoße ich regelmäßig an andere grenzen und nun will ich es mal mit advancedcontent+content_dump probieren.
Post Reply

Return to “Module und Tags”