PHP Framework (was: PHP Templating)

[Alan Smith]

Dinis,

Thanks for brining these things up; I'm glad we're talking about them now.

 

I've spoken with Alexis about the template system and I from what I've read I still believe that is more useful only when you want to allow users or designers without any knowledge of the underlying language to modify it. The main disadvantage I see, although this depends on the framework, is the lack of ability to generate html code to iterate through groups of objects.

I want to stay away from "generators" as much as possible. I worked with CakePHP, and its html generators, for almost a year. There is nothing more frustrating than depending on a generator and discovering it can't do what you want or doesn't handle the data the way you are. Often times hacks were required to get the desired behavior. Many times I found myself ripping out the generator and replacing it with plain html that did what I needed. Why couldn't html have been used the first time around? For example, passing an array to a function to generate a drop-down (a.k.a. select) is only a couple lines short of a foreach loop to do the same thing. And what if you come back later and need to add a class to the options? Well, if it's not supported by the generator you'll have to rip it out and write the html. If you don't want to write html use an editor that can auto-complete or insert snippets. In the end, I've found generators to be more trouble than they're worth.

One thing we might consider is migrating the project to a framework like Yii, CakePHP, or whatever.

I can't discourage the use of CakePHP, in any project, enough. As I said, I worked with it for almost a year and hated it. The "automagic" is truly magic in that you have little control over it. If the magic works the way you want, that's great, but if it doesn't, it's a waste of time to try and mold it to what you're doing.

I have a huge gripe with most frameworks out there: they don't strive for simplicity. A lot give in to the restrictions of php as a language and don't try to find workarounds that truly improve developers' code. Most are bloated, resource intensive, hogs that enforce rules that must be followed or the program won't work properly. A lot of projects would be better off if they didn't use a framework. For example, here is some code in the current AL member system:

$email = FormEmail::find("`name` = '{$name}'", array('limit' => 1));

Does it run? Yes. Could that be run in other php frameworks and get the same result? No (I've only seen one other, very little known, framework that could run that). Is it possible with php? Yes, it's running now on the AL server. Why can't other frameworks do that? Because they don't try hard enough.

Here's the bottom line: if it can be done with less code in regular php, in a way that's not much less readable than a framework, the framework should be avoided.

 

Alan, what's the plan regarding this issue? Maybe start a new thread about the framework and introduce us to the current state of the framework/project? Or will we start from scratch?

The framework used in the current AL system is something I wrote many years ago. It's not up to my current standards so we won't be using that. I don't discourage all use of framework-like libraries. If you have a code-base you're fond of, let me know. However, CakePHP will not even be considered (I know it well, I've hacked in my own additions to the core). If we use a framework it must be flexible and lightweight. If you're going to suggest a framework please come up with a well thought out description of what sets it apart and makes it the best.

We will start from scratch. The current code is outdated and we can do better.

Alan

[Mark Steve Samson]

I tried every Rails-based php framework I could find. Recess, Akelos, maintanable, etc (I never tried CakePHP. Benchmarks were a big turn-off). But after getting comfortable with one, I begin to yearn for flexibility. Like Alan said: if it can be done with less code in regular php, in a way that's not much less readable than a framework, the framework should be avoided. But I guess you develop this kind of thinking if you've learned PHP right from the basics or when frameworks weren't a hype yet. If you think you can do better, you would want something better. It's our knowledge that becomes the benchmark when it comes to choosing a framework to work with. But in reality, the frameworks exist not to impose the right way of doing things but rather the faster way of finishing a project. Right now I've been using Kohana in most of my projects. I agree with most of the conventions and standards they impose and it lets me code faster without getting all over my face. I've also recently settled with the Propel ORM. It's a gem for projects that has a schema that changes alot or if you often move your code from your local server to the remote staging one.

--

Mark Steve Samson

Freelance Web Developer

http://marksteve.me

[Mark Steve Samson]

Oh, sorry for posting in the wrong discussion. I didn't read ahead before I posted that. Anyways, I was looking for the feature list of the panel.

[Alan Smith]

Mark,

I couldn't agree more!

I designed Acorn and Oak to solve the problem of there being no small framework (I prefer "toolkit" when referring to Acorn/Oak) that provided the essentials (mainly models, views, and routing). Those functions are implemented as cleanly and elegantly as I could manage. I tried to keep the lines of code as few as possible while providing a great feature set (e.g. partials are supported).

Alan

[Alexis Métaireau]

Le 10/28/2010 05:52 AM, Alan Smith a �crit :

Alan, have you looked at http://www.pluf.org/ ?
Another question I have is about the usage of PHP: why using PHP and not
another language ?

Alex

[Dinis Lage]

Regarding PHP frameworks, my vote goes for Yii, although Kohana seems pretty similar, but Yii seems to have a slight advantage in performance and seems that IDE integration is slightly better (although atm doesn't work all that well when compared to other languages).

Anyhow, the main reason to use PHP is because it just works anywhere, but with the resources at hand that's not an issue and so I'd vote for both rails or django.

Since we're starting from scratch, we should definitely consider another language. I occasionally work with ruby (and rails) and like it very much. As for Python (and django) never used it but would be very happy to get my hands on it.

Dinis

2010/10/28 Alexis Métaireau <ameta...@gmail.com>

[Alexis Métaireau]

Le 10/28/2010 06:34 PM, Dinis Lage a écrit :
> Anyhow, the main reason to use PHP is because it just works anywhere, but
> with the resources at hand that's not an issue and so I'd vote for both
> rails or django.

Nice.

> Since we're starting from scratch, we should definitely consider another
> language. I occasionally work with ruby (and rails) and like it very much.
> As for Python (and django) never used it but would be very happy to get my
> hands on it.

I'm a python and django dev, but why not having a try on ruby and rails,
if you want.

Any of those two could be really funnier than PHP :)

Alex

[Alan Smith]

Alex,

I had not heard of Pluf but it looks clunky. Also, things are laid out in a confusing way; maybe it'd all make sense if I came from a Django background. Thanks for making me aware of it but we won't be using it; it's too sprawling.

Alan

[Gregory Mendez]

Alan and I discussed languages and frameworks a bit before starting this project. I know we have a lot of members who are familiar with rails and django (and thus python and ruby) since we have been hosting those frameworks for a couple years now, but we felt php might be more accessible simply due to the larger community.

Prior to the current new member system that Alan wrote, we had a project to code the same app in rails. After a couple years we shut down that project. My impression as a non-coder of rails is that you can do simple things very fast and easily, but if you are trying to do anything unique it can be very slow and dirty.

I don't have any experience with django coders, so i don't have any strong opinions on it.

If you guys decide python would be best for this project I'll go along with it, but we had provisionally selected php simply so that we would more easily be able to recruit volunteers.

It is worth noting that this entire project was conceived because we had just added django hosting and wanted to add more python frameworks. We were going to roll out TurboGears and Pylons and found they couldn't run on the same server as Django with our current system. With php the hosting is dead simple and little to no thought needs to be paid to the frameworks used.

-Gregg