Frameworks and IDEs

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
Jorge
Forum Newbie
Posts: 14
Joined: Tue Mar 21, 2006 8:36 pm

Frameworks and IDEs

Post by Jorge »

Hello all!

I'm currently under the planning and research stage of a year long web application project that will be, eventually, implemented in php. Being a fourth year Software Engineering student I'm familiar with designing and architecting robust and reliable systems. Implementation wise I am epxerienced with J2EE technology in a struts approach and integrating mostly any Apache Group Project technology.

The project's main topic is that of data management, data retrieval from various sources, data cleasing/scrubbing, staging and sharing.

Now, initially I thought I'd work with J2EE and struts, something I know very well. But discussions with the project's clients, consultants and stakeholders have favoured php technology for various justifyable reasons which I will not get into. The Phrame php Framework follows the struts approach I'm familiar with but I rather favour something totally new. Sticking to one approach all the time isn't good for experience. :)

Anyhow, I've been researching php web application frameworks that offer the following "functionalities":
- Small Learning Curce (Overall, I'm not familar with php. I've only worked on it once and that was for a minor upgrade and maintenance issue)
- Loosely coupled MVC (i.e. Modularity)
- Object-Oriented
- Object-Record Mapper (ORM)
- Caching (very important)
- Validation
- AJAX (For this project, this is more of a business-level requirement than a technical one)
- Abstraction. This is very important. For instance, I want the coding to be done in terms of objects, methods and properties. Not of URLs and query parameters. Another example would be the use of custom tag librairies.
- Enables/Forces clean coding. Seperating view from logic. This has to do with abstraction and MVC. But I want to stress the importance of this.
- Excellent documentation.
- Active Support.

Based on my current research, I'm leaning towards the ZOOP framework: http://zoopframework.com/
It has excellent documentation, which is a must.
I've heard good things about Seagull, but am not impressed on how it is documented. Unless there's some documentation source I'm missing...


Also, I'm still looking for a php IDE. Since I'm used to eclipse I initially thought I'd just install a php development environment plugin but come to think of it, I rather work with a IDE fully dedicated to php. The IDE I'm looking for has to offer the following:
- Complete Debugger (Code breakpoints, Stack Trace View...)
- Integrated Version Control
- Code Documentation Tool
- Nested Code Completion
- Refactoring
- Overall nice look and feel with syntax highlighting and other features that increase readability
- Automated Packaging and Deployment.
- Plugin Support

Right now I'm looking at Zend Studio.


Any suggestions or discussion on frameworks and IDEs for this particular subject matter?
Cheers and thanks for you inputs.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Welcome ... and from your exaustive list -- join the club! ;)

First let me ask about two things it your post that jumped out at me:

1. "the project's clients, consultants and stakeholders have favoured php technology for various justifyable reasons which I will not get into." Oh, please get into it. This is the kind of stuff we love to hear about around here. Give us some red meat and we'll give better feedback!

2. "Caching (very important)" This comment/requirement is sort of the tip of the iceberg about a lot of things in your post. The reason you'd want caching, and there are several different kinds, is because you have a performance problem. But you haven't built anything yet. So relating to this and the rest of your list -- what are the real known requirements and what are things that you think will be nice/cool to have?

On to your specific question about frameworks and IDEs. I think the IDE question is probably easier in your case and I would recommend Eclipse because it fits with your Java background. Eclipse is also the direction that Zend is headed as well.

Frameworks are really personal preference. My only recommendation is that you pick one that has more that just a guy behind it, because that guy always goes away at some point.
(#10850)
fastfingertips
Forum Contributor
Posts: 242
Joined: Sun Dec 28, 2003 1:40 am
Contact:

Post by fastfingertips »

The reason you'd want caching, and there are several different kinds, is because you have a performance problem
Here i disagree you, you may get good results without caching if you do things right, but if you are able to achieve some extra speed using caching why you shouldn't :).
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

I use Eclipse with the current CVS version of the PHPEclipse plugin. It's not as advanced as, say, Zend Studio. But one is free, and familiar - the other is not. Both are good IDE's for general purpose development with PHP/HTML/CSS. Zend has recently released a preview of a separate Eclipse PHP-IDE which will contain a few features from Zend Studio - but that's still a few months into the future for something stable.

Caching is over-rated IMO. Designing with caching in mind can be dangerous - you can well end up missing an obvious solution to something that appears to need caching. Very little in PHP needs caching - unless its something that requires a lot of static repetitive processing - such as certain XML configuration files, and similar. Even database caching via PHP is over-rated - many database's have much more efficient intelligent caches.

I've only used Seagull in passing. It seems from that limited experience to be quite well designed - but unfortunately under documented (which though common is always a let down). Many others exist each claiming a set of features that usually include MVC, etc. A lot are inspired if not direct ports of Ruby on Rails or Java Struts and so are typically highly structured. There are also component based options that let you roll your own framework like ezComponents and the future Zend Framework (both have few inter-class dependencies).

On learning curves - the problem with frameworks is that they'll all require some degree of investment to build up familiarity and experience. PHP itself has a small learning curve but also has a few additional steps up the curve (more like leaps) such as OOP, Security Practices, etc. which are a must for most projects. This may or may not be small...
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

fastfingertips wrote:
The reason you'd want caching, and there are several different kinds, is because you have a performance problem
Here i disagree you, you may get good results without caching if you do things right, but if you are able to achieve some extra speed using caching why you shouldn't :).
Which kind of caching? Opcode cache? Template cache? Configuration cache? Query cache? etc. etc. etc.

I have no problem with caching when and where needed, but if your design spec says: Implement Cache, then you are forcing all kinds of design constrants to solve a non-existant problem.
(#10850)
Jorge
Forum Newbie
Posts: 14
Joined: Tue Mar 21, 2006 8:36 pm

Post by Jorge »

arborint wrote: 1. "the project's clients, consultants and stakeholders have favoured php technology for various justifyable reasons which I will not get into." Oh, please get into it. This is the kind of stuff we love to hear about around here. Give us some red meat and we'll give better feedback!
Well these are the more relevent points that were discussed:
Since most of the logic of this project is located in the database layer, we wanted to minimize the amount of middleware between our system view and the actual data. Implementing in Java, for instance, will add data delagetion and a certain overhead of logic we can avoid with php (so I've been told).
Another issue was that of the fact that we will be using a statistical analysis tool called R:
http://www.r-project.org/
We have great documentation, reusable code and consultant/academic resource for R implementation within a php environment and not taking advantage of them would be just plain proposterous.

arborint wrote: 2. "Caching (very important)" This comment/requirement is sort of the tip of the iceberg about a lot of things in your post. The reason you'd want caching, and there are several different kinds, is because you have a performance problem. But you haven't built anything yet.

Please read the following extract from the protoytpe report I wrote:
Latency:
Reducing the amount of time it takes for queries to return their results to the client side of the application is an attribute that will greatly increase performance quality in retrospect to data flow under the influence of real time constraints. Before any query result can be displayed to the client, the application needs to set up a connection with the database, open it, execute the query, retrieve the set of records corresponding to the query result, close the connection and, only then, will it be ready to display any form of result. This set of necessary operations greatly affects latency, mainly due to the amount of layers that is needed to go through (i.e. from the highest level, which is the view aspect of the application, to the lowest one: the database). Furthermore, the data flow travels both ways, back and forth, following a send and receives path.

Network Traffic:
Traffic created by database connection and interaction can reach unsafe complexity that needs to be properly managed. Particularly in handling data flow which can become a traffic issue if too many connections are to be taken into account. When several users are given the possibility to simultaneously and concurrently access data, network traffic automatically becomes a risk that needs to be taken into account. Focusing on hardware power alone to solve this issue would be a grave mistake and any solution at a implementation logic level should be taken into account in order increase performance.

Proposed Solution:
Such application quality issues related to database access and communication can be tackled by reducing the amount of queries sent to the database and data received from it. This can be done by identifying redundant queries, executing them once and caching their results for future referral. Applying a cache pattern for data retrieval will reduce the previously discussed risks.

Risks:
Implementation of this quality solution within the prototype has revealed potential performance risk in applying such a caching pattern. First of all, caching is done on the server side of the application. This implies that the server environment will have to cope with caching at a per-user basis. Considering the significant amount of data objects (which mainly consist of record sets) that can be collected by a user during his session, caching and managing these data for every user will cause overloading of the server’s cache pool. This risk can be approached and dealt with by focusing the actual caching at the client level and limiting the amount of caching permitted per session. Further studies and research will have to be done in caching techniques and algorithms in order to establish the optimal solution for this case.

Implementing a proper cache manager also poses a significant risk. If a user is to read data from the cache, then it should be guaranteed that he is dealing with the most recent and up to date data. Reading from the cache might introduce phantom data to the user that no longer reflect the actual contents of the database. Because of this, smart caching should constantly be enabled throughout runtime in a highly dependable way. Inserting modification or new items in the database should immediately be reflected in the cache. This introduces a potential synchronization risk to the cache pattern. Validation must be implemented in order to ensure data integrity at runtime.
arborint wrote: So relating to this and the rest of your list -- what are the real known requirements and what are things that you think will be nice/cool to have?
This is in its own entire document/report... it's pretty big and still a draft. :wink:

As for the framework, I will most likely work with the Symfony Framework for it's excellent documentation and tutorials. It also satisfies key requirements I'm looking for in a framework:
http://www.symfony-project.com/

I have a meeting regarding the project ot attend to right now but there's more stuff I want to discuss later.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Jorge wrote:Please read the following extract from the protoytpe report I wrote:
Again, it look like you have not implemented the "prototype" so there are, as yet, no real performance problems -- only potential one.
Jorge wrote:
... focusing on hardware power alone to solve this issue would be a grave mistake and any solution at a implementation logic level should be taken into account in order increase performance. ...
I don't think anyone has ever proposed a bad-code + hardware-power solution to a client and got the contract. ;) But to ignore the often extreme cost effectiveness of adding hardware vs. adding programmer time would be a graver mistake. Unless of course you can talk your client into paying for a cool query cache! :D
(#10850)
Gambler
Forum Contributor
Posts: 246
Joined: Thu Dec 08, 2005 7:10 pm

Post by Gambler »

On performance tuning before having performance issues:
http://www.flounder.com/optimization.htm
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

That's a pretty good article. To paraphrase the three points:

- The naive path. You don't even realize you've got a preformance problem. You're probably in trouble, because if it is an actual problem, you didn't know it was there.

- The inexperienced path. You realize you've got a problem, so you immediately start writing software to deal with it.

- The experienced path. You realize you've got a problem, so you build a well designed system and then deal with the actual preformance problems.
(#10850)
Post Reply