Hallo zusammen,
ich habe mir mal das SimpleTagging Modul angeguckt. Nach kurzer Modifikation der MaximumCMSVersion ließ es sich problemlos installieren (wobei ich mit dem Modul noch nicht richtig experimentiert habe). Jedenfalls wird die Tag-Verwaltung über Content-Blöcke realisiert - womit das tagging Content-Seiten basiert ist. Zudem scheint das Tagging nur auf backend-Ebene zu funktionieren.
Gerne würde ich aber die Besucher (keine Registrierung) die Inhalte taggen lassen (idealerweise auch noch mit Blacklist Unterstützung). Kennt jemand eine gute Lösung bei der ich die Zuordnung über eigene IDs steuern kann und bei der Besucher Einträge taggen können (öffentlich mit Spam-Schutz)? Sofern keine CMSMS Lösung besteht, kennt jemand ein empfehlenswertes einbindbares Stand-Alone Tool? Ajax oder nicht ist eigentlich Wurst, nur keine Services, möchte die Daten selbst hosten.
Beste Grüße
Nils
Öffentliche Besucher taggen Beiträge - Lösungsansätze?
Re: Öffentliche Besucher taggen Beiträge - Lösungsansätze?
Sopp... wollte nicht warte 
Ich habe eine Basis-Version eines Tagging Plug-ins geschrieben.
öffentliche User können ein an beliebiger Stelle auftauchendes Formular mit Komma separierten Tags ausfüllen. Nach dem Absenden werden die Tags in einer Tabelle gespeichert. Sofern ein Tag für eine Kombination bereits besteht wird hierfür ein Zähler erhöht.
Beim Aufruf müssen eine item-id, group-id und die tag-url übergeben werden. Diese drei ergeben die Zuordnung eines Tags. Somit kann ein Tag auch für mehrere Elemente gelten, über die Gruppierung und item-id lässt sich das Tagging quasi universal für jede Form von Content oder Modul anwenden. Tag-url muss nicht zwingend eine URL sein sondern kann jeglichen Text enthalten. Über den Parameter "counter" kann das Plugin zudem als counter mit mehreren simultanen ident-elementen genutzt werden.
Das ganze lässt sich dann natürlich auch ausgeben. Z.b. alle Seiten mit Tag XYZ, die Tags eines Items, oder alle Tags einer Gruppe.
Im Grunde funktioniert's bereits ganz gut. Das ganze muss jetzt noch abgesichert, dokumentiert und aufgeräumt werden. Performance muss auch nochmal ran und irgendwie braucht das Ding noch 'ne Admin Oberfläche. In ein paar Wochen könnte das Ding dann richtig fertig sein.
Beste Grüße ich geh jetzt ins Bett
Nils

Ich habe eine Basis-Version eines Tagging Plug-ins geschrieben.
öffentliche User können ein an beliebiger Stelle auftauchendes Formular mit Komma separierten Tags ausfüllen. Nach dem Absenden werden die Tags in einer Tabelle gespeichert. Sofern ein Tag für eine Kombination bereits besteht wird hierfür ein Zähler erhöht.
Beim Aufruf müssen eine item-id, group-id und die tag-url übergeben werden. Diese drei ergeben die Zuordnung eines Tags. Somit kann ein Tag auch für mehrere Elemente gelten, über die Gruppierung und item-id lässt sich das Tagging quasi universal für jede Form von Content oder Modul anwenden. Tag-url muss nicht zwingend eine URL sein sondern kann jeglichen Text enthalten. Über den Parameter "counter" kann das Plugin zudem als counter mit mehreren simultanen ident-elementen genutzt werden.
Das ganze lässt sich dann natürlich auch ausgeben. Z.b. alle Seiten mit Tag XYZ, die Tags eines Items, oder alle Tags einer Gruppe.
Im Grunde funktioniert's bereits ganz gut. Das ganze muss jetzt noch abgesichert, dokumentiert und aufgeräumt werden. Performance muss auch nochmal ran und irgendwie braucht das Ding noch 'ne Admin Oberfläche. In ein paar Wochen könnte das Ding dann richtig fertig sein.
Beste Grüße ich geh jetzt ins Bett
Nils
Re: Öffentliche Besucher taggen Beiträge - Lösungsansätze?
So spontan hätte ich an ein modifiziertes Comments-Modul gedacht
... aber du bist ja schon weiter.

Re: Öffentliche Besucher taggen Beiträge - Lösungsansätze?
Hi Cyberman,
ungefähr in die Richtung geht es auch ein wenig. Hatte auch erst gedacht das Comments Modul ein wenig aufzubohren. Allerdings habe ich dann doch neu angefangen - damit ich den ganzen Code auch wirklich kenne
.
Vielleicht habt ihr ja noch ein paar Ideen die man in ein Tagging Modul noch einfließen lassen könnte? Habe ein wenig experimentiert, das (noch) Plug-in kann mit allen gängigen Modulen verknüpft werden, die Ihre Daten per Smarty ausgeben. Die Kombination von drei Identifikations-Merkmalen reicht wohl aus um jeglichen Content durch User Taggen zu lassen. Auch kann ein Tag Formular mehrmals pro Seite auftauchen.
Allerdings werden bis jetzt alle Parameter als versteckte Felder im Forumlar übergeben, nach State-of-the-Art fühlt sich das nicht an. Da kommt zwar noch ein Captcha zwischen... aber richtig gefallen tut mir das noch nicht.
Um mySQL Injections abzufangen habe ich an sowas gedacht:
Sollte doch reichen, oder was meint ihr?
Ach ja, ich habe überlegt dem Tagging Plugin noch eine extra Daten-Spalte für User-Zugehörigkeit zu geben. Somit könnte jeder FEU seine eigenen Tags auf der Seite haben. Das macht natürlich eher Sinn bei Seiten mit großem Inhalt und großer Community, auch müssen dabei noch ein paar mehr Dinge bedacht werden. Daher wollte ich mal horchen, ob überhaupt Interesse an einer solchen Zusatzfunktion bestünde.
Beste Grüße
Nils
ungefähr in die Richtung geht es auch ein wenig. Hatte auch erst gedacht das Comments Modul ein wenig aufzubohren. Allerdings habe ich dann doch neu angefangen - damit ich den ganzen Code auch wirklich kenne

Vielleicht habt ihr ja noch ein paar Ideen die man in ein Tagging Modul noch einfließen lassen könnte? Habe ein wenig experimentiert, das (noch) Plug-in kann mit allen gängigen Modulen verknüpft werden, die Ihre Daten per Smarty ausgeben. Die Kombination von drei Identifikations-Merkmalen reicht wohl aus um jeglichen Content durch User Taggen zu lassen. Auch kann ein Tag Formular mehrmals pro Seite auftauchen.
Allerdings werden bis jetzt alle Parameter als versteckte Felder im Forumlar übergeben, nach State-of-the-Art fühlt sich das nicht an. Da kommt zwar noch ein Captcha zwischen... aber richtig gefallen tut mir das noch nicht.
Um mySQL Injections abzufangen habe ich an sowas gedacht:
Code: Select all
$dirty_input= $_POST["input"];
$clean_input = mysql_real_escape_string(stripslashes(ltrim(rtrim($dirty_input))));
Ach ja, ich habe überlegt dem Tagging Plugin noch eine extra Daten-Spalte für User-Zugehörigkeit zu geben. Somit könnte jeder FEU seine eigenen Tags auf der Seite haben. Das macht natürlich eher Sinn bei Seiten mit großem Inhalt und großer Community, auch müssen dabei noch ein paar mehr Dinge bedacht werden. Daher wollte ich mal horchen, ob überhaupt Interesse an einer solchen Zusatzfunktion bestünde.
Beste Grüße
Nils
Last edited by nhaack on Tue Jan 06, 2009 12:49 am, edited 1 time in total.
Re: Öffentliche Besucher taggen Beiträge - Lösungsansätze?
This is really fancy 
REST API ist schon mal 'ne gute Sache. XML bekommt man da wohl auch raus. Damit kann ich ein paar Funktionen von mir einfach mitnutzen. Die jetzigen Tagging-Funktionen könnte man auch nutzen um zurückgegebene Tags der opencalais API abzuspeichern. Die Frage ist nur, wie mit Updates von Content umgegangen wird? Was passiert wenn Seiten gelöscht werden oder textlich komplett geändert werden? Man könnte in diesem Fall zwar die Tags eines Objekts löschen und neu Anfragen - aber es macht klar, dass ich noch ein gutes Stück tiefer graben muss (Modulentwicklung, Admin-Oberfläche, Event-Hooks).
Andererseits könnte man die Tag Daten auch einfach als XML im Cache lassen und gar nicht als Eintrag in die DB aufnehmen. Und dann bei Aufruf als Smarty Objekt bereit stellen.
Ich denke ich muss mich erstmal genauer einlesen. Wie werden die API Ergebnisse optimal mit dem Content-Verschmolzen? Hat hier jemand mit dem Thema semantische Metadaten schon mehr Erfahrung?
Insgesamt aber ein sehr schöner Tipp. Passt optimal in ein experimentelles Projekt von mir. Habe noch ein paar Tage Urlaub, da lässt sich vielleicht sogar ein funktionierender Prototyp entwickeln.
Beste Grüße
Nils

REST API ist schon mal 'ne gute Sache. XML bekommt man da wohl auch raus. Damit kann ich ein paar Funktionen von mir einfach mitnutzen. Die jetzigen Tagging-Funktionen könnte man auch nutzen um zurückgegebene Tags der opencalais API abzuspeichern. Die Frage ist nur, wie mit Updates von Content umgegangen wird? Was passiert wenn Seiten gelöscht werden oder textlich komplett geändert werden? Man könnte in diesem Fall zwar die Tags eines Objekts löschen und neu Anfragen - aber es macht klar, dass ich noch ein gutes Stück tiefer graben muss (Modulentwicklung, Admin-Oberfläche, Event-Hooks).
Andererseits könnte man die Tag Daten auch einfach als XML im Cache lassen und gar nicht als Eintrag in die DB aufnehmen. Und dann bei Aufruf als Smarty Objekt bereit stellen.
Ich denke ich muss mich erstmal genauer einlesen. Wie werden die API Ergebnisse optimal mit dem Content-Verschmolzen? Hat hier jemand mit dem Thema semantische Metadaten schon mehr Erfahrung?
Insgesamt aber ein sehr schöner Tipp. Passt optimal in ein experimentelles Projekt von mir. Habe noch ein paar Tage Urlaub, da lässt sich vielleicht sogar ein funktionierender Prototyp entwickeln.
Beste Grüße
Nils
Re: Öffentliche Besucher taggen Beiträge - Lösungsansätze?
Sopp,
die Basisarbeiten sind abgeschlossen. Wobei ich die API für Semantische Metadaten noch noch nicht eingebunden habe (ist aber auf meiner Projekt-Merkliste). Diese werde ich in einem gesonderten Plug-in ansprechen. Dieses Plug-in soll dann aber optional die gewonnenen Tags im "Public Tagging" Modul ablegen können.
Nachfolgend eine kurze Beschreibung, mit der Bitte um Feedback. In den nächsten Schritten, werde ich dann aus dem Plug-in ein Modul mit Verwaltung und Konfiguration machen.
Nachfolgend das DB Layout:
tag_id - int(11) Key
item_id - varchar(64) Zuordnung Element
group_id - varchar(64) Zuordnung Gruppe
tag_string - varchar(64) Der einzelne Tag
tag_target - varchar(160) Das Ziel des Tags
tag_target_title - varchar(120) Der Titel des Ziels
tag_counter - int(11) Counter des Tags (+1 wenn Tag bei Eingabe bereits existiert)
privacy_level - int(1) extra Ident-Feld oder Angabe des Privacy Level
user_id - varchar(30) extra Ident-Feld oder Angabe einer Benutzerkennung
Im Moment sind noch recht üppige Puffer vorhanden, das kann bei sehr größer Tabellen (+500k) natürlich schnell zu hohem Platzkonsum führen. Allerdings ist hiermit eine echt coole Flexibilität möglich. Im Moment bestehen folgende Funktionen:
1) Show Form (hier können die Tags von Besuchern eingegeben werden
2) Counter (hier kann ein Tag zwangsweise hochgezählt werden)
3) Display (nach Übereinstimmung: item_id, group_id, tag)
4) All Count (Counter im "1.000.000 Burger Sold" style (zählt einfach alle ausgelieferten & getaggten Seiten)
5) Process (nimmt http post-parameter und schreibt in die DB)
Mit "Show Form" wird ein einfaches 1-Feld Formular eingeblendet das ein Benutzer (egal ob FEU oder nicht) im Front-End nutzen kann um ein Element mit einem Tag zu versehen.
Mit "Counter" wird jegliche Anzeige unterdrückt. Zudem kann ein Tag angegeben werden. Sobald die Seite aufgerufen wird, wird dieser Tag dann hochgezählt. Zusammen mit den diversen Ident-Feldern lassen sich vielseitige Hit-Counter realisieren. Man könnte hiermit theoretisch sogar automatisierte AB Test realisieren bei denen CMSMS über Smarty die erfolgreichsten Inhalte selektiert.
"Display" kann genutzt werden um die Ergebnisse gefiltert auszugeben. Alles über Smarty bereit gestellt, daher sehr flexibel. Es wird automatisch eine Gewichtung vorgenommen und das Ergebnis als zusätzlicher String "size1" bis "size5" zurück gegeben. Sehr komfortabel um den Ergebnissen CSS Klassen zuzuordnen (für Cloud-Ansicht). Auch kann hier eine Liste der häufigst aufgerufenen Seiten (Counter) erstellen.
"All Count" wird genutzt um die Summe aller Hitcounter einer Gruppe auszugeben. Hiermit lässt sich ein einfacher Gesamtzähler anzeigen.
"Process" kann genutzt werden um Post-Parameter anzunehmen. Sehr praktisch, wenn die Tag Funktion per AJAX auf einer eigenen CMSMS Seite ablaufen soll.
Jederzeit können group_id, user_id und privacy_level angegeben werden.
Jetzt muss ich mich nur mal schlau machen, wie man ein Modul erstellt. Bis jetzt haben Plug-ins immer gereicht. Aber ich habe im Wiki schon eine umfangreiche Anleitung gesehen und mir das Skeleton Modul besorgt. So schlimm kann das nicht sein, oder
Sonstige ToDo's sind Captcha Support (kleine Matheaufgabe VS Grafik
) und ein eventueller Time-Stamp der Erstellung des Tags, damit ließen sich bestimmt spannende Verlaufsdaten ableiten.
Freue mich auf Feedback
Beste Grüße
Nils
die Basisarbeiten sind abgeschlossen. Wobei ich die API für Semantische Metadaten noch noch nicht eingebunden habe (ist aber auf meiner Projekt-Merkliste). Diese werde ich in einem gesonderten Plug-in ansprechen. Dieses Plug-in soll dann aber optional die gewonnenen Tags im "Public Tagging" Modul ablegen können.
Nachfolgend eine kurze Beschreibung, mit der Bitte um Feedback. In den nächsten Schritten, werde ich dann aus dem Plug-in ein Modul mit Verwaltung und Konfiguration machen.
Nachfolgend das DB Layout:
tag_id - int(11) Key
item_id - varchar(64) Zuordnung Element
group_id - varchar(64) Zuordnung Gruppe
tag_string - varchar(64) Der einzelne Tag
tag_target - varchar(160) Das Ziel des Tags
tag_target_title - varchar(120) Der Titel des Ziels
tag_counter - int(11) Counter des Tags (+1 wenn Tag bei Eingabe bereits existiert)
privacy_level - int(1) extra Ident-Feld oder Angabe des Privacy Level
user_id - varchar(30) extra Ident-Feld oder Angabe einer Benutzerkennung
Im Moment sind noch recht üppige Puffer vorhanden, das kann bei sehr größer Tabellen (+500k) natürlich schnell zu hohem Platzkonsum führen. Allerdings ist hiermit eine echt coole Flexibilität möglich. Im Moment bestehen folgende Funktionen:
1) Show Form (hier können die Tags von Besuchern eingegeben werden
2) Counter (hier kann ein Tag zwangsweise hochgezählt werden)
3) Display (nach Übereinstimmung: item_id, group_id, tag)
4) All Count (Counter im "1.000.000 Burger Sold" style (zählt einfach alle ausgelieferten & getaggten Seiten)
5) Process (nimmt http post-parameter und schreibt in die DB)
Mit "Show Form" wird ein einfaches 1-Feld Formular eingeblendet das ein Benutzer (egal ob FEU oder nicht) im Front-End nutzen kann um ein Element mit einem Tag zu versehen.
Mit "Counter" wird jegliche Anzeige unterdrückt. Zudem kann ein Tag angegeben werden. Sobald die Seite aufgerufen wird, wird dieser Tag dann hochgezählt. Zusammen mit den diversen Ident-Feldern lassen sich vielseitige Hit-Counter realisieren. Man könnte hiermit theoretisch sogar automatisierte AB Test realisieren bei denen CMSMS über Smarty die erfolgreichsten Inhalte selektiert.
"Display" kann genutzt werden um die Ergebnisse gefiltert auszugeben. Alles über Smarty bereit gestellt, daher sehr flexibel. Es wird automatisch eine Gewichtung vorgenommen und das Ergebnis als zusätzlicher String "size1" bis "size5" zurück gegeben. Sehr komfortabel um den Ergebnissen CSS Klassen zuzuordnen (für Cloud-Ansicht). Auch kann hier eine Liste der häufigst aufgerufenen Seiten (Counter) erstellen.
"All Count" wird genutzt um die Summe aller Hitcounter einer Gruppe auszugeben. Hiermit lässt sich ein einfacher Gesamtzähler anzeigen.
"Process" kann genutzt werden um Post-Parameter anzunehmen. Sehr praktisch, wenn die Tag Funktion per AJAX auf einer eigenen CMSMS Seite ablaufen soll.
Jederzeit können group_id, user_id und privacy_level angegeben werden.
Jetzt muss ich mich nur mal schlau machen, wie man ein Modul erstellt. Bis jetzt haben Plug-ins immer gereicht. Aber ich habe im Wiki schon eine umfangreiche Anleitung gesehen und mir das Skeleton Modul besorgt. So schlimm kann das nicht sein, oder

Sonstige ToDo's sind Captcha Support (kleine Matheaufgabe VS Grafik

Freue mich auf Feedback
Beste Grüße
Nils
Re: Öffentliche Besucher taggen Beiträge - Lösungsansätze?
Klingt nach deinem nächsten Schweizer Messer
...
