Welcome! Log In Create A New Profile

Advanced

[PHP] Swiftlet is quite possibly the smallest MVC framework you'll ever use.

Posted by Elbert F 
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
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 <[email protected]>

> 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
>
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
flowcharthttp://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
<[email protected]>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 <[email protected]>
>
>> 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
>>
>
>
On Mon, Feb 13, 2012 at 09:24:38AM +1100, Elbert F wrote:

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

I didn't look thoroughly at your code (though, if the respondent's
perceptions were correct, I'd have to agree with his prescriptions for
improvement). But I wanted to make a comment about autoloaders, since
you mentioned it.

My philosophy, since autoloading was introduced, was that it was a cool
way to avoid having a lot of complicated file inclusion calls all over
the place. Just tell the autoloader function where different types of
files were located, and then just instantiate classes as you like. Easy.

But I recently did some work for one of these companies with a million
file internally developed framework. And at the top of each file, they'd
include a require_once() (or similar) call for each of the files which
would be called if you needed to instantiate a class from any of those
files. So rather than putting all the magic in an autoloader function,
they'd simply include the file where they knew it would be needed.
(E.g., you know you're going to be calling your Date class in this file,
so you put a require_once() call to the file that contains it at the top
of this file.)

The more I've thought about it since then, the more I've considered it a
Good Thing(tm). It makes troubleshooting existing code a whole lot
easier. I don't have to wonder what the autoloader is doing or where the
files are, on which the current file depends. It sort of obviates the
autoloader stuff, but I'd rather do that than spend hours trying to
track down which file in which directory contains the class which paints
the screen blue or whatever. (Yes, I'm aware that require_once()
introduces some latency.)

Just something to consider.

Paul

--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, Feb 12, 2012 at 11:36 PM, Paul M Foster <[email protected]> wrote:
> The more I've thought about it since then, the more I've considered it a
> Good Thing(tm). It makes troubleshooting existing code a whole lot
> easier. I don't have to wonder what the autoloader is doing or where the
> files are, on which the current file depends. It sort of obviates the
> autoloader stuff, but I'd rather do that than spend hours trying to
> track down which file in which directory contains the class which paints
> the screen blue or whatever.

Yeah, this is the sort of problem better handled by a tool than
switching away from autoloaders.

Exuberant Ctags is your friend.

--
Benjamin Hawkes-Lewis

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Hi, Paul

I personally pretty much like the idea of auto-loaders, but that's a
personal point of view.
If you have always develop with scripts having autoloaders you'll hate to
write a *require_once* command at the beginning of all files. And what
would a dependency-injection-container be without an autoloader ;)
http://www.slideshare.net/fabpot/dependency-injection-with-php-53

If you write your code in OOP you should always have unique class-names. If
you follow this and use a good naming-convention both ways should be
usable. I prefer to use autoloaders, you maybe not and that makes code so
personalized ;) *like-it*

Bye
Simon

2012/2/13 Benjamin Hawkes-Lewis <[email protected]>

> On Sun, Feb 12, 2012 at 11:36 PM, Paul M Foster <[email protected]>
> wrote:
> > The more I've thought about it since then, the more I've considered it a
> > Good Thing(tm). It makes troubleshooting existing code a whole lot
> > easier. I don't have to wonder what the autoloader is doing or where the
> > files are, on which the current file depends. It sort of obviates the
> > autoloader stuff, but I'd rather do that than spend hours trying to
> > track down which file in which directory contains the class which paints
> > the screen blue or whatever.
>
> Yeah, this is the sort of problem better handled by a tool than
> switching away from autoloaders.
>
> Exuberant Ctags is your friend.
>
> --
> Benjamin Hawkes-Lewis
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
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 <[email protected]>

> 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 flowcharthttp://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 ToroPHPhttp://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 <
> [email protected]> 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 <[email protected]>
>>
>>> 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
>>>
>>
>>
>
On Mon, Feb 13, 2012 at 09:01:03AM +0100, Simon Schick wrote:

> Hi, Paul
>
> I personally pretty much like the idea of auto-loaders, but that's a
> personal point of view.
> If you have always develop with scripts having autoloaders you'll hate to
> write a *require_once* command at the beginning of all files. And what
> would a dependency-injection-container be without an autoloader ;)
> http://www.slideshare.net/fabpot/dependency-injection-with-php-53

I wrote a quite solid dependency-injector one time, and used it for a
while. But it introduced a certain opacity into my code that I didn't
like very much, and I ultimately abandoned it, even though it worked
quite well.

It's kinda like in C. If I want to use the strchr() function, I know I'd
better do an #include <string.h> to get that functionality. I can't just
assume all the library functions are all just there, waiting for me to
use them. While I've often complained about having to include those
header files to get to those functions, I still prefer having those
"include" calls obviously staring at me at the top of my files. I don't
have to *assume* it's there somewhere. I can see it right there, and it
comforts me.

Maybe all this is my "C" upbringing....

Paul

--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login