Routes
11 views
Skip to first unread message
Smiley
Feb 28, 2011, 10:41:49 AM2/28/11
to ecamp-dev
Heute spontan durch den Kopf gegangen, inspiriert durch Github und
durch Fortes Aussage "die Leute können sich die Camp-nr eh nicht
merken":
Jedes Lager ist entweder einer Gruppe zugeteilt oder einer
Privatperson.
(Klammer auf: Auch bei Zuteilung zu einer Gruppe gibt es einen Owner,
der Spezialrechte hat).
Das Lager ist dann erreichbar durch Namen anstatt Nummern, z.B.:
http://ecamp/rburg/pios2010
oder
http://ecamp/smiley/my_very_private_camp
Was meint ihr?
durch Fortes Aussage "die Leute können sich die Camp-nr eh nicht
merken":
Jedes Lager ist entweder einer Gruppe zugeteilt oder einer
Privatperson.
(Klammer auf: Auch bei Zuteilung zu einer Gruppe gibt es einen Owner,
der Spezialrechte hat).
Das Lager ist dann erreichbar durch Namen anstatt Nummern, z.B.:
http://ecamp/rburg/pios2010
oder
http://ecamp/smiley/my_very_private_camp
Was meint ihr?
Smiley
Mar 8, 2011, 4:08:07 PM3/8/11
to ecamp-dev
Hab noch ein paar Inputs die etwas weitergehen (mehr in Richtung
Socialising/Datenschutz, etc.), aber die obige Idee aufgreifen.
Anregungen gerne erwünscht, sonst implementiere ich das so ;)
Wenn ich hier von einer Gruppe spreche, ist immer das Abbild einer
Pfadigruppe gemeint. Freie Interessensgruppe a la Facebook habe ich
hier nicht behandelt.
- Name, Pfadiname und Profilbild sind Allgemeingut, d.h. jeder der
eingeloggt ist kann danach Suchen und Ansehen
- Es gibt Gruppen. Diese sind hierarchisch organisiert.
- Jede Gruppe hat "Manager" und "Mitglieder".
- Um einer Gruppe als "Mitglied" beizutreten braucht es die
Bestätigung durch den Manager
- Um in einer Gruppe eine Managerrolle zu übernehmen braucht es die
Zustimmung eines Managers der Vatergruppe (Beispiel: Ernennung zum
Abteilungsleiter braucht Bestätigung durch Corpsleiter)
- Gruppenzugehörigkeit ist Allgemeingut (Auflistung, wer in welcher
Gruppe ist beim Userprofil und Gruppenprofil für alle sichtbar)
- Gruppennamen und Benutzernamen teilen sich einen gemeinsamen
Namespace (wichtig für die Routen, siehe erster Post)
- Jedes Lager gehört entweder einem Benutzer oder einer Gruppe
(wichtig für den URL-Aufruf, siehe erstes Posting)
- Auch Lager die einer Gruppe gehören haben einen Ersteller der auf
dem Lager Adminrechte hat
- Jedes Lager hat "Mitarbeiter". Diese sind natürlich unabhängig von
Gruppenzugehörigkeit (will heissen, ich muss nicht Teilnehmer einer
Gruppe sein um in einem Gruppenlager mitzuarbeiten und umgekehrt nur
weil ich Teilnehmer einer Gruppe bin arbeite ich nicht automatisch im
Lager mit)
- Zu jedem Lager können Einstellungen zur Sichtbarkeit gemacht werden
(z.b. privat, öffentlich aufgelistet, öffentlich einsehbar, etc.).
- Zu einem Lager, welches Teil einer Gruppe ist, können zusätzliche
Einstellungen auf Gruppenebene verteilt werden (z.B. Auflistung für
Gruppenmitglieder, erweiterte Einsicht für Gruppenmitglieder,
spezielle Rechte für Gruppenmanager, etc.).
- Jeder User kann Freunde haben
- User können ihren Freunden mehr Einblick geben als anderen Usern
(z.B. Kontaktdaten, besuchte Kurse, geleitete Lager, gesharte Blöcke,
etc.)
- Die Freundesliste wird desweiteren dazu verwendet, schnellen Zugriff
auf oft verwendete Kontakte zu haben (z.B. bei Personensuche, bei
Lagereinladungen, etc.)
Was meint ihr zum Gruppenkonzept? Wird das so funktionieren oder ist
das zu umständlich und zu wenig autonom? Wo seht ihr die grossen
Vorteile von hierarchischen Gruppen im Gegensatz zu "freien Gruppen"?
Inwiefern könnte die "Macht" des Gruppenmanagers ein
Sicherheitsproblem darstellen?
Socialising/Datenschutz, etc.), aber die obige Idee aufgreifen.
Anregungen gerne erwünscht, sonst implementiere ich das so ;)
Wenn ich hier von einer Gruppe spreche, ist immer das Abbild einer
Pfadigruppe gemeint. Freie Interessensgruppe a la Facebook habe ich
hier nicht behandelt.
- Name, Pfadiname und Profilbild sind Allgemeingut, d.h. jeder der
eingeloggt ist kann danach Suchen und Ansehen
- Es gibt Gruppen. Diese sind hierarchisch organisiert.
- Jede Gruppe hat "Manager" und "Mitglieder".
- Um einer Gruppe als "Mitglied" beizutreten braucht es die
Bestätigung durch den Manager
- Um in einer Gruppe eine Managerrolle zu übernehmen braucht es die
Zustimmung eines Managers der Vatergruppe (Beispiel: Ernennung zum
Abteilungsleiter braucht Bestätigung durch Corpsleiter)
- Gruppenzugehörigkeit ist Allgemeingut (Auflistung, wer in welcher
Gruppe ist beim Userprofil und Gruppenprofil für alle sichtbar)
- Gruppennamen und Benutzernamen teilen sich einen gemeinsamen
Namespace (wichtig für die Routen, siehe erster Post)
- Jedes Lager gehört entweder einem Benutzer oder einer Gruppe
(wichtig für den URL-Aufruf, siehe erstes Posting)
- Auch Lager die einer Gruppe gehören haben einen Ersteller der auf
dem Lager Adminrechte hat
- Jedes Lager hat "Mitarbeiter". Diese sind natürlich unabhängig von
Gruppenzugehörigkeit (will heissen, ich muss nicht Teilnehmer einer
Gruppe sein um in einem Gruppenlager mitzuarbeiten und umgekehrt nur
weil ich Teilnehmer einer Gruppe bin arbeite ich nicht automatisch im
Lager mit)
- Zu jedem Lager können Einstellungen zur Sichtbarkeit gemacht werden
(z.b. privat, öffentlich aufgelistet, öffentlich einsehbar, etc.).
- Zu einem Lager, welches Teil einer Gruppe ist, können zusätzliche
Einstellungen auf Gruppenebene verteilt werden (z.B. Auflistung für
Gruppenmitglieder, erweiterte Einsicht für Gruppenmitglieder,
spezielle Rechte für Gruppenmanager, etc.).
- Jeder User kann Freunde haben
- User können ihren Freunden mehr Einblick geben als anderen Usern
(z.B. Kontaktdaten, besuchte Kurse, geleitete Lager, gesharte Blöcke,
etc.)
- Die Freundesliste wird desweiteren dazu verwendet, schnellen Zugriff
auf oft verwendete Kontakte zu haben (z.B. bei Personensuche, bei
Lagereinladungen, etc.)
Was meint ihr zum Gruppenkonzept? Wird das so funktionieren oder ist
das zu umständlich und zu wenig autonom? Wo seht ihr die grossen
Vorteile von hierarchischen Gruppen im Gegensatz zu "freien Gruppen"?
Inwiefern könnte die "Macht" des Gruppenmanagers ein
Sicherheitsproblem darstellen?
Forte
Mar 8, 2011, 6:06:44 PM3/8/11
to ecamp-dev
Ich bin der Meinung, dass sich das alles ganz gut anhört!
=> Gruppen und User im selben Namespace find ich ne super Idee!
Nur einen Punkte möchte ich in Frage stellen. Müssen wir in einem
ersten Wurf die Sichtbarkeit eines Lagers für Gruppenmitglieder und
Andere unterscheiden?
Diese Frage stellt sich für mich aus zwei Gründen:
- Kann das dem Nutzer einfach verständlich gemacht werden?
- Kann ich das für jede Gruppe, von welcher ich Mitglied bin,
individuell einstellen? (Wenn Ja: Wird das plausibel ersichtlich??)
(Wenn Nein: Wo ist dann der Gewinn??)
Zudem fehlen Gedanken zum erstellen von neuen Gruppen.
Wer kann neue Gruppen erstellen? Müssen diese immer einer VaterGruppe
angehören?
Gruss Forte
=> Gruppen und User im selben Namespace find ich ne super Idee!
Nur einen Punkte möchte ich in Frage stellen. Müssen wir in einem
ersten Wurf die Sichtbarkeit eines Lagers für Gruppenmitglieder und
Andere unterscheiden?
Diese Frage stellt sich für mich aus zwei Gründen:
- Kann das dem Nutzer einfach verständlich gemacht werden?
- Kann ich das für jede Gruppe, von welcher ich Mitglied bin,
individuell einstellen? (Wenn Ja: Wird das plausibel ersichtlich??)
(Wenn Nein: Wo ist dann der Gewinn??)
Zudem fehlen Gedanken zum erstellen von neuen Gruppen.
Wer kann neue Gruppen erstellen? Müssen diese immer einer VaterGruppe
angehören?
Gruss Forte
Smiley
Mar 9, 2011, 4:10:35 AM3/9/11
to ecamp-dev
On 9 Mrz., 00:06, Forte <fo...@musegg.ch> wrote:
> Nur einen Punkte möchte ich in Frage stellen. Müssen wir in einem
> ersten Wurf die Sichtbarkeit eines Lagers für Gruppenmitglieder und
> Andere unterscheiden?
>
> Diese Frage stellt sich für mich aus zwei Gründen:
> - Kann das dem Nutzer einfach verständlich gemacht werden?
> - Kann ich das für jede Gruppe, von welcher ich Mitglied bin,
> individuell einstellen? (Wenn Ja: Wird das plausibel ersichtlich??)
> (Wenn Nein: Wo ist dann der Gewinn??)
Also, der Usecase, den ich im Kopf habe geht so: Die 2. Stufe der
> Nur einen Punkte möchte ich in Frage stellen. Müssen wir in einem
> ersten Wurf die Sichtbarkeit eines Lagers für Gruppenmitglieder und
> Andere unterscheiden?
>
> Diese Frage stellt sich für mich aus zwei Gründen:
> - Kann das dem Nutzer einfach verständlich gemacht werden?
> - Kann ich das für jede Gruppe, von welcher ich Mitglied bin,
> individuell einstellen? (Wenn Ja: Wird das plausibel ersichtlich??)
> (Wenn Nein: Wo ist dann der Gewinn??)
Pfadi XY erstellt ein Lager und ordnet dieses der Gruppe "Pfadi XY"
zu. Die Leiter der 2. Stufe aber auch der anderen Stufe sind
Mitglieder der Gruppe "Pfadi XY". Das Lager ist erreichbar unter /
pfadi_xy/stufe2_sola2011. Nun kann z.B. das Lager so eingestellt
werden, dass alle Mitglieder der Gruppe "Pfadi XY" Lesezugriff auf das
Lager haben, ohne dass diese als Gäste ins Lager hinzugefügt werden
müssen.
Die Frage ist also nicht "in welchen Gruppen bin ich Mitglied",
sondern "zu welcher Gruppe gehört das Lager", und das ist maximal 1.
Die Checkbox wäre dann in den Lagereinstellungen und heisst z.B.
"Mitglieder der Gruppe PfadiXY" haben Lesezugriff auf das Lager".
Lager die keiner Gruppe zugeordnet sind (/smiley/
my_private_camp_with_forte) haben dieses Feature nicht. In einer erste
Linie müssen diese Einstellungen sicher noch nicht implementiert
werden. Mit geht es mehr um die Frage, ob wir den Aufwand der
hierarchischen Gruppen betreiben wollen, um später die Möglichkeit zu
haben, genau solche Features einzubauen.
> Zudem fehlen Gedanken zum erstellen von neuen Gruppen.
> Wer kann neue Gruppen erstellen? Müssen diese immer einer VaterGruppe
> angehören?
Sicht die Bestätigung durch den Gruppenmanager (z.B. Corpsleiter kann
neue Abteilungen erstellen oder bewilligen). In einer Übergangsphase
müssen wir uns sicher noch einen Weg über die Admins überlegen,
nämlich dann, wenn es noch gar keine Gruppenmanager gibt (Usecase:
Forte möchte Corpsleiter werden, in der Gruppe PfadiLuzern gibt es
aber noch keine Manager).
Von mir aus braucht es immer eine Vatergruppe. Diese hierarchischen
Gruppen sollen ja die Pfadistruktur (oder von mir aus auch andere
Vereinsstrukturen) wiederspiegeln. Die Möglichkeit, freie
Interesennsgruppen zu bilden, ist für mich ein anderes Thema. Ob diese
dann im Frontend ähnlich behandelt werden (z.B. ob da auch Lager
zugehören können oder ob es sich um reine Socialising-Gruppen handelt,
hab ich mir auch noch nicht wirklich überlegt).
Forte
Mar 9, 2011, 7:21:08 AM3/9/11
to ecamp-dev
Jo, die Usecases kann ich gut nachvollziehen. Siehe das ganz ähnlich.
Ich denke, wenn man die Einstellungen auf die Gruppe beschränkt,
welcher das Lager angehört, ist es auch übersichtlich;
So kann man einem Lager zwei Einstellungen bezüglich Sichtbarkeit
vornehmen:
Sichtbarkeit für Gruppenmitglieder
Sichtbarkeit für die Öffentlichkeit
Werte dafür könnten vielleicht folgende sein:
- Nicht einsichtbar;
- Nur Leserecht;
- Bearbeitungsrecht;
- Administrationsrecht / Moderationsrecht / LagerleiterRecht??
Die konkreten Rechte müssten noch diskutiert werden; Ich glaube
jedoch, dass es sinn macht, (mindestens) zwei verschiedene Rollen für
Schreibberechtigte zu führen.
Zusammengefasst glaube ich, sollte das Konzept ReadyToGo sein ;)
Ich denke, wenn man die Einstellungen auf die Gruppe beschränkt,
welcher das Lager angehört, ist es auch übersichtlich;
So kann man einem Lager zwei Einstellungen bezüglich Sichtbarkeit
vornehmen:
Sichtbarkeit für Gruppenmitglieder
Sichtbarkeit für die Öffentlichkeit
Werte dafür könnten vielleicht folgende sein:
- Nicht einsichtbar;
- Nur Leserecht;
- Bearbeitungsrecht;
- Administrationsrecht / Moderationsrecht / LagerleiterRecht??
Die konkreten Rechte müssten noch diskutiert werden; Ich glaube
jedoch, dass es sinn macht, (mindestens) zwei verschiedene Rollen für
Schreibberechtigte zu führen.
Zusammengefasst glaube ich, sollte das Konzept ReadyToGo sein ;)
Forte
Mar 9, 2011, 8:34:31 AM3/9/11
to ecamp-dev
Mir wurde soeben ein Problem bewusst, welches gerne noch in die Rund
werfen möchte.
Es gibt verschiedene pfadis, welche gleich heissen... beispiel: pfadi
winkelried!
Das ergibt für die hirarchische struktur kein problem, jedoch beim
routen schon...
speziell, wenn ein AL in seiner Abt für die einzelnen stufen gruppen
einrichten möchte, könnte das ärgerlich werden... (da die einfache
lösung von uniquen gruppennamen sehr einschränkend wirken kann!!)
werfen möchte.
Es gibt verschiedene pfadis, welche gleich heissen... beispiel: pfadi
winkelried!
Das ergibt für die hirarchische struktur kein problem, jedoch beim
routen schon...
speziell, wenn ein AL in seiner Abt für die einzelnen stufen gruppen
einrichten möchte, könnte das ärgerlich werden... (da die einfache
lösung von uniquen gruppennamen sehr einschränkend wirken kann!!)
Strix
Mar 9, 2011, 6:59:47 PM3/9/11
to ecamp-dev
Nur, um kurz mal noch meinen Senf dazu beizusteuern: Wie wäre es, wenn
die Gruppen nicht fix sind, sondern "Projektgruppen" erstellt werden
können? Es ist selten, dass 2 Lager nacheinander von den gleichen
Leuten verwaltet werden, mal können die einen, mal die andern nicht.
Ausserdem könnte man gleich noch etwas damit umsetzen, was mir
eindeutig fehlt: irgendeine Möglichkeit, Dokumente den Lagern
anzufügen. Sei es gleich auf den Server zu laden oder zumindest so zu
verlinken, dass jede "Projektgruppe" einen lagerspezifischen
"Projektordner" besitzen kann.
Und wenns mit eindeutigen Namen nicht geht, müssen halt trotzem
Nummern hinhalten...
Gruss
Strix
die Gruppen nicht fix sind, sondern "Projektgruppen" erstellt werden
können? Es ist selten, dass 2 Lager nacheinander von den gleichen
Leuten verwaltet werden, mal können die einen, mal die andern nicht.
Ausserdem könnte man gleich noch etwas damit umsetzen, was mir
eindeutig fehlt: irgendeine Möglichkeit, Dokumente den Lagern
anzufügen. Sei es gleich auf den Server zu laden oder zumindest so zu
verlinken, dass jede "Projektgruppe" einen lagerspezifischen
"Projektordner" besitzen kann.
Und wenns mit eindeutigen Namen nicht geht, müssen halt trotzem
Nummern hinhalten...
Gruss
Strix
Smiley
Mar 10, 2011, 4:36:00 AM3/10/11
to ecamp-dev
On 10 Mrz., 00:59, Strix <st...@schwyzerstaern.ch> wrote:
> Nur, um kurz mal noch meinen Senf dazu beizusteuern: Wie wäre es, wenn
> die Gruppen nicht fix sind, sondern "Projektgruppen" erstellt werden
> können? Es ist selten, dass 2 Lager nacheinander von den gleichen
> Leuten verwaltet werden, mal können die einen, mal die andern nicht.
Ich versuch mal kurz ein wenig Übersicht ins Gruppenchaos zu bringen.
> Nur, um kurz mal noch meinen Senf dazu beizusteuern: Wie wäre es, wenn
> die Gruppen nicht fix sind, sondern "Projektgruppen" erstellt werden
> können? Es ist selten, dass 2 Lager nacheinander von den gleichen
> Leuten verwaltet werden, mal können die einen, mal die andern nicht.
Wir reden hier über 3 Arten von Gruppen:
- Lagermitarbeiter (von Strix Projektgruppen genannt): Leiter, die
zusammen ein Lager/Kurs planen. Das ist die einzige Gruppe die es in
eCampv2 bereits gibt und wird wahrscheinlich sehr ähnlich in V3
umgesetzt.
- Hierarchische Gruppen: Abbildung der Pfadistruktur (Kantone, Corps,
Abteilungen). Der Schwerpunkt hier ist weniger die Arbeit am Lager
sondern der Social Network Aspekt (In welcher Pfadi ist der Forte
schon wieder? Wer ist eigentlich in der Kantonsleitung vom Kanton
Appenzell? Der Dingsda der war doch von der Pfadi XY aber wie heisst
der schon wieder?). Weitere Ideen die schon gefallen sind:
Abteilungsinterne Diskussionsplatform, Newsplatform (der
Kantonalverband kann Nachrichten posten, die dann bei allen Leitern
des entsprechenden Kantons erscheinen), Statistiken (in welchem Teil
der Schweiz ist eCamp verbreitet), etc.
- Freie Gruppen: Abteilungsübergreifende Interessensgruppen a la
Facebook ("Ich will wieder ein BuLa", "Topkursteilnehmer XZ", ...).
Der Schwerpunkt hier wäre ganz klar im Socialising.
> Ausserdem könnte man gleich noch etwas damit umsetzen, was mir
> eindeutig fehlt: irgendeine Möglichkeit, Dokumente den Lagern
> anzufügen. Sei es gleich auf den Server zu laden oder zumindest so zu
> verlinken, dass jede "Projektgruppe" einen lagerspezifischen
> "Projektordner" besitzen kann.
sind Dokumentenanhänge bei einzelnen Blöcken. Für eine allgemeine
Dokumentenablage pro Lager liebäugeln wir ein wenig mit einer
Anbindung an die Dropbox-API.
> Und wenns mit eindeutigen Namen nicht geht, müssen halt trotzem
> Nummern hinhalten...
Winkelried fallen mir spontan einige Namen ein (winkelried, rburg,
rothenburg, winkelried_LU, ...). Auf Stufenebe Gruppen einzüführen
macht aus meiner Sicht wenig Sinn, es sei denn, die Abteilung ist so
gross wie beim Corps Musegg, aber dann haben die einzelnen Stufen/
Stämme/Meuten meist wieder Namen, die man verwenden kann (Sioni,
etc.).
Die Alternative wäre (wie Strix erwähnt) Nummern oder hierarchische
Routen (luzern/seetal/rburg), finde ich aber beides nicht so toll.
Strix
Mar 10, 2011, 4:57:37 AM3/10/11
to ecamp-dev
Das grosse Problem an den hierarchischen Gruppen wird sein, diese
aktuell zu halten. Woher sollen wir wissen, wenns in Abteilung X einen
neuen AL gibt? Wer sagt uns, dass Corps Y einen neuen Coach hat etc??
Wenn schon, würde ich die aber mit hierarchischen Routen umsetzen,
anders wirds unglaublich mühsam. Das einfachste wären eindeutige
Nummern, das schwierigste eindeutige Namen. Bei Routen hätte man etwas
einprägsames (man wird sich wohl noch merken können, wo man Leiter
ist) und trotzdem in jedem Fall eindeutig.
Bzgl Dokumentenablage: Dropbox hätte den Vorteil, keinen Speicherplatz
zur Verfügung stellen zu müssen. Ich weiss nicht, auf welchen Servern
ecamp läuft, bzw wieviel Platz uns zusteht etc.
aktuell zu halten. Woher sollen wir wissen, wenns in Abteilung X einen
neuen AL gibt? Wer sagt uns, dass Corps Y einen neuen Coach hat etc??
Wenn schon, würde ich die aber mit hierarchischen Routen umsetzen,
anders wirds unglaublich mühsam. Das einfachste wären eindeutige
Nummern, das schwierigste eindeutige Namen. Bei Routen hätte man etwas
einprägsames (man wird sich wohl noch merken können, wo man Leiter
ist) und trotzdem in jedem Fall eindeutig.
Bzgl Dokumentenablage: Dropbox hätte den Vorteil, keinen Speicherplatz
zur Verfügung stellen zu müssen. Ich weiss nicht, auf welchen Servern
ecamp läuft, bzw wieviel Platz uns zusteht etc.
Forte
Mar 10, 2011, 1:47:51 PM3/10/11
to ecamp-dev
Heute hatte ich wärend einer Busfahrte eine Idee (die kommen auch
immer in den unerwartetsten Momenten)...
Die Gruppen aktuell zu halten kann nicht unsere Aufgabe sein;
Unmöglich.
Doch dafür sollte es Lösungen geben (ob durch Manager, oder
Selbstverantwortung...)
Zu den Routs: (DIE Idee)
Es sollten zwei routes unterstützt sein. Zum einen eine Eindeutige
über die GruppenId/LagerId.
Daneben könne wir schöne Routs unterstützen, welche zusammen mit dem
User, welcher diese
Url abfragt eindeutig werden. Hoffentlich.
Bei Mehrdeutigkeit kann dem Benutzer eine List von möglichen Lager
angezeigt werden, aus welcher
er das gewünschte Lager auswählt. (Diese Leitet dann auf die
Nummerierte URL weiter)
Damit die Nutzer die schönen Routes auch lernen, muss die Logik in
beide Richtungen implementiert werden.
Sowohl von der URL zum erwünschten Lager, wie auch von einem Lager
eine User-Spezifisch URL.
(Dies sollte jedoch machbar sein!)
Mir gefällt diese Lösung sehr, auch wenn man sich zweierlei
Einschränkungen bewusst sein muss.
1) Öffentliche Lager können nicht so angesprochen werden (ansonsten
können unerwünschte Verdeckungen auftreten)
2) Es kann passieren, dass ich einem Mitleiter eine URL schicke,
welche sich bei ihm anders verhält.
(Wenn auch das Verhalten nur bescheiden anders sein kann; und
zwar, dass die genannte Auswahlliste auftritt)
Was meint ihr?
immer in den unerwartetsten Momenten)...
Die Gruppen aktuell zu halten kann nicht unsere Aufgabe sein;
Unmöglich.
Doch dafür sollte es Lösungen geben (ob durch Manager, oder
Selbstverantwortung...)
Zu den Routs: (DIE Idee)
Es sollten zwei routes unterstützt sein. Zum einen eine Eindeutige
über die GruppenId/LagerId.
Daneben könne wir schöne Routs unterstützen, welche zusammen mit dem
User, welcher diese
Url abfragt eindeutig werden. Hoffentlich.
Bei Mehrdeutigkeit kann dem Benutzer eine List von möglichen Lager
angezeigt werden, aus welcher
er das gewünschte Lager auswählt. (Diese Leitet dann auf die
Nummerierte URL weiter)
Damit die Nutzer die schönen Routes auch lernen, muss die Logik in
beide Richtungen implementiert werden.
Sowohl von der URL zum erwünschten Lager, wie auch von einem Lager
eine User-Spezifisch URL.
(Dies sollte jedoch machbar sein!)
Mir gefällt diese Lösung sehr, auch wenn man sich zweierlei
Einschränkungen bewusst sein muss.
1) Öffentliche Lager können nicht so angesprochen werden (ansonsten
können unerwünschte Verdeckungen auftreten)
2) Es kann passieren, dass ich einem Mitleiter eine URL schicke,
welche sich bei ihm anders verhält.
(Wenn auch das Verhalten nur bescheiden anders sein kann; und
zwar, dass die genannte Auswahlliste auftritt)
Was meint ihr?
Strix
Mar 10, 2011, 2:42:30 PM3/10/11
to ecamp-dev
Und damit die Routes auch funktionieren, muss man im Hintergrund
trotzdem mit eindeutigen IDs arbeiten, damit nicht plötzlich einer auf
ein Lager zugreifen kann, nur weil er die Route kennt, nicht aber die
Berechtigung hätte. Ich würde im Backend voll auf IDs setzen und im
ästhetischen Frontend kann man immer noch Routes umsetzen. Ich finde
es einfach etwas gefährlich, im Hintergrund mit Routes zu arbeiten...
trotzdem mit eindeutigen IDs arbeiten, damit nicht plötzlich einer auf
ein Lager zugreifen kann, nur weil er die Route kennt, nicht aber die
Berechtigung hätte. Ich würde im Backend voll auf IDs setzen und im
ästhetischen Frontend kann man immer noch Routes umsetzen. Ich finde
es einfach etwas gefährlich, im Hintergrund mit Routes zu arbeiten...
Smiley
Mar 11, 2011, 9:42:22 AM3/11/11
to ecamp-dev
@Forte: Ich hab nach unserem Telefon gestern nochmals drüber
geschlafe, und hier meine finale Meinung :)
URL für User-Profil:
http://ecamp/smiley
eindeutige URL für ein persönliches Lager (Lagername muss innerhalb
meiner pers. Lager eindeutig sein):
http://ecamp/smiley/sola2011
URL für Gruppen-Profil:
http://ecamp/pbs/luzern/rburg/pios
eindeutige URL für ein Gruppenlager (Lagername muss innerhalb der
Gruppe eindeutig sein):
http://ecamp/pbs/luzern/rburg/pios/sola2011
Quick-URL für alle Lager, in denen ich mitleite (und nur in denen,
keine Quick-URLs für andere Lager):
http://ecamp/sola2011
Wie Forte bereits erklärt hat: Wenn die Quick-URL mehrdeutig ist, wird
eine Auswahl präsentiert und auf die eindeutige URL weitergeleitet.
Ein paar Unschönheiten gibts noch:
- Benuterznamen und "Root-Gruppen" teilen sich einen Namespace (nicht
so schlimm)
- Lager dürfen nicht gleich heissen wie ein Benutzername oder eine
Root-Gruppe (finde ich irgendwie nicht so doll)
geschlafe, und hier meine finale Meinung :)
URL für User-Profil:
http://ecamp/smiley
eindeutige URL für ein persönliches Lager (Lagername muss innerhalb
meiner pers. Lager eindeutig sein):
http://ecamp/smiley/sola2011
URL für Gruppen-Profil:
http://ecamp/pbs/luzern/rburg/pios
eindeutige URL für ein Gruppenlager (Lagername muss innerhalb der
Gruppe eindeutig sein):
http://ecamp/pbs/luzern/rburg/pios/sola2011
Quick-URL für alle Lager, in denen ich mitleite (und nur in denen,
keine Quick-URLs für andere Lager):
http://ecamp/sola2011
Wie Forte bereits erklärt hat: Wenn die Quick-URL mehrdeutig ist, wird
eine Auswahl präsentiert und auf die eindeutige URL weitergeleitet.
Ein paar Unschönheiten gibts noch:
- Benuterznamen und "Root-Gruppen" teilen sich einen Namespace (nicht
so schlimm)
- Lager dürfen nicht gleich heissen wie ein Benutzername oder eine
Root-Gruppe (finde ich irgendwie nicht so doll)
Strix
Mar 11, 2011, 10:42:05 AM3/11/11
to ecamp-dev
Bei den User--URLs wird enorm schnell zu Konflikten kommen. Ich wäre
da eher für die Facabook-Variante: URL und Benutzername (Pfadiname)
sind unabhängig voneinander und die URL wird mit einer Nummer
vergeben. Wer schnell genug ist kann, solange noch frei, einen eigenen
Namen reservieren (http://ecamp.pfadiluzern.ch/strix). Wenn der
vergeben ist, muss man sich halt eine Alternative suchen (http://
ecamp.pfadiluzern.ch/strixbeni; http://ecamp.pfadiluzern.ch/strixX;
http://ecamp.pfadiluzern.ch/strix_beni etc)
da eher für die Facabook-Variante: URL und Benutzername (Pfadiname)
sind unabhängig voneinander und die URL wird mit einer Nummer
vergeben. Wer schnell genug ist kann, solange noch frei, einen eigenen
Namen reservieren (http://ecamp.pfadiluzern.ch/strix). Wenn der
vergeben ist, muss man sich halt eine Alternative suchen (http://
ecamp.pfadiluzern.ch/strixbeni; http://ecamp.pfadiluzern.ch/strixX;
http://ecamp.pfadiluzern.ch/strix_beni etc)
Forte
Mar 15, 2011, 7:49:04 AM3/15/11
to ecamp-dev
Die aktuelle Version von den Routes gefällt mir gut! (die Version ist
im eCamp/devel einsehbar)
Eine kleine Idee, welche bezüglich Performance diskutiert werden
könnte, ist mir heute noch durch den Kopf geschossen.
Wir könnten für die hierarchischen Gruppen ein anderes Trennzeichen
verwenden, als den "/".
Eine URL würde dann zum Beispiel so aussehen:
http://ecamp.pfadiluzern..ch/pbs:luzern:rburg:pios/sola2011
Ich glaube, dass das sowohl performanter als auch benutzerfreundlicher
sein kann.
Ob der ":" das richtige Trennzeichen ist, möchte ich an dieser Stelle
noch nicht endlich
vorschlagen (doch die schlechteste Wahl sollte es nicht sein).
Leider kenne ich den Code vom Vanity-Router noch nicht ausreichend, um
beurteilen zu können, ob der das
Umsetzen kann. Doch ich glaube, dass es daran nicht scheitern kann.
im eCamp/devel einsehbar)
Eine kleine Idee, welche bezüglich Performance diskutiert werden
könnte, ist mir heute noch durch den Kopf geschossen.
Wir könnten für die hierarchischen Gruppen ein anderes Trennzeichen
verwenden, als den "/".
Eine URL würde dann zum Beispiel so aussehen:
http://ecamp.pfadiluzern..ch/pbs:luzern:rburg:pios/sola2011
Ich glaube, dass das sowohl performanter als auch benutzerfreundlicher
sein kann.
Ob der ":" das richtige Trennzeichen ist, möchte ich an dieser Stelle
noch nicht endlich
vorschlagen (doch die schlechteste Wahl sollte es nicht sein).
Leider kenne ich den Code vom Vanity-Router noch nicht ausreichend, um
beurteilen zu können, ob der das
Umsetzen kann. Doch ich glaube, dass es daran nicht scheitern kann.
Reply all
Reply to author
Forward
0 new messages