Having never used a CMS system before, I'm just starting evaluating .net CMS systems, with the two most attractive options seemed to be Umbraco or Orchard.
Re Umbraco, I'd prefer to use the MVC flavoured v5, rather than spending lots of time learning XSLT for version 4.7, when that has come to the end of its development cycle. But, is now (May 2012, very soon after the release of 5.1) is actually a good time to start out on the Umbraco learning curve, as there doesn't seem to be the depth of support and documentation out there for v5 compared to v4? I'm sure it'll be improving all the time, but as it'll be my first CMS system, it seems a little scary leaping into a brand new, rapidly developing system.
Sorry for the subjectiveness / vagueness of the question, but any useful comments comparing the probable learning curves of Orchard and Umbraco 5.1 would be very much appreciated.
You may already be aware of this but as of today (13th June 2012) Umbraco 5 is officially an abandoned project due to the fact it was fundamentally flawed at the architecural level and deemed unfixable.
It was announced at the Developer Conference... you can see the reasons why in the blog post below. Suffice to say, you're advised to not use it.
http://umbraco.com/follow-us/blog-archive/2012/6/13/v5-rip.aspx
or watch the rather cringeworthy keynote video here :
http://umbraco.com/follow-us/blog-archive/2012/6/13/cg12-keynote-video.aspx
4.7.x supports Razor - so you don't have to learn XSLT.
That being said, v5 is the future, and it is out, so I wouldn't bet my money on v4 for a new project. Check v5 out, read the bits of documentation that are available, and ask in the umbraco forums if you're stuck. Umbracians are friendly and do help each other out in the forums.
EDIT
Umbraco v5 has been discontinued - you should not use it for any production site.
I agree with the above poster: You don't need to xslt with umbraco at all, v4.7 supports Razor.
Its a good time to start learning v5, but I would not promise any deadlines to clients any time soon. There are a lot of performance related issues that make it unsuitable for all but the smallest of sites right now - If your deadline is 6 months out, you could probably bank on V5 being stable by then, anything less than that, and you are better of sticking with 4.7, which is really fast, full-featured and a pleasure to work with.
Depending on the site, and if you stick with razor, the upgrade might not be that hard if you ever need to do it. I just spent about 3 months developing a v5 site, and because of the problems had to convert back to 4.7. The conversion wasn't that hard, and now being back in 4.7 makes really appreciate how stable it is.
Related
I had selected sproutcore as a framework right before Ember forked from sproutcore. I am left uncertain of which way to go and a bit frustrated in the apparent dilution of efforts caused by the fragmentation - as rarely does that lead to better things. The efforts of Sproutcore 2.0 (now Ember) seemed to be going in the right direction of modularization and reuse of other javasript components (jQuery), however it is really unclear from an outside view why the two efforts had to split... couldn't we have modular code, and a widget library module too?
The main questions are:
What are the effective differences between the two efforts?
What is history of the split?
What is sproutcore future, where is it going now?
Is Ember going develop to be a complete replacement for sproutcore?
As someone who has both a Sproutcore app and an Ember app close to a production launch, I'll take a stab at your questions (re-ordered for clarity). All of the below is what I've observed with no inside knowledge. A bit of it is speculation, so I've enabled wiki mode on this answer, so that more informed people can correct details.
What is history of the split?
Here is what I've pieced together:
SproutCore was created by Charles Jolley's company Sproutit as the basis of their Mailroom product in 2007. Jolley later joined Apple and Sproutcore was used to build the original web apps for Mobile Me. The mandate was to recreate the experience of Mac apps like Mail and iCal, and that effort continues on Sproutcore today with iCloud.
Jolley left Apple and formed a company called Strobe in San Francisco with a vision in part to leverage Sproutcore. The team at Strobe decided that Sproutcore didn't fit many Web 2.0 use cases well enough, and was too much of an all-or-nothing proposition for developers, so they initiated an effort toward Sproutcore 2. The goals of Sproutcore 2 were modularity, and a more HTML-aware approach that would be more accessible to web developers everywhere. Backbone's early traction was part of this analysis.
After struggling to move the Sproutcore codebase toward this vision, the Strobe team decided to start fresh with Sproutcore 2 (internal codename Amber). Charles wrote the core Run Loop and key-value observer code. Yehuda Katz and Tom Dale were the lead Strobe developers on the project. The vision at the time was that Strobe and the community would eventually port over most features and functionality from Sproutcore 1.x to Sproutcore 2.
Strobe business efforts were not yielding hoped-for results, and the company weighed its options, eventually deciding on a acquisition of Strobe talent by Facebook. Before this happened, a number of Strobe employees, including Katz and Dale, split off to form a new company called Tilde.
Tilde decided to continue to develop Sproutcore 2, but change the name (to Amber.js and then Ember.js) and goals of the project. They dropped long-term goals of backward compatibility with Sproutcore. They dropped support for any kind of view widget library and focused on the HTML/CSS use case with tight integration of data binding with the Handlebars templating language.
Since the dissolution of Strobe, stewardship of Sproutcore 1.x has passed from Jolley to Tyler Keating, and the community has re-focused on cleaning up Sproutcore 1.x, which was in an uncomfortable place for a while when the idea of Sproutcore 2 was looming.
What are the effective differences between the two efforts?
The similarities in the projects are that they feature very similar object models. They have similar property, observer and binding systems, too.
Sproutcore includes a library of view widgets like toolbars, list views, grid views, buttons, and theming system, and a focus on defining the view layer via Javascript and absolute positioning managed by the library. It is very powerful for creating desktop-style apps on the web.
Ember has a smaller footprint. It features tight integration with Handlebars. It is an alternative to Backbone for many projects. It aims to provide a standard application architecture for client-side apps and eliminate boilerplate code.
Those differences will likely lead to the frameworks diverging, although there has been some consideration of adopting the same core. In that scenario, Sproutcore would use Ember's "metal" library and perhaps other core libs).
What is Sproutcore's future, where is it going now?
This thread has minutes from the a recent contributor's meetup.
https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#
The short-term roadmap is to focus on solidifying the marketing materials, demos, and codebase. The team recently released the Sproutcore Showcase. There is general consensus about replacing abbot, the Ruby build tools for Sproutcore, with a Javascript(node.js)-based solution, which is now under active development. There is also a desire for fewer "large" merges of code from companies like Apple and more frequent releases. Sproutcore 1.8 was recently released.
Is Ember going develop to be a complete replacement for sproutcore?
Not likely. The Ember core team has been clear that they have no intention of personally developing those missing features. It is possible that community members may develop those as separate projects -- flame.js is the most ambitious attempt so far. Ember's design choices make it easier to integrate with projects like jQuery UI, so a full replacement may or may not be necessary.
1) The official line is Sproutcore is intended for RIAs and Ember.js is intended for "web-styled" applications. So when you look at iCloud think Sproutcore and when you look at Twitter think Ember.js.
From the technical standpoint, Ember.js is focused on more modularized code and so called "semantic-templates" for views. Sproutcore is more monolithic.
2) I'm not sure anyone really knows. If you look at the timeline, Charles Jolley left Apple to form a company called Strobe, which developed a full-stack platform for application development. Strobe hired Yehuda Katz and others, who began working on slimming down SC so it would run better on mobile devices. After about a year, Yehuda left to form the company Tilde, and a month after that Facebook bought Strobe in what is widely regarded as a talent acquisition.
So interpret that as you will.
3) This is an excellent question. Recently there was a meetup and several things were discussed. Key points discussed were:
SC is still alive and kicking
Improve documentation (we have been hearing that for a while).
Keep the good parts the code that was introduced post 1.4.5 in development of SC2 and get rid of or move to optional modules other stuff (like Templates)
new javascript-based build tools
completely new canvas based view layer, called Blossom.
Some sort of foundation/corporate backing for SC
There are probably others that I missed
4) Definitely not a replacement, although you can use any framework to build any app (it's all javascript, after all).
I know that Symfony2 has been released, but is it production ready, or are they still finding and fixing so many bugs as to make it impractical?
How is performance in a production environment? Are there current benchmarks anywhere?
I'm looking to build an n-tier web site and am deciding on whether learning sf2 will be time well spent compared to just sticking with sf1.4.
What gaps are there in symfony2 - from what it seems there's no official admin generator. Is anything else missing?
I have released a Symfony 2 based project that was featured in a major newspaper and did well. I'd deem it as production ready. I also did some load tests with jMeter and the man from the hosting company was impressed by the performance.
The only thing lacking IMO is the amount of tutorial and special articles that you have for Symfony 1. Nevertheless, I'll use Symfony 2 for all my future projects.
One slight problem at the moment could be the hosting companies: You absolutely need PHP 5.3 (most companies still offer 5.2 only) and a caching mechanism (APC or memcached) for maximum Doctrine 2 performance.
Symfony2 is definitely production ready. The developers are just fixing minor bugs since the stable release. I know Fabien Potencier published some benchmark tests a while ago, but I can't find them. Maybe you'll have better luck. Anyway, I believe it's faster than any other framwork out there.
You're right when you say there isn't an official admin generator, but you can use SonataAdminBundle, which is absolutely awesome (but a little hard to get to work properly).
See here regarding the admin generator - apparently there is one :)
symfony2 propel crud generator
I have a website written in Symfony 1.4. It was my first symfony website and the learning curve was a bit steep for me. It is a fairly complicated website, and I don't want to 'fix it' if its not broken.
Having said that, since sf 1.4 is now legacy code, I will eventually want to port the site to sf 2.0. as a matter of fact, I am relaunching the site early next year, and I want to know if I might just as well bite the bullet and "port" the site from 1.4 to 2.0 in one go.
So, I need to know answers to the following:
How much of what I already know from 1.4 is applicable to 2.0?
Are there any jobeet or askeet type tutorials out there that show how to build an entire app using the sf framework?
Am I mad, thinking of porting a big website in effectively just over a month (working only part time?) - i.e. is the "big bang" approach the wisest/only approach?
I don't want to 'fix it' if its not broken.
Don't!
Am I mad, thinking of porting a big website in effectively just over a month (working only part time?)
Yes, you are! :)
Symfony2 and symfony 1.4 are wildy different. We're not talking about some updates to symfony 1.x, we're talking about a brand new framework from the ground up. It's really like asking "How hard would it be to switch from symfony 1.4 to Zend Framework/Kohana/Yii/CakePHP/etc...".
I moved a project (in its very early stages) from symfony 1.4 to Symfony2 and found that except for my familiarity of the MVC pattern, not much (if anything) else was transferable from symfony 1.4 to 2. We're talking about new directory structures, new classes, Doctrine 2, the (awesome) Dependency Injection Container, and more.
Symfony2 has its own learning curve, and even though the architecture is better than symfony 1.4, you will be spending a good amount of time going through trial and error and reading the docs.
Symfony2 is great, and I recommend learning it, but do so at a manageable pace. There's a number of tutorials online - check them out and go through the official Symfony2 docs and cookbook when you're ready.
#Arms response is fantastic. Even though the answer has been accepted, I thought I'd add a few of my thoughts to the discussion.
I started work on the development of a personal project about a year ago. I chose symfony 1.4 because Symfony 2 wasn't in a stable phase and I was already an expert in symfony 1.4.
After working for a year in my spare time (I work a full time job) and this is what I have (and it's still growing, about 60% done):
70,000 lines of php code (Doctrine queries, actions, templates)
10,000 lines of custom javascript code
3000 lines of YAML
My schema.yml file for example is 872 lines which consists of 62 table definitions.
My routing file is 500 lines.
Moving a schema definition of that size over to Doctrine2 entities would be a mammoth task. It would take me a very long time. If I were to rewrite what I've done now to Symfony2. It would probably take me a year.
Transitioning over my current authentication system (sfDoctrineGuard) over to a symfony2 implementation would also big a big task. All my command line tasks, doctrine queries, templates would have to change.
In fact, everything would have to change. The only thing that would stay the same is the database username and password.
If I had the resources and time I would consider moving over to Symfony2. One of the biggest advantages I'd get is the performance gain and the better architecture that Symfony2 offers.
I work with symfony2 at the moment in my full time job and I like it a lot but there are still certain things which I'm not sure how to achieve in symfony2 which I know how to do in symfony 1.
For the moment, moving over to Symfony2 for my project is a definite NO. I'd like to but as I have said I don't have the time or resources to and plus the application is working very well indeed. Everything has been re-factured and I've been careful with the development to make sure I'm not repeating code.
Also, maintenance of Symfony 1.4 is due to end in about a year.
If it works well then don't change it. Only change it when you have the resources available and you're knowledgeable in Symfony2 to make sure you don't give yourself any headaches.
Best of luck.
Symfony 1.4 is not legacy code. It is still fully supported by the Symfony team and has a 3 year support promise which ends at the end of November 2012.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am starting a new Symfony project that will be very important to my company. My experience is only with Symfony 1.4. and I have 3 months to complete the project.
The project should be around for years and will grow to have many features. I know that many people are already using Symfony 2 in production, but do you think it's a bad idea to go with 1.4?
Every situation is different. I don't see any problem with 1.4, but some people are suggesting I use Symfony 2 because eventually we will need to upgrade and do a lot of rewriting of code.
Plus, there is Doctrine 2. I would be using 1.2.4. Again, I know that Doctrine 2 is really great, but am I going off a cliff by sticking with 1.2.4? It seems to do everything we need.
Thanks for any insight.
Why you should use Symfony 2.0:
Faster. Many Symfony components have seen performance improvements and it also now supports edge side includes.
Fixes weaker design. Symfony 1.x is great, but some components had flaws, like logging (now outsourced) and tasks (more flexible). Forms in 1.x were powerful, but had some flaws; forms in 2.0 are better.
It's the future. Symfony 1.x will expire before the lifetime of your project. You already said you will be rewriting it. It makes no sense to wait.
Cleaner, easier code. Namespaces, more decoupling, generally even more beautiful than Symfony 1.x was.
Doctrine 2.0. Way faster, way easier to use.
The only possible reason to go with 1.x is time concerns. However, if this project is that important, it makes more sense to increase the time limit (if it is unfeasible), then to do it in 1.x and waste all that time rewriting it later.
Well, Symfony 2.0 should really be your bet if you had more time to get the project done. Symfony 2.0 developers are still struggling to learn the right way to use all those nice standards and best practices.
The community using SF 1.4 is already mature and has solved every single problem that all the common (and others not common) scenarios could present.
All those arguments about speed do not apply to 90% (or more?) of projects built on SF. Unless you need a high performance webapp (serving more than 500-1000 requests/minute), you gonna be fine using SF 1.4. If you need to serve more than that you can always using one more server to the scene. An optimized SF 1.4 app can perform pretty good.
I'm trying to say that all the talk about performance is not a problem for most apps. People do not think about it when raising the speed flag.
SF 1.4 is a well structured framework. It really speed things up during development. SF 2.0 is a community under development. People are still developing solutions and plugins for the most common problems.
I'm still using SF 1.4 for all my new projects. Mainly because I got a lot done on it that get my projects done really fast. All my customers don't need a high performance webapp, however I have my own projects that need to be fast and after optimization they really are.
I've struggled with this since 1.0. Ok great i finished my 1dot 0 project wicked fire it up...no wait there is now 1.1...ok upgrade go through all the upgrade troubles... ok cool NOW it's ready to go but no wait 1.2 is out now...FFS... ok upgraded everything to 1.2 struggled through learning this new forms class and plugin issues cuz sfGuard needs a new version blah blah blah... ok now we are ready to go fire it up but no wait...they've release 1.3 AND 1.4 on the same day WTH. Ok how bad is this upgrade going to be??? phpmailer good swiftmailer bad. or is it the other way around this time. Oh FFS what is this symfony2 all about now.....
I'm sure i'm not the only one that has gone through that (or similar scenario)
what matters is what YOU know and what YOU are good at. Symfony 2 i'm sure is great awesome best ever blah blah blah. But if it takes you three months to get up to speed and work all the bugs out that WILL come up. Then you're better to go with 1.4 and build on what you know.
I'm sticking with 1.4 because i have a large code base that i've built up that works just fine. As you can see by the varied opinions though the debate could rage on for a while.
That's my two cents anyway.
I'm still doing my projects in Symfony 1.4, but outlining a strategy for yourself on how to make those changes towards 2.0 would be a good idea. Also, it sounds like there is some frustration with Doctrine, and Propel development seems to have been awakened. There may be a switch in many preferences towards Propel in the future.
Short term:
If you know that sf1.4 allows you to finish the project in the time you have doing all the stuff requested by the customer go with that.
Pro: you know it, no costs for you on technology
Cons: end of support November 2012, Lime for testing (or plugin for PHPUnit), using an "old" solution
Long term:
As you said the project should be around for years so I think that many developers will work on it. Sf2 is much more decoupled and uses PHPUnit for testing. Allows you to use ESI and performs very good with HTTP standards (no application cache).
Pro: brand new tool, very active project, a couple of steps above sf1.4, as web will evolve also Sf2 will embrace that changes and support development
Cons: you don't know it but you can hire someone to help you (GTD and learning a new framework)
Getting things done is more important than using the latest and greatest and although symfony 2 appears to be a better version all round, symfony 1.4 is still a great product, has a greater pool of knowledgeable developers and therefore if you do hit any stumbling blogs, you are much more likely to find a solution in a much shorter time.
For your purposes symfony 1.4 is good enough and will give you a greater appreciation of symfony if and when you decide to move over to symfony 2.
There are enough similarities between the versions to be able to gain useful knowledge through using symfony 1.4 and it means that for now, you get the best of both worlds -- useful experience for later on and getting things done.
Go with Symfony 2.
I'm doing the switch from 1.4 to 2 right now because of the advanced ACL features of Symfony 2.
It will save you a lot of time in the end.
I would go with symfony 2. You have all the feature improvements (faster, doctrine 2, etc etc etc), but that is not why I would go for it.
Symfony 2 has had thorough security testing, which is vital for any real project. Add tot hat the fact that long term support won't cover your projects lifetime, and it really is neccessary to build it in 2.
I just started my first project in SF2, after working for a few years in sf 1.x. There are a lot of changes, but it didn't take too long to adapt.
My experiences with web-frameworks was that they are relative "unstable". Not that they crash but that there are quite a few changes which then force one to reprogram ones code. I wonder what web development packages you've used and how much work it was/is to maintain that code?
"Changes are a part of the requirement."
I dont think that the web packages that we design changes a lot. If it changes, then it is a bad design. If we use external API's, a very few get deprecated, otherwise most of them are the same.
Some packages used as a JAVA/J2EE programmer:
- MVC
- Struts
- few AJAX frameworks
These are very basic one used. Most the other ones are self developed and once the design of the web package is done, we don't change the design.
Any library which is under active development would be unstable. Look at .NET for example, every month there's a new better way to do old stuff. On the other hand open source libraries tend more to throw old deprecated methods away because it makes code better and that's what makes them happy.
But I wouldn't recommend to use anything old and unsupported anyway, you'll be on your own although the environment would be completely stable.
The best way possible seems to be just freeze the version of library you start using and switch to new one only there's huge benefit in doing so. At least that's how everyone is doing that.
Frameworks like .NET and jQuery have been largely backward compatible and allows you to use new features slowly.
Mootools however... the API broke so many things from 1.11 to 1.2 to 1.3. Upgrading was not straightforward in that case.
As a rule, I try to wait for something to be out of beta before embracing it in production code. An endorsement can go a long way too - since Microsoft has called jQuery the winner of client-side frameworks its been easy to encourage others to pick it up too.
Most of my experience is with Ruby on Rails, so I'll share what I've seen with it over the last few years.
Rails updates at a pretty good clip, but you don't really need to update unless you need features or the rare security patch. As an example, I have a rails app running in our company right now that was coded about 2.5 years ago that only needed to have some work done to it once this year to upgrade it to a new version to be compatible with apache mod_rails, it was originally written against Rails 1.2 I believe. Of course, that was an intranet app which didn't have any security requirements. All in all, it's been pretty pain free. If I had kept using mongrel + mod_proxy it wouldn't have only needed to be updated once for a security patch.
Rails is pretty secure, vulnerabilities are fairly far between. There have been a few more Ruby vulnerabilities than Rails vulnerabilities if memory serves me right, but all in all it's pretty solid, and upgrading your ruby shouldn't break rails, especially if you use a distro that backports security fixes.