Right now I'm not sure...
I'd say yes. I'm using it. I know for a fact that Universal are using it on some of their (thousands of) sites. I will add some caveats, however:
There are serious problems with setting it up, especially if you want to debug into the libraries.
The helper functions favour prototype, as opposed to the more modern jQuery. This is changing rapidly, however.
The documentation is a bit chaotic, again the Castle Team are working on that.
I'm not guaranteeing every last "out-there" feature works, but the point of the system is actually to keep it simple.
Compared to vanilla ASP.NET, it's an absolute joy. I assure you that you won't miss viewstate.
We have been building a fairly large application with it for the past year and a half. Its been nice not to have to deal with the old ASP/Page based model and use the better Model/View/Controller design pattern.
To get the new stuff you really need to work off the trunk of development because they don't do releases very often. We have a lot of tests that get the framework involved so when an update in the framework breaks something we depend on we know about it immediately.
If you have to work in .NET this beats the heck out of the alternatives.
There is an overview on the monorail forum: http://forum.castleproject.org/viewforum.php?f=6
I'm using it for an application and haven't had any big issues with it.
The biggest problem is indeed find good documentation and examples.
I've had no problems setting it up. Julian, I don't think it is constructive to say things like "serious problems" without any further clarification or example.
Debugging into the libraries is trivial. Because it's open source, you can debug into the whole thing.
I've been using MonoRail for production for ages on many projects, as an employee, as an indie contractor, and for non-work related sites.
I know I'm biased on that, however I can whole heartedly promise that my positive usage experience is what lured me into contributing to the project, not the other way around.
Related
I am wondering why DataRecevied (or ReadChar()) haven't been implemented in Mono. I couldn't find anything on the notes for the 3.x beta and both are old known issues (The first is even mentioned on the Mono documentation) and seemingly easy to fix.
There are even "workarounds" such as this that feel not-so-hard to integrate.
Is there any solid reason for it being standing so long? Does nobody actually care? Is Mono not really under active development? The 3.x beta would point otherwise...
Mono is under active development. Xamarin is the main company behind it (as in, number of contributions compared to other companies).
This means, of course, that bugs/features that the Mobile offerings use get prioritized faster than other things. Do you have a company that heavily uses the System.IO.Ports namespace? Then consider contributing to it, it hasn't received much love lately.
PS: You do not even need to code to start contributing. For example, first thing you could do is review contributions from others, like this one.
I cant decide between this two options.
M Project vs Sproutcore
I'm building an application that will be primary served on mobile but has to be viable on desktop.
Mproject is on the edge with number and variability of his prebuilded widgets and may happen that I will need some more or at least alter some behavior.
So this is kind of down side of Mproject. But it looked for first review that Mproject need less code for basic stuff.
And the second problem comes with the skins. I will basicaly need reskin everything a lot. The design of app has to be very unique.
So I want to know which of them is easily to reskin not just by theme-roller and similar stuff.
I would appreciate any other JavaScript-only frameworks recommendations.
Thanks for all replies.
I'm not sure what kind of application are you building so you should take care with my answer.
M-Project solved our problems fine, and help us to make it clear code ... when you understand how it works. It requires a bit of hard work, the documentation is a bit poor and is a new project where some things are not yet implemented. You can change application look modifying HTML and CSS so I think you should have no problems with this.
Also you can download their code and modify it without problems, it is easy to read and modify if you need any specific behavior.
On other side, I never used Sproutcore, it have a really nice look. But documentation say it is focused on desktop applications. Probably you will not have too much problems to adapt the output HTML for mobile devices, I guess.
Lastly, I think you can take a look on Lungo.js Framework.
Best regards.
I've been reading up on several PHP frameworks, and reduced my candidates to CodeIgniter and Symfony (I know there are many more). Strongly leaning towards CodeIgniter, but have not 100% decided quite yet.
I'm not looking for a general "CodeIgniter vs Symfony" discussion.
One thing keeps coming up in comparisons: people say Symfony is for "advanced" coders and "bigger" sites; CodeIgniter is for "beginner" coders and "smaller" sites. But I have yet to see any technical proof of this. Everything I'm seeing about CodeIgniter feels right.
Can anyone explain structurally and technically where people are basing these statements on?
I want to understand all I can. Once I make a decision, I want to focus my attention on one framework.
Thanks,
Matthew
The biggest technical difference between CodeIgniter and Symfony (ver 1 and 2) is that Symfony is much easier to extend. This is especially true with Symfony2; you can replace entire parts of the framework as you see fit with custom code, or code from other libraries. You can even take any number of core components from Symfony2, and build your own framework on top of it. But, it's important to note that because Symfony is so 'advanced', it has a higher learning curve.
Here's how I see it: CodeIgniter is great when you have a small(ish) project that falls in the category of problems CodeIgniter is meant to solve. But when you want to do something your way, not CodeIgniter's way, you're going to have to fight the framework, which is never fun.
On the other hand if you're working on a Symfony2 project and want to do something your way, you can. It won't necessarily be quick, but it is possible. To me, that's the most important thing - you need to be able to make the framework do what you want it to do.
If you have time, read through the Symfony docs and cookbook - they should give you an idea of what Symfony is capable of and how to customize and extend it.
Everything I'm seeing about CodeIgniter feels right.
Then go with CodeIgniter. The most important thing is that you're comfortable with the framework/toolset. If you complete a project and find that it's lacking in features, you can always check out other frameworks.
I would recommend starting without a framework. If you have been programming awhile and are comfortable with concepts like MVC and why you might implement your code in this pattern, then frameworks start to make more sense.
Frameworks are good for larger projects where there are many programmers and you need a consistent method of building application layers, like MVC. The framework will likely provide some mechanism for object management and a consistent way for you to build application events (controller) and to separate the view logic from the model logic.
My PHP apps have been smaller, so I have not used any frameworks. When I used to code in Coldfusion, on larger apps, I used MachII, Model-glue, Fusebox and ColdBox. Each was good at something, each promoted consistency, but each had a lot of overhead and often times felt like it was in the way. I saw some developers get stuck because of the framework.
I did not start using any CF frameworks until I had build smaller apps without one.
If you like CodeIgniter better, for whatever your reasons, go with it.
CodeIgniter, because of the gentle learning curve and the great documentation. Give other frameworks a go if you ever feel you outgrow CI, which you may never do.
I am looking into developing a commercial application using PHP. Since I have experience in CodeIgniter and it has been working well for me, I decided to use it. Now, if ever my application comes to a point that it needs to grow and have to have custom modifications in the platform, is it possible to modify the CodeIgniter source code to the point that it's far from the original?
I'd strongly recommend not modifying the source code as this is the back bone of the application will make updating to futures releases of codeigniter impossible.
Instead you should be creating your own classes/libraries that extend the core bases. This is best practice.
The codeigniter users guide has some fantastic information regarding this, http://codeigniter.com/user_guide/general/creating_libraries.html
Good luck.
Don't modify it, extend it. Ellislab is good about releasing bug fixes and patches, and the last thing you want is to have to re-engineer all the updates into your new hybrid everytime they release updated source code. Plus, different features and bug fixes are released at different paces for the core and reactor, so unless you plan to lock your framework in at the current version, extending is the way to go.
The good news is CI is built for and encourages extensions of the source. The system folder and the application folder separation are a clear indication of how you should segregate your enhancements from the base libraries.
CodeIgniter is written in PHP. You can completely rewrite the framework anyway you like. So the answer is "yes".
There are many big websites that were written in a different language or build on a framework when they started and have been rewritten many times since. I think a lot of developers (mostly freelancers) are over-thinking when starting out. When I start a project, then I try to get it done and get it out in the web asap. If a website starts taking of - and most of the times start making you money - then you can always take the time to rewrite it.
I think it is a lot more important to spend time when you plan and design your database and tables. I think it is a lot harder to redo parts of your database later on then it is to rewrite the code that uses the data.
Just my 2 cents.
If you have used CI, then you should know that being a PHP framework that all of the source-code is there in the download, furthermore opening the system and application folders and looking through there will tell you a lot. Yes all of the source is there in plain English (plain programming English) and not only is it in plain English but has been extensively documented inside and out (literally that is in the source and in the user-guide). CI gained initial fame from that simple fact, that all code is extensively and meticulously documented.
Beyond all that, the question itself raises concerns that maybe you should study CI a bit further before writing commercial applications using it. Ci is a powerful and very easy to use PHP framework, but it is not a WYSIWYG. In my opinion, a coder should know his tools inside and out in order to be able to create a solid secure and trusted application. The first measure of which is to read the user manual, you should know at the very least everything in it, and since there are 12 sections in it that cover everything from extending CI libraries to creating your own libraries, and everything in between I would say you need to spend a little more time with it.
I want to say though, I am not being rude or trying to shame you in any way I am simply saying that you should learn the framework a bit more before venturing into a commercial application using it.
In the early days of PHP people realized how amazingly easy it was to use and how fast you could write an application with it. At the time the major options where very difficult for new and hobby programmers to use or involved expensive software to run, PHP was free, easy to learn and most of all ran on a free OS. It also took hardly any setup to get going, you could download PHP and essentially be programming in minutes. All of these factors lead to the almost destruction of the language.
Entry level programmers were destroying it with bits of code taken from other applications, never knowing (or caring) what the code actually did beyond the simple fact that it did what they wanted at the time, never considering or even investigating if the code might be harmful. Because of this practice PHP applications that had grown to Goliath sized websites, taking thousands of hits an hour were:
beginning to crash
being hacked to reveal sensitive customer/client data
generally crumbling all around the web
All because since the language was so easy to use that people had taken advantage of it and failed to take time to learn it. PHP was becoming a joke to other professional programmers and wasn't even thought of as a viable application language by many who had dubbed it "the copy and paste" language.
So my advice to you, please take the time to know your tools inside and out, what makes them tick, if they have any gotchas and where they are vulnerable. I understand that in order to learn a language to a professional level you have to build with it so I suggest that you take it slow with CI stick to the core for now. Trust me when I say that even in its purest form CI is an amazing and powerful tool that in the right hands can create awesome powerful web application, but in the uneducated/inexperienced hands it can create havoc and destruction.
So (stepping off of the soap box) I simply ask that if you are serious about creating commercial applications period that you take your time and learn your tools/language become as close to an expert on them as possible. I gurentee that if you do that you will always have work when you need it and you will spend less hours beating your head against the table or worse explaining to a client why their site is down.
I truly wish you good luck, just slow down and learn your trade and you will do just fine.
Yes, Codeigniter is an open source framework. However, I would advise against modifying the core of Codeigniter, as most files can be extended and rewritten safely without modifying the core files which will cause you headaches if you ever decide to update.
To extend a core class by default you would do this in Codeigniter. We'll extended the parser class for this example, but this applies to all classes pretty much. This link in the comprehensive user guide will give you all the information you need to extended and overload methods inside of a Codeigniter core class: http://codeigniter.com/user_guide/general/core_classes.html
Is VCL dead, or does it have a future as a GUI library? As CLX ended, is there any chance for cross-platform support in future releases?
I've had to do some work with legacy app that uses Borland's VCL(BCB6). Now that new features have to be implemented, it's necessary to revalue alternatives. Whether to stick with VCL or migrate to some other library/framework.
I've never read much what's happening in the field Embarcadero(Borland) tools. At least there seems to be only few VCL tagged questions here in SO and no much luck with google either.
Whether to continue using VCL in your project, or migrate to an alternative depends alot on your requirements. The VCL framework is powerful and mature, with lots of 3rd party components, which makes it a good idea to consider. The alternatives have been improving rapidly, and to point out one as the ultimate choice really requires you to carefully consider your requirements, and validate the strengths and weaknesses of the different frameworks.
Considering that cross platform is on the road map, I remind you that so has 64 bit support been for quite a while. We might see cross platform support, perhaps on schedule, perhaps delayed as we have seen with many previous features. I want to believe its coming because I truly like the VCL framework, but I always have a natural doubt concerning the official road map of the RAD studio series - sorry David. ;)
If you've researched the different alternatives, and found VCL to be the best choice based on its relevance to your project, then I'd consider using the VCL framework, especially if it is a framework you are familiar with. Learning a new framework can - while often a good idea - be a time consuming job. So even though there might be a risk of the framework not being held alive (as will there be with any alternatives) you might save a lot of work staying with the familiar framework, if it is the framework that suits your project the most.
If you do consider going with C++ Builder and the VCL, you might find that the C++ Builder Journal is a valuable source of information, they have a relatively quite forum, but with some interesting posts in it, and some free hints on their website: www.bcbjournal.com.
Of course there is also the embarcadero forums, and this site, it may be a good idea to search the Delphi forums and categories, since it seems there are more active users on these, and by far more posts. One good thing though, is that conversion from Delphi to C++ in VCL related questions is quite simple.
VCL is undergoing continued development.
Cross platform is on the current roadmap.
The embarcadero forums are still a valuable resource.
As a user of VCL I must say that your observations are truly correct. VCL might appeal to you, but the resources available compared to QT and other toolkits is poor at least esp. at SO. Our team have also found several bugs in their components, and have more than once patched components to make our application stable. Still for me the main reason to migrate is that VCL locks you in with a single set of development tools. I must admit that I have a hard time trying to find any really good reasons to continue to use it if you have the resources to migrate.
Given that bcc32 and its libraries is also very buggy, the lockin gets even more serious, The last months me and my team have spent more time fixing issues caused by the compiler than actually developing features. For me this is such a serious impediment that its cost overweight its benefits tenfold. Unfortunately the costs of migrating for us is so high that we at least for now have to endure its pains.