Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
On Sun, June 26, 2005 12:57 pm, M Saleh EG said: In all the cases if someone thinks a framework is bloated. Should just keep it bloated for him/herself. Programmers, and specially PHP programmers who are the majority of web-programming in IT labor market. So being it bloated for someone or perceived to be bloated has no meaning for some other programmers, unless having the same needs and environment. It's simply a matter of prefrence. Period. By this logic, Windows is not bloated. Q.E.D. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
On Sat, June 25, 2005 7:32 am, Matthew Weier O'Phinney said: * Catalin Trifu [EMAIL PROTECTED] : I also tend to stay away from PEAR, which is kinda bloated for my taste, except the Log package. rant I hear that a lot on this list, and I don't understand the reasoning behind such comments -- perhaps because nobody offers any reasoning, only the opinion? I'm a PEAR user, and I've found the packages anything *but* bloated. Granted, I only use a subset of PEAR, but that subset has made mycoding easier. I use DB, Log, Mail, Mail_MIME, HTML_QuickForm, Cache_Lite, and Pager daily; additionally, we use custom PEAR error handlers to catch errors generated by these packages, log them, and display custom error pages. If I'd had to write the functionality I have readily available in these packages, I wouldn't have a job right now. They've helped me meet numerous deadlines. If somebody could offer some *constructive* criticism of PEAR -- PEAR as it is TODAY, not 3 years ago, when I last tried it -- these comments would have more weight. As it is, I feel they're just FUD based on ignorance. /rant rant When I see some killer feature in PEAR that I think will make up for the *DAYS* of my time that PEAR wasted three years ago, I'll try it again. I remain adamant that PEAR is bloated, has too many internal dependencies, and gives me nothing faster/easier than rolling my own. YMMV /rant :-) I *like* the PEAR guys. I appreciate that they've given some great code that lets people just slap it in and it works. I'm sure some people just LOVE the integrated error handling that silently eats all the errors in PEAR. Maybe they even appreciate that it also eats all the following errors I was sending to the Apache log which I monitored. :-( :-( :-( If that's how you want to build you application, more power to you. *I* don't like to work that way. I will probably continue to boil down my opinion to PEAR is bloated rather than waste time on this list, yet again, provding specific details of my experience. Read the archives if you want detail. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
In general, anyone could then say oh .Net framework, Java framework, CPAN, or then any other full blown frameworks bloated! I believe these kind of posts would not effect noone but it might create a bad perception for the net/platform voyagers! Every framework, be it based on a language or an environment has a flexibility level that could satisfy some segment of programmers, and thus keeping some segments unhappy. It's a matter of prefrence and the kind of functionalities and repositories that a programmer or a team might need. However, a general adjective can not be given just like that without any specification of the matter and why it is said it is in our case Bloated. In all the cases if someone thinks a framework is bloated. Should just keep it bloated for him/herself. Programmers, and specially PHP programmers who are the majority of web-programming in IT labor market. So being it bloated for someone or perceived to be bloated has no meaning for some other programmers, unless having the same needs and environment. It's simply a matter of prefrence. Period. M.Saleh.E.G +97150-4779817
Re: [PHP] Re: PHP web archeticture
On 6/24/05, Joe Muddah [EMAIL PROTECTED] wrote: Thanks a bunch. I have alot of work now ahead of me to decide which framework to use. Any opinions on which one is the best? I've used Mojavi heavily and I dabbled with Binarycloud a bit. I like Ruby on Rails best: http://www.rubyonrails.org/ -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP web archeticture
On Sun, 2005-06-26 at 21:45, Greg Donald wrote: On 6/24/05, Joe Muddah [EMAIL PROTECTED] wrote: Thanks a bunch. I have alot of work now ahead of me to decide which framework to use. Any opinions on which one is the best? I've used Mojavi heavily and I dabbled with Binarycloud a bit. I like Ruby on Rails best: http://www.rubyonrails.org/ I think he's looking for a PHP approach. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP web archeticture
Hi,
I personally use phrame because it's small, pretty fast, easy to setup
and was enough for my needs, although it does not seem to be maintained
anymore.
I think you should choose the one which better suits the needs of your
project.
It's rather hard to say that framework is better than the other.
I also tend to stay away from PEAR, which is kinda bloated for my taste,
except
the Log package.
Other than that, it all comes to project needs, personal choice and testing
for
features, speed, stability and support (if you are interested in such things)
although
tests are not always very concludent since they depend on many factors.
Catalin
Joe Muddah wrote:
Thanks a bunch. I have alot of work now ahead of me to decide which
framework to use. Any opinions on which one is the best?
On 6/24/05, Catalin Trifu [EMAIL PROTECTED] wrote:
Hi,
You can take a look at phrame.sf.net, phpmvc.net, horder.org,
binarycloud.com
adodb.sf.net (for fast db abstraction layer).
Read around and one of those will surely satisfy your needs.
Catalin
Joe Muddah wrote:
I am trying to design a website archeticture. Does anyone have any
links or experience with archetictures that actually work. Any ideas
of how to layout a website would be greatly appreciated.
This is what I am thinking of doing
1)Seperate Logic from presentation
Using Templates (Smarty) for presentation
Using PHP Objects for logic (no echo statements)
2)Use Controllers to bring together logic and presentation
I don't really have an idea yet of how to do this. I am thinking
about having something like a page variable to figure out what
template to output, action variable to figure out what objects are
called (save, delete, etc.). All this would be under a switch
statment. Example:
switch($page){
case UserListPage
if(action==saveUser)
userObject-saveUser(_$POST)
displayTemplate(UserList)
case EmailPage
.
}
Thanks.
j.m.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
* Catalin Trifu [EMAIL PROTECTED] : I also tend to stay away from PEAR, which is kinda bloated for my taste, except the Log package. rant I hear that a lot on this list, and I don't understand the reasoning behind such comments -- perhaps because nobody offers any reasoning, only the opinion? I'm a PEAR user, and I've found the packages anything *but* bloated. Granted, I only use a subset of PEAR, but that subset has made mycoding easier. I use DB, Log, Mail, Mail_MIME, HTML_QuickForm, Cache_Lite, and Pager daily; additionally, we use custom PEAR error handlers to catch errors generated by these packages, log them, and display custom error pages. If I'd had to write the functionality I have readily available in these packages, I wouldn't have a job right now. They've helped me meet numerous deadlines. If somebody could offer some *constructive* criticism of PEAR -- PEAR as it is TODAY, not 3 years ago, when I last tried it -- these comments would have more weight. As it is, I feel they're just FUD based on ignorance. /rant -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association| http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:[EMAIL PROTECTED] | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
On Sat, 2005-06-25 at 10:32, Matthew Weier O'Phinney wrote: * Catalin Trifu [EMAIL PROTECTED] : I also tend to stay away from PEAR, which is kinda bloated for my taste, except the Log package. rant I hear that a lot on this list, and I don't understand the reasoning behind such comments -- perhaps because nobody offers any reasoning, only the opinion? I'm a PEAR user, and I've found the packages anything *but* bloated. Granted, I only use a subset of PEAR, but that subset has made mycoding easier. I use DB, Log, Mail, Mail_MIME, HTML_QuickForm, Cache_Lite, and Pager daily; additionally, we use custom PEAR error handlers to catch errors generated by these packages, log them, and display custom error pages. If I'd had to write the functionality I have readily available in these packages, I wouldn't have a job right now. They've helped me meet numerous deadlines. No matter how many deadlines PEAR helps you meet and how much you may find the PEAR modules indispensable, you are expressing a subjective opinion unrelated to the OP's comment about bloated. A package can be very bloated and still be extremely useful to someone who doesn't have the time or the ability (not to say you don't have the ability) to implement similar functionality themself. Additionally PEAR does present a centralized location for common functionality with good peer review, however IMHO I side with the OP with respect to much of PEAR being bloated. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
* Robert Cummings [EMAIL PROTECTED] : On Sat, 2005-06-25 at 10:32, Matthew Weier O'Phinney wrote: * Catalin Trifu [EMAIL PROTECTED] : I also tend to stay away from PEAR, which is kinda bloated for my taste, except the Log package. rant I hear that a lot on this list, and I don't understand the reasoning behind such comments -- perhaps because nobody offers any reasoning, only the opinion? I'm a PEAR user, and I've found the packages anything *but* bloated. Granted, I only use a subset of PEAR, but that subset has made mycoding easier. I use DB, Log, Mail, Mail_MIME, HTML_QuickForm, Cache_Lite, and Pager daily; additionally, we use custom PEAR error handlers to catch errors generated by these packages, log them, and display custom error pages. If I'd had to write the functionality I have readily available in these packages, I wouldn't have a job right now. They've helped me meet numerous deadlines. It may be my opinion, but I've also given some reasoning for my opinion: help in meeting deadlines, centralized error handling, and variety of packages. I've helped to *qualify* my opinion. I'll do more of that below. No matter how many deadlines PEAR helps you meet and how much you may find the PEAR modules indispensable, you are expressing a subjective opinion unrelated to the OP's comment about bloated. A package can be very bloated and still be extremely useful to someone who doesn't have the time or the ability (not to say you don't have the ability) to implement similar functionality themself. Correct; ability isn't the problem; time often is. aside However, I also find that I start by creating some functionality myself, and then as special cases start popping up, modifying, adding on... and then discovering that an equivalent PEAR package already exists that covers all these special cases and a number I hadn't thought of. (Pager comes to mind). I often wonder if what is meant by 'bloat' is that those claiming 'bloat' feel that the PEAR code covers too many special cases -- cases they have not encountered or do not expect to encounter. Personally, I feel that I'd rather have all my bases covered; I can see a point in wanting to keep code trimmed to the necessary cases, though. /aside Additionally PEAR does present a centralized location for common functionality with good peer review, This is one of the selling points for PEAR; many eyes looking at the code, including people who aren't invested in the particular problem. Having the diversity of reviewers often makes for better code. however IMHO I side with the OP with respect to much of PEAR being bloated. Then explain what you mean by 'bloated'. Just throwing out that phrase doesn't give anybody any extra information -- just your opinion. Can you give some examples to *qualify* your statement that PEAR is bloated? That was the main thrust of my rant -- people throwing out unqualified opinion statements like 'PEAR sucks' or 'PEAR is bloated' without explaining *why*. -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association| http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:[EMAIL PROTECTED] | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
Matthew Weier O'Phinney wrote: I also tend to stay away from PEAR, which is kinda bloated for my taste, except the Log package. rant I hear that a lot on this list, and I don't understand the reasoning behind such comments -- perhaps because nobody offers any reasoning, only the opinion? There is some justification, but as you correctly note, it's mostly based on what PEAR was a few years ago or because of some bad experience with a particular package (often both). I'm a PEAR user, and I've found the packages anything *but* bloated. Part of the perception was that the PEAR base class was a bit bloated, and combined with the poor performance of OO in PHP 4, this did make a noticeable difference in many cases. Luckily, both aspects have been improved. :-) Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
On Sat, Jun 25, 2005 at 10:32:41AM -0400, Matthew Weier O'Phinney wrote: If somebody could offer some *constructive* criticism of PEAR -- PEAR as it is TODAY, not 3 years ago, when I last tried it -- these comments would have more weight. As it is, I feel they're just FUD based on ignorance. The documentation for some of the less well known packages is poor or non-existant, or at least that's what I've always noticed and has been my major bug bear with PEAR for a long time. For example, I want to use the DB_Pager module but there is *no* end user documentation, all I have to work with is some poorly formatted information pulled from the API comments. There are also a lot of packages (again, less well known ones) that haven't been updated in a long time, in some cases several years. I'm not saying that PEAR in general is a stale project, or that it's no good (on the contrary, I use several of the packages on my sites and they're very useful), but I do get the feeling that the non-core packages have been left to rot both in terms of updates and documentation. I've used both PEAR and CPAN for a few years now and I've noticed that CPAN tends to win hands down in terms of documentation and updates. That might just be down to the particular packages I've happened to use but given a choice I know which one I'd rather use. Paul -- Rogue Tory http://www.roguetory.org.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
Paul Waring wrote: I've used both PEAR and CPAN for a few years now and I've noticed that CPAN tends to win hands down in terms of documentation and updates. That might just be down to the particular packages I've happened to use but given a choice I know which one I'd rather use. Yeah, you're basing that on which ones you've used. The interesting thing about CPAN is that it has far more crap than PEAR. This seems to work out well, because the best packages trickle up in terms of reputation. For example, most Perl developers use Test::More to implement their tests, but there is a lot of stuff in CPAN that does the same thing (and outputs a TAP-compliant protocol), and many of them existed before Test::More. PEAR is much more guarded, and it has a higher quality to quantity ratio. This has some advantages. Of course, it also has disadvantages - there will always be complaints about PEAR being political (independent of whether it actually is) by those whose packages don't get accepted. Another problem is stagnant or poor packages that solve an important problem. With CPAN, I can just write a better solution, and if it is actually better, everyone starts using that. With PEAR, I need to try to work with the original author, which might involve enough effort just to make contact that I give up, and the better solution is never developed. It's a risk. Anyway, take what I say with a grain of salt - I have contributed no CPAN or PEAR packages (yet). :-) Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
On Sat, 2005-06-25 at 11:06, Matthew Weier O'Phinney wrote: * Robert Cummings [EMAIL PROTECTED] : On Sat, 2005-06-25 at 10:32, Matthew Weier O'Phinney wrote: * Catalin Trifu [EMAIL PROTECTED] : I also tend to stay away from PEAR, which is kinda bloated for my taste, except the Log package. rant I hear that a lot on this list, and I don't understand the reasoning behind such comments -- perhaps because nobody offers any reasoning, only the opinion? I'm a PEAR user, and I've found the packages anything *but* bloated. Granted, I only use a subset of PEAR, but that subset has made mycoding easier. I use DB, Log, Mail, Mail_MIME, HTML_QuickForm, Cache_Lite, and Pager daily; additionally, we use custom PEAR error handlers to catch errors generated by these packages, log them, and display custom error pages. If I'd had to write the functionality I have readily available in these packages, I wouldn't have a job right now. They've helped me meet numerous deadlines. It may be my opinion, but I've also given some reasoning for my opinion: help in meeting deadlines, centralized error handling, and variety of packages. I've helped to *qualify* my opinion. I'll do more of that below. Your argumentation is flawed, you are using a red-herring technique to justify how PEAR is not bloated by giving examples of its usefulness. I give no argumentation either way as to the usefulness of PEAR. I have used PEAR and continue to use PEAR as I see a need; however, that usefulness has ABSOLUTELY NO BEARING on whether it is bloated or not. Now so far you have said the following: - I use such and such a package in PEAR - I wouldn't have a job if not for PEAR - PEAR has helped me meet deadlines - centralized error handling No matter how many deadlines PEAR helps you meet and how much you may find the PEAR modules indispensable, you are expressing a subjective opinion unrelated to the OP's comment about bloated. A package can be very bloated and still be extremely useful to someone who doesn't have the time or the ability (not to say you don't have the ability) to implement similar functionality themself. Correct; ability isn't the problem; time often is. - ability isn't problem time often is aside However, I also find that I start by creating some functionality myself, and then as special cases start popping up, modifying, adding on... and then discovering that an equivalent PEAR package already exists that covers all these special cases and a number I hadn't thought of. (Pager comes to mind). - pear often already has equivalent code - covers all these special cases I often wonder if what is meant by 'bloat' is that those claiming 'bloat' feel that the PEAR code covers too many special cases -- cases they have not encountered or do not expect to encounter. Personally, I feel that I'd rather have all my bases covered; I can see a point in wanting to keep code trimmed to the necessary cases, though. /aside Additionally PEAR does present a centralized location for common functionality with good peer review, This is one of the selling points for PEAR; many eyes looking at the code, including people who aren't invested in the particular problem. Having the diversity of reviewers often makes for better code. however IMHO I side with the OP with respect to much of PEAR being bloated. Then explain what you mean by 'bloated'. Just throwing out that phrase doesn't give anybody any extra information -- just your opinion. Can you give some examples to *qualify* your statement that PEAR is bloated? That was the main thrust of my rant -- people throwing out unqualified opinion statements like 'PEAR sucks' or 'PEAR is bloated' without explaining *why*. So far all the reasons you've given to indicate why PEAR is NOT bloated have nothing to do with why PEAR is or is not bloated. You have clearly indicated a passion for it, a usefulness from it, even established a decent amount of superiority in it, but if anything your arguments have indicated why it is bloated in many respects: - covers all of these special cases (and by virtue probably more) - I can see a point in wanting to keep code trimmed to necessary cases though - rather have all my bases covered It is my opinion and the opinion of many others that the fact that PEAR covers so many exceptional cases, the fact that PEAR implements such a generalize error handling system, the fact that PEAR do so much generic everything to make everone happy, that these elements that make it so versatile also make it feel bloated. It's like kicking a soccer ball to the goal, but rather than take the most direct route, you take the fringe route to cover all your bases...ultimately this is generally a longer path. Now that I've given examples of why bloated please refrain from giving subjective measurements of gratitude over arguments that
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
* Robert Cummings [EMAIL PROTECTED] : On Sat, 2005-06-25 at 11:06, Matthew Weier O'Phinney wrote: * Robert Cummings [EMAIL PROTECTED] : On Sat, 2005-06-25 at 10:32, Matthew Weier O'Phinney wrote: * Catalin Trifu [EMAIL PROTECTED] : I also tend to stay away from PEAR, which is kinda bloated for my taste, except the Log package. rant I hear that a lot on this list, and I don't understand the reasoning behind such comments -- perhaps because nobody offers any reasoning, only the opinion? I'm a PEAR user, and I've found the packages anything *but* bloated. Granted, I only use a subset of PEAR, but that subset has made mycoding easier. I use DB, Log, Mail, Mail_MIME, HTML_QuickForm, Cache_Lite, and Pager daily; additionally, we use custom PEAR error handlers to catch errors generated by these packages, log them, and display custom error pages. If I'd had to write the functionality I have readily available in these packages, I wouldn't have a job right now. They've helped me meet numerous deadlines. It may be my opinion, but I've also given some reasoning for my opinion: help in meeting deadlines, centralized error handling, and variety of packages. I've helped to *qualify* my opinion. I'll do more of that below. Your argumentation is flawed, you are using a red-herring technique to justify how PEAR is not bloated by giving examples of its usefulness. Actually, my argumentation was not specifically about 'PEAR is bloated', but more along the lines of the many comments I've seen on this list to the effect of 'PEAR sucks'. But I've also seen many comments like the one from Catalin about 'PEAR... is kinda bloated', without indicating why they think so. I should have been more clear in my rant that I'm tired of hearing generalized negative statements against PEAR that are then unqualified (i.e. no substative reasons given). The statement 'PEAR is bloated' doesn't indicate in what way it is bloated. Unfortunately, many read 'bloated' as a negative, and thus as an indication that one should stay away from the code; thus may a developer who has a problem that could be easily solved by PEAR code be turned away from it. Additionally, saying 'PEAR is bloated' doesn't take into account the fact that PEAR is a large group of packages, and that each package within PEAR should be judged on its own. For instance, I've heard and read some good arguments as to why the PEAR package itself is bloated; however, if you've ever taken a look at Cache_Lite, you'd probably agree that it is anything *but* bloated. (The authors of that package put no dependency on PEAR.php, and coded with a goal of efficiency and optimization.) snip Then explain what you mean by 'bloated'. Just throwing out that phrase doesn't give anybody any extra information -- just your opinion. Can you give some examples to *qualify* your statement that PEAR is bloated? That was the main thrust of my rant -- people throwing out unqualified opinion statements like 'PEAR sucks' or 'PEAR is bloated' without explaining *why*. So far all the reasons you've given to indicate why PEAR is NOT bloated have nothing to do with why PEAR is or is not bloated. You have clearly indicated a passion for it, a usefulness from it, even established a decent amount of superiority in it, but if anything your arguments have indicated why it is bloated in many respects: - covers all of these special cases (and by virtue probably more) - I can see a point in wanting to keep code trimmed to necessary cases though - rather have all my bases covered It is my opinion and the opinion of many others that the fact that PEAR covers so many exceptional cases, the fact that PEAR implements such a generalize error handling system, the fact that PEAR do so much generic everything to make everone happy, that these elements that make it so versatile also make it feel bloated. It's like kicking a soccer ball to the goal, but rather than take the most direct route, you take the fringe route to cover all your bases...ultimately this is generally a longer path. And, as I said, I can completely see your point. But, as noted above, saying PEAR gives a false impression that *all* code in PEAR is bloated, which is simply not the case. On the other hand, you've also given a very nice overview of *why* people feel some code in PEAR is bloated -- which is what I've been driving at. You've qualified the statement, and that's worth much more than simply tossing the phrase off. Thank you! I guess the moral of the story is: we now have a thread we can point to that shows some of the arguments for why some consider code in PEAR bloated, but also that : * bloat != lack of usefulness. * not all code in PEAR is bloated Thanks for your responses, Rob. -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
* Paul Waring [EMAIL PROTECTED] : On Sat, Jun 25, 2005 at 10:32:41AM -0400, Matthew Weier O'Phinney wrote: If somebody could offer some *constructive* criticism of PEAR -- PEAR as it is TODAY, not 3 years ago, when I last tried it -- these comments would have more weight. As it is, I feel they're just FUD based on ignorance. The documentation for some of the less well known packages is poor or non-existant, or at least that's what I've always noticed and has been my major bug bear with PEAR for a long time. Indeed, the DocBook requirement for PEAR documentation is a major issue even with PEAR developers. For example, I want to use the DB_Pager module but there is *no* end user documentation, all I have to work with is some poorly formatted information pulled from the API comments. Just an FYI: Use the Pager package instead. Under doc/Pager/examples in your PEAR directory is a Pager_Wrapper.php script that shows how to use it easily with DB. Pager, unlike DB_Pager, is well documented. There are also a lot of packages (again, less well known ones) that haven't been updated in a long time, in some cases several years. I'm not saying that PEAR in general is a stale project, or that it's no good (on the contrary, I use several of the packages on my sites and they're very useful), but I do get the feeling that the non-core packages have been left to rot both in terms of updates and documentation. This is an issue I've seen PEAR attempt to address this past year through the introduction of its QA team. But the process is still far from tuned. The above are *great* examples of why people might not choose PEAR -- and constructive ones at that. Thanks. I've used both PEAR and CPAN for a few years now and I've noticed that CPAN tends to win hands down in terms of documentation and updates. That might just be down to the particular packages I've happened to use but given a choice I know which one I'd rather use. Ah, a fellow perl developer! CPAN is, for me, *the* reason to code in perl. The perl culture is one that includes testing and documentation as the norm -- and that has made for a solid library in CPAN. However, the TIMTOWDI principle also means that forking is a foundation principle. This can be seen as either a pro or a con: pro, in that you have choice in what module to use; con, in that you then have to evaluate a number of modules. After having said that, though, I'll continue coding PHP anyday! -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association| http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:[EMAIL PROTECTED] | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
Matthew Weier O'Phinney wrote: The perl culture is one that includes testing and documentation as the norm You might be interested to know that there is a PHP equivalent for Test::More, the CPAN library that prompted the testing revolution that Perl seems to have undergone in the past five years or so. It is packaged as a standard part of Apache-Test (which now has support for testing PHP applications): http://search.cpan.org/dist/Apache-Test/ Hope that helps. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
I don't think a lot of people think tat PEAR sucks, we are all, as a community, just looking for ways to make it better. C On 6/25/05, Chris Shiflett [EMAIL PROTECTED] wrote: Matthew Weier O'Phinney wrote: The perl culture is one that includes testing and documentation as the norm You might be interested to know that there is a PHP equivalent for Test::More, the CPAN library that prompted the testing revolution that Perl seems to have undergone in the past five years or so. It is packaged as a standard part of Apache-Test (which now has support for testing PHP applications): http://search.cpan.org/dist/Apache-Test/ Hope that helps. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
Hi, I feel like I should answer your anger towards my opinion. First of all I consider PEAR to be bloated for the following reasons; it's a large library, it tries to cover a very general approach and please 99% of case one may encounter. It's exception system is overused and the overhead of it is not to be disregarded. Granted, PHP5 brings PEAR into a new light with it's new object model, but till recently, php4 was in place and it's object model made big class libraries quite a problem. Let's not forget there are few out there using php5 in production. I, for one, prefer to use highly specialezed libraries, which are designed for one purpose only and which are carefully coded to achive that purpose with maximum efficiency and as less overhead as possible. I think PEAR is a very good class library and it's code is very nice and well thought. I use the Log package of PEAR, which does not depend on the PEAR core and I am very happy with it. I don't deny it's usefullness nor do i contest it in any way, I simply prefer a different approach when building a project. If I were to compare PEAR with another well known library from the C++ world I would compare it with MFC and if I am to choose between smaller, leaner and meaner PHP libraries over PEAR then I will choose them just as I would choose ATL/WTL over MFC. It can be that development time may be a bit longer but the code quality will be better in my opinion and I for one value more code quality over a few hours of extra time. Btw! I do keep an eye on PEAR as I do on many other PHP libraries and I do monthly research about what's new and noteworthy in the PHP world. For example, when the issue of using a database layer and a templating engine came into the big picture, I tried both PEAR::DB and ADOdb as I tried PEAR::HTML_* and Smarty. I decided to use ADOdb and Smarty because they were smaller and faster. My decision was based on personal experience and not influenced by opinions expressed by others; of course I did take the time to see what others have to say but the decision was mine to make. I may as well have been wrong in making that decision but for now I am quite happy with it and I don't consider switching to PEAR as a better alternative. Catalin P.S. Please forgive me if my opinion offended you in any way. Matthew Weier O'Phinney wrote: * Catalin Trifu [EMAIL PROTECTED] : I also tend to stay away from PEAR, which is kinda bloated for my taste, except the Log package. rant I hear that a lot on this list, and I don't understand the reasoning behind such comments -- perhaps because nobody offers any reasoning, only the opinion? I'm a PEAR user, and I've found the packages anything *but* bloated. Granted, I only use a subset of PEAR, but that subset has made mycoding easier. I use DB, Log, Mail, Mail_MIME, HTML_QuickForm, Cache_Lite, and Pager daily; additionally, we use custom PEAR error handlers to catch errors generated by these packages, log them, and display custom error pages. If I'd had to write the functionality I have readily available in these packages, I wouldn't have a job right now. They've helped me meet numerous deadlines. If somebody could offer some *constructive* criticism of PEAR -- PEAR as it is TODAY, not 3 years ago, when I last tried it -- these comments would have more weight. As it is, I feel they're just FUD based on ignorance. /rant -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Module testing; WAS Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
* Chris Shiflett [EMAIL PROTECTED] : Matthew Weier O'Phinney wrote: The perl culture is one that includes testing and documentation as the norm You might be interested to know that there is a PHP equivalent for Test::More, the CPAN library that prompted the testing revolution that Perl seems to have undergone in the past five years or so. It is packaged as a standard part of Apache-Test (which now has support for testing PHP applications): http://search.cpan.org/dist/Apache-Test/ I've seen you mention Apache-Test before, but I didn't realize that it had integrated PHP testing in it. Looks interesting. I've actually been using phpt tests for a number of months now, and find them very well suited for most tasks I throw at them (typically API testing). However, I could see Apache-Test being useful for full application testing. Thanks for pointing this out! -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association| http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:[EMAIL PROTECTED] | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Stop spreading PEAR FUD; WAS Re: [PHP] Re: PHP web archeticture
* Colin Ross [EMAIL PROTECTED] : I don't think a lot of people think tat PEAR sucks, we are all, as a community, just looking for ways to make it better. I don't think a lot of people think it sucks; it's just that I often see statements on this list like 'PEAR sucks' or 'PEAR is bloated' without the authors of said statements offering any reasons why they think so. I wanted to address these reasons, instead of just letting the comment slide on by this time. -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association| http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:[EMAIL PROTECTED] | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP web archeticture
* Joe Muddah [EMAIL PROTECTED]: I am trying to design a website archeticture. Does anyone have any links or experience with archetictures that actually work. Any ideas of how to layout a website would be greatly appreciated. This is what I am thinking of doing 1)Seperate Logic from presentation Using Templates (Smarty) for presentation Using PHP Objects for logic (no echo statements) 2)Use Controllers to bring together logic and presentation I don't really have an idea yet of how to do this. I am thinking about having something like a page variable to figure out what template to output, action variable to figure out what objects are called (save, delete, etc.). All this would be under a switch statment. Example: shamelessSelfPromotion I'm the author of the PHP port of Perl's CGI::Application, Cgiapp.class.php (http://cgiapp.sourceforge.net/). Cgiapp is designed for exactly the usage you present above. It is a lightweight, abstract Controller class upon which you build your application class. All screens are handled as 'run modes', and each run mode is a method in the class. Templates are used by default, with Smarty being the default engine, though the template methods may be easily overridden to accomodate other template engines (several users indicate they use it with Savant). Additionally, it's built to allow the creation of reusable, customizable web applications. Your libraries can be placed in one location, and then instance scripts in your document root may customize the behaviour of the application through parameters passed to the constructor. I've used it on two of the sites below, garden.org and nationalgardenmonth.org, both of which get very high traffic. Additionally, I've used it on a client site for a Fortune 100 company. It's robust and tested. If you give it a whirl and have questions, feel free to email me directly. /shamelessSelfPromotion -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association| http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:[EMAIL PROTECTED] | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP web archeticture
Hi,
You can take a look at phrame.sf.net, phpmvc.net, horder.org, binarycloud.com
adodb.sf.net (for fast db abstraction layer).
Read around and one of those will surely satisfy your needs.
Catalin
Joe Muddah wrote:
I am trying to design a website archeticture. Does anyone have any
links or experience with archetictures that actually work. Any ideas
of how to layout a website would be greatly appreciated.
This is what I am thinking of doing
1)Seperate Logic from presentation
Using Templates (Smarty) for presentation
Using PHP Objects for logic (no echo statements)
2)Use Controllers to bring together logic and presentation
I don't really have an idea yet of how to do this. I am thinking
about having something like a page variable to figure out what
template to output, action variable to figure out what objects are
called (save, delete, etc.). All this would be under a switch
statment. Example:
switch($page){
case UserListPage
if(action==saveUser)
userObject-saveUser(_$POST)
displayTemplate(UserList)
case EmailPage
.
}
Thanks.
j.m.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP web archeticture
Thanks a bunch. I have alot of work now ahead of me to decide which
framework to use. Any opinions on which one is the best?
On 6/24/05, Catalin Trifu [EMAIL PROTECTED] wrote:
Hi,
You can take a look at phrame.sf.net, phpmvc.net, horder.org,
binarycloud.com
adodb.sf.net (for fast db abstraction layer).
Read around and one of those will surely satisfy your needs.
Catalin
Joe Muddah wrote:
I am trying to design a website archeticture. Does anyone have any
links or experience with archetictures that actually work. Any ideas
of how to layout a website would be greatly appreciated.
This is what I am thinking of doing
1)Seperate Logic from presentation
Using Templates (Smarty) for presentation
Using PHP Objects for logic (no echo statements)
2)Use Controllers to bring together logic and presentation
I don't really have an idea yet of how to do this. I am thinking
about having something like a page variable to figure out what
template to output, action variable to figure out what objects are
called (save, delete, etc.). All this would be under a switch
statment. Example:
switch($page){
case UserListPage
if(action==saveUser)
userObject-saveUser(_$POST)
displayTemplate(UserList)
case EmailPage
.
}
Thanks.
j.m.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP web archeticture
On Fri, 2005-06-24 at 23:41, Joe Muddah wrote: Thanks a bunch. I have alot of work now ahead of me to decide which framework to use. Any opinions on which one is the best? InterJinn of course. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
