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


> 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
> 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
> ..
> I pretty much also like the no-config part.
> http://en.wikipedia.org/wiki/Convention_over_configuration
> Bye
> Simon
> 2012/2/12 Elbert F <i...@elbertf.com>
>> 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.
>> 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
>> the controller or view. I updated the code to reflect this. It should
>> like your second flowchart<
with the added concept of plugins, which can hook into anything).
>> Symfony's routing is nice, many smaller frameworks take a similar
>> (e.g. Sinatra <http://www.sinatrarb.com/> and ToroPHP<http://toroweb.org/
>> However, I like the fact that Swiftlet requires no configuration. Just
>> 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 <
>> simonsimc...@googlemail.com> 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:
>>> constructor is only for initializing the variables you need to execute
>>> 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
>>> 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
>>> 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 <i...@elbertf.com>
>>>> 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

Reply via email to