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.


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. 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 <
> 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: 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 <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