Related
I do not have much experience using frameworks or anything so that leaves me with little experience using Models (MVC). I have no interest whatsoever in using a framework at the moment. I am working on a website and I am trying to model some objects but I'm not sure exactly how I should be designing the class.
For instance, right now I have a class with a few public members which can be accessed directly. I have started prototyping some functions (select, delete, update) but I am not sure
If these functions should be static
If these functions should accept parameters or use the class members instead
If these functions should even exist how they do currently
If the entire concept I'm going for is the right thing to do
I can't seem to find any sort of hints on the interwebs as to how to create a model class.
If you're using a factory class then all verbs are usually instance methods and the factory is instantiated with some sort of DB session.
If the verbs are member's of the entity's class select is usually a static method while update is usually an instance method and delete is usually defined both ways (IE: delete(recordID) and entity.delete())
The entire concept is the right thing to do but you're going to do it wrong. Period. Making a scalable model like this takes a lot more time and effort than people have at their disposal. I know you have no interest in using a framework but you should.
My inference from your question is that this is a low profile project, and you have enough flexibility from your boss/client/teacher that you can build it however you want. That in mind, here is what I would think about when working on this.
If MVC is a new concept to you, then Test-Driven Development is almost certainly and alien one as well. However, I first cracked into a real understanding of OOP while doing it, so I suggest you give it a try. Writing some simple unit tests first against your model classes will take you through the exercise of figuring out how those model classes are going to be used. You'll be working with the external API of each of those objects (or groups of objects if you're not a TDD purist), and that will help guide the design of the internals. Check out PHPUnit for getting started, as the documentation has some great examples as well.
I think the TDD approach will lead you to the following conclusions:
Probably not. Static data/methods are usually only useful when you absolutely need one copy of something. I find in web apps that aside from maybe a resource connection like the DB this is rarely the case.
This depends on what the function does. Keep in mind that using local variables implies side-effects, or changes in the state of the object. If the data you need to operate on should not change the state of the entire object, use a parameter and return a value. It's also easier to test these kinds of methods.
Again, writing tests for these functions that illustrate how you'll use them in the application will lead you to a conclusion one way or another about whether you need them or whether they are designed correctly. Don't be afraid to change them.
Absolutely. How else are you going to become comfortable with MVC if you don't roll your own implementation at least once? In fact, it's probably better to grasp the concepts with real experience before you move to a more professional framework. That way, you'll understand why the concepts and conventions of the framework are the way they are.
Oh, and the lack of clarity that you're finding on what a model class is, is probably due to the fact that it's the part of your application that is most customized. This is your data model and domain logic, so a lot of it is case-specific. The best resource, though, IMHO is Martin Fowler, whose excellent book Patterns of Enterprise Application Architecture goes into a lot of detail on how and why to design a particular set of "model" classes with one pattern or another. Here is the online pattern library--obviously the book is more detailed.
Hope that helps somewhat.
When using PHP, I think designing object oriented model adds extra work with little benefits - even when looking on large frameworks, it's common to just use assoc-arrays that you can get from resultsets (see f.ex. the multiparadigm approach of Zend MVC).
While Object-Relational mapping is much more established among strongly typed languages like Java, there are already tools for PHP as well (f.ex. Doctrine). You may check it out if having OO-oriented model is what you want, but be aware that OR-mapping has severe issues of it's own and might be of little use in PHP (haven't tried it myself in a dynamic language yet).
For most newly started project, picking a good framework is usually a way to go - it can save you time and promote best practices (of course after some learning time that's different for every tool out there). When using some framework, you should always try to find out the framework's / community approach to solving specific problems (like model design & data access) before experimenting on your own.
The "correct" way to abstract away data access using object-oriented concepts is a hot-button topic for a lot of people. Put another way, there are several ways to do it and there is no "one right" way.
Rolling your own works best if you are seriously upgrading an existing application. This is because you have a heap of code that is already database dependant and you have some bounds for the necessary refactoring. It also teaches you about abstracting code because a lot of refactoring involves removing (or reducing) code duplication. Once you've done this to completion, you will have a much better idea of how a data model layer should work. Or at least, should work for the way you program. And you will know what not to do next time you build one. :-)
If you're starting a new codebase and haven't worked with a framework or object layer but know you need to build one, then the best advice I can give is to be willing to build one later, and refactor the code to suit when that does happen. Yes, it will likely mean your application will get 90% rewritten a few times.
Writing an object abstraction layer is difficult and you will end up with dense code that is fairly defensive about things, and doesn't take chances. But once you've got it working, you will also know how to build robust code, because it will probably be debugged fairly thoroughly.
No because, static methods are hard to test
It depends of the parameter, life cycle, etc. Impossible to answer without seeing some code.
?
No
OOP requires at least 10 years of experience to have a better view on what is wrong/right/better/worse.
So, if you are not a OOP expert, instead of losing too much time reinventing the wheel, I would suggest:
Use a well-known framework for the technical part
Create your classes/framework for the business/functional part.
(1) Will help you be ready in no time for the classic technical part (Session, database interaction, etc.). Will avoid you to make errors others already did.
(2) This is your core business, it should be "your DNA".
Also, using a well-known/good technical framework will make you read quality code and help you progress. (Be carefull some frameworks are really of poor quality)
When you will have enough experience, you will be able to skip the technical framework part and build/customize your own... because technical framework are usually evil (They serve too many purposes). :)
This isn't a question about what framework to use. I've learned both Rails and Django, and I write all of my webapps in PHP. My question is why bother with the frameworks? It's always taken me longer to use a framework than to reuse old MySQL code and build "models" with phpMyAdmin. I also like writing everything myself, because I know what's going on. I can still reuse functions, etc. and do things how I want, and this freedom seems to be missing from most frameworks.
I'm not saying that my way is right; in fact, I'm trying to figure out where my logic fails. The hype can't be just thin air. What am I missing?
The basic idea of a framework is to allow you to work at a higher level of abstruction and write only the code you have to write to implement your specific requirements. All the other repetitive stuff is handled for you by the framework, and probably with far fewer bugs and security holes than if you did it yourself.
It may feel like it takes longer to learn a framework than to just do it yourself using basic language features and standard APIs, but it's simply not true - not if the framework is good and the app is non-trivial, and especially not once you have learned the framework (using a different one for each new project would of course be idiotic) and factor in the time it would take to find and eliminate all the bugs and correct all the design mistakes that have long since been found, eliminated and corrected in the framework by its developer community.
Almost every developer has cowboy coder instincts that tell him "Doing things yourself is much more fun than using code others have written, and I'm sure I'm good enough to get it right the first time, so it will even be faster and better!". These instincts are almost always wrong.
Frameworks allow you to concentrate on the application itself rather than worrying about the boilerplate code that you'd otherwise have to write for every application. They allow you to structure you site in a much more logical (mostly object-oriented) way, using tried and tested design patters such as model-view-controller. The code in framework is generally more mature and of a higher standard than code you would write yourself for one-off projects as framework have a large community of developers perfecting the code perfecting the code over year. This means that framework-driven sites often perform better and are much more secure.
You also mentioned you like writing things yourself - I know where you're coming from. My solution to this was to write my own framework - I get to reuse and improve my code with every project I do and I know the entire codebase inside out.
Writing it your self may make it easier for you to understand things your self but unfortunately it can make it much harder for other developers to understand what is happening. Frameworks will often be better documented and have a larger community that can support a new developer that is working on the app that you wrote.
I think a big part of it is what you focus on. Frameworks standardize the parts that you shouldn't have to keep revisiting, which helps you focus on the application as a whole. If you reuse your own code all the time you're already using your own makeshift framework.
Your comparing a framework (Rails) to a language (PHP). A framework is going to give you pre-built components so you can spend time on what makes your project unique.
You may already have a code base that helps do this for you. Check out some of the PHP frameworks since that's where you are more comfortable. Take a look at CakePHP, CodeIgnitor and/or Zend Framework.
If you are building many small apps/sites, using a framework may make your life easier.
I think a good step for you is to create your own framework with the code you've programmed so far. ;)
Try to make your code parametrizeable, in other words: create components which you can reuse in different parts of a website (for instance: styled containers), or in different websites (form generators/validators).
You can even go further and create base-classes from which you extend new classes to build your websites. (for instance: data objects with generic select/insert/update/delete methods).
I bet this gives you the best view on why frameworks are so damn handy ;)
It'll take you longer to initially use a framework for the same reasons a PHP developer would take longer to initially use Ruby - you're not familiar with it.
Once you're familiar with them, frameworks can offer the ability to skip the mundane and focus on actually writing the important parts of the app.
You should also just use a PHP based framework like Symfony or CakePHP using them should reduce your production time considerably.
One reason to use a frame work is code separation. Take symfony for example. The model is all done with propel or doctrine libraries. Very little SQL needed. You instantiate a new object and user getters and setters, to store your data, and instead of writing SQL in your page code you create functions in the objects related to the query. When you need to access the same kind of data on different pages you are asking the model for it, keeping the business logic with the model where it should be, so there's never any difference. All the work is done in the "action controller function". You get all the data you need, and then put as little php in the display, basically just echoing the variables you got in the action controller, (with the exception of some for loops and if statements for conditionals. I have found this a more efficient way to code, and on my 2nd project saw the production time cut in half.
You don't need to learn a new language python/ruby just to use a great framework, just have to fin one that works for you.
First, PHP has frameworks too, so the question as stated misses the point.
Yes, you can write your own framework, and as Kris said, there's no shame in that. However, part of the leverage of code reuse is the collective value of the efforts of many. It's not just about reusing your own code. Frameworks encapsulate the common tasks and patterns we all share and provide well tested solutions with many iterations of improvements from the community. No individual effort is going to measure up to that, no matter who you are.
If you roll your own, it will only become world class due to the collective effort of world class people, and that will only happen if your idea merits the attention. The top frameworks out there are already proven on those criteria.
DHH is a smart guy, but the Rails we have today never could have been realized by him alone. Not even close.
If you like "writing everything yourself" as you say, then choose a framework with a core philosophy that matches yours, and start making core contributions in the areas where you can see room for improvement.
Depending on the functions of your Web Application, it can be faster to develop without a framework. For example when the Webapp is just some kind of data viewer.
But as soon as you begin to implement more advanced functions, you are much more efficient with a framework.
Try do do this from scratch:
- proper Form validation
- Handling of multiple Language and Date/Time formatting
- Authentication
See a framework as free tools and stable implemented function for you to use.
Sounds to me like you have already written your own framework in php, since you do mention code reuse.
I can imagine it being easier to use your own set of wheels instead of adapting to someone else's. No shame in that.
Frameworks are there mainly to help people who are semi-new to PHP (or the specific language it is built on) to be able to build a website to an extent that it is secure and easy enough to add on extra parts to the site without having to know a lot about the specifics like security, MySQL (or other database types). In my opinion it is a fairly good way to help break coders into a language, allowing for the fact that the framework isn't too complex of course.
EDIT The reason behind me saying they are for beginners is because myself, as a beginner has used frameworks to break myself into languages a lot better.
I am a capable programmer and I write software for a living. I am taking up a new project to build a website that has a bunch of forms that perform CRUD operations on a database and some multimedia. I am very familiar with PHP and Python and have written some websites in them. I have written some rake tasks and a few ruby scripts that run in production, but I never wrote any websites in ruby. I am considering using Rails, but I have the following questions. It would be great to know the answers to any/all of these:
The project should be done in a month and is very time sensitive. Is 1 month enough for learning with and building a website in RoR?
Writing direct SQL queries is one of my strengths and I would like to use it. I heard that RoR is a pain to use if I am writing SQL queries directly. Is this true? Or can I just say execute a query, give me the results (as a list or dictionary) and then I will tell you how to render them?
I have heard that RoR does joins in memory and doesn't use the facilities offered by the database. Is this correct?
I need to create a website that displays a lot of Images, videos and Java applets. Would RoR hinder my ability to do this?
I am OK using a PHP framework. Is this a bad idea? If not, which PHP framework is closest to Rails in terms of programming convenience.
Answering your questions in order:
You could certainly learn Rails in that time. It's enough time to build a Web site too, but whether it's enough time for you to build your Web site is a different question. I would personally not want to try such a thing on a tight deadline.
You can write your own SQL queries, but there's little point to using Rails if you are going to work around all of its features.
Joins are normally done as part of the database queries generated by ActiveRecord.
Using ROR is pretty much orthogonal to having images, videos, etc. on a page.
I haven't used it, but CakePHP aims to be quite Railsy. Zend and CodeIgniter are more popular and I'm told better by people who have used all three, though.
The project should be done in a month
and is very time sensitive. Is 1 month
enough for learning with and building
a website in RoR?
Given the experience you describe I imagine one month to learn and build a simple-ish app (especially if it is CRUD based) should be enough. If there is a significant level of complexity I would be loath to learn a new technology and deliver a complicated site in one month.
Writing direct SQL
queries is one of my strengths and I
would like to use it. I heard that RoR
is a pain to use if I am writing SQL
queries directly. Is this true? Or can
I just say execute a query, give me
the results (as a list or dictionary)
and then I will tell you how to render
them?
The rails way is to use the ActiveRecord object mapppings it gives you (and mostly these work very well) It is also very easy to write direct SQL if that is what you want to do
ModelName.find_by_sql('your query')
is how you do that
I have heard that RoR does joins
in memory and doesn't use the
facilities offered by the database. Is
this correct?
ActiveRecord does a lot for you, but wherever performance is an issue, as above you can write your own SQL to leverage the advantages of the database.
I need to create a
website that displays a lot of Images,
videos and Java applets. Would RoR
hinder my ability to do this?
I don't see why it should. There are lots of gems and plugins out there which help with this sort of functionality, so it may well be the case that a lot of code could already be written for you.
I am OK
using a PHP framework. Is this a bad
idea? If not, which PHP framework is
closest to Rails in terms of
programming convenience.
I'll let a PHP expert answer this bit.
The project should be done in a month and is very time sensitive. Is 1 month enough for learning with and building a website in RoR?
If it's time-sensitive, stick with what you know.. That said, Rails has lots of plugins to handle things like image-uploads which may save you a lot of time. Rails has "scaffold generators" which create basic CRUD applications in a single command:
./script/generate scaffold title:text description:text when:datetime
..will generate the controllers/views to create/edit/delete items. You can then easily wrap nicer looking HTML around it, add authentication (via restful_authentication), and you may have your completed application in a few hours..
Writing direct SQL queries is one of my strengths and I would like to use it. I heard that RoR is a pain to use if I am writing SQL queries directly. Is this true? Or can I just say execute a query, give me the results (as a list or dictionary) and then I will tell you how to render them?
There's very few situation where you'd need to write SQL with ActiveRecord, but you can. RoR is still Ruby code, so you can always use a MySQL library and do away with ActiveRecord if you really need to write raw SQL (but, again, you almost certainly don't)
I have heard that RoR does joins in memory and doesn't use the facilities offered by the database. Is this correct?
There's no reason ActiveRecord cannot perform JOIN's via SQL queries, the ActiveRecord::Associations::ClassMethods mentions associations being performed via JOIN's.
Besides, even if it does do JOINs through memory, it's worked perfectly well for however long Rails has been around..
I need to create a website that displays a lot of Images, videos and Java applets. Would RoR hinder my ability to do this?
No. They're all just bits of HTML, which Rails can output as easily as any other framework.
I am OK using a PHP framework. Is this a bad idea? If not, which PHP framework is closest to Rails in terms of programming convenience.
Absolutely. If you don't go with Rails, use a PHP framework!
I would recommend against choosing a framework based on "how close to Rails" it is. PHP isn't Ruby. Trying to "port" (in a manner) a framework to a different language rarely works as well as writing a framework for that language.
As I commented on Chuck's answer, "CodeIgniter and Zend are good PHP web-frameworks. CakePHP is a good Ruby on Rails imitation"..
I found CodeIgniter felt much more like PHP (in a good way), it's documentation is also my favourite of any project I've used!
The Zend Framework is very modular, you can drop bits of Zend into an existing PHP app, or use it's MVC routing system.
CakePHP seems to be trying to make PHP act like Ruby, rather than making a framework that fits nicely with PHP.
All that said, the reason you use Ruby on Rails is the community (and thus all the plugins and stuff that revolve around it).
For example, paperclip plugin makes it extremely easy to an image-upload form (along with thumbnailing). To use it you add (to your model):
has_attached_file :photo, :styles => {:thumb=> "100x100#", :small => "150x150>" }
Then in your view, where you want the upload form to be, add:
<% form_for :user, :html => { :multipart => true } do |f| %>
<%= f.file_field :photo%>
<% end %>
That's it.
What I would recommend is spend a day making something simple in Rails. There's countless great tutorials (Railscasts are a good, random, example) and plenty of books on it. See if you like it, if not try CodeIgniter, Zend or CakePHP (or Django, or Merb, or.... Just don't spend the whole month trying frameworks!)
As you have some Python experience have you had a look at Django?
Rails is great for CRUD stuff.
1 - If you're already familiar with Ruby and MVC, a month should be fine. If not, there's a lot to learn.
2 - Rails will let you execute SQL queries, but it's really set up to take advantage of ActiveRecord.
3 - Rails is designed to switch between database types, so ActiveRecord does a lot on its own. Look into ActiveRecord Associations for more info.
4 - Never tried Java applets, but the rest work fine.
5 - If you're more comfortable with a PHP framework it's not a bad idea at all. There are even a few that try to replicate a lot of Rails features, such as CodeIgniter.
Check out RailsGuides for a better idea about all this.
I am OK using a PHP framework. Is this
a bad idea? If not, which PHP
framework is closest to Rails in terms
of programming convenience.
I guess CakePHP is close to RoR for a PHP framework.
I have not tried Rails myself, but wonder if it is a convenience. As far as Ive read (like the guy who spent 2 years making Rails do something it should not) when you need to do something more complex you apparently have to fight and hack the framework.
There are other frameworks for Ruby, PHP and Python. I suggest you look around a bit more before you decide.
If you want to code in PHP you could try Symfony with Zend Framework.
The project should be done in a month and is very time sensitive. Is 1 month enough for learning with and building a website in RoR?
It could be, but it could also make things unnecessarily harder on you. I usually wait for a project with a relaxed timeline to try and learn a new technology. If time is of the essense, bust out your favorite language and get it done.
Writing direct SQL queries is one of my strengths and I would like to use it. I heard that RoR is a pain to use if I am writing SQL queries directly. Is this true? Or can I just say execute a query, give me the results (as a list or dictionary) and then I will tell you how to render them?
I am not a Rails developer, but I do know it uses ActiveRecord. I am sure, however, that there is also a way to make it execute raw queries as most ORM do. Right there however you're going against the grain of what the framework wants you do and you may run into problems.
I have heard that RoR does joins in memory and doesn't use the facilities offered by the database. Is this correct?
Anything that abstracts out things for you, particularly database relationships, is going to be far from efficient. Worrying about it beforehand is usually not necessary, and once your application is finished it is common practice to then identify any particular slow queries and redo them by hand if necessary.
I need to create a website that displays a lot of Images, videos and Java applets. Would RoR hinder my ability to do this?
I have no idea why it would.
I am OK using a PHP framework. Is this a bad idea? If not, which PHP framework is closest to Rails in terms of programming convenience.
CakePHP is by far the closest framework to RoR. It borrows from a lot of its ideas. I have used it with some success in the past. CodeIgniter, while not related to Rails, is also terrific if you want something lightweight that won't force you to do anything its way.
http://www.doctrine-project.org/
I've had great success with the doctrine ORM : if you are writing object oriented php then this does the object->database record mapping for you. AFAIK this is one of the plusses to the django / rails framework.
So this links up the oop/database functionality like this:
$foo = new User(); // makes a new 'transitory' user object
$foo->name = 'bob'; // works like you'd expect
$foo->save(); // but this pushes it into the database.
//(There's a 'name' column in the 'User' table already: set up when Doctrine initializes).
& if you want a framework, it's a part of symfony now.
It's very motivating to have a real project to learn a new technology or approach, but it is possible to take on too much. It'll take 5 times longer than you'd take in the technology you know. Which can be okay - the learning, and the results might be worth it. But doesn't sound like this is appropriate here.
Rails is a great framework, but learning that framework and becoming more familiar with constructs specific to Ruby might be a bit much to do simultaneously with a one month deadline.
To step into a web application framework, I would recommend using a PHP framework if you are already familiar with PHP. While not a port, CakePHP is very much similar to Rails. It is modeled after Rails, and is my favorite PHP framework. symfony is a solid framework, but if you're looking for something more Rails-esque I recommend you try CakePHP.
If you're not already married to using Rails or something like it, I would recommend the Zend Framework. It is by far the most comprehensive web application framework available for PHP.
All of these frameworks will allow you to do all of the things you mentioned. It might be easier to think of them as a select group of building blocks than a comprehensive operating system for your website that you extend with plug-ins. That would be more similar to a CMS like ExpressionEngine. You can do anything with these frameworks, they're simply code bases for you to draw from to make developing web applications less tedious.
The Akelos framework is a PHP framework that purports being a port of Rails, so you might also be interested in that.
As for writing SQL queries, it's possible with any PHP framework, but the idea behind these frameworks is convention over configuration. Each has its own ORM scheme to abstract SQL queries away from the developers. While this might be due to the fact that many web developers, at least in my experience, are terrified of SQL, as someone who also likes writing SQL, I do appreciate the massive amounts of time that an ORM framework can save. Again, when the application is developed it's pretty much standard practice to profile the ORM's performance and look for areas to improve. Rapid-prototyping is a huge part of web application frameworks, so tools like this might actually be a hindrance to you. Like others have said, using one of these frameworks might end up being pointless if you're just going to work around their facilities.
Should you decide not to use one of these, PHP has a plethora of mature projects that will help you build an application, but seeking these out and learning how to implement them may take a great deal longer than learning a framework.
IMO a month is very tight to learn and launch in a month ( I'm assuming you're not full time though ) and you wouldn't be full time if you're learning as well. You know how it is when you get deeper.
About a month ago I faced the same dilemma between RoR and MVC. After a few weeks (learning at night ) I learned enough about RoR framework but ruby language was very new to me, the client wanted delivery and I was still in the "playground/sandbox" phase
So, because I know c# and the .net framework well and I can find resources quickly I have since open for MVC and within 2 weeks I've delivered something to the client.
So in my experience, learn RoR give it a week. If you're finding it takes more than say 40 hours to get going with the actual application, then stick with PHP and do RoR when you have more time and less time restraints.
Goodluck either way though!!
If you're comfortable with Model View Controller stucture then Ruby on Rails isn't too hard to learn. I myself came from PHP's Zend Framework to Ruby on Rails and really found it a relief. I like the whole idea of convention over configuration that Rails uses. It keeps your application (and all future applications) well structured, which in my option is extremely important and time saving.
At this time I've been programming in Ruby with Rails for maybe about 6-7 months and I'm really enjoying it. Clean code, VERY fast development, it's really incredible. Especially with the generator files and database migrations.
As for RoR being a pain when writing raw queries, I'm not sure, I never even have to write them but you sure can with a simple method. That shouldn't be a problem.
Once I started developing web applications in Ruby on Rails, I did not want to go back to PHP. Purely because I'm pretty much in love with how Rails works, the conventions, rapid development, clean code, consistent structure etc etc etc. But these days I now and then still get asked by clients to develop a web application with PHP. But in my eyes, if I went back in to Zend Framework I'd probably really get stressed as I find it extremely inefficient. (That might be my own fault, I'm not sure, but in my eyes, compared to Rails, meh). I discovered the PHP Framework "CakePHP". This framework is as far as I know the closest thing to Rails and I currently use it to develop PHP applications. It's pretty straightforward and works great. It also has a VERY nice thing called the "cookbook" on their website which helps you get up and running very quickly. So if you were to choose a PHP framework I would personally go with CakePHP just because its the closest thing to Rails.
The only thing I myself am a little annoyed about with Rails is that it requires a certain version of Rails to be installed, and that version must be compatible with a specific version of Ruby. You'll need to get the hang of Gems, Plugins (which aren't hard to understand, to be honest). But along with deployment, if you're running Apache 2+ then you need Passenger. Also to be safe you will want to freeze your gems and that kind of stuff to avoid conflicts with the servers specifications and installed utilities.
There's a lot more to learn than just the language and the framework when it comes to Ruby on Rails. PHP is pretty simple, just upload and it works. So you might want to look in to that as well before developing the application.
I think Rails is great, and it would be my first choice for such a project, but if you are in fact under a tight deadline and you are starting from square one with Rails, just don't do it. Go with what you know. PHP might not be the greatest, but it's a very serviceable language.
Despite what people might say, Rails does have a non-trivial learning curve, especially if you are not familiar with MVC. There's definitely a "Rails Way" to do things, and coming from most other frameworks, it takes a while to grok.
I think if you try to rush and learn Rails, you're just going to get frustrated, and I'm afraid this would taint your impression of it. Instead, try learning it in your spare time, or on a project with a more relaxed timeline. I think you'll get a lot more out of it this way.
I think adding the complexity of rewriting what you already know in a month - on a time sensitive project is a bad idea. Using any framework/tools you are unfamiliar with is probably a bad choice on any "time sensitive" project.
That being said the Zend_Framework for php is pretty solid with its form abstractions. I found an easier time moving to ZF than RoR - I tried both at the same time.
The documentation for ZF is fair - reading the actual code of the library is still my best source for documentation though. It isn't that tough to learn or start up - and if you don't mind IRC / stackoverflowing questions you should be able to learn it pretty fast.
Don't board the Rails train just because it looks cool. I know it's what everyone is talking about these days but to be honest, it's really not that special and you'd be better off using a framework written in a language you are comfortable with. If you are really good at SQL then it would take longer to learn how to use ActiveRecord than to just write the queries by hand, and ActiveRecord is basically half of Rails, which kind of defeats the purpose of using the framework. So based on the background info you provided, I'd say go with a PHP framework like CodeIgniter (haven't used it myself but I heard it's great, sounds like what you need).
The project should be done in a month
and is very time sensitive. Is 1 month
enough for learning with and building
a website in RoR?
As its been said before, stick with what you know if the deadline is short.
I am OK using a PHP framework. Is this
a bad idea? If not, which PHP
framework is closest to Rails in terms
of programming convenience.
CakePHP is very ruby like and I have been told that its a good stepping stone for PHP programmers to get in to Ruby and MVC.
use php + Zend Framework it's have all features of ror and more faster
ror is very slow, very expensive, and require powerful server
* The project should be done in a month and is very time sensitive. Is 1 month enough for learning with and building a website in RoR?
it's enough to learn Zend Framework
* Writing direct SQL queries is one of my strengths and I would like to use it. I heard that RoR is a pain to use if I am writing SQL queries directly. Is this true? Or can I just say execute a query, give me the results (as a list or dictionary) and then I will tell you how to render them?
should to writing SQL queries directly, ror make very slow and unoptimization queries
* I am OK using a PHP framework. Is this a bad idea? If not, which PHP framework is closest to Rails in terms of programming convenience.
all you need is mvc framework, I offer you take Zend Framework
For 1 month project use what you know better! Until now I have used Qcodo and Qcubed, but you generate your interface only from the database. Any PHP framework uses DSL. I love Python as language but never used. I was looking Ruby On Rails yesterday and it seems pretty nice. RoR has provided a new way to write agile web applications, but now there is grails too. Grails is written in Groovy, runs over the JVM and is dynamic language. The strengh of Grails is that can use any Java code and framework but with the simplicity of a dynamic language. With Grails you can do the same things of Rails and even more.
My advice, use what you know better, meanwhile learn Grails, this is what I am doing now.
Is 1 month
enough for learning with and building
a website in RoR?
Yes.
Writing direct SQL queries is one of
my strengths and I would like to use
it. I heard that RoR is a pain to use
if I am writing SQL queries directly.
Is this true? Or can I just say
execute a query, give me the results
(as a list or dictionary) and then I
will tell you how to render them?
Writing raw sql with Rails is not any more difficult than doing it with PHP. The object returned will be a hash of column-name/value pairs. The only problem may come if you decide to start using ActiveRecord which returns an ActiveRecord object (not a plain hash)
I have heard that RoR does joins in
memory and doesn't use the facilities
offered by the database. Is this
correct?
If you use raw sql, Rails shouldn't interfere with it.
I need to create a website that
displays a lot of Images, videos and
Java applets. Would RoR hinder my
ability to do this?
No.
I am OK using a PHP framework. Is this
a bad idea? If not, which PHP
framework is closest to Rails in terms
of programming convenience.
IDK.
I really like using ActiveRecord, but if you prefer raw sql, Rails can still be worth using. You'll get good url handling, a lot of built-in security, nice MVC architecture, and a nifty templating system, all while writing Ruby, which for many, has been a good experience.
Nice thread - some great comments in here everyone. This has been useful to me.
I have a relatively simple application up and working with some basic functionality which i have built as a bit of a project. I would like to now build on that, and add some more complex features, including login.
The code has got quite complex, and it's written in plain php, so all the presentation code is mixed in with the logic. I have decided that before I go any further I'd like to re factor it to separate this out, so it's easier to maintain and add to. I've been researching MVC and think that's the way i should be going.
I had decided to give the zend framework a go, and have spent a while trying to get to grips with it, however I have found the learning curve extremely steep as I have no object oriented experience.
Is there another framework or option that anyone could recommend? I am considering having a look at cake based on reading other posts in this forum but I'd accept any guidance - my "requirments" are
easiest to learn for non OO experience
includes some login / authentication features
handles database interaction with mysql easily.
All suggestions appreciated!
As stated very eloquently here already, frameworks are good until you want to do something they're not suited for, plus they can abstract the language to the point where you're effectively learning them rather than the language you're coding in.
I would encourage you to roll your own. If you understand the principles of MVC and you have a fair-to-middling knowledge of PHP then it won't be too hard (there's already several pointers around), plus you'll come out of it far further ahead than if you'd just used someone else's.
Smarty templating engine.
http://www.smarty.net/
I've personally used Symfony. It's a very complete and well-supported framework which is relatively easy to get started with. My experience with frameworks is that for simpler projects they can be quite a burdon.
The people at my workplace swear by Cake. It does seems to be quite flexible and certainly fast to develop with once you know it. However, I would echo da5id and say that it's always safest to build your own - you know exactly how it works, you get some good PHP experience (instead of Cake experience), and you don't have to spend hours either fighting with it to get it do do what you want, or reading up on how to use it in the first place.
I am not at all convinced that "MVC" really exists as a paradigm in PHP incidentally - the V and the C are so hopelessly intertwined in most cases because the form is the view.
Build yourself a code generator that will output PHP classes based on your database tables. If you're really clever you can get it to inspect the database for relationships and even build the joins in PHP too. Then create a second set of classes that each inherit from the table-based-class that lets you customize its behaviour. Rely on these secondary classes in your business code. (It's a form of the Generation Gap pattern)
In addition to being a framework, Fat-Free also has its own templating engine that goes beyond just variable substitution. It allows you to invoke functions and class/object methods along with familiar PHP-like expressions.
I want to create a 100% object oriented framework in PHP with no procedural programming at all, and where everything is an object. Much like Java except it will be done in PHP.
Any pointers at what features this thing should have, should it use any of the existing design patterns such as MVC? How creating objects for every table in the database would be possible, and how displaying of HTML templates etc would be done?
Please don't link to an existing framework because I want to do this on my own mainly as a learning excercise. You will be downvoted for linking to an existing framework as your answer and saying 'this does what you want'.
Some features I'd like to have are:
Very easy CRUD page generation
AJAX based pagination
Ajax based form validation if possible, or very easy form validation
Sortable tables
Ability to edit HTML templates using PHP
I've gone through many of problems on your list, so let me spec out how I handle it. I am also OOP addict and find object techniques extremely flexible and powerful yet elegant (if done correctly).
MVC - yes, hands down, MVC is a standard for web applications. It is well documented and understandable model. Furthermore, it does on application level what OOP does on class level, that is, it keeps things separated. Nice addition to MVC is Intercepting Filter pattern. It helps to attach filters for pre- and post-processing request and response. Common use is logging requests, benchmarking, access checking, caching, etc.
OOP representation of database tables/rows is also possible. I use DAO or ActiveRecord on daily basis. Another approach to ORM issues is Row Data Gateway and Table Data Gateway. Here's example implementation of TDG utilising ArrayAccess interface.
HTML templates also can be represented as objects. I use View objects in conjunction with Smarty template engine. I find this technique EXTREMELY flexible, quick, and easy to use. Object representing view should implement __set method so every property gets propagated into Smarty template. Additionally __toString method should be implemented to support views nesting. See example:
$s = new View();
$s->template = 'view/status-bar.tpl';
$s->username = "John Doe";
$page = new View();
$page->template = 'view/page.tpl';
$page->statusBar = $s;
echo $page;
Contents of view/status-bar.tpl:
<div id="status-bar"> Hello {$username} </div>
Contents of view/page.tpl:
<html>
<head>....</head>
<body>
<ul id="main-menu">.....</ul>
{$statusBar}
... rest of the page ...
</body>
</html>
This way you only need to echo $page and inner view (status bar) will be automatically transformed into HTML. Look at complete implementation here. By the way, using one of Intercepting Filters you can wrap the returned view with HTML footer and header, so you don't have to worry about returning complete page from your controller.
The question of whether to use Ajax or not should not be important at time of design. The framework should be flexible enough to support Ajax natively.
Form validation is definitely the thing that could be done in OO manner. Build complex validator object using Composite pattern. Composite validator should iterate through form fields and assigned simple validators and give you Yes/No answer. It also should return error messages so you can update the form (via Ajax or page reload).
Another handy element is automatic translation class for changing data in db to be suitable for user interface. For example, if you have INT(1) field in db representing boolean state and use checkbox in HTML that results in empty string or "on" in _POST or _GET array you cannot just assign one into another. Having translation service that alters the data to be suitable for View or for db is a clean way of sanitizing data. Also, complexity of translation class does not litter your controller code even during very complex transformations (like the one converting Wiki syntax into HTML).
Also i18n problems can be solved using object oriented techniques. I like using __ function (double underscore) to get localised messages. The function instead of performing a lookup and returning message gives me a Proxy object and pre-registers message for later lookup. Once Proxy object is pushed into View AND View is being converted into HTML, i18n backend does look up for all pre-registered messages. This way only one query is run that returns all requested messages.
Access controll issues can be addressed using Business Delegate pattern. I described it in my other Stackoverflow answer.
Finally, if you would like to play with existing code that is fully object oriented, take look at Tigermouse framework. There are some UML diagrams on the page that may help you understand how things work. Please feel free to take over further development of this project, as I have no more time to work on it.
Have a nice hacking!
Now at the risk of being downvoted, whilst at the same time being someone who is developing their own framework, I feel compelled to tell you to at least get some experience using existing frameworks. It doesn't have to be a vast amount of experience maybe do some beginner tutorials for each of the popular ones.
Considering the amount of time it takes to build a good framework, taking the time to look into what you like and loathe about existing solutions will pale in comparison. You don't even need to just look at php frameworks. Rails, Django etc are all popular for a reason.
Building a framework is rewarding, but you need a clear plan and understanding of the task at hand, which is where research comes in.
Some answers to your questions:
Yes, it should probably use MVC as the model view controller paradigm translates well into the world of web applications.
For creating models from records in tables in your database, look into ORM's and the Active Record pattern. Existing implementations to research that I know of include Doctrine, more can be found by searching on here.
For anything AJAX related I suggest using jQuery as a starting point as it makes AJAX very easy to get up and running.
Creating your own framework is a good way to gain an appreciation for some of the things that might be going on under the hood of other frameworks. If you're a perfectionist like me, it gives you a good excuse to agonize over every little detail (e.g. is should that object be called X or Y, should I use a static method or an instance method for this).
I wrote my own (almost completely OO framework a while ago), so here's my advice:
If you've worked with other frameworks before, consider what you liked/didn't like and make sure yours gives you exactly what you want.
I personally love the MVC pattern, I wouldn't dream of doing a project without it. If you like MVC, do it, if you don't don't bother.
If you want to do JavaScript/AJAX stuff, do use a JavaScript library. Coding all your own JavaScript from scratch teaches you a bit about the DOM and JavaScript in general, but ultimately its a waste of time, focus on making your app/framework better instead.
If you don't want to adopt another framework wholesale, take a look at whether there are other open source components you like and might want to use, such as Propel, Smarty, ADOdb, or PEAR components. Writing your own framework doesn't necessarily mean writing everything from scratch.
Use design patterns where they make sense (e.g. singletons for database access perhaps), but don't obsess over them. Ultimately do whatever you think produces the neatest code.
Lastly, I learned a lot by delving into a bit of Ruby on Rails philosophy, You may never use RoR (I didn't), but some of the concepts (especially Convention over Configuration) really resonated with me and really influenced my thinking.
Ultimately, unless your needs are special most people will be more productive if they adopt an existing framework. But reinventing the wheel does teach you more about wheels.
At the risk of sounding glib, this seems to me like any other software project, in this sense:
You need to define your requirements clearly, including motivation and priorities:
WHY do this? What are the key benefits you hope to realize? If the answer is "speed" you might do one thing, if it's "ease of coding" you might do another, if it's "learning experience" you might do a thid
what are the main problems you're trying to solve? And which are most important? Security? Easy UI generation? Scalability?
The answer to "what features it should have" really depends on answers to questions like those above.
Here are my suggestions:
Stop what you're doing.
It's already been done to death.
Click this Zend Framework or that CakePHP or maybe even this Recess Framework.
Now, my reasons:
... if you've worked with developers at all, you've worked with developers that love reinventing the wheel for no good reason. This is a very, very common failure pattern.
... they would go off and write hundreds and thousands of the crappiest languages you could possibly imagine ...
... "Oh, I'm gonna create my own framework, create my own everything," and it's all gonna be crappier than stuff you could just go out and get ...
from StackOverflow Podcast # 3.
So, save yourself some time, and work on something that solves a problem for people like a web app that lets people automatically update Twitter when their cat's litter box needs cleaning. The problem of "Object Oriented PHP Framework" is done. Whatever framework you slap together will never be as reliable or useful or feature rich as any of the freely available, fully supported frameworks available TODAY.
This doesn't mean you can't have a learning experience, but why do it in the dark, creating a framework that will grow into a useless blob of code, leaving you without anything to show for your time? Develop a web app, something for people to use and enjoy, I think you'll find the experience incredibly rewarding and EDUCATIONAL.
Like Jim OHalloran said, writing your own framework gives you a very good insight into how other frameworks do things.
That said, I've written a data-access layer before that almost completely abstracted away any SQL. Application code could request the relevant object and the abstraction layer did lots of magic to fetch the data only when it was needed, didn't needlessly re-fetch, saved only when it was changed, and supported putting some objects on different databases. It also supported replicated databases, and respected replication lag, and had an intelligent collection object. It was also highly extensible: the core was parameter driven and I could add a whole new object with about 15 lines of code - and got all the magic for free.
I've also written a CRUD layout engine which was used for a considerable percentage of a site. The core was parameter driven so it could run list and edit pages for anything, once you wrote a parameter list. It automatically did pagination, save-new-delete support etc etc, leveraging the object layer above. It wasn't object-oriented in and of itself, but it could have been made so.
In other words, a object-oriented framework in PHP is not only possible, it can be very efficient. This was all in PHP 4, BTW, and I bumped up against what was possible with PHP 4 objects a couple of times. :-)
I never got as far as a central dispatch that called objects, but I wasn't far away. I've worked with several frameworks that do that, though, and the file layout can get hairy quickly. For that reason, I would go for a dispatch system that is only as complex as it needs to be and no more. A simple action/view (which is almost MVC anyway) should get you more than far enough.
I initially started creating my own framework with similar ideals to your own. However, after a couple of months I realised I was re-creating work that had been done many times over. In the end I found an open source framework which was easily extendable and used it as a basis for my own development.
The features I implemented myself:
MVC Architecture
Authentication object
Database access class
URL rewriting config
Pagination class
Email class
Encryption
The features I looked at and thought, forget it! I'll build on top of someone elses:
Caching class
Form validation class
FTP class
Plugin-ability classes
Of course, writing a framework that outperforms the open source options is possible, but why would you bother?
It's true that some developers reinvent the wheel for no good reason. But because there are already good frameworks around doesn't mean that it's a waste of time doing one yourself. I started on one a while ago with no intention of using it for anything more than an exercise. I highly recommend doing it.
I've got the perfect link for you my friend: http://nettuts.com/tutorials/php/creating-a-php5-framework-part-1/. This is an awesome tutorial I have looked at, and its not too overwhelming. Plus look around the PHP section of that site I saw an article on CRUD. As for the AJAX look elsewhere, but you have to start somewhere, and this tutorial is awesome.
Note: this tutorial has 3 parts and I think it brings up MVC in the second instalment, but starts the first part using other methods.
The one, huge selling point I would look for in a new framework is that it would make writing testable code easy.
We typically work with Zend Framework, and it's mostly awesome, but trying to unit test/test drive ZF-based code is not far short of masochism.
If you could provide a framework that replaces the MVC parts of ZF with something that allows us to write testable code, whilst still allowing us to use the library parts of ZF, I will - quite literally - buy you a beer.
I'll buy you two beers if you ditch the AJAX. There's a huge gulf between an OO PHP framework and a JavaScript framework.
Please don't link to an existing framework
I will not, I started writing my own for learning purposes, and took a peek into some of the mainstream frameworks, and even with my limited knowledge see so many mistakes and bad ideas in them.
They're built by hardcore developers, not end users.
I'm in no way saying I could write better than the "big boys" but I (along with most of you I imagine) could point out why some things they do are bad, even if just because they're not end user/non-developer friendly...
I wonder how your framework is doing, some 6 years on?
Are you still working on it? Did you stop?
Should You Write Your Own Framework
This is probably a little late for you, but for anyone else, writing your own framework is a fantastic thing to do for learning purposes.
If, however, you are wanting to write one other than learning purposes, because you cannot work out the one you are using, or because it's too bloated, then do not!
Believe me, and don't be insulted, you would not be here contemplating it if you are a knowledgeable enough developer to do so successfully!
Last year I wanted to learn OOP/classes, and more advanced PHP.
And writing my own framework was the best thing I did (am actually still doing), as I have learned so much more than I anticipated.
Along the way I've learned (to name a few):
OOP/Classes many best practices which come with it - such as
Dependency Injection, SRP
Design patterns, which help you write code and structure your system
in such a way that it makes many things logical and easy. For an
example see Wiki - SOLID
Namespaces
PHP Error Handling and all of the functionality which that provides
A more robust (and better) understanding of MVC, and how to apply it
appropriately (as there is no clear cut way to use it, just guides
and best practices).
Autoloading (of classes for OOP)
Better code writing style and more structured layout, and better
commenting skills
Naming conventions (it's fun making your own, even if based on
common practices).
And many other basic PHP things which you invariably come across accidentally from reading something.
All of this not only vastly improved my grasp of PHP and things which come with it, to a more advanced level, but also some of the commercially/widely used methods and principles.
And this all boosted my confidence in using PHP in general, which in turns makes it easier to learn.
Why Write a Framework To Learn All of This
When you start out, you learn the basics - A (variables), then B (how to write a basic function), etc.
But it doesn't take long when you're trying to learn more advanced things, that to learn and use D and E, you also have to learn and understand F, G, H, and J, and to know those you have to know K, L, and M, and to know parts of L and M you first need to understand N and O...
It becomes a minefield as trying to learn one thing brings the need to first learn a few other things, and those other things often bring a need to understand various other things.
And you end up a mile away from where you started, your mind tingling and shooting sparks from it, and about 20 tabs open all with various advanced PHP things, none of which you are 100% comfortable with.
But over time, with practice and most certainly dedication, it will all fit into place, and you'll look back at code, even a collection of files/classes, and think "Did I write that.."?
Writing a framework helped greatly with this "minefield" because:
I had specific tasks to do, which brought about the need to learn and
implement other things, but specific things. This allowed me to focus
on less things at once, and even when something branches off to
various other things, you can reel it back in to where you started
because you are working on something specific. You can do this with
any learning, but if you do not have some goal, or specific task you
are focusing on, you can easily get distracted and lost in the ether
of things to learn.
I had something practical to work with. Often reading tutorials about
an animal class, and how cat and dog classes extend animal etc,
can be confusing. When you have a real life task in your own
framework, such as how do I manage XYZ, then you can learn how
classes work easier because you have trial and error and a solid
requirement which you understand, because you created the
requirement! Not just theory-like reading which means nothing
usually.
I could put it down when my mind was blown, although as it was my
framework (my Frankenstein's monster in the beginning :P) I wanted to
press on, because it was interesting, and a personal goal to learn
and sort the next stage, to resolve an issue I was stuck with, etc.
You can do it how you want. It might not be best practice, but as long as you are trying to learn best practice, over time you will improve, and likely easier than just reading tutorials, because you are in control of what and how you do something.
Wait, I Shouldn't Re-invent the Wheel Though
Well, firstly, you cannot reinvent the wheel, it is impossible, as you will just make a wheel.
When people say "Don't reinvent the wheel", they of course mean "there are already frameworks out there", and to be fair, they are written by skilled developers.
That's not to say the frameworks don't have problems or issues, but in general they are pretty solid, secure and well written.
But the statement is nonsensical in relation to writing your own framework!
Writing your own framework for learning purposes is really useful.
Even if you plan to use it commercially, or for your own website, you haven't just "re-invented the wheel", you've made something else.
Your framework won't be like the others, it won't have many features and functionality, which might be a major advantage to you!
As long as you understand about best security practices etc, because you can think you are writing a great system, which is super fast and without all the bloat other frameworks have, but in fact you have holes in places which someone could crawl into...
But a project for learning which you don't use on the internet is ideal - or use it, eventually, when you are advanced enough to know it's secure!
With all that said, you should write your own framework IF:
You are not needing it any time soon! It takes a lot of time as
there are so many aspects to consider, learn, and trial and error
leads to refactoring (a lot at first!)
You are willing to read, code, test, change, read, code, and read
some more. There is a lot of good advice on the internet for advanced
PHP, most of it mind blowing at first, like reading all the design
patterns. But they eventually make sense, and end up helping you
resolve problems you face, and how to do things within your
framework.
Willing to put the time in, and keep trying to improve, and head
towards best practice, especially with security. Speed issues shouldn't be an issue with a small framework, and besides, if you have a fairly decent system, you can usually refactor and make speed improvements. usually if you have significant speed issues it means you've chosen intensive operations, which can usually be addressed by doing it a different way.
.
Without previous experience, or an advanced knowledge of PHP, you will likely spend some time writing a framework, further reading and knowledge will show you that your approach is skewed, and so you might delete everything and start again.
Don't be disheartened by this.
I did exactly that, as I learned so much advanced patterns and ways of doing things along the way in the first month, I ended up where refactoring was no good, and a blank canvas with a whole new approach was the only option.
However, this was quite pleasing, as I saw a much better structure take form, and I could see not only a better framework foundation start to take place, but realised it was because I had a better understanding of advanced PHP.
Just do it! Just make sure you have a plan of what you want it to do before you even write some code.
Seriously, write down on paper how you are going to load error checking, are you going to have auto loading, or include files when needed? Are you going to have a centralised loading mechanism, which instantiates classes when you need them, or some other method?
Whatever you do, and whatever stage you are at, if you are heading into new territory, plan it first. You'll be glad of it when you hit a brick wall, can go back to your plans, and realise a slight deviation to your plans will resolve it.
Otherwise you just end up with a mess and no plan or way to re-deign it to resolve the current problem or requirement you face.
You are looking to build exactly same thing I've worked on for a few years and the result is Agile Toolkit.
Very easy CRUD page generation
$page->add('CRUD')->setModel('User');
AJAX based pagination
All pagination and many other things are implemented through a native support for AJAX and Object Reloading. Below code shows a themed button with random label. Button is reloaded if clicked showing new number.
$b=$page->add('Button')->setLabel(rand(1,50));
$b->js('click')->reload();
Ajax based form validation if possible, or very easy form validation
All form validations is AJAX based. Response from server is a JavaScript chain which instructs browser to either highlight and display error message or to redirect to a next page or perform any other javascript action.
Sortable tables
Table sorting and pagination has a very intuitive and simple implementation when you can really on object reloading.
Ability to edit HTML templates using PHP
This seems out of place and a wrong thing to do. Templates are better of in the VCS.