Wat hoort bij wat... ?
Ik wil graag wat meer duidelijkheid zodat ik mijn directorystructuur kan optimaliseren.
Ik denk dat je grofweg 3 "secties" hebt waar alle code onder valt:
1. framework (alles wat met het framework te maken heeft)
2. beheer/cms (alles wat met het cms te maken heeft)
3. frontend (alles wat met de "voorkant" van de website te maken heeft)
Iedere sectie heeft dan weer z'n eigen controllers, models, views enz.
Wat ik graag wil weten is het volgende:
Van de onderstaande zaken is het heel duidelijk dat ze bij het framework horen:
- een Session class
- een Router
- een Request class
- een FrontController
Vraag 1)
Maar waar hoort nu bijvoorbeeld een login module bij, of een gallery module (die plaatjes toont)?
Deze kun je zowel aan de backend als de frontend gebruiken. Vrij algemeen dus. Zouden die dan thuishoren onder de noemer "framework", of kan ik beter een algemene module directory (library met modules) maken die zowel door frontend als backend gebruikt kan worden? Moet ik bijvoorbeeld nog een sectie "4. algemeen" maken?
(Ik wil het graag even simpel houden en daarom aub even geen verwijzingen naar bestaande frameworks, maar puur een antwoord vanuit jullie eigen gedachtengang: hoort een login / gallery module onder het kopje "framework", "beheer/cms", "frontend" of "algemeen"?)
Vraag 2)
Zijn er überhaupt modules die je alleen aan de backend (cms) kant gebruikt, of juist alleen aan de frontend kant??? Als ik bijvoorbeeld denk aan een banner module, dan heeft deze (denk ik) 2 hoofdfuncties. Enerzijds gebruik je deze module in de backend (cms) om de juiste banners in te voeren / activeren. Anderzijds gebruik je deze module om de juiste banners aan de frontend (op de website) te tonen. Valt zo'n bannermodule dan onder het kopje "beheer/cms" of onder het kopje "frontend", of zou je 'm in een algemene map moeten plaatsen? Of nog gekker, moet ik een aparte "banner frontend module" maken en een aparte "banner backend module"?
Wie kan wat duidelijkheid scheppen?
Gewijzigd op 10/01/2013 01:33:31 door Ozzie PHP
Quote:
Vraag 1)
Maar waar hoort nu bijvoorbeeld een login module bij, of een gallery module (die plaatjes toont)?
Maar waar hoort nu bijvoorbeeld een login module bij, of een gallery module (die plaatjes toont)?
Nou, ik ben niet zo filosofisch ingesteld, maar doe toch een poging. :)
Een framework is je tool waarmee je applicaties bouwt.
Dus als ik voor een framework kies, dan doe ik dat om zo min mogelijk te hoeven doen om mijn probleem op te lossen.
Dus als ik een login systeem in mijn applicatie zou moeten nemen, dan ga ik kijken in mijn tool (lees framework) zitten daar elementen in die ik daarvoor moet gebruiken.
Immers, als dat niet het geval is, waarom zou ik überhaupt dan een framework gebruiken.
Dat is stukken sneller gemaakt in good old plain php of functioneel php.
Goed, voor de die hard OO'ers kun je misschien het argument gebruiken het moet te hergebruiken zijn.
Kan ook, in plain php word dat een grote vergaarbak aan chaos.
Daar zijn we denk ik het wel over eens.
Dus stel we zouden iets van MVC gebruiken, dan kan dat met de logincontroller, loginmodel, loginview te kopiëren al een stuk schelen als je het wil gebruiken in een andere applicatie.
Dan hebben ze ook nog modules uitgevonden.
Dat is eigenlijk in mijn optiek je MVC idee nog slimmer indelen van je onderdelen.
Je zou het zo kunnen maken, mits daarvoor je framework is ingericht om in 1 map modules/login je MVC door te trekken. Dat is nog handiger, want dan is het 1 mapje login in je nieuwe applicatie mikken en je bent klaar.
Ikzelf ben op dit moment een webhosting controlpanel aan het bouwen.
Wat daarin voor mij het aller belangrijkste is, is dat het veilig is.
Nou zit er in het framework wat ik gebruik een soort van session systeem waar ik zo mijn vraagtekens bij zet.
Anders gezegt, het is 'Kom Uit Tilburg' :)
Is dan het hele framework slecht? nee hoor, want wat we niet hebben of gebruiken bouwen we toch wat anders voor. Dat kan immers. Er is niemand die zal zeggen dat dit slecht is.
Met 1 session_start() in de index.php waar het hele systeem start, en met 1 session_controller extend op de andere controllers was mijn probleem opgelost.
Heb ik modules nodig? zou niet weten waarom.
Immers de hele applicatie word eenmalig gebruikt met als doel de user hun webhosting te beheren .
Als het geheel af is, en bedenk me om bijvoorbeeld iets van een optie te geven om bijvoorbeeld iets van wordpress automatisch te laten installeren.
Dat is niet zo zeer iets wat in een controlpanel gedaan hoeft te worden, dus zou ik dat als een module kunnen aan kunnen bieden. Zo blijft mijn applicatie in takt, en mocht het controlpanel ooit bij een ander terecht komen, dan kan die deze uitbereiding evt. erbij nemen of niet. :)
Een CMS kan je ook op basis van je framework bouwen.
Je kan ook kiezen voor een bestaand CMS systeem en dit implementeren in je applicatie.
Dan zal je dus op de een of andere manier dit samen moeten laten werken met je framework.
Nogmaals, hoe je je applicatie indeelt, welke naam je er aan geeft, en als laatste hoe je je mappen structuur opzet, is totaal niet van belang.
Als jij zelf of als je met anderen samen werkt moet het alleen duidelijk zijn hoe je het maakt.
Ook de benaming frontend en backend zijn denk ik niet zoals het in het algemeen word gezien.
Een redenatie van frontend zou kunnen zijn dat is wat er uiteindelijk in mijn view gebeurd.
De backend handelt het af.
Je kan ook redeneren, backend is mijn cms systeem, het frontend is het gene wat de gebruikers zien.
Niemand kan voor jou beslissen hoe het beestje bij naam word genoemd. Dus het is nooit fout.
Als jij het zelf maar snapt, en evt. je klanten kan uitleggen hoe jou systeem werkt.
Ward van der Put op 10/01/2013 08:11:35:
Ozzie, er schuilt een verborgen aanname in je vraag: de fysieke directory- en bestandsstructuur zou moeten overeenkomen met de logische structuur. Daar kun je vraagtekens bij zetten.
@Ward: kun je misschien wat duidelijker uitleggen wat je bedoelt te zeggen? Ik proef uit jouw opmerking dat je mijn structuur niet vindt kloppen, maar je geeft vervolgens niet aan hoe jij het zelf zou doen...
@Bart: dankjewel voor je uitgebreide reactie!!! Dat waardeer ik zeer. Ik kom er ook steeds meer achter dat iedereen het op z'n eigen manier doet. En dat ga ik dus ook maar eens doen ;)
Maar wat ik me bijvoorbeeld afvraag... wat is nu precies een "framework". Moet je een framework zien als een verzameling van alle "technische" zaken die je nodig hebt om een website te kunnen bouwen? Denk bijv. aan een router, een session manager, een frontcontroller, een request class enz. Óf, is een framework breder dan dat, en bevat een framework bijvoorbeeld ook allerlei handige modules, zoals een bannermodule, een nieuwsbriefmodule, een loginmodule enz. Kortom, wat is eigenlijk een framework?
(Oh ja, ik ga alles zelf maken. Ik werk dus niet met een bestaand framework.)
Gewijzigd op 10/01/2013 14:17:07 door No One
Zoals ik al zei, ga ik alles zelf maken... maar ik moet alleen een beetje doorkrijgen wat bij wat hoort. Stel we nemen het voorbeeld van een loginmodule. Moet ik het dan (bijvoorbeeld) zo zien dat de loginmodule bij het CMS hoort. Deze loginmodule heeft een eigen controller, model en view... maar maakt daarnaast gebruik van bestanden (database, sessie e.d) uit het framework. Zou je dat zo kunnen zeggen?
En nog een tweede vraag: als je een module hebt die banners toont, dan heeft die (denk ik) 2 hoofdtaken. Enerzijds moet je via de CMS de juiste banners kunnen plaatsen. Anderzijds moeten op de website zelf de juiste banners getoond worden. Je hebt dus zeg maar een "backend" gedeelte (het invoeren van de banners) en een "frontend" gedeelte (het tonen van de banners op de website). Stop je dit allemaal in één en dezelfde module? Of stop je dit in 2 modules? Eentje voor de backend en een voor de frontend?
en je vraag 2: dat kun je helemaal zelf verzinnen...je zou zeggen het hoort allemaal bij elkaar..dus bij elkaar...je zou ook kunnen zeggen, de module code voor het CMS wil ik in mapje CMS en de module code voor de frontend in mapje frontend...tis net wat je wil...het is jouw framework, je moet gewoon doen wat je zelf het prettigste vind bij bijvoorbeeld onderhoud en uitbreidbaarheid..
Gewijzigd op 10/01/2013 14:39:54 door No One
Applicatie specifieke code is dan alles wat je niet perse nodig hebt als je een applicatie wilt. Denk hier bijv. aan een ApplicatieModule, AdminModule, GuestbookModule, ect. Sommige van deze modules, zoals de AdminModule, zul je in bijna al je applicaties gebruiken, toch is het niet de basis van elke applicatie.
Resteert er nog steeds één vraag die ik al eerder stelde. Als je een bannermodule hebt, dan heb je een admin deel waarmee je de juiste banners kunt uploaden en activeren. En je hebt een frontend deel, waarmee de juiste banners op de website worden getoond.
Nu is mijn vraag... hoort dit bij elkaar? Zit dit in één en dezelfde module, of is het beter om dit te scheiden in een admin en frontend module?