PHPHulp Framework
Ik zat net is te denken, misschien is het leuk om een eigen phphulp framework te schrijven met wat phphulp leden. Puur voor educatieve doeleinden, maar natuurlijk ook dat phphulp leden deze kunnen gebruiken.
Het voordeel is dat er altijd mensen zijn die er veel van weten en dus vragen makkelijk kunnen beantwoorden. Ik denk ook dat veel leden er veel van zullen leren, door alleen maar te volgen wat er allemaal gebeurd zonder er zelf mee aan te helpen.
Of het haalbaar is weet ik niet, maar het is het proberen waard.
Zijn er met mij nog mensen met animo voor zo'n project of ben ik de enige...
Laat maar weten.
Schrijf eens een tut over een framework, dat kan een leuke toevoeging zijn voor phphulp.
Het is zeker weten een leuk idee, een soort van OpenSource idee, waarbij iedereen iets kan schenken en alleen echte kenners het kunnen goedkeuren (of een soort van Wikipedia idee). Ik het wel animo voor zo'n project, maar ik heb gewoonweg geen tijd voor zo'n (groot) project. En ik denk dat er wel meerdere mensen geen tijd hebben... of wel wes :P
pgFrank schreef op 26.03.2008 17:12:
Waarom niet leren werken met bv. symfony of Zend Framework? Die worden ook professioneel toegepast, daar scoor je bij het zoeken van een baan of klanten meer punten mee.
Omdat soms juist het uitdenken van de structuur het leuke is van het maken van een framework. Okee, het staat niet stoer op je CV, maar dat wordt ook niet verplicht van een hobby. Je hoeft niet altijd te denken in centjes :)
Het lastige van een framework (maken) is dat je constant moet kiezen tussen features en gemak. Wil je alles aanpasbaar maken, of ga je voor de conventie boven configuratie, en verplicht je de gebruikers ervan problemen op precies deze ene manier op te lossen. Zend = features en configuratie, CakePHP is conventie & gemak. Voor beiden is wat te zeggen, en de keuze is persoonlijk. Daarom is het lastig lijkt mij om met anderen een evenwicht te vinden. De een wil wat meer features, de ander wat meer simpelheid. Je kan bijvoorbeeld een hele hiërarchie van objecten & interfaces maken, om het zo mogelijk te maken ieder object te kunnen vervangen en de werking iets te kunnen aanpassen. Zo heb je wel veel controle, maar het kost ook veel code, en de code wordt ingewikkeld. Als je die hele hiërarchie toch eigenlijk altijd maar voor 1 ding gebruikt, kan je ook een hele lading klassen overboord gooien om het te versimpelen. Maar dan is er minder configuratie, minder mogelijkheden.
Desalniettemin is en blijft het een leuk idee, omdat iedereen zijn vaardigheden dan weer wat opschroeft en het biedt een kans om iets te verwezenlijken met samenwerking. En stel dat we het project van start laten gaan, hoe doen we dan de organisatie. Een CSV omgeving opstellen zou een optie kunnen zijn. Maar je kunt dan niet garanderen dat iedereen ook wel na een wat langdurigere periode dezelfde animo (lees: het enthousiasme erin houden) heeft.
niet om het tot een functioneel eind te brengen, er zijn er genoeg die goed werken, maar als project voor iedereen op phphulp die het leuk vind.
natuurlijk zijn er genoeg mensen die meer dan genoeg te doen hebben, of nog een andere serie projecten om van te leren op de wachtlijst hebben staan(ik hoor bij die laatste)
vraag is natuurlijk: hoe zet je het op zodat iedereen zijn steentje bij kan dragen, maar dat het geen zooi word.
ik denkt dat voor een gezamenlijk script een oop ding het beste is, zodat iedereen zijn eigen classen kan maken, zonder de rest te slopen.
maar als je nou in de scriptlib een categorie zou maken voor de framework.
dan maak je zeg maar de 'core'
dat is dan een ding dat bestanden in een map include en waar je met call_user_func ofzo dan weer dingen me kan doen.
dat zegmaar de core verplicht is, en verder kan je alles uit die categorie in een map gooien en vervolgens gebruiken.
zoiets als het plugin systeem van wordpress...
zo kan iedereen klungelen wat hij wil, en de gebruiker de 'plugins' zoeken die hij handig vind.
opzich lijkt het mij wel cool om het compleet uit plugins te laten bestaan, en dan later misschien eens standaard bundeltjes te maken van de beste en meest belangrijke plugins ofzo...
maar misschien is dat ook wel weer een heel slecht plan, ik weet het niet.
Om zo'n project te laten werken moet je namelijk afspraken maken en als iedereen (of een grote groep) mensen toegang tot de code heeft is er altijd wel iemand die even snel iets toevoegt zonder zich aan deze afspraken te houden. Ook zullen er beslissingen genomen moeten worden over bijvoorbeeld de implementatie (waar Jelmer ook al op wees), ga je voor functionaliteit of gebruiksgemak? (er van uitgaande dat dit een keuze is).
Is het onderdeel dat iemand (of een groepje) maakt, dan wordt het opgenomen in de niet-voor-iedereen toegankelijke repository waar altijd werkende code in staat. Die is te downloaden door iedereen, en die werkt. Daar zorgen de beheerders van die repository voor. En die beheerders kies je weer uit op basis van kennis en bijdrage. Als iemand veel succesvolle onderdelen heeft bijgedragen is het handig om hem toegang te geven tot de werkende repository zodat hij zijn eigen fouten kan verbeteren. (... en de andere beheerders niet de diffs voor hem hoeven toe te passen)
De open repository is dan echt voor de community. De beheerders van de repository met een werkend geheel en beperkte toegang zullen waarschijnlijk iets intiemer zijn aangezien zij ervoor moeten waken dat de code in 'hun' repository altijd zal moeten werken en van goeie kwaliteit zal moeten zijn. * Maar ga hier niet in de fout door ze een afgesloten discussieruimte te geven, ze moeten betrokken blijven bij de community en de community bij hun. *
Misschien is het een goeie oefening om van iedere module eerst een API uit te werken, en een beschrijving van wat alle componenten doen. Op basis daarvan kunnen dan eventueel testcases gemaakt worden en ontwerpfouten komen vroeg naar voren. Daarnaast heb je al een beetje een handleiding gelijk, en zie je welke onderdelen je kan hergebruiken die in 1 van beide repositories zit. Let wel dat wanneer de API eenmaal vaststaat het lastig wordt hem te veranderen wanneer andere onderdelen hem gaan gebruiken. Dus vooral daar zit het denkwerk. Misschien is een wiki voor deze ontwerpen wel handig, zodat anderen hun ideeën over de API kunnen toevoegen, zonder lastig te doen met bestanden in de repositories. En er is mooi ruimte voor discussie
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
Jelmer:
Misschien is het een goeie oefening om van iedere module eerst een API uit te werken, en een beschrijving van wat alle componenten doen. Op basis daarvan kunnen dan eventueel testcases gemaakt worden en ontwerpfouten komen vroeg naar voren. Daarnaast heb je al een beetje een handleiding gelijk, en zie je welke onderdelen je kan hergebruiken die in 1 van beide repositories zit. Let wel dat wanneer de API eenmaal vaststaat het lastig wordt hem te veranderen wanneer andere onderdelen hem gaan gebruiken. Dus vooral daar zit het denkwerk. Misschien is een wiki voor deze ontwerpen wel handig, zodat anderen hun ideeën over de API kunnen toevoegen, zonder lastig te doen met bestanden in de repositories. En er is mooi ruimte voor discussie
Bijna gelijk aan mijn idee, alleen is testcases misschien weer net een burg te ver, hierdoor kan het voor veel phphulp bezoekers wel eens te lastig worden en dat zou jammer zijn.
Door een API of een 'proof of concept' te maken kan je goed beslissen of iets geschikt is en kan er toch nog gemakkelijk aan gesleuteld worden.
Ik denk dat dit idee, het platform waarop zo'n soort project gedaan kan worden niet eens zo lastig is op te zetten. Het enige wat je eigenlijk nodig hebt is initiatiefnemers en een server met een wiki en twee SVN-repositories.
Ik denk alleen dat het vooral lastig is het project op te starten, we zitten immers niet allemaal bij elkaar waar we makkelijk kunnen brainstormen etc. Dat maakt communicatie lastiger (niet onmogelijk).
Ik zelf heb wel een aantal keer een framework tot een einde gebracht, het probleem achteraf was alleen altijd dat ik iets gemaakt had wat toch eigenlijk niet helemaal goed was. Daarom denk ik ook dat vooraf vast leggen wat er gemaakt gaat worden erg belangrijk is.
@Jelmer, jij zou eventueel wel willen mee doen? Jou kennis van zaken is denk ik hoger dan die van mij dus dat komt goed uit(A).
Voor mensen in het algemeen, stuur mij een pm als je wel interesse hebt om mee te doen, dan zal ik kijken of er gewoon animo is.
Ik ben (was?) ook al met anderen bezig met een soortgelijk project, maar niemand begint, iedereen wacht op elkaar. Dat is het grote probleem dat we in het begin zullen moeten overwinnen.
Ik heb zelf een redelijk framework nu, al twijfel ik altijd of ik het wel moet gebruiken. Het is vooral gemaakt omdat ik het ontwerpen ervan leuk vind, en op die manier al veel heb nagedacht over problemen als hoever ga je in abstractie, hoe verbind je de onderdelen met elkaar, hoe bouw je een cache op, welke rol krijgt de database etc. Niet dat ik overal een oplossing voor heb, wel argumenten. En ik ben best bereid stukjes code en oplossingen ook in de SVN op te nemen.
Misschien volgen er vanzelf zelfs wel wat tutorials over MVC, OO programmeren, waar je op oet letten etc.
Maar het grootste probleem blijft: wie begint? Als er een repository, wiki en inderdaad ticketsysteem - dat is ook bijzonder handig - is, kom ik vanzelf :P
SVN-Repository: http://svn2.assembla.com/svn/phphulp_framework_core
Trac: http://trac2.assembla.com/phphulp_framework_core
Wiki: http://www.assembla.com/wiki/show/phphulp_framework_core
Om updates te kunnen maken aan svn moet je een login aanmaken bij:
Assembla. En dan invoegen in dit project, dan kan ik je toestemming geven.
Zal dadelijik tweede space opzetten, eerst even eten:).
Gewijzigd op 01/01/1970 01:00:00 door stien ss
het word denk ik inderdaad een probleem om te beginnen.
ik ga nu niet me doen met phpen, maar ik kom wel eens hier langs om wat te praten over het idee, en misschien kom ik later medoen.
het lijkt mij ook wel leuk om een cms te maken, maar dat is voor een andere keer...
of gaat dit project gewoon dood zonder verdere aandacht?
had ik wel verwacht, maar wel jammer...