Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Whenever I create a PHP library (not a framework) I tend to reinvent everything every time.
"Where to put configuration options?"
"Which design pattern to use here?"
"How should all the classes extend each other?"
and so on...
Then I think, isn't there a good library framework to use anywhere?
It's like a framework for a web application (symfony, cakephp...) but instead of creating a web application, this framework will help coder to create a library, providing all the standard structure and classes (observer pattern, dependency injection etc).
I think that will be the next major thing if not available right now. In this way there will be a standard to follow when creating libraries, or else, it's like a jungle when everyone creates their own structure, and a lot of coders just code without thinking of reusability etc.
There isn't any framework for creating libraries at the moment?
If not, don't you agree with me that this is the way to do it, with a library framework?
Because I am really throwing a lot of time (weeks!) just thinking about how to organize things, both in code and file level, when I should just start to code the logic.
Share your thoughts!
Ah well, now Bill basically said everything I was going to say, but anyway. I can throw in some links:
If you want something you can just throw into to your webroot and start coding your application into, you are looking for a full-stack framework that strongly uses Convention over Configuration. From the modern frameworks, Symfony comes to mind.
If you want standalone components, look for component libraries like Zeta Components (formerly ezComponents) or Zend Framework or Symfony Components (includes a DI framework). You can reuse these or extend them to add additional requirements. Or use Doctrine if you need an ORM. And don't forget about PEAR.
However, how you use the above or what you do with them is nothing you could download somewhere. Architecture and Design is the task of the developer (or architect). You cannot download that, because it likely won't fit your application without heavy modification. Patterns, like the GOF patterns or the PoEAA patterns offer guidelines on how to solve problems on a general level, but you always have to adapt them to your application.
I think there are frameworks that meet your needs. Developers make a distinction between full-stack frameworks and more component-based frameworks.
The component-based frameworks include a collection of more fine-grained components that can be used more or less independently. Examples are configuration, authentication, email, web services, etc.
If you're talking about a framework that makes it easier to develop those components, I'm not sure what the value is there. Frameworks provide value by abstracting common code that they're sure you're going to need. What's the common code between an authentication component and an email component?
Frameworks increase developer productivity for well-known tasks. The more specific and well-known the task is, the more the framework can assume it knows how to do it. Example: Drupal or MediaWiki.
But frameworks don't do OO design for any arbitrary code for you. That's moving in the opposite direction, away from more specific, and toward broader tasks. It's hard to identify the common code that can be abstracted from such a broad set of technology as "libraries."
Most of what you describe is called software engineering. It's the essence of using base software and language tools to form a complex solution. As far as making it easier and abstracting away the repetitive parts, that's what most modern languages do try to do.
I guess the answer to your question is: Python, .NET, Ruby
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I've done some development in RoR and I'm now trying to make something in PHP.
I think the MVC architecture is an ideal frame for my current project (users, application data, purchases, etc.)
Is there implementation of MVC on the web that is recommended or does PHP just not work in the same way as Rails and every MVC in PHP must be hand made?
My google fu is weak and I couldn't really find anything conclusive.
These four are MVC frameworks:
CakePHP
Symfony
CodeIgniter
Kohana
I prefer CodeIgniter and Kohana, because they're pretty focused and not bloated at all, and because they both, besides being MVC, are also big on the convention over configuration principle, meaning you don't have to go around maintaining XML/YAML/etc config files of your classes, URL routes, etc.
In particular I like Kohana because it has this nifty file system-based configuration hierarchy (they call it "Cascading Filesystem") which basically means you have even less configuration nonsense to maintain, because based on where you put your app's files (classes, config files, etc), the framework will know which parts of the system will be overridden. So I'd recommend you give Kohana a test run. Beware though, it's relatively new and the documentation is kind of weak, so if your google fu is indeed weak as you say, then you might be better off going straight for CodeIgniter, which has been around for longer and thus has more docs. But I'd still keep an eye on the Kohana project.
Symfony is... too bloated for my taste (i.e. having to run scripts in order to "generate views" and whatnot), but I've seen some large successful projects running on it.
Rails is an MVC framework, for PHP you could use CodeIgniter or CakePHP both of those use the MVC design pattern. CodeIgniter is the bomb.
You can find more discussion about PHP frameworks here: http://www.quora.com/Whats-the-best-MVC-framework-for-PHP
I haven't looked into other frameworks, I have found Codeigniter to satisfy most of my requirements from an MVC framework.
Sure, Theres Codeignitor and Frostbite Framework.. Both are good, and easy to find via google. Here is a whole list of php frameworks: http://matrix.include-once.org/framework/simple
Everyone else pretty much nailed it. The only reason I'm adding on to this question is because you use Ruby on Rails, and as such, CakePHP is going to be the most similar framework for you.
I use CodeIgniter because it's very well-documented and lightweight (with very little magic), but that's just my personal preference. Cake will be most like what you're used to.
I think laravel is best for you. Remember, frameworks are for SSBs Small scale businesses. For large scale businesses you write your own framework with all planning, execution phases etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Which one of this frameworks would you recommend to someone who knows the basics of PHP?
What are the advantages and disadvantages?
I wouldn't suggest any frameworks to someone who knows just the basics. Instead, I'd suggest to get a firm grip on OOP and the most common Design Patterns first, because that is what you will find in these frameworks. It also doesn't hurt to know your way around the various available PHP libs and extensions.
I think frameworks are a double edged sword for beginners. You may be able to do more in less time in many cases but in other cases (not a few) you will make mistakes because you do not understand the complexity of the framework code. I think you should be able to read a framework and understand its architecture if you want to use it.
That said it seems that the real cracks use Symfony. It might become or might already be the best, most versatile, most powerfull framework out there. But it definitely needs a lot of understanding of the principles of programming as well as web techonology and server technology in general.
Also very powerfull and much easier to start with is Zend Framework. It can definitely do much more for you than Kohana.
If you want a lightweight framework, Kohana is a good choice too. It has come a long way the last months and I think it is rapidly establishing itself as the new lightweight favourite.
So all in all, the three frameworks you mentioned are the three top frameworks on the PHP framework market at the moment and you won't make a mistake with any of them.
UPDATE: It is now 8 years later and Kohana is no longer maintained. Laravel would be my current recommendation for a relatively simple yet very powerful PHP framework.
Even though ZF is well established and well documented, I would suggest Kohana since it is quite a bit less complex. It is very easy to start tinkering with it by simply downloading or cloning the sample application from github.
Symphony is not for beginners. I disagree that frameworks in general are not for beginners. Starting with a blank file and no framework leaves all of the architectural design up to someone who has no idea what they are doing while starting with a lightweight framework like Kohana gives you a well-organised platform and documentation to hit the ground running. Learning OO without any examples to guide you is very difficult since you don't already know what good OO design looks like.
After downloading/cloning the Kohana sample app, hit the docs and you'll be writing well-designed OO code in no time.
For a beginner and using the three examples you gave I would say start with Kohana(or Code Igniter) for these reasons.
It's a lightweight framework which is a good starting point for full PHP development because it serves as a guide in how to organize a project in a language that doesn't have a lot of structure on it's own
Introduces basic MVC concepts.
Has basic features that will be useful in any PHP project e.g. caching, data filtering etc
I would then move on the Zend Framework if you plan or strive to work on larger projects for these reasons:
Kohana documentation is greatly lacking (it's manageable for a beginner because you end up poking around and see what makes a framework tick so that they don't see like this ominous holy code which is a plus; but in a major project with timelines it's annoying)
Kohana enforces certain conventions which is often inconvenient in major projects
Lacks mature features that are useful in "enterprise" development e.g. a decent unit testing system (there is rudimentary phpunit modules to use in Kohana and you can certainly use base PHPUnit but in contrast Zend Framework has extended PHPUnit functionality to better suite it's framework)
Better support. Zend framework has the Zend Company behind it as well as a huge community. This is a huge win for them because it permeates in everything about the framework e.g. configuration is thought out much better in Zend framework,more robust security featues, proper class autoloading based on PEAR namespacing, and it has a plethora of contributed components. Some of these benefits you can shrug of when starting but become invaluable when taking on large projects.
I've not used symfony but from what I can tell that also has some useful features once you get more versed in PHP (better ORM, better scaffolding etc). Synopsis: Kohana is a good start but I'd advise against roosting there if you plan to get into PHP beyond small sites.
In your case I would go with (in this order):
Kohana
Zend Framework
Since they are easier to pick up (specially for a beginner) than Symphony.
I always wondered why people say that not providing a unit test system is a major drawback in a framework. Well, testing you app is your responsibility and you should use the tools you're most comfortable with. Me, for instance, prefer SimpleTest and are bothered with framework that come bundled with and promote the use of their own testing system. Why learn another unit test system when SimpleTest is more than enough?
Notice that providing a unit test system and unit testing the framework is two completely different things. The framework should be unit tested, period. But for this task, the developers of the framework may use the tool they prefer most. They may even roll their own test framework (it seems that some people never learn and keep reinventing the wheel). However, (IMHO) the framework test should be kept separate from the framework itself. It shouldn't even be included on the framework tarball, but be kept as a separate package that interest only to developers of the framework.
Just my 2c.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What is the best method of understanding how and why a framework was written the way it was?
Develop a feature for it, or fix a bug. If you use the framework for developing a real-world solution, you can make a list of shortcomings to address or features to add that would make your task easier.
Fixing a bug will really help you understand the code, because most of the time you are given a piece of example code that recreates it, which you can then trace down into the bowels of hell to find where things go wrong.
All it takes is persistence, really.
Take a very simple component and analyze the code. For example, look at some of the components of the Zend Framework (something utterly simple like Zend_Version or, to step up a bit but still keep it simple, Zend_Debug). Pick them apart and see what makes them tick. Then, try to write your own simple component.
After making many websites 'from scratch' I found myself reusing the same scripts over and over, and I found some things tremendously tedious because I never bothered to abstract them away before for re-usability. So, if you have any experience making websites, you should have a pretty good feel for what your framework should include. If not, I would probably start by thinking of an MVC file structure, get your framework to first work with views, then controllers, then models. Then make sure each of those is easily extendable because no matter how hard you try, there will always be things missing... and then just start slapping on utilities as you need them (form helpers, model helpers, etc.). In other words, come up with a project for which you would like to use the framework, and build the framework and website concurrently.
I know the world needs another like it needs a hole in the head, but writing your own framework is a great way of learning a language. I wrote a fairly complete one in PHP in under a fortnight and learned a hell of a lot about PHP and Web development in the process.
The only reason I haven't released it is because I was finally not happy with the way it managed session state, but that was a good learning experience too!
I think the way to begin framework design is to write down about 5 basic aims for it. For mine, these were:
aimed at producing simple Web apps with a dozen or so forms
aimed at people with a good knowledge of SQL
no procedural code PHP or otherwise (except for that in SQL SPs)
no HTML/javascript/CSS programming needed
application described in XML
work on a vanilla PHP/Apache stack
no state maintenance on server
That was enough to get me started.
The other suggestion I can make is to try to build an app using the framewark at the same time as you build the framework itself. This will quickly reveal problems and suggest ideas for new directions abd features.
You are on the right track. Just remember that Rome wasn't built in one day. Every house is built over a longer period, brick by brick.
By using a framework, you will discover some of it'S shortcommings and be able to find some functionality that is missing or needs improvement.
Start there, develop the improvement and submit it to the frameworks community for peer review. Even if they decide not to include your work into the framework, you will receive very valuable feedback on your work.
Don't stop there, use what you learned in your first attempt for a second one (and a third, fourth, fifth...) That way you will learn to understand what others expect from the framework (which might differ very much from your own expectation), and slowly understand the inner workings of hte framework itself.
Conclusion: Be patient and persevere. Understanding will follow. (Sounds esoteric, I know. But it may work!)
There are a number of things that most frameworks include, although the definition is fuzzy.
Provide a basic bootstrapper (manage settings, setup environment, check for compatability issues between PHP versions, etc.)
URL Routing - How to define rules for which URLs point to which pages.
Manage plug-ins, libraries, modules, etc.
Database ORM - Manipulate objects instead of writing SQL queries (simplified)
Templating - Usually involves creating a mini-language for template logic (loops, conditionals) to avoid having PHP code in the template itself.
Beyond this, most frameworks also include a slew of libraries from simple e-mailing to advanced web service API's.
I would recommend two frameworks to look at:
Codeigniter
I recommend this because it's a "batteries included" framework that works out of the box. It also has a great community, lots of 3rd party libraries. CI has a bit of trickery to get the framework to play nice with both PHP4 and PHP5, which is also good to know (because, for some reason, a lot of people still use PHP5). You should also take a look at KohanaPHP, which is a branch of CodeIgniter that has been rewritten as a strict PHP5 framework.
Zend Framework
Zend is a module-based framework. Instead of dropping everything in a directory and churning out pages, you pick the parts you need and glue them together yourself. Since Zend is made by the folks behind the engine behind PHP (confused yet?) it uses "the latest and greatest" of PHP5 - everything is Objected-Oriented and it uses type hinting. Very clean code, if a bit verbose.
I think the essential stuff is the bootstrapper (the "glue" for the framework), as well as how each framework implements a system to support user-made libraries and plug-ins. The rest you can find as stand-alone applications elsewhere.
you should really try to understand, on a high level, the life cycle of a request. here's a good example a what happens from request to response in the Zend Framework, http://framework.zend.com/manual/en/zend.controller.basics.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
My team at work is considering to use a framework for developing web sites and applications. Some of the seniors are convinced we should use the Zend Framework because it is easier to pick-and-choose the features so the framework we will be light-weight.
I'm afraid however that they are only looking at the technical advantages that a lightweight framework will have. In my opinion it is better to have a full-stack framework (and I am a proponent of Symfony) because
It will also provide us with a standard way of working without writing new documentation.
If we would like to use new features we would only have to read the documentation to see how it can be used instead of having to build it into our setup of Zend first.
I don't expect all my questions to be answered by everybody but this is what I am looking for in the answer:
Do I have a point here?
Have you been in a similar situation and how did you handle that?
Do you have more arguments that I could use OR could make me reconsider my own opinion?
The context:
I work at a small shop with about 10 programmers. We mostly program PHP. We use a really simple inhouse developed framework and ORM library that are practically undocumented and lack anything but the most basic features (no validators, no transactions, no caching, no authentication)
And why not both? I have been using symfony since 2006, have been a real Doctrine fan for one year, and for a few months, we've reach many steps on the productivity ladder by integrating Zend components directly onto our symfony applications.
The real strength of symfony lies on the decoupling of everything, and the easy extensibility of the framework. You can replace almost every layer of the whole thing. Just copy/paste the Zend directory in /lib/, and add this singleton in /config/ProjectConfiguration.class.php:
static public function registerZend()
{
if (self::$zendLoaded)
{
return;
}
sfToolkit::addIncludePath(sfConfig::get('sf_lib_dir') . '/vendor', 'back');
require_once(sfConfig::get('sf_lib_dir') . '/vendor/Zend/Loader.php');
Zend_Loader::registerAutoload();
self::$zendLoaded = true;
}
And use freely any Zend component you might like.
You might be interested in the new Jobeet tutorial, and especially at the Search part, which uses Zend_Lucene_Search.
Symfony is really easy to use and can get a fully functional site with sessions, caching, unit and functional testing, automated deployment and more up and running in a very short amount of time. You only really need to worry about code to access and display your data. Whist it may not be as lightweight as a roll-your-own implementation, the amount of code you have to maintain will be less.
The Propel/Creole ORM works well, has built in validators etc and is set up to be extensible out of the box.
When transitioning an in-house framework over to Symfony I was able to re-use lots of library code simply by putting it in one of the lib directories that Symfony scans at startup.
Although I've not used it, there is a Zend bridge built into Symfony that allows you to use Zend modules if needed.
Hope that helps.
I think the ZF documentation and community involvement is better. I also like the naming scheme, coding standard and extensibility of it. ZF also seem to get a lot of new features and improvement to existing classes like an open source project, from many different people working on their own pet projects.
I don't really see how Symfony is an advantage for a group of 10 programmers. Clearly you should be able to relatively fast set up a default configuration for new projects, and have lots of extensibility built on top of and in addition to ZF.
How is ZF not "full stack"? It seems to contain every element Symfony does, and then some. Moreover ZF has a "pick your poison" approach, allowing you to use different pieces in different methods. (As an example, we use Zend_Config in lots of different places, just so everyone can expect a reasonably uniform configuration system, even on tiny pieces of code).
I'm afraid however that they are only looking at the technical advantages that a lightweight framework will have. In my opinion it is better to have a full-stack framework (and I am a proponent of Symfony) because ...
It depends a lot on the type of application(s) you're building. If you're building a lot of low-complexity, mostly content-driven applications, then Symfony will shine. On the other hand, if your application doesn't fit into the naked-object paradigm of Symfony (For example, if it's complex and not entirely focused on content management), you may find it more of a hurdle, than a help.
I have limited experience with either, but a good starting point for setting "standards" for Zend is to follow their tutorials for using the different modules - many of them give sane defaults that work for 99% of the projects out there.
I would say it comes down to what you need it for - Zend for flexibility, Symfony for a quicker start and pre-developed standards if your project has no extraordinary needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am a long time PHP user when it comes to web applications and am mostlz comfortable with it. However, I have a one semi-large project whose maintenance / extensibility has reached its end of a life cycle. I was weighing on different PHP frameworks (there were no when the project originated), since it is the way to go for this project, and I came to conclusion the ebst option would be to do it with Zend Framework.
Symfony seemed to complicated (I don't like setting up database model as that
CakePHP seemed murky
Igniter I liked at first, but then it seemed to me it is more like Zend with less features and no Zend behind it
Zend I like the system of that I can use only what I like and not being tied into a specific directory structure, and of course there is Zend behind it. Performance is what potentially bothers me
Now, after this little rationale behind choosing Zend, there are several things I see as a deal breaker when choosing a framework.
I haven't used ORM in the past because I am more than comfortable writing SQL directly, so I still need to be convinced to use ORM
Not too much abstraction going on from the guts
Flexible directory structure
As long as this project is going to be written anew, I just as might write it in Python/Django, since I am quite familiar with Python, but not with Django. So, I would like to know if there is someone that worked with both Zend Framework and Django frameworks and if can outline a few key point differences?
I must also say that this project is made as a standard site/admin dual project. That is, it is basically two sites in one. One is for frontend and users, other is for data administration in the backend. I must and will build backend on my own, some scaffolding methods would be cool, but full automatic scaffolding is as good as nothing in this case.
I am still quite not sure how one approaches building basically two applications within a directory structure of, what is supposed to be, one application. Do you just make two separate applications and rely on URL scheme from there on to separate them? www.example.com and all of the /* being one application and www.example.com/admin/* being a second application.
Sorry for the long question(s), but as you can see - everything is pretty much related to one problem - I need to start a project anew, it has already established database+data which I can remodel, but would like to keep that kind of work at minimum.
Ok, thank you everybody - looks like I'll try and implement this stuff with Zend, gives me most flexibility out of the package (I did tests with both), and we'll see how it goes.
Well Django is more fullstack framework than Zend. It's more similar to symfony than Zend.
Django can reverse engineer your database into ORM classes. and has a cli tool that help you do stuff ( admin and model generators, project skeleton generation etc.)
Zend is more of a component framework. it has its own MVC and ORM implementation but you need to write that stuff alone. Its approach is to use only stuff that you need without imposing some directory structure.
In your case Django will have some advantages because of its great admin generator module, and Django itself is pretty fast (faster than most PHP frameworks).
I'm personally using symfony with Zend framework for some stuff I need (Mail, OpenID, Lucene search), but have played a bit with Django and I like it.
Zend doesn't include a real ORM. It provides some helper classes but you are mostly on your own in modelling your database and writing your own SQL queries. So you would have full freedom there. As Deresh says, Zend is modularized so you can pick and choose the parts you want.
Personally I use Zend together with DB_DataObjects from PEAR as by ORM. It can auto-generate your skeleton code. It is a very simple solution for handling simple queries but I can always write custom SQL where necessary.
Regarding separation of the two admin and frontend I would suggest putting them on different domains, e.g.: admin.yoursite.com (backend) and www.yoursite.com (frontend). You can probably work it with having them both on the same URL but it is not really a use-case that is supported by Django or Zend.
I'm not so experienced with Django, but from what I've read about it, it doesn't seem to be what you're looking for (too much "abstraction from the guts").
Zend framework does not provide you with an ORM. It provides you with some tools that might aid in maintainability of your code (for example its much easier to do $user->save() on a Zend_Db_Table_Row object then to manually type in the equivalent SQL string).
If you're more comfortable doing SQL, that's totally cool and Zend digs that...just beware that there might run into some more maintenance issues down the rode. I would suggest going with a "named query" approach where you store you queries in an external resource and load them "on demand".
Zend has a very flexible directory structure...the recommended one only facilitates in making things a little easier.
You can easily pull of your admin section urls using modules and routing....its a very common use case in Zend.
Bottom line is, Zend is a "presentation framework" mostly. That's what it excels at. It gives you a clean way of organizing the presentation (the screens) that are shown to your users and aids in maintenance.
It doesn't do much for you from a data perspective. This is up to you, and is probably 90% of the work that needs to be done to become "maintainable".
The goal is that your business logic stuff and data access stuff should function within any "framework", and even without a web server! Otherwise you'll just move you unmaintainable mess from whatever you have to Zend.
Also, I wouldn't concern myself with performance...mosy things can fixed with a good caching strategy.
I can't compare between Zend and Django, but I can tell you it's entirely possible to have the Django "admin" application run on a different domain (virtual named server), and you don't need to duplicate any code. You just build your Django app as normal but put the admin app and url in a different virtual server that shares a common database server/cluster.
The Django admin app does have limitations, but it's very powerful for something that comes almost free.
Finally, when I first started Django I had a lot of disdain for ORM's in general but I accept them now as a useful tool in the toolbox.