[UPHPU] PHP Framework Project Launch - Coders welcome to attend

Lonnie Olson fungus at aros.net
Thu Jun 2 12:08:08 MDT 2005


On Jun 2, 2005, at 10:40 AM, John David Anderson wrote:
> One of the problems with some frameworks is that you have to write  
> a kabillion configuration files and register actions and forms...  
> (*cough* struts *cough*) and the work in setting up the framework  
> ends up being more than if you just wrote everything from scratch,  
> not to mention the hit the system takes in keeping track of  
> everything. I really like lightweight and atomic.

I agree.  An amazing example of this is Horde.  It is a total PITA to  
get setup.

> Awesome idea - I'd like to define my DB structure, and have PHP  
> classes (with get and set methods) and DB tables automatically  
> generated and tied to the DB abstraction layer of my choice. Form  
> generators and validation rules could then be added to any data  
> object class you wanted.

I dislike get and set methods, they just add unnecessary complexity  
to something that is often not needed.

I don't want to have to support *any* Db abstraction layer.  I will  
support ONE db abstraction layer.  I highly prefer Pear::DB.  If we  
start adding capabilities to support more our project will turn into  
another PITA craptastic framework.

> Many frameworks use Smarty or another engine - I'd recommend  
> following this trend. Partly because I already know and like  
> Smarty, but I think re-creating the presentation layer could be a  
> lot of work.

I highly dislike Smarty.  PHP can in itself be a presentation layer,  
and still be separate from the logic of the site.  Why bother  
learning a whole new template language when we already know a good  
one (PHP).  And again, I do not want to support many template  
engines, only one.  I will bend to the will of the group and use  
Smarty, if we implement some kind of page caching as well.

> Sorry to be another monkey wrench thrower (especially because I  
> wasn't at the meeting), but my vote is for PHP 5, too. I think if  
> we write it with the fading version in mind, we'll just want to  
> redo it in the near future. I really want to get in the habit of  
> using Exceptions and some of the OOP magic of PHP 5, and a project  
> that forces me to work in PHP 5 would be a great way to dive in.
>
> If we decide PHP4, though I'm totally cool with that. I think  
> either way is really workable.

Well I was at the meeting and we initially decided on using PHP4 due  
to global compatibility, but after hearing all the arguments about  
PHP5 here, I have changed my mind.  We should use PHP5.

Upgrading to incompatible versions is always a "chicken and the egg"  
kind of problem.  No one writes apps in PHP5 until servers support  
it, but servers don't support it until people write the apps.  This  
is entirely my issue.  I haven't upgraded my servers because I have  
so many people using old crappy PHP4 code that would break.

So I think we should just make the jump to PHP5 anyway.  It is good  
motivation to upgrade our servers and applications.  If we do choose  
PHP5, I will personally commit to building a special PHP5 server to  
be an option for ArosNet customers to prove that I will put my money  
where my mouth is.

--lonnie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2482 bytes
Desc: not available
Url : http://uphpu.org/pipermail/uphpu/attachments/20050602/44a0f0e1/smime.bin


More information about the UPHPU mailing list