At my company we have a web application that we have been developing for over 5 years. We still have a codebase that contains PHP4 and has been extended with loads of PHP5.
The LOC is pretty big, about 471k. It is not based on a framework, ORM, etc, etc.
The developers who started of with this project ignored any i18n and translations. All the language texts are hardcoded in the software. Yes, I know this sucks big time.
At the moment we're fine since we only sell this in the language the software is written in but we're also looking at expanding abroad.
I'm struggling with the best approach on dealing with the translation.
How would you guys approach this? Would it be better to rewrite using a framework since that would probably also improve the codebase and providing a solid structure. Or would you just use the current software and filter out the language texts.
Any tips and hints on this subject are appreciated!
I think both variants are possible. You can leave your code, or rewrite. But as you know rewriting is a long process, in spite of that fact you've writing it for over 5 year.
If it's still stable, works fine, and PHP4 and other 'tasty things' you don't need, you can leave and just review all hardcoded texts. i18n helpers are very easy to make. You have to do nothing more then:
Choose appropriate way of storing texts and translations
Caching mechanism for already loaded translations
Class and helper for i18n operations.
You should analyse you bussiness plan well, if you decide to rewrite you code.
Still got an additional answer. Translating almost identical strings is very costly. Multiply that with the number of languages and one realizes: a good internationalization with sharing of same strings, and maybe formats, is really more efficient.
A first rewrite of the templating part, probably makes sense. First by hand, then with an automatic conversion tool written by you. It should prepare I18N.
In my experience, it's not a good job to have a single project with two major goals - especially if those goals are almost entirely unrelated from a business point of view. I'd have one project team responsible for localization (which may well involve more than just translation - different countries have different legal requirements, currencies, payment providers, etc.), and one team for "improving the code base".
I'd start by having the localization team work out a rough plan (and cost) for "the simplest thing you could do" - retro-fitting localization functionality into the site as it is right now. Unless that cost is unacceptable form a business point of view - I'd go down that route.
If the business case for refactoring hasn't been made, I'd not try to shoe-horn it into your localization project - I've seen similar things happen before, and all the developers wanted to work on the cool refactoring stuff, talk about the relative merits of various frameworks, and which source code control system to use, while the thing the business cared about was pushed to the future; eventually, the business owners lost interest in the project, and cancelled it.
If there really is no realistic way to do the localization without a refactoring effort, I'd still run it with two, separate teams. The localization team can be a primary requirements owner for the refactoring team, and they do need to work together - but by keeping the two projects running independently, you avoid the risk that you get 90% of the refactoring done, but only 10% of the localization.
It sounds like you have more than a translation project ahead of you. If you're wanting to take it abroad, you'll have to redesign at least part of the system.
If your budget allows for it and the benefit justifies it, you'll want to step back and take a look at the overall design. Keep what you can, but don't be afraid to rip out, redesign, replace and upgrade major portions of it.
Much has changed in the last 5 years, so if it's an app that you plan on selling for many more years, it's likely worth the investment in redesign.
It depends on what the priorities are, as to what you should do.
If the main concern is the language translation, then you can start with just taking out the hard-coded strings so they can be internationalized.
If there are other needs, such as wanting to easily support different databases, then that would help determine if there is a better approach.
Related
We have an old and big PHP application with complex business logic. Now the project almost fully consists from spaghetti-code. I plan to do a smooth migration using Symfony e.g. rewrite some features using Symfony. Also seems DDD is a good choise for the project like this. So the main idea is to make a rewriting of some features to make it more clean and easy to maintain. Any suggestions?
Thanks.
Actually the DDD principles can be applied in the context of a legacy code base refactoring. This is how we did (and are still doing it), but don't take it as a silver bullet:
Phase 1 - Strategic preparations:
1.) Use Context Mapping to identify Bounded Contexts and their integrations. Try to be agnostic towards your current architecture. This is actually very hard to do because of biases. It comes in handy if you do it with people that are no constant users of the old system.
2.) Sort the contexts by strategic value and identify your Core Domain (Where is the money?), eventually finding Supporting Sub Domains (parts of the system that support achieving your strategic goals) and Generic Sub Domains (things that are absolutely necessary, i.e. compliance and accounting).
3.) Bring Stakeholders, Developers and Product Owners together to form a common language, the Ubiquitous Language within the different Domains that capture the intents and capabilities of the business. Be dogmatic about a central dictionary of these terms, if you hear something ambiguous during discussions, resolve it and add it to the dictionary. This is an integral part of any DDD project since we are modelling the capabilities of the business, which means the code and the stakeholders language should carry the same semantics.
4.) OTPIONAL: Depending on the size and working methodologies of your organization, you might have to restructure it. Let Conway's Law work for you and create a certain feature gravity by reassigning teams and individuals to the different domains that you have identified earlier as value streams where the best and brightest should be working on the Core Domain. Enable direct communication interfaces between developers and stakeholders to work closely on specification and constantly distilling the Model.
Phase 2 - Implementation:
0.) If you have no experiences with such a complex refactoring, get external help (consultants) or hire experienced engineers that have done this before. Believe me, you will need it (I have learned it the hard way myself).
1.) Create a Bubble Context in which you are free to redesign your models and integrate it with the legacy system. There are a lot of integration patterns (you can find a nice summary of those patterns here and here. Always ask yourself if the context in question has enough strategic value and is bound to evolve over time and has to nicely respond to change in the future. In the end it is all about creating Software that is easy to change and refactor. Iterate, rinse and repeat. Always refactor the new code as early as you gain new insights from the business.
NOTE: Don't try to do too much. The Bounded Context's play very nicely as Microservices boundaries, but a lot of times people underestimate the complexities of a distributed system. If you don't have the availability and performance requirements that would require this architecture, then a well designed, modular monolith can be just the correct tool to get the stuff done.
EDIT
If you are interested in the Strategic part of DDD you MUST watch Paul Rayner's talk from DDDEU 16 here.
DDD is a set of methodologies to facilitate team communication. It has less to do with refactoring and more to do with architecture.
I don't know if this qualify for SO, anyhow the explanation would be huge. There's no "silver bullet" method here. Personally I would try to isolate components, and migrate those one by one to a or several new Symfony application(s).
DDD is not relevant there. You can find many usefull pattern/methods in Martin Fowler books, especially "Refactoring" and "Patterns of Entreprise Architecture".
We are currently bringing an online business software to other EU markets, where not only language but also rules and regulations differ from country to country which made me wonder, what is the best way to implement such in a software?
The UI localization isn't really a problem - done that more times then I could care to count, but for example while invoicing countries tend to require different data (well not totally different, but different enough to make you think about it architecture wise) meaning different inputs, different validations and somewhat different handling of that data.
Which way can be considered better?
The standard way of localizing UI and adding the needed conditional statements for showing extra and hiding non-essential elements with similar conditionals in the Controller classes
Creating a copy of the app for the given country with slightly altered controllers and views (which will make the constant updates a nightmare, but the code much cleaner)
Trying to somehow create a Factory/Builder pattern around this?
While the last one sounds most reasonable to me, it frustrates me even more, as I have no clue on where to start yet. Any good pointers on that?
Language of the choice is PHP with Laravel
Definitely do not make different copies.
Have a look at your current database architecture and see how you can expand it to fulfill your requirements. Then rewrite or update the business-logic code layer of your application.
Then you will only need to make minor adjustments in the front-end.
This post is some kinda old, But the title is general and could be found by some others via search, so I wrote my answer in the following:
I think it's totally based on your architecture. In recent years, peoples are following different principles to break-down the whole application into meaningful microservices with specific tasks and boundaries. This mindset would help you to analyze the whole business process and the places that you may need to do some customization for each customer or country.
for example, for product catalog or inventory management, the processes between each country may not differ. but in the payment or order management, invoicing you need to do small modifications which would be quite easier while you are following a microservice pattern. Furthermore, you can have your own plugin loader structure which lets you modify, override and extend each instance by having a filter/hook feature in your application as you might have seen in WordPress and other opensource platforms.
I and my partner are trying to develop a website, and we are arguing which language to use to build a website. We both have some experienced with PHP with Codeigniter 1.6++ as well as RoR, although my partner used rails when it was in RoR1, which now is RoR3.
He wants to use PHP with CodeIgniter because he knows whats going around more explicitly, while RoR does not seem to satisfy him.
I want to use RoR 3, because it takes less time, and there are many gems which I can use (devise for example).
He is kind of worrying that Ruby on Rails won't be easy to change some configuration in db or codes once the websites gets bigger and bigger.
I just hate to think about writing lines and lines of codes from the scratch with Codeigniter within 2 months.. although I think it was not easy to manage db tables, once things got settled in rails..
So, I have been wondering.. is there any big advantage one from the other?
As an avid user of both I would not say that this is a question of which framework is better or worse as they are apples and oranges.
CodeIgniter has not changed all that much since 1.6.x both of your experience is still valid and you will be able to code right from the get-go.
Rails 3 is wonderful but quite a lot has changed since Rails 1 (not that I was using it back then). I think your partner would have too much time scratching his head unless you are going to be there for him to constantly answer the WTF's that will inevitably come up.
To explain, I am a CodeIgniter man and have been for years. There is not much to it, no conventions and what code is there is simple, easy to extend and easy to ignore if you don't like it.
Recently starting working with Rails has been a great series of highs and lows but it's not always quicker. I spent 2 hours implementing a fully functional user system with fb, twitter, etc and had most of my controllers built, but since then I have spent hours trying to get various date formats to play nicely with the ActiveRecord, or trying to override create_at, manually set id's and all the other stuff that nobody ever mentions you are not allowed to do.
If you need to pump out some code fast then Rails might be an option. If you want fine grained control over everything and have a really lightweight base to build your application on then CodeIgniter really would be a better choice.
Or, look at FuelPHP which is a framework me and a few others are working on to combine the two into one Configuration over Convention framework with a command line utility to bring in some of Rails best features. Saves a fair bit of code and you'll feel right at home.
You can make most languages do most things at the end of the day, just a matter of how long it'll take you.
Hopefully you know your project well enough to know what the major stumbling blocks are liable to be and then match them against your combined knowledge to solve them within both languages. Which ever you both feel more comfortable with overall should win. You will be able to do it in either, just a matter of familiarity and confidence with the language (as well as availability of libraries for complex tasks).
Incidentally, this question would be better on https://softwareengineering.stackexchange.com/
From a management perspective, I can tell you that if you plan on growing in the future, you will pay twice as much and have to look twice as long for RoR programmers. PHP programmers on the other hand are easy to find and hire since the language is ubiquitous. I have known of companies that were bought and their product completely folded just to recruit the Ruby talent because it is so hard to find.
I am creating the cms for a relatively simple site - portfolio, some general content pages, custom blog etc.
What are some of the best patterns to consider before diving into the design.
I want the system to be as flexible as possible without being too complex.
I have looked for some good resources that discus cms and blog design but can't find anything too good.
My language is php but I suppose I am looking for more language independent advice.
Flexibility without complexity... nice program.
Maybe you're a genius and you will make something that feet your needs. But I think the biggest problem you will face is security and robustness. So really, take other advices on this page and have a look at wordpress, drupal, joomla and ezpublish. A lot of security stuff is already done. And not only security...
So, study some of these tools, track their flaws, check their security policy. Study how they handle caching, sessions, bootstrap, absolute & relative url managment, documents (images, videos, etc), ajax, authentification, identification, acl, user interfaces, rich-text editing, migrations, templating, page composition, content filtering (I try to remove the things you won't need, plugins, database abstraction, fine caching, css and js minification, all the extra-complex stuff not needed for a single instance simple CMS). Soon you'll have a 'picture' of the stuff they've done.
By doing this work, you'll certainly notice some big differences, and mistakes. You'll start going on irc and flaming developpers, telling them that others have done better choices. You'll start forgetting to shave. You'll maybe do some contributions. Some will be accepted, others won't. Old core devs doesn't like when someone explain why they made mistakes (and they make mistakes).
Now, comes the day you have a beard. Some of your contributions will start looking like forks. You will have ennemies, and friends, or followers. And you will start feeling the force.
And you will go on irc and tell god that the world is ugly and that you'll make the first CMS which will be flexible without being complex. And people will cry. And birds will run in circles. And you will be able to explain what are the design pattern of a CMS.
I am a user. I know what I want. Doing what I want will make user happy. I'm happy.
You shall not trust code from people with glasses
"MVC MVC MVC" : and the people responds 'that shall be done'
Seriously, There's still a place for a good CMS with disruptive innovation, the fork history has started long time ago with phpNuke (as far as I can remember). But some of the actual products are really fine for most tasks.
I'm probably risking the reputation here, but my experience shows that building your own CMS can be a very justified decision, especially when you get familiar with current opensource systems and understand what exactly they lack in terms of features, security or what not. Open-source often means a lot of backward-compatibility concerns and bad architecture decisions that cannot be easily changed.
I strongly suggest that instead of just taking on MVC you take a look at ideas that make it attractive.
One main problem with CMSes is the range of technologies involved in driving dynamic web-sites: imperative php for logic, declarative SQL for data queries, markup HTML for interface, imperative/functional javascript for dynamic interface, JSON for ajax calls etc. To keep the system manageable you have to keep these technologies in a controlled and understandable environment, but yet allow for smooth integration. Knowledge and best practices are out there. MVC is but one approach to manage this problem.
My choice at the time was to use the following principles:
Object-oriented code with static calling (php is a one-run thing, many instances of code objects are rarely justified), nothing except for one line of init code in global context
100% code-design separation with the use of XSLT and custom content processor
Custom router that can take any http request and reroute it to registered methods
Custom content processor that can take arbitrary method output and convert it into any usable format such as xhtml, xml, json etc. based on the request parameters (i.e. http://local/class/method.xhtml, http://local/class/method.json)
One copy of code for as many virtual web servers as necessary
SQL query builder (chosen for flexibility over ORM) for all database queries
Mandatory filtering of method input with filter_* functions
I believe you can choose a few that you like :) And good luck!
A good pattern to start with is the Model View Controller pattern, or MVC.
This pattern suggests to seperate your application's logic in the following layers: data logic(model), manipulation or business logic (controller) and display logic (view).
This is a good pattern to start with as you'll run into other problems (and thus patterns) along the way.
The following website explains the MVC concept quite well: MVC Principles
There is no point reinventing the wheel unless you are trying to better it in anyway.
THere are a lot of CMS available already. I personally have worked with ezpublish. There are other options such as drupal etc. This is the list of all open source cms avaliable - Click here
If you are just trying to learn then you can perhaps pick any one of the popular opensource and work on them to find its architecture and design.
Besides, I dont think anyone can give you a list of design patterns that would be best for a CMS tool. Because each design pattern solves some particular problem. And, you just have to choose a design pattern depending on a specific problem you want to solve in your project.
These days, writing your own CMS is a horrible waste of time. The usual open source solutions -- these days Joomla, WordPress and Drupal are popular -- are written by thousands of people and while you might loose a little flexibility by using on that's ready made this is by far offset by not needing to redo everything from scratch. If you go with Drupal, you can also enjoy high quality, massively scalable etc code :)
If Your rquiremnt is portfolio, some general content pages, custom blog only, Wordpress will be simple and Better.
In PHP so many CMS available , most popular one is Joomla.
I've been a PHP developer for many years now, with many tools under my belt; tools that I've either developed myself, or free-to-use solutions that I have learned to trust.
I looked into CodeIgniter recently, and discovered that they have many classes and helper routines to aid with development, yet saw nothing in the examples that I couldn't do just as easily with my own tools. Simple things like DB abstractions, Email helpers, etc. There was some interesting code relating to routes - mapping urls to the right controllers; but even that's not particularly difficult to code yourself if you've ever written an MVC style web app with pretty urls.
Even after looking through some of the other popular frameworks, I still see nothing that would be that much of a time-saver. Even looking at the forums, I see people struggling to get the tools to work for them. I do understand how they would be more useful for junior developers, since full system design skills take a while to understand and appreciate fully.
Yet, I'm often told that I should use an off-the-shelf framework to produce my solutions, but I still remain unconvinced. What's the real benefit to someone like myself? Am I just being elitist, or is this a common opinion?
Edit: Looking at some of the answers here, should I perhaps consider packaging up my toolset as its very own framework, writing some documentation and posting tutorials? If I'm hesitant to take on other's frameworks, would opening it up and getting more eyes on it help to improve my own skills/tools?
Frameworks have several advantages:
You don't have to write everything. In your case, this is less of a help because you have your own framework which you have accumulated over the years.
Frameworks provide standardized and tested ways of doing things. The more users there are of a given framework, the more edge cases that have been encountered and coded for. Your own code may, or may not, be battle hardened in the same way.
Others can be recruited onto a project with a standard framework and have access to the documentation, examples and experience with that framework. Your own snippets may or may not be fully documented or have examples of use... but isn't much chance that others are comfortable with them initially.
EDIT:
With regards to your idea of packaging up your own framework, the benefit of cleaning it up for public consumption can be larger than the benefit of getting others to use it.
The reason is simple: you will have to re-evaluate your assumptions about each component, how they fit together and how clear each piece is to understand. Once you publish your framework, your success will be strongly dependent on how easy it is to get up and running with.
Big wins with little effort are essential for adoption (those wins will encourage people to delve further into the framework). Ruby on Rails in an example of a framework that gives such big wins with little effort, and then has hidden layers of features that would have overwhelmed someone just getting started. (The question of the quality of RoR apps is not the point, the point is about adoption speed).
After people adopt a framework, it is about the ease of continued use. Little details like consistent parameter use patterns make all the difference here. If one class has many parameters on every method, while another has setters that are expected to be called before invoking methods, you will lose users because they can't get a "feel" for what is expected in a given case without resorting to the documents.
If both ease-of-adoption and ease-of-living-with issues are addressed properly, you only have to get lucky for people to adopt your framework. If those issues are not addressed properly, even an initial interest in the framework will wane quickly. The reason is that there are many frameworks: you will need to stand out to gain the advantages of having others using your kit (as they rightfully are as wary of your framework as you are of others).
Here's another reason not to create your own framework. Linus' Law - "Given enough eyeballs, all bugs are shallow". In other words, the more people who use a given framework, the more solid and bug-free it is likely to be.
Have you seen how many web frameworks there are for Java? Back in the day, it was fashionable for any half-decent developer/architect to write their own custom web framework. And at the end of the day, 95% of them looked like a custom implementation of Struts (the most popular Java web framework at the time). So they basically created a Struts clone that was: 1) proprietary; and 2) not as well documented and tested.
Let's face it - writing our own customer framework is fun, but what happens next? It becomes a maintenance burden to keep up with the framework yourself (or the poor soul who replaces you). And maintaining software is much, much more costly, especially when it comes to custom frameworks. Is the company in business to solve domain problems or in the business of maintaining frameworks?
I forget who said it, but I once heard a great quote - "The first rule to creating your own framework is: don't". Somebody else has probably gone through the effort of doing so and probably done the same work you would have done. Save yourself the time, effort, and testing.
There's many comments here as to the advantages of using a framework, and certainly I think in a good many cases they are perfectly correct.
HOWEVER
All frameworks come with the downside that they have a domain of problems that can be fitted into them. If your problem is well inside the scope of the domain then using a framework isn't an issue, and most of the time it's readily apparent if your problem is well outside the domain so you don't give it a thought. Issues arise when you try to force a problem into a framework that it just doesn't quite fit into or has some unusual non-standard feature - in which case you complete 90% of the code really fast then spend all the time you've saved figuring out how to bend or extend the framework so it can accomplish some obscure requirement. Because in these case your solution/extension has to plug into the framework it can often be more difficult to code than if you'd come to it independently.
In the wrong circumstances this can actually be disastrous. For example if a client asks for a project that you believe will fit into a framework solution and you quote accordingly, then after completing 90% you find the gotcha then you can be really up the creek, especially if it's some feature that the client is insistent upon (and it always is). These issues tend to arise because it is not always apparent from the word go where the gotchas might lie, particularly if you're using a framework you are less familiar with (and you have to from time to time).
This is really the same problem as arises with deploying any third party software in a project. Myself from experience I have no qualms about using frameworks or similar, but given the choice I will always go for the lightest, thinnest, wrapper I can find that will do what I need. That way I gain the advantages, whilst knowing that if issues do arise (and they are generally less likely to with a thinner wrapper) then figuring out how to work around them is likely to be simpler than learning an extensive code-base to the point where I can safely modify it.
The framework code is likely to be well-tested and relatively free of bugs. By using it you save yourself time testing/maintaining your own code to do the same thing.
And any time saved is good. Laziness pays off in programming.
One thing that you will be missing out on is all of the Validation that goes into a popular framework.
Your routines simply don't have the same exposure that the popular libraries have.
You may have a point.... however I wouldn't underestimate the power of many, as an example phpBB is as far as i'm concerned the bb solution to use. Why? Because there are many, many thousands of posts on their support boards and many people using it who are knowledgeable and can help people solve problems.
Therefore the only reason in your case to use a popular framework is the many others that use it, report bugs against it, fix it and support it. It'll be tricky to get the same coverage on your own libraries.
I would go against the grain here, and say, you should use your own custom framework, If the software you are building is the core of your business. As Joel would say, "Find the dependencies - and eliminate them". If you are just putting up a little website for your company, and you business isn't maintaining websites, then go ahead and use a framework. But when that website is your business, then you shouldn't depend on a framework from somebody else to let you get the job done.
I think the main reason is that when you use a common framework, there are a lot of people who are instantly familiar with your product.
Apart from that I think it's most important that whatever tools you use actually get the job done. If it happens to be familiar to other people, then that's a bonus.
I agree you should use your own custom framework. Not only is it easier for you to understand, but it provides the ultimate in job security!
Three reasons I can think of immediately:
A well-known framework will be familiar to other developers who may have to work on your project
A well-known framework will have resources like books, discussion boards, and other experts that can be used for finding out more information
Managers will often have a "don't reinvent the wheel" philosophy. In fact, existing solutions have probably solved the same problems that you'd discover if you create your own solution.
All of that said, there may still be a place for your own solutions. We wouldn't have so many frameworks (or scripting languages) to choose from if no one started something new.
Any experienced developer can build a framework -- the challenging part is convincing others that it's worth using. You'll need to create documentation and tutorials for it for those who plan to use or maintain it. You'll probably need to create a demo site to prove that its useful and actually works like it's supposed to.
That alone can be a considerable investment, not including bugs that could pop up in between. When its all said it done, it could be worth spending time learning another framework instead of making your own.
You mentioned CodeIgniter -- I personally feel like that's a pretty framework -- it doesn't get much more barebones than that.
What you essentially have is your own framework. So, it isn't a time-saver FOR YOU, because you have already spent the time to develop the framework. If you didn't have that to build from, it would certainly be easier and faster to use an existing framework than to roll your own.
What you need to look at is whether or not your framework is better than other options out there, and whether your familiarity with your own code outweighs having other eyes looking at it, and other people using it in enough different ways that the likelihood of any problems being found and corrected is much higher.
Also, if your framework is so much better than everyone elses', you might consider opening yours up to the community ;)
As you probably know: "time is money". So by using a popular framework with a lot of helpers, a lot of code examples on web and a big community you do more in less time.
Sometimes it if ok to use frameworks because you become more productive, but in some advanced and difficult projects it may happen so that the framework stays in your way and you have to find workarounds.
I think there is no definitive answer. You should put in balance the pros and cons and take the right decision for your project.
Usually I adopt popular frameworks very fast but not in critical parts of the projects and in time I extend their usage.
I think that if you don't see a need to use a framework then don't.
The reason I use a framework for example Django for python or Rails for Ruby or Webforms and MVC for ASP.net is because they make it easier and faster to write applications for them. In the case of Ruby and Python not using a framework for me would make me go crazy.
If you have something that works and don't see a need to use a framework I would say stick with what you feel is best. But, I would still keep up to date with frameworks.
I think they are more useful if you are starting from scratch and don't have the time to write your own. If you already have a codebase you developed over the years, they may be much less useful, but it may still be useful to take a look and see what they did.
For example, I am sure major game development shops are not using third-party tools, engines and frameworks, not because they are not sufficient, but they already have built their own since the 80's or whatever.
Plus, if you are using an off-the-shelf component, there is no way to exceed it in its particular area. If you need to be a market leader in a particular dimension, you should be building your own solution in that dimension, so you can lead. If you don't need this capability, using a third-party component that is just as good as yours may be a good solution as long as it is an easy transition. Time to train in the new tool and living with its idiosyncrasies may or may not be worth it though.
The other thing to consider is that if you can build something, you truly understand it. Otherwise, you don't. Now, you don't need to fully understand stuff to use them, so long as they "just work", but we all know how that goes... :)
Can you solve the problems you are given have with your code faster and more reliably than public frameworks?
If yes, then keep using your own.
If no, then find the framework that does a better job and run with it for that project.
It all comes down to which codebase gets the job done better(for the value of better given by the client. ;) )
Disadvantages.
Most frame works are not object orientated. (code igniter does show some promiss)
Most of the code is done via includes. trying to track down the problem is like pulling on a thread on a sweater, and having to unravel the entire garment to fully understand the creation.
Most frame works have poorly written documentation.
Most frame works try to do many many many things.
I find from my experience developing with frame works that it takes a good 3-6 months to get on top of the code base. And its only after that period of time that you will find out weather you are trying to fit a square peg into a round hole. Given that most php projects want to be finished before that period has elapsed, it will cost employers more to get any project using a big "frame work" to fruition.
Many of the php Frame works were written for php 4, and were written in a different enviroment. They have been extended greatly, but are showing their origins. The use of global constraints is particularly prevalent. I am hoping that php 6 puts most of them to death. Code igniter escapes most of this, but it is new, and has object orientated parts.
Some frame works have written code that is not needed, and causes problems.. eg: CAKE has a most excellent model view controller, but its session handling is a disaster. Unfortunately frame works are not written in a modular way. Often its an all or nothing option.
MOst programers "hack" the frame work to get it to do what they want. This leaves future programers sractching their heads. It also makes "upgrading" the frame work a impossibility.
I have yet to see a frame work that implements unit testing. (how do you know that you have not broken it).
give me a well written object any time. At least them you know the scope right off the bat.
Advantages are that it's already written and tested by multiple people therefore less likely to be bug prone.
Disadvantages are that it's not built specifically for your application and therefore will most likely perform worse.
All in all, I can't really see much reason to use one considering you already have your own...although it may be worth releasing that open source so others are able to bug check and recommend improvements.