Bestandsbeheer in een CMS

[orf]

In een CMS gebruik je regelmatig afbeeldingen en documenten. Bijvoorbeeld een nieuwsbericht met een vaste afbeelding of een lopende tekst met daarin een afbeelding.

Wij gebruiken daarvoor een repository met afbeeldingen en bestanden, waarin je nieuwe mappen aan kunt maken, bestanden kunt uploaden en in de verschillende elementen van modules kun je deze afbeeldingen en bestanden selecteren.

Na verloop van tijd wordt zo'n repository een chaos. Iedere gebruiker heeft een andere logica voor bestandsnamen, je ziet gebruikers met mappen waarin 100-en foto's staan en je ziet gebruikers juist tientallen mappen aanmaken.

Het gevolg is dat afbeeldingen meerdere keren geüpload worden omdat dat sneller is dan het terugvinden van een afbeelding in een bepaalde mapstructuur.

In veel grote CMS-en is bestandbeheer onderbelicht; het wordt vaak op dezelfde manier opgelost: gebruikers kunnen vrij mappen aanmaken en bestanden in deze mappen plaatsen.

Hoe zou je dit beter kunnen organiseren? Je kunt denken aan tagging, maar ook tags worden door verschillende gebruikers heel verschillend toegepast.

We denken nu aan een aantal slimme filters:
- bestandstype
- bestandsgrootte
- afbeeldingsgrootte (pixels)
- geüpload door XXXX
- afbeelding of bestand wordt gebruikt binnen module XXX (bijvoorbeeld nieuws)

Daarmee maak je de bestanden makkelijker doorzoekbaar, maar het eigenlijke probleem (de chaos in mappen en bestanden) voorkom je hier niet mee.

Hoe maak je een universeel systeem in je CMS, waarbij het CMS de ene keer gebruikt wordt voor een simpele website met één beheerder en de andere keer door tientallen beheerders binnen een grote organisatie?

[F_J_K]

Hoe maak je een universeel systeem in je CMS, waarbij het CMS de ene keer gebruikt wordt voor een simpele website met één beheerder en de andere keer door tientallen beheerders binnen een grote organisatie?

offtopic:
Dat moet je imho niet willen. Zet de juiste tool in voor de juiste klus, je koopt ook geen Siebel als MS BCM voldoet als "CRM" en maakt geen auto die bijv. zowel 100 kuub zand kan vervoeren als kan fungeren als taxi.

De combi van gebruikt binnen rubriekX (en Y en Z); geüpload door afdelingY; en juist ook interne 'map' (via een selectielijst van standaardmetadata aan de figuur gehangen) vind ik handig werken.
Maar uiteindelijk is het net zo veel de discipline van de gebruikers (resp. de mate waarin de gebruikers door hebben dat het handig is om binnen bepaalde grenzen te werken) als de applicatie die het doet.

[orf]

F_J_K schreef op dinsdag 17 februari 2009 @ 14:35:
[...]

offtopic:
Dat moet je imho niet willen. Zet de juiste tool in voor de juiste klus, je koopt ook geen Siebel als MS BCM voldoet als "CRM" en maakt geen auto die bijv. zowel 100 kuub zand kan vervoeren als kan fungeren als taxi.

offtopic:
Toch willen we graag dat het systeem voor al onze websites gebruikt kan worden. Dat werkt ook erg goed, door de modulaire opzet kunnen we er zowel grote als kleine systemen mee bouwen. Voor bestandsbeheer moet het vooral geschikt zijn voor de grotere sites; bij kleine websites ontstaat niet echt chaos.

De combi van gebruikt binnen rubriekX (en Y en Z); geüpload door afdelingY; en juist ook interne 'map' (via een selectielijst van standaardmetadata aan de figuur gehangen) vind ik handig werken.
Maar uiteindelijk is het net zo veel de discipline van de gebruikers (resp. de mate waarin de gebruikers door hebben dat het handig is om binnen bepaalde grenzen te werken) als de applicatie die het doet.

Geen suggesties voor een andere structuur dan mappen met bestanden? Ik vind dat we nog iets teveel in hokjes denken en uitgaan van het gebruikelijke (een Windows verkenner achtige interface). Wellicht zijn er betere opties.

Je moet vooral niet allemaal extra handelingen moeten verrichten bij het uploaden van een bestand, maar je wilt ook niet een ongeorganiseerd zooitje.

[Gomez12]

filesysteem structuur neerzetten in je db. De fysieke files gewoon in 1 map dumpen met sha1 / md5's als filenamen.

Upload iemand een dubbel bestand dan bestaat de hash al dus hoef je hem niet fysiek dubbel op te slaan, alleen in je db maak je een dubbele verwijzing.

Je filesysteem in je db kan je zo exotisch maken als je zelf wilt ( vb eigen tags /afdelings tags / overall tags filters bijv maken ).
Het ongeorganiseerde zooitje ontkom je niet aan zolang je de medewerkers niet opvoed.

Wat voor mooie technische oplossing je ook wilt maken, het valt of staat altijd bij de gebruikers...

[orf]

Gomez12 schreef op dinsdag 17 februari 2009 @ 22:41:
Upload iemand een dubbel bestand dan bestaat de hash al dus hoef je hem niet fysiek dubbel op te slaan, alleen in je db maak je een dubbele verwijzing.

Je filesysteem in je db kan je zo exotisch maken als je zelf wilt ( vb eigen tags /afdelings tags / overall tags filters bijv maken ).
Het ongeorganiseerde zooitje ontkom je niet aan zolang je de medewerkers niet opvoed.

Wat voor mooie technische oplossing je ook wilt maken, het valt of staat altijd bij de gebruikers...

Dubbele bestandsnamen is een lastig iets. In veel gevallen betekent een dubbele bestandsnaam niet 2x hetzelfde bestand. Zeker bij fotoalbums heb je te maken met mooie bestandsnamen als SC01.jpg.

Ook wil ik proberen de fysieke mappen niet té groot te maken, het filesystem wordt daar niet sneller op.

Voor de verschillende modules binnen het CMS (nieuws, agenda, fotoalbums, dossiers, etc) willen we standaard al mappen gaan aanmaken. Wanneer je vanuit een module iets gaat uploaden, wordt dan als default al de juiste map geselecteerd. De gebruiker is daarna wel vrij om alsnog ervoor te kiezen naar een andere map te uploaden.

[CrisT]

orf schreef op woensdag 18 februari 2009 @ 10:05:
[...]


Dubbele bestandsnamen is een lastig iets. In veel gevallen betekent een dubbele bestandsnaam niet 2x hetzelfde bestand. Zeker bij fotoalbums heb je te maken met mooie bestandsnamen als SC01.jpg.

Ook wil ik proberen de fysieke mappen niet té groot te maken, het filesystem wordt daar niet sneller op.
...

dubbele bestandsnamen check je niet, je checkt de hash van de bestanden. En die garanderen toch redelijk uniekheid (collisions daargelaten, maar die kans is te verwaarlozen)

[orf]

CrisT schreef op woensdag 18 februari 2009 @ 10:21:
[...]


dubbele bestandsnamen check je niet, je checkt de hash van de bestanden. En die garanderen toch redelijk uniekheid (collisions daargelaten, maar die kans is te verwaarlozen)

Hmm, inderdaad; dat had ik zelf ook moeten kunnen bedenken. Thanks

[Nick_S]

orf schreef op woensdag 18 februari 2009 @ 10:05:
[...]
Ook wil ik proberen de fysieke mappen niet té groot te maken, het filesystem wordt daar niet sneller op.

Dan kun je op basis van de hash een aantal subdirectories aan maken, bv.:

/{hash.charAt(0)}/{hash.charAt(1)/{hash}

Volgens mij levert dit wel een redelijk eerlijke verdeling op qua bestanden per map en heb je maximaal 16 mappen per directory. Bij 2 levels zit je bij 100.000 afbeeldingen op gemiddeld 400 afbeeldingen per map, bij 3 levels zijn dit er zelfs maar 25.

[F_J_K]

Pas op: een te verwaarlozen kans is groter dan 0 en een expres een niet-0 kans inbouwen op het publiceren van, in plaats van het bedrijfslogo pak-em-beet de prive-foto's van de vrouw van de directeur, lijkt me geen goede strategie..

Schijfruimte is niet snel een probleem, vindbaarheid is dat veel meer. En dan is opleiden van de gebruiker linksom of rechtsom nodig. Wel een hash gebruiken om het de gebruiker te laten weten dat het bestand er waarschijnlijk al staat en dan voorstellen die versie te gebruiken is wat anders. Maar dan moet je er weer wel aan denken wat er moet gebeuren als er een nieuwe versie komt van het bestand: dat zal zeker niet altijd automatisch op alle plaatsen moeten vervangen. En dan moet je dus een OK vragen van alle 'eigenaren' van de plaatsen waar het koppelde document is gezet.

---

orf schreef op dinsdag 17 februari 2009 @ 22:32:
Geen suggesties voor een andere structuur dan mappen met bestanden? Ik vind dat we nog iets teveel in hokjes denken en uitgaan van het gebruikelijke (een Windows verkenner achtige interface). Wellicht zijn er betere opties.

Je moet vooral niet allemaal extra handelingen moeten verrichten bij het uploaden van een bestand, maar je wilt ook niet een ongeorganiseerd zooitje.

Ik zeg niet dat je 'fysieke' mappen moet willen, ik zeg dat je uit een beperkte set van standaardmetadata kunt selecteren. Als je maximaal 1 veld toestaat levert dat inderdaad een directorystructuur op, maar er is geen reden om dat niet een paar velden toe te staan. Maar 'te publiceren' bestandsnaam los zien van de fysieke bestandsnaam is idd handig en dat maakt iets als Nick_S in "Bestandsbeheer in een CMS" ook lekker makkelijk.

En dat kan best handig zijn: een plaatje is bijv. zowel 'vogel' als 'marketinglogo'.

offtopic:
Nick_S: de combi van underscores en Terry Pratchett levert je een boel bonuspunten \o/