Delicious Framework

  • Beste ictscripters,


    Ik ben al een tijdje bezig met een framework en nu is de eerste versie af. Nu vroeg ik me af of jullie deze willen testen, dit gaat met name om de routing en installatie op de server omdat ik hier de meeste problemen verwacht. Verder verwacht ik zoveel mogelijk kritiek + feedback om het te verbeteren!


    Linkje naar mijn Git-project


    Ter info omdat de README nog niet af is:
    Het framework is alleen voor php 5.3 of hoger!
    De public_html map is de ROOT van je webserver, de inhoud moet je plaatsen in je public_html of www map dit is per server verschillend.
    De library map één map onder de public_html zodat het hetzelfde is als de huidige structuur, deze is dus NIET via de URL te benaderen.


    Let op! deze versie bevat nog geen resources alleen een kleine hello world applicatie...


    Huidige bugs:
    Geen bugs


    Alvast bedankt!


    Met vriendelijke groet,


    Michael

    Dit was mijn spreekbeurt, zijn er nog vragen?

    Bewerkt 2 keer, laatst door M.Beers ().

  • Wat je met de error logs heb gedaan is leuk, maar noem dit niet echt een framework omdat je error reporting en een auto-load erin hebt gezet. beetje zonde om het te plaatsen als je alleen nog de "Hello World" hebt.

  • Tredgy De resources komen in de volgende versie, eerst moet dit goed getest worden zodat het werkt op meerder servers ;)
    Verder maak ik nu 1 topic aan die ik gewoon bump zodra er een nieuwe versie komt stuk efficiënter denk ik zo.


    Maargoed bedankt voor het testen alvast, ik ga nu beginnen met resources als de database, modellen, templates, sessions, security etc.


    Edit:


    Update aan het framework gedaan:
    05-08-2013 - Resource loader toegevoegd
    05-08-2013 - Basis view class toegevoegd


    Coming up next:
    - Basis caching
    - Template + layout class
    - Database class
    - ORM class (Object-relation mapping)

    Dit was mijn spreekbeurt, zijn er nog vragen?

    Bewerkt één keer, laatst door M.Beers ().

  • Ik heb op GitHub zojuist je project bekeken. Enkele dingen vallen mij op:
    - Je begint je class JavaDoc altijd met de naam van de class. Dit is overbodig, exporteer de JavaDoc maar eens met PHPDoc.
    - Je hebt common functies. Waarom zitten deze functies niet in de correcte classes?
    - Je gebruikt een underscore als prefix voor private (en protected?) velden. Waarom doe je dat? Heeft het echt toegevoegde waarde?
    - Meerdere classes zijn singletons in je framework. Negen van de tien keer heb je singletons helemaal niet nodig. In jouw geval denk ik ook niet. Singletons hebben veel nadelen.
    - Waarom is een Controller een ResourceLoader? Die link zie ik niet, volgens mij is dat een fout in je architectuur.


    Ik zie overigens wel dat je niet maar zo iets doet, en wel degelijk kan programmeren. Doe je ook een opleiding zoals Informatica of hobby je alleen?


    De beste toevoeging die je naar mijn mening kunt doen, is dependency injection. Dat maakt het hele boeltje een stuk overzichtelijker.

  • Je begint je class JavaDoc altijd met de naam van de class. Dit is overbodig, exporteer de JavaDoc maar eens met PHPDoc.
    Hier heb ik nog geen prioriteit aan gesteld dus word later gewijzigd :) evengoed bedankt voor de opmerking.


    Je hebt common functies. Waarom zitten deze functies niet in de correcte classes?
    Geen idee eigenlijk, momenteel nog niet echt naar gekeken omdat deze geen prioriteit hadden en simpel te vervangen zijn.


    Je gebruikt een underscore als prefix voor private (en protected?) velden. Waarom doe je dat? Heeft het echt toegevoegde waarde?
    Is natuurlijk geen toegevoegde waarde, meer een herkenningspunt voor mezelf en niet echt storend ofzo.


    Meerdere classes zijn singletons in je framework. Negen van de tien keer heb je singletons helemaal niet nodig. In jouw geval denk ik ook niet. Singletons hebben veel nadelen.
    Dit zijn momenteel 2 classes, hier heb ik voor gekozen omdat je deze echt maar 1x gebruikt binnen het hele framework, namelijk de URL Request en de Routing van de URL Request. Hier heb ik een tijd over getwijfeld dus ik ga dit nog herzien.


    Waarom is een Controller een ResourceLoader? Die link zie ik niet, volgens mij is dat een fout in je architectuur.
    Momenteel is dit nog apart omdat ik misschien ook mijn basis Model toegang wil geven tot de Resources vandaar een extensie met een Resourceloader.


    Verder doe ik een informatica opleiding, net het 2e jaar pas. Wat wordt er met dependency injections bedoelt, interfaces enzo?

  • Aha, op welke hoge school zit je?


    Dependency injection staat in principe los van het gebruik van interfaces. Misschien kun je wat rond kijken op het internet voor informatie? Mocht je er vragen over hebben hoor ik het natuurlijk graag.


    Goed dat je de feedback positief oppakt!

  • Aha, ik ben zelf bijna klaar en zit op de HAN. Over twee weekjes studeer ik als het goed is af. :)


    Dependency injection houdt in dat alle benodigde dependencies voor een class worden ingeladen door een dependency injection container. In jouw geval maakt je Dispatcher bijvoorbeeld gebruik van het Request object. Je zou dan in je code de dispatcher opvragen uit de context, bijvoorbeeld:


    PHP
    $context->getObject('Dispatcher');


    De dispatcher heeft vervolgens de volgende constructor:


    PHP
    class Dispatcher {
    
    
      private $request;
    
    
      public function __construct(Request $request) {
        $this->request = $request;
      }
    }


    De context zorgt er vervolgens zelf voor dat de Dispatcher de Request binnen krijgt. Dit is denk ik iets de eenvoudig uitgelegd, maar ik zal wellicht volgende week wel eens een DI container in elkaar prutsen in PHP.


    In Java zijn verschillende (goede) voorbeelden te vinden zoals Spring Context, Google Guice en PicoContainer.

  • Stefan.J Ik heb inmiddels een PDF gelezen van Fabien Potencier (maken van Symfony) 104 pagina's, alleen ik snap het niet echt...
    Hoe zorg ik bijvoorbeeld dat ik die resources kan aanroepen zonder dat ik telkens een nieuwe container hoef te maken want dat is toch t voordeel om je overhead te beperken...

  • Ik heb onze Fabien even opgezocht, en ik vind wel dat hij een sterk artikel heeft gelezen over DI: http://fabien.potencier.org/ar…t-is-dependency-injection


    Had je dat al gelezen? Want het legt het basisprincipe goed uit. Zo eenvoudig als mogelijk, zonder alle poespas, waar ik nu mee aankom. :)


    Stel je voor, je hebt de volgende classes:



    Dan moet je nu voor het maken van A-object, ook een B- en C-object maken. Een van de voordelen van een DI container, is het volgende. Ik heb zojuist een context geschreven, en die kan al het volgende:


    PHP
    $context = new Context();
    $a = $context->load('A');
    $a->hello();


    Dat is hip hé? Ik vraag om een instantie van A, en vanzelf zoekt de context de juiste classes op die A nodig heeft, en maakt ze voor mij aan. De context, die nog veel te simplistisch is, ziet er nu als volgt uit:



    Het wekt nu allemaal nog veel te automagisch, en de performance is waarschijnlijk ook als een bad-eend, maar dat is wel op te lossen.


    Helpt dit een beetje?

  • Als het goed is moet de onderstaande classe een hoop doen... mits ik het goed begrepen heb ;) dit is voor setter/getter injections dan...


    Dit was mijn spreekbeurt, zijn er nog vragen?

    Bewerkt 2 keer, laatst door M.Beers ().

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!