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

Mac Newbold mac at macnewbold.com
Thu Jun 2 13:02:51 MDT 2005


Today at 12:27pm, John David Anderson said:

> On Jun 2, 2005, at 12:08 PM, Lonnie Olson wrote:
>> I dislike get and set methods, they just add unnecessary complexity to 
>> something that is often not needed.
>
> I like them because they are a way to centralize your application's access to 
> a certain set of data. If I want to change the way a person's birthdate is 
> displayed, its easier to change a single get rather than tracking down 
> accesses in other places. I can see how this could totally be personal 
> preference, though.

That's where I'd use a function for formatting my dates. The internal 
representation won't change, just the way they get displayed on the site, 
so any time I want to print it, I'd use the format function instead of a 
"get" func.

>> 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.
>
> Maybe we can just have an interface-like class that allows you to do whatever 
> you want.
>
> I like Pear::DB too, but I'm trying out adodb on a new project. Its supposed 
> to be faster. (http://phplens.com/lens/adodb/)

Speed of our database abstraction is probably largely irrelevant, unless 
one is horribly bad. The speed of your queries and of your database itself 
will make a much bigger difference overall.

I also agree with fungus, though. We should pick one and use it. End of 
story.

>> 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.
>
> Again, a good case for allowing people to do the presentation however they 
> want. In defense of Smarty, however, it has some nice features that have saved 
> me time, and the 'language' you have to learn is trivial.

I'm with fungus on this one. The "language" may be trivial, but why write 
all your pages twice? Why have to manage twice as many files? Why another 
layer of something that can go wrong or slow you down or break things? It 
is, in my opinion, unnecessary complexity that we don't need to add. 
Fungus is absolutely right: PHP _was_ designed to be able to let you mix 
and separate app logic, display logic, and presentation however you see 
fit. Without an extra layer or an extra language.

Mac

--
Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/



More information about the UPHPU mailing list