Welke folder structuur / layout gebruiken jullie en waarom?

[xces]

Beetje een algemene topicnaam. Ik merk dat ik de laatste jaren zo nu en dan switch van folderstructuur;

De ene keer gebruik ik een dergelijke structuur
- /img/home
- /css/home
- /js/home
- /php/home
- /inc/home

dus voor iedere 'pagina' als er voor dat onderdeel een include is zet ik dat in de resp. folder. Dit is voornamelijk gebaseerd op Smarty, want Smarty wil dat je tpl en PHP kunt scheiden. Als je echter 'onderdelen' van websites wilt kopieeren kun je beter een dergelijke structuur aanhouden

- /.../home/css
- /.../home/img
- /.../home/js
- /.../home/php
- /.../home/inc

Dus alles van 1 pagina bij elkaar gegroepeerd.

Nu zijn er meer wegen die naar Rome leiden, en zo heb je bijv. ook het Zend Framework wat een folderstructuur adviseert, maar wat gebruiken jullie eigenlijk, en vooral, waarom dat?

[Bosmonster]

Per pagina indelen is sowieso nogal raar, aangezien je heel veel elementen van verschillende pagina's kunt hergebruiken.

Je kunt assets beter op type organiseren (zoals visuals, backgrounds, etc)

En als je zoveel CSS/JS hebt dat je dat in mappen wilt gaan onderverdelen denk ik dat je eens moet kijken of je dat aantal niet kan verminderen. Een bestand per pagina is ook daar redelijk onzinnig gezien het mogelijke hergebruik.

[ Voor 38% gewijzigd door Bosmonster op 13-04-2010 09:53 ]

[xces]

Hmm, goed punt.. Zelf ben ik aan het denken aan onderstaande opzet;

code:

website/_inc         : basiscode welke door meerdere website gebruikt kan worden
- website/_inc/js
- website/_inc/css
- website/_inc/img
- website/_inc/php
website/cache        : minified JS/CSS/thumbnails e.d.
website/php          : php code
website/theme        : theme afhankelijke code zoals img/js/css etc.?
website/tpl          : templates voor specifieke pagina code
website/upload       : upload map voor CMS
website/webstat      : webalizer

edit: Ik minify al mijn CSS & Javascript (on the fly, indien gewijzigd), dus er is per pagina (in de HTML naar de client gestuurd) maar 1 CSS en 1 JS file. Zodoende heb ik volledige vrijheid in het bewerken, als ik save en upload zal er automatisch een nieuwe minified versie worden gecreeerd.

[ Voor 21% gewijzigd door xces op 13-04-2010 09:58 ]

[mithras]

Haal sowieso je serverside code uit je webroot. Nu kan je allerlei zaken opvragen die je helemaal niet wilt serveren. Onze applicaties zien er altijd zo uit:

/
  application/
    configs/
    controllers/
    models/
    views/
    application.php
  library/
    My/
    Custom/
  public/
    index.php
    styles/
    scripts/
    images/

Je kan alleen op de index.php uitkomen welke direct doorverwijst naar application.php. Binnen de applicatie staat alle website-specifieke code. Reusable code staat in een library. De public bevat alleen de bestanden welke echt via de webserver benard moeten worden. Als de server een keertje plat ligt heb je niet al je broncode op straat liggen.

[MueR]

Wij houden ongeveer deze structuur aan:

code:

/assets            Content images, attachments enzo hier
/cache              Duidelijk, dicht via htaccess
/static            Layout spul:
  /images            Background images, logos, icons etc
  /scripts          Javascripts
  /styles            Stylesheets
/system            Codebase, dicht via htaccess
  /admin              Zie map "site" (incl submappen)
  /classes          Algemene classes binnen ons framework, wat submappen voor de uitgebreide libraries als db classes
  /functions          Algemene functies binnen ons framework
  /site             Site
    /classes          Site specifieke classes
    /functions      Site specifieke functies
    /handlers        Controllers
    /postbacks      Controllers voor POST requests
    /templates      Templates

[AtleX]

/
+---non-www
|   +---engine
|   +---frameworks
|   +---libs
|   \---templates
\---www
    +---css
    +---images
    \---js

non-www bevat dus de files die niet via HTTP opvraagbaar dienen te zijn, deze worden indien mogelijk buiten de webroot geplaatst en anders via een .htaccess afgeschermd. In www staan alle javascript- & css-bestanden en afbeeldingen, deze zijn dus wel publiekelijk toegankelijk.

[Noxious]

Mijn indeling is vrijwel altijd zo:

code:

/var/www/vhosts/domein.nl/web/_images
                             "_includes
                             "_css
                             "_js
                             "_swf

                         "scripts/cron

                         "mail/user1
                              "user2

                         "logs/access.log
                              "error.log

[xces]

mithras schreef op dinsdag 13 april 2010 @ 10:02:
Haal sowieso je serverside code uit je webroot.

Hmm, als het gaat om Ruby code kan ik dat nog begrijpen, maar als je een website structuur hebt van bijv.
.../www/www.website.nl/ = public
.../www/sub.website.nl/ = public

Wat zou je in het geval van een PHP website buiten de web-root dan willen hebben, buiten bijv. config files met wachtwoorden?

[MoietyMe]

Wij hebben alles zo staan:

/root
- css (alle css-bestanden)
- images (alle plaatjes)
- scripts (alle js-bestanden)
- templates (een include voor de css/js dingen als de footer etc.)
- mme (CMS)

[mithras]

xces schreef op dinsdag 13 april 2010 @ 10:54:
[...]

Hmm, als het gaat om Ruby code kan ik dat nog begrijpen, maar als je een website structuur hebt van bijv.
.../www/www.website.nl/ = public
.../www/sub.website.nl/ = public

Wat zou je in het geval van een PHP website buiten de web-root dan willen hebben, buiten bijv. config files met wachtwoorden?

In shared hosting omgevingen (en op een dedicated server richten we het op eenzelfde manier in) heb je in de "user" folder deze structuur: domains/mijn.domein.nl/public_html/
Dus zit er een laag tussen de folder van de domein en de webroot. Daar zetten we dan de application + library in

Daarnaast is de applicatie geschikt om als multidomain-cms te dienen. Dan heb je dus in je root (naast de domain folder) de library en application staan. Dan staat op domains/mijn.domein.nl/ nog wat extra's qua website specifieke configuraties. En dan in de webroot de index.php. Zo heb je meerdere domeinen (en dus websites) die beheerd worden vanuit een applicatie

[Mr. Dean]

Zelf gebruik ik de volgende structuur:

code:

/root
 - /css/ -alle css files
 - /js/ -alle javascripts
 - /images/ -alle plaatjes
 - index.html
 - pagina.html

Als ik php gebruik wil ik 'js' nog wel inwisselen voor 'scripts', maar dat komt zelden voor.

[Noxious]

Ik hoop niet dat je echt alles in /root zet Mr. Dean

[xces]

@Mithras; nu ga ik zelf redelijk off-topic, maar 'zelf' heb ik het zo ingericht;
/hosting/home/<user>/
/hosting/home/<user>/logs/
/hosting/home/<user>/cgi-bin/
/hosting/home/<user>/certs/
/hosting/home/<user>/www/
/hosting/home/<user>/www/sub.domein.nl/
/hosting/home/<user>/www/www.domein.nl/

Apache en het filesystem zijn zo ingericht dat iedere website ook onder rechten van <user> draait, dus wat dat betreft is er geen 'apache' user die overal bij kan.

Misschien zou het beter zijn om te gaan naar een volgende structuur:
Buiten het feit dat ik dan mijn logs, certificates en cronjobs per (sub)domein kan groeperen zie ik niet veel voordelen, of zie ik wat fundamenteels over het hoofd? Mijn mail draait overigens op een externe server:

/hosting/home/<user>/
/hosting/home/<user>/sub.domein.nl/certs/
/hosting/home/<user>/sub.domein.nl/cgi-bin/
/hosting/home/<user>/sub.domein.nl/logs/
/hosting/home/<user>/sub.domein.nl/public/
/hosting/home/<user>/www.domein.nl/certs/
/hosting/home/<user>/www.domein.nl/cgi-bin/
/hosting/home/<user>/www.domein.nl/logs/
/hosting/home/<user>/www.domein.nl/public/

Structuur php website op een shared hosting omgeving:
Door jullie beredeneringen ben ik tot de volgende structuur gekomen voor een php website welke op een shared hosting omgeving draait, zonder dat ik verder de apache structuur ga omgooien. Wat vinden we hiervan?

code:

/_/                 : basis 'layout map' welke door meerdere sites gebruikt kan worden
    /js/
    /css/
    /img/
    /php/
    /tpl/ (??)
/cache/             : minified JS/CSS/thumbnails e.d.
    /gfx/
        /header/
        /menu/
        /thumb/
    /minify/
    /mailing/
    /tmp/
/layout/            : layout afhankelijke bestanden zoals img/js/css etc.?
    /js/            : Javascript files
    /css            : Stylesheets
    /img/           : Afbeeldingen
    /php/           : PHP code, af te schermen dmv htaccess
    /tpl/           : Templates
/upload/            : upload map voor CMS
/webstat/           : webalizer
index.php           : controller file welke de benodigde bestanden include

[ Voor 50% gewijzigd door xces op 13-04-2010 12:40 ]

[ZpAz]

code:

.htaccess
index.php
/application
    bootstrap.php
    /config
        /application.ini
        /config.ini
    /controllers
    /layouts
    /models
    /views
/library
    /Zend
    /ZendX
/public
    /css
        style.css
        ie[x].css
    /images
    /js
        /jquery
             /plugins

Zo ongeveer.

Alles naar index.php wat geen bestaand bestand is, alles dichttimmeren behalfe public en index.php evt een /upload en /cache er bij.

[ Voor 210% gewijzigd door ZpAz op 13-04-2010 12:42 ]

[xces]

sterker nog, ik kan alles dichttimmeren behalve de cache map, public/images en index.php
Ik minify namelijk mijn CSS en Javascript, dus die worden vanuit cache/minify geserved.

[MueR]

En wat schiet je daar mee op? Zolang directory indexes uit staan zou ik niet alles gaan dichttimmeren. Directory met code, uiteraard. De rest: live and let live hoor.

[xces]

goed punt, scheelt weer.

[Verwijderd]

Voor men hobby websites gebruik ik meestal volgende structuur

code:

/
- /_css/            : css bestanden
- /_js/         : javascript bestanden
- /_images/     : afbeeldingen
    - /_layout/     : afbeeldingen ~ onderdelen van de layout (background images, borders, ...)
    - /_content/    : afbeeldingen ~ images die te maken hebben met content
    - /_icons/      : afbeeldingen ~ icoontjes zoals arrows, bullets, ...
    - /_silk/       : afbeeldingen ~ silk icons (http://www.famfamfam.com/lab/icons/silk/)
- /_cache/          : cache files
- /_includes/       : php ~ includes
- /_lib/            : php ~ base code & functies, ...
- /_templates/      : php ~ html templates (header, footer, ...)
- /_modules/        : php ~ de website/pagina's zelf maar dan zonder mod_rewrite voor de SEO

Uiteraard zitten hier de nodige .htaccess bestanden bij om bepaalde directory's & bestanden te beschermen tegen ongewenste bezoekers & bots

De underscore voor elke folder is een bewuste keuze om zelf wat meer overzicht te houden in men code en soms ook wel handig om snel even een find / replace te doen

[xces]

Kim, ik snap je underscore niet, want als je die overal gebruikt is het nut een beetje ... weg..

[moozzuzz]

Ik kom (als hobbyist) op een soortgelijke structuur uit als de andere hobbyisten alleen gebruik ik geen underscore maar een getal wat makkelijker sorteert :^p

code:

/01static/
/02dynamic/
/03pix/
/04..../

[Verwijderd]

moozzuzz schreef op dinsdag 13 april 2010 @ 16:42:
Ik kom (als hobbyist) op een soortgelijke structuur uit als de andere hobbyisten alleen gebruik ik geen underscore maar een getal wat makkelijker sorteert :^p

code:

/01static/
/02dynamic/
/03pix/
/04..../

Wow, back to BASIC

[Verwijderd]

xces schreef op dinsdag 13 april 2010 @ 15:18:
Kim, ik snap je underscore niet, want als je die overal gebruikt is het nut een beetje ... weg..

ergens wel ja ... het is maar hoe je het bekijkt ...

Nu ik gebruik in hoofdzaak meuk: Notepad++ 5.6.8 & web developer toolbar voor het ontwikkelen / debuggen en als ik dan op zoek ben naar iets vind ik de underscore net handig, ook omdat je in je code soms tags of syntax hebt met bijna identieke woorden background-image, include(), ..., voor mij is het dan net een hulp & verduidelijking zodat ik weet waar ik mee bezig ben. Ik ben dan ook iemand die eerder visueel ingesteld is, als ik dus door men code snel wil scrollen ... ik betrap me er dan ook soms op dat ik meer tijd in naamgeving, uitlijning, ... van men code steek dan in de functionaliteit zelf

[joint_me]

pff, daar ga ik me niet mee bezig houden

We hebben gekozen voor framework Rails en die komt met een folder structuur, niet moeilijk doen gewoon die aanhouden.

[Cartman!]

moozzuzz schreef op dinsdag 13 april 2010 @ 16:42:
Ik kom (als hobbyist) op een soortgelijke structuur uit als de andere hobbyisten alleen gebruik ik geen underscore maar een getal wat makkelijker sorteert :^p

code:

/01static/
/02dynamic/
/03pix/
/04..../

En wat heeft dat voor praktisch nut dan?

edit: jammer dat hier dan weer niet op geantwoord wordt

[ Voor 7% gewijzigd door Cartman! op 18-04-2010 15:48 ]