Hi Simon, Moving the set_error_handler to index.php gives the developer the ability to remove it before pushing the site to a production environment. I agree that in most cases you don't want the live site to fail completely when it trips over an unset variable but I prefer to have it on by default to encourage good habits. Moving the autoloader as well is a good idea but I'd need a copy of the function wherever I bootstrap Swiftlet (e.g. tests). It doesn't seem worth the trouble to avoid two require statements. Plugins are quite simple and can indeed extend anything, including other plugins. Elbert http://swiftlet.org > Hi, Elbert > > I personally would remove the set_error_handler completely. This is a > configuration that the administrator has to handle himself. In a > development-env they want to see all errors, warnings etc, yes - even a > strict_notice. But in a production-env they dont want to show anything to > the user - just show a general error if something really heavy happened. > You can put that in the index.php but I'd wrap it in comments or remove it. > > In my opinion it's a good idea to move the autoloader into the index.php. > Then you can even call your app class using the autoloader ;) > > I'm just curious what exactly you want to try with the plugins ... Should > they simply be extensions or also possibilities to extend other plugins? I > also wrote my own framework 3 years ago and was more about making things > way more complex than they could be just to think about maximum flexibility > .. > > I pretty much also like the no-config part. > http://en.wikipedia.org/wiki/Convention_over_configuration > > > Bye > Simon > > 2012/2/12 Elbert F <info@xxxxxxxxxxx> > >> Hi Simon, >> >> I think you're right that I may be abusing the constructor a bit. I'm >> going to follow your suggestion and split it up into smaller functions. I'm >> also thinking of moving the set_error_handler and spl_autoload_register >> functions to index.php where Swiftlet is bootstrapped so they can be >> changed. >> >> You make another good point about the model; it's never supposed to access >> the controller or view. I updated the code to reflect this. It should work >> like your second flowchart< http://betterexplained.com/wp-content/uploads/rails/mvc-rails.png>(perhaps with the added concept of plugins, which can hook into anything). >> >> Symfony's routing is nice, many smaller frameworks take a similar approach >> (e.g. Sinatra <http://www.sinatrarb.com/> and ToroPHP<http://toroweb.org/ >). >> However, I like the fact that Swiftlet requires no configuration. Just drop >> in your class and it works. The file structure and classes already do a >> good job describing themselves. >> >> Excellent feedback, thanks! >> >> Elbert >> >> >> >> On Sun, Feb 12, 2012 at 10:53 PM, Simon Schick < >> simonsimcity@xxxxxxxxxxxxxx> wrote: >> >>> Hi, Elbert >>> >>> I've looked through the code and found it quite tiny :) I like that. >>> >>> Until now I found some things that I'd like to discuss with you: >>> >>> In the class App you're doing all the stuff (routing, calling the >>> constructor aso) in the constructor. Would it not be better to have >>> separate functions for that? I like the way I learned from using Java: The >>> constructor is only for initializing the variables you need to execute the >>> other functions of this class. >>> Of course you can have a function that then calls all those small >>> functions and maybe directly return the output. >>> >>> I dislike the way you treat with the model .. currently it gets the >>> controller, the view and the app itself. If you ask me the model only needs >>> some configuration. I cannot come up with an idea where you'd need more >>> than a connection-string and some additional settings. The model has >>> several methods to gather the data that has been requested and gives it >>> back. If you'd ask me, there's no need for interaction with the app, >>> controller or view. >>> >>> I'd like to see an option for the router like the one I've seen in >>> symfony2 ... that was quite nice .. There you can define a regexp that >>> should match the called url, some variables that should be extracted from >>> that and some default-variables. It's quite hard to explain in the short >>> term, but take a look at their documentation: >>> http://symfony.com/doc/current/book/routing.html >>> >>> I'd like you to create a small workflow what your framework is doing in >>> which order. Your framework to me looks like this image: >>> http://imageshack.us/f/52/mvcoriginal.png/ But I'd rethink if this >>> structure would give you more flexibility: >>> http://betterexplained.com/wp-content/uploads/rails/mvc-rails.png >>> >>> I hope you got some input here you can work with. I'd like to hear your >>> feedback. >>> >>> Bye >>> Simon >>> >>> >>> 2012/2/12 Elbert F <info@xxxxxxxxxxx> >>> >>>> I'm looking for constructive feedback on Swiftlet, a tiny MVC framework >>>> that leverages the OO capabilities of PHP 5.3. It's intentionally >>>> featureless and should familiar to those experienced with MVC. Any >>>> comments >>>> on architecture, code and documentation quality are very welcome. >>>> >>>> Source code and documentation: http://swiftlet.org
