| SitePoint Sponsor |
Not sure if this should go in the PHP forum or the Ruby forum, but since this one is new and needs more posts, I'll put it here.
I'm curious to hear from people who have used both, how does PHPonTrax (which calls itself and RoR clone), compare to Ruby on Rails?
Off Topic:
Does anyone else find it funny, that 37Signals, the people who invented Ruby on Rails, use php-based PunBB for the Basecamp forums? :P http://www.basecamphq.com/forum/
I think PHPontrax is new. Let me try it.
I don't think 37signals people have enough time to code a forum once again! Since there are already great forums available to use, they did! That's what I believe
No, why reinvent the wheel? PunBB is a perfectly good piece of forum software. I'm sure they've got better things to do than waste their time on yet another piece of forum software.Does anyone else find it funny, that 37Signals, the people who invented Ruby on Rails, use php-based PunBB for the Basecamp forums? :P http://www.basecamphq.com/forum/
PHP Rails clones keep on coming out of the woodwork but they will never be as expressive and elegant as Rails, due to PHP's limitations (or more accurately, Ruby's advantages and ability to create great DSLs). By all means try them out but I'd always recommend Rails as the Ruby language and the expressiveness of Rails as a result of this is part of what makes using it so enjoyable.
Parts of the official ROR website use PHP too.
I don't think PHPonTrax is as good as Rails because you'll still be coding in PHP, and that isn't as clean as Ruby.
I've just been having a look at PHPonTrax today and it looks promising as a Rails clone, but it's nowhere near finished yet.
I was hoping it'd give me an easier intro to Rails before/while learning Ruby but there's only really the base functionality there so far.
Ditto, I agree, the clones will never have everything Rails has because Ruby is a superior language. The only exception I could say would be Python (Only coz it's similar to ruby on the surface), which if I remember rightly has CherryPy. The PHP and Java ports will never be that good.Originally Posted by Fenrir2
Personally, I would stick to Cake if you have to use PHP. It's more mature. However, I can safely say that in my old job, when we were deciding to move to Rails / Ruby or Cake / PHP, we were happy we went with Ruby in the end. It's a lot more elegant as a language, and doesn't take long to learn
I made a point of this in some other topic today:
PHP on Trax (http://phpontrax.com):
1. TRUE TO RAILS: Follow Rails as closely as possible. Others (e.g. Cake) does not.
a. benefit: Rails is great, why stray?
b. benefit: Only need to really learn one framework (instead of many) for all those who do both ruby and php.
2. FAMILIARITY: Ruby is not hard to learn, but this framework will allow smoother transition for those desiring to adopt Ruby in addition to PHP.
3. LIBRARIES: Works with PEAR, It is farther along than they mention on their site (in other ways as well). Ruby does not have enough libraries yet, although we hope they will grow quickly.
4. Supports PHP5, which is one step closer to true OO.
5. MORE: I will try to get some updates from the Trax guys this weekend, as well as input from current users of Trax--since I know the head dev.
(http://phpontrax.com)
What libraries does ruby not have that you need? I find that while its true that ruby may have less libs than php, the quality of these libs is vastly superior. The attitude in the ruby community is usually closer to having one or two high quality libs that do the same thing but do it well as compared to php where there are hundreds of libs but much of them are of dubious quality.
Using ruby only instead of php for the last year coming from 5 years of php here. I haven't come across a situation yet where there was some lib I needed that was missing from ruby. And if anything was missing it is usually because it would be trivial to write yourself. You really ought to try ruby more and get to know whats available for it before saying it has missing libraries. Also trying to clone rails with php no matter how close you try to stay with the rails way of doing things, there are going to be rubyisms that just can't be handled anywhere near as elegantly with php. Ruby is really not that hard to learn if you know php well enough to use a framework like this, so your time might be better spent actually expanding your horizons and learning the real rails/ruby. I think you will be more than pleased that you did. I know I am ;-)
Cheers-
-Ezra
While this is undoubtedly true, there are still many occasions where one has no choice but to use PHP, so there definitely is a need for a php framework that's as easy to use as rails is. To that end, I fully encourage people to port rails to php as much as they want.
As for PHP on Trax itself, it is more Rails-like than Cake is, but it isn't quite a rails clone. It's certainly lacking a lot of the functionality found in rails, but that may be just a question of time.
You're right. If you are stuck with php as a platform then these rails clones could definitely be a good alternative. I'm not knocking php as a language or the rails clone frameworks if you are stuck in phpland. But if you have a greenfield project and have a choice of rails versus a rails clone in x language, then I would definitely go with rails. I might be biased thoug. I now make 100% of my income working with ruby/rails ;-)
True, but its pretty much one serious developer, and a couple others that have added a few contributions, so it really needs some community support to really move forward.
Rails, IMHO, isn't that good. Using rails I'm forced to use ActiveRecord. CRUD doesn't help me at all. I use SQLite/Firebird and transactions with multi-table queries/inserts. I use a PHP-specific Object Database. I also use XML databases and SOAP resources. CRUD can't use any of those.a. benefit: Rails is great, why stray?
I'm also forced to intermix code and HTML. Erm, no. I stopped sucking my thumb when I was 4.
OK. Sounds good. But what about improvement? I'm sure that there'll be some way of improving the model, database abstraction, etc. All that "learning one framework" will achive is stopping progression. Isn't invention born of necessity?Only need to really learn one framework (instead of many) for all those who do both ruby and php.
I'm still looking for decent XML and XSLT libraries. All I want to do is translate an object to XML, and use XSL to translate that. PHP4? Easy. PHP5? Easier! Ruby? Erm... err... well... still waiting for all the RoR bods to point me in the right direction. And if the result is not as quick as PHP's XML extension then sorry, but I'll see you in a few years when I've got to convert someone's Ruby app into PHP7.What libraries does ruby not have that you need?
Also, I'd like to see a very simple db abstraction layer. Not ActiveRecord, no ORM, nothing as over-blown as that. Something simple, like the Eclipse library that used to be available for PHP4 (and which I still use and have ported to PHP5 for my own use). That baby was refactored to such a level that the developer just gave up because he couldn't go any further!
I'm not ruby bashing here.
Ruby is a lovely language to use, and I'm really enjoying playing with it. But Rails, IMHO, isn't all its played up to be. And all the RoR bods playing it up aren't really looking at what they're using from an objective (no pun intended) point of view. They're just feeding off they hype.
If you're looking for a simple, easy to use, and fully extensible framework for PHP look to Mojavi. You're not forced to use a specific db abstraction layer, model, or even render (you can add your own). I've studied lots of PHP frameworks over the past few years, and most are ports of Java/Ruby/Python frameworks. Mojavi is the first that is developed to play to PHP's strengths.
Check it out. You might be surprised.
Woah. Lets just stop here.
1) You aren't force to neccesarily forced to use ActiveRecord. You could use Og and another ORM called ActiveSchema is under development too. Rails doesn't lock you into any specific component.
2) Clearly if you are already working with a PHP-specific solution, then Rails isn't a good fit (or anything that isn't PHP).
3) I'm not quite sure what CRUD has to do with anything. There is nothing about Rails, or indeed ActiveRecord, that limits you to basic CRUD. ActiveRecord also has SQLite support and I believe Firebird support is there too. I can't comment on any database-specific functionality.
I'm sorry, but are you talking about? Templates are code. HTML is code. The idea that separation of code and HTML is good is a myth. It is the separation of business logic, control flow and presentation/view that you are after. Rails MVC model accomplishes this just fine.I'm also forced to intermix code and HTML. Erm, no. I stopped sucking my thumb when I was 4.
ERb is chosen as the default Rails templating model as it is easy, works and fits the one language to suit them all methodology. But that said, there is nothing stopping you from using alternative templating languages - if you like Smarty-style templating, you could use Liquid. Or you could build your views entirely with code, using the XML builder syntax.
I'm still confused when developers bring up reservations about mixing code and HTML. XSLT aside, what alternative is there exactly? You have to embed your data into your templates somehow.
I fail to see how using RubyOnRails stops progression. Thats a pretty throwaway statement with no real explanation.OK. Sounds good. But what about improvement? I'm sure that there'll be some way of improving the model, database abstraction, etc. All that "learning one framework" will achive is stopping progression. Isn't invention born of necessity?
Right...you've clearly missed REXML for XML parsing, Builder for construction, and XML-Mapping for object to XML mapping.I'm still looking for decent XML and XSLT libraries. All I want to do is translate an object to XML, and use XSL to translate that. PHP4? Easy. PHP5? Easier! Ruby? Erm... err... well... still waiting for all the RoR bods to point me in the right direction. And if the result is not as quick as PHP's XML extension then sorry, but I'll see you in a few years when I've got to convert someone's Ruby app into PHP7.
I'll ignore the flamebait comment about PHP7...lets come back to that once PHP has sorted out the mess that is its global namespace and function library, the lack of namespacing in general and pushed PHP6 out of the door ok?
Define DB abstraction layer. I presume you mean something that simply lets you interface with your database using a vendor-agnostic API. First of all, I question the overall use of such a thing if you are using database-specific features. But if thats all you want, then you simply need Ruby's DBI library.Also, I'd like to see a very simple db abstraction layer. Not ActiveRecord, no ORM, nothing as over-blown as that. Something simple, like the Eclipse library that used to be available for PHP4 (and which I still use and have ported to PHP5 for my own use). That baby was refactored to such a level that the developer just gave up because he couldn't go any further!
Why you would want to directly access your database instead of having a dedicated model layer for anything other than small, simple projects is beyond me though. ActiveRecord is the perfect solution for people who want to use an ORM without using something as extensive and complex as Hibernate for Java.
Perhaps not, but you are doing a good job of coming across as pretty ignorant.
I'm not ruby bashing here.
If Rails wasn't all its played up to be, the hype would have died long ago. People who play it up do so because they have used it. Many people, myself included, are already moving towards RubyOnRails from PHP, .NET and Java because its just incredibly good at what it does - provide a platform for building web applications. I hope you aren't suggesting that people are making concious business decisions to move to a new development platform on hype alone - how insulting.Ruby is a lovely language to use, and I'm really enjoying playing with it. But Rails, IMHO, isn't all its played up to be. And all the RoR bods playing it up aren't really looking at what they're using from an objective (no pun intended) point of view. They're just feeding off they hype.
Congratulations. You just described Rails. The only thing Rails binds you to is the MVC model and perhaps the Controller/Routing layer. As I have already explained, both the model and view layers are pluggable, you are free to use any Ruby library out there (quality, rather than quantity I find) and Rails is fully extensible...components, plugins, engines and further to that nothing is stopping you from extending the source (due to Ruby's wonderfully open nature).If you're looking for a simple, easy to use, and fully extensible framework for PHP look to Mojavi. You're not forced to use a specific db abstraction layer, model, or even render (you can add your own). I
I enjoy using Rails on a daily basis. I wouldn't use Mojavi if you paid me. I've used it, it was unbelievably verbose and I always felt like I was working against it. In retrospect, PHP's syntax doesn't help. Also, last time I read, v3 was no longer under active development. I could never go back to PHP for anything but the simplest of sites as I'd miss Ruby's wonderful syntax and fully OO model, and Rails' expressive DSL-like syntax. I'll happily go as far as stating that anybody who tried Mojavi after using Rails, and actually preferred it, is firmly in the minority, and a glutton for punishment I might add.
I have to agree with Luke. I used Mojavi for 2 years. The great thing about Mojavi is that there is no documentation. I can't even describe how much fun I had killing hours looking at source code, just to figure out basic functionality. Not to mention that Mojavi has gone from Mojavi2->Mojavi3->(Agavi Split)->Mojavi4, in a period of three years.
You want the layout feature of Rails in Mojavi? Ok, hack your own.
Rails kicks ***, the documentation is great, many books are being written about it!
-Steven
I've never seen the point of ORM. I can happily write efficient SQL, and understand how to use arrays. Why bother adding in an extra layer of confusion? I used propel for a short while, which was a nightmare. Queries were 100x slower than the equiv done in straight SQL wrapped in DAOs and using a basic abstraction layer.
Ah, well I may have that wrong. From chatting to ruby bods, it seems that a lot of apps are quick builds that have one or two tables with limited joins. How well would RoR/ActiveRecord handle left/right joins across 10 tables?3) I'm not quite sure what CRUD has to do with anything. There is nothing about Rails, or indeed ActiveRecord, that limits you to basic CRUD. ActiveRecord also has SQLite support and I believe Firebird support is there too. I can't comment on any database-specific functionality.
Oh. I mean, I'm not an overly advanced OOP programmer, but I thought it was a good thing to seperate the business logic and final output? I personally use XSL for my presentation logic after outputting straight XML. This has allowed me the flexibility and power to do things such as quickly change between HTML4/XHTML/Text/JSON/YAML and have my app act as a XML-RPC/SOAP resource.The idea that separation of code and HTML is good is a myth. It is the separation of business logic, control flow and presentation/view that you are after. Rails MVC model accomplishes this just fine.
Smarty was something I ran screaming from a long time ago.ERb is chosen as the default Rails templating model as it is easy, works and fits the one language to suit them all methodology. But that said, there is nothing stopping you from using alternative templating languages - if you like Smarty-style templating, you could use Liquid. Or you could build your views entirely with code, using the XML builder syntax.
The XML builder syntax sounds interesting. I'm currently passing objects to a renderer at the moment which are converted to XML without me having to do anything. Is this similar to what its doing?
I think its the fact that it ties you to HTML, which can be a limitation. Especially when you're creating an app that might have unexpected results. A short while ago RSS/ATOM wasn't that big, so everyone output straight HTML. Now they're having to back-track and create seperate output logic to cope with the rise in RSS/ATOM use. Seperating out the HTML from the View logic means you can switch between output formats without much overhead.I'm still confused when developers bring up reservations about mixing code and HTML. XSLT aside, what alternative is there exactly? You have to embed your data into your templates somehow.
I never said that. I said "learning one framework" will stop progression. A lot of people learn by example, and only having one source of inspiration may limit progression.I fail to see how using RubyOnRails stops progression. Thats a pretty throwaway statement with no real explanation.
Yes, I must have. I'll check further on those. Anything that will do quick XSL translation?Right...you've clearly missed REXML for XML parsing, Builder for construction, and XML-Mapping for object to XML mapping.
Hey, I never said PHP was "da bomb" or anything. It has its failings, just like every language. Remember, languages are like religion, and I'm buddhist!I'll ignore the flamebait comment about PHP7...lets come back to that once PHP has sorted out the mess that is its global namespace and function library, the lack of namespacing in general and pushed PHP6 out of the door ok?I personally think lack of namespacing is an outrage. But what they are concentrating on may be much more important, things like native UTF support, etc. Whats that song...? "Things can only get better"!
Yes. I try to keep with very straight-forward SQL when available. Although it is nice to use the odd MySQL or SQLite feature.Define DB abstraction layer. I presume you mean something that simply lets you interface with your database using a vendor-agnostic API. First of all, I question the overall use of such a thing if you are using database-specific features. But if thats all you want, then you simply need Ruby's DBI library.
Maybe I have missunderstood the benefits of ActiveRecord. I only know that without any ORM I've managed to save myself lots of time and effort by rendering db query results directly to XML.Why you would want to directly access your database instead of having a dedicated model layer for anything other than small, simple projects is beyond me though. ActiveRecord is the perfect solution for people who want to use an ORM without using something as extensive and complex as Hibernate for Java.
When putting the data into the db I've always found that straight SQL is much easier than ORM methods, and once the stuff's in there, I've no need to manipulate it when pulling it back out. ORM seems redundant when you think of it like that, IMHO. Maybe I've got things wrong?
That I am, but I've not met any on the RoR wagon as knowledgeable as you. I must be using the wrong forums. Keep your eye out for me - I'll be sticking around on sitepoint and your comments would be greatly appreciated!Perhaps not, but you are doing a good job of coming across as pretty ignorant.
Oh dear. I must have been working in the wrong companies. So many times have I heard the phrases "We're using X because (the client/investor wants us to|its better than Y/Z|I think it might be fun|I've always wanted to give it a go)". Thankfully I've got some input into the decisions now.I hope you aren't suggesting that people are making concious business decisions to move to a new development platform on hype alone - how insulting.
Great! I'm sure I'll learn more about it as I play. I humbly appologise for insulting RoR. Still, it would be useful if there were a good PHP to Ruby tutorial, like the ASP to PHP ones in the old days.Congratulations. You just described Rails. The only thing Rails binds you to is the MVC model and perhaps the Controller/Routing layer. As I have already explained, both the model and view layers are pluggable, you are free to use any Ruby library out there (quality, rather than quantity I find) and Rails is fully extensible...components, plugins, engines and further to that nothing is stopping you from extending the source (due to Ruby's wonderfully open nature).
I've found that if you go with the flow of Mojavi, and tweak where its needed, its actually a very helpful framework. In fact, using it has helped me create some apps in a *very* short time.I enjoy using Rails on a daily basis. I wouldn't use Mojavi if you paid me. I've used it, it was unbelievably verbose and I always felt like I was working against it. In retrospect, PHP's syntax doesn't help. Also, last time I read, v3 was no longer under active development. I could never go back to PHP for anything but the simplest of sites as I'd miss Ruby's wonderful syntax and fully OO model, and Rails' expressive DSL-like syntax. I'll happily go as far as stating that anybody who tried Mojavi after using Rails, and actually preferred it, is firmly in the minority, and a glutton for punishment I might add.
FYI (bolded to catch the eye of other readers):
M3 is currently out as a stable release, and M4 under active development in its planning phase. The project has just been handed over from the creator to the community, which is lacking a majority of good OOP programmers. If you're than unhappy with Mojavi, why not voice your concerns on the forum and help them change things for the better? I'm sure we'd all appreciate your expertise.
Thank you for setting me straight. Away I go to dig more into RoR!
OK, lets take this one at a time.
The point of an ORM is usually to decouple your domain model from the database. Whilst this isn't strictly the case with ActiveRecord, that is a limitation of the Active Record pattern, not ORM in general. However, even with ActiveRecord, it enables you to treat your domain objects like any other object, i.e.:
I appreciate the point about query speed (though I question the 100x slower claim), however I do not think that an "optimise first" approach is a good thing. Come up with a strong design first, optimise later. Get a working application then think about tuning it where needed. If speed is of the utmost importance, use direct SQL instead of the built-in ActiveRecord methods. However, you should still encapsulate this as a class method on your domain object. E.g.Code:@people = Person.find( :all ) @people.each do |person| puts person.name end
Code:@people = Person.optimised_find( some_params ) class Person def self.optimised_find self.find_by_sql("SOME QUERY HERE") end endI can't answer that question as I have never needed to do something so complex, but I can tell you that if there isn't anything built into ActiveRecord that does what you need, or does it quick enough, there is nothing stopping you from running SQL directly. You can even get access to the underlying connection adapter if you need to.Ah, well I may have that wrong. From chatting to ruby bods, it seems that a lot of apps are quick builds that have one or two tables with limited joins. How well would RoR/ActiveRecord handle left/right joins across 10 tables?
ActiveRecord is there to make your life a lot easier in general, but it doesn't prevent you from using SQL when you need it.
You should always separate your business logic from your output, and Rails does this. Consider the following...Oh. I mean, I'm not an overly advanced OOP programmer, but I thought it was a good thing to seperate the business logic and final output? I personally use XSL for my presentation logic after outputting straight XML. This has allowed me the flexibility and power to do things such as quickly change between HTML4/XHTML/Text/JSON/YAML and have my app act as a XML-RPC/SOAP resource.
The Model (Business Logic):
The model includes a custom finder method for easily finding all active users.Code:class User < ActiveRecord::Base def self.find_active_users self.find(:all, :conditions => [ "status = ?", 'active' ]) end end
Controller (Application Control Flow):
The View (template):Code:class UsersController < ActionController::Base # maps to http://myapp/users/list_active def list_active @users = User.find_active_users end end
As you can see the template contains no business logic whatsoever, and only the simplest of presentation logic (loop through each user and display the user name and description). The controller instructs the model to load all active users and makes the resulting collection available to the view.Code:<h1>Active Users</h1> <% @users.each do |user| %> <h2><%= user.name %></h2> <p><%= user.description %></p> <% end %>
To improve separation, advanced presentation logic can be wrapped up in view helpers that are automatically available in the view.
When it comes to web applications, you basically have two options: XML or HTML. What else what you need for a web application? Rails is after all a web framework, and it offers you both of the above. The XML builder style templates is a lot easier for building XML documents, such as RSS feeds. Having an XML feed is simply a case of having a separate action.The XML builder syntax sounds interesting. I'm currently passing objects to a renderer at the moment which are converted to XML without me having to do anything. Is this similar to what its doing?
I think its the fact that it ties you to HTML, which can be a limitation. Especially when you're creating an app that might have unexpected results. A short while ago RSS/ATOM wasn't that big, so everyone output straight HTML. Now they're having to back-track and create seperate output logic to cope with the rise in RSS/ATOM use. Seperating out the HTML from the View logic means you can switch between output formats without much overhead.
So in addition to the users example above, we might have:
Then, in our template, users_rss.rxml (the .rxml extension indicates this is an XML builder template, and Rails automatically ensures the correct content-type header is sent):Code:# in the controller... def users_rss @users = User.find(:all) end
The above is just small XML example, and would produce for example:Code:xm.users { @users.each do |user| xm.user { xm.name( user.name ) xm.description( user.description ) } end }
More information on that here.Code:<users> <user> <name>Joe Bloggs</name> <description>Blah blah</description> </user> <user> <name>Luke Redpath</name> <description>Blah blahM/description> </user> </users>
I've not really used XSL with Ruby but I did find this:Yes, I must have. I'll check further on those. Anything that will do quick XSL translation?
http://www.rubycolor.org/sablot/
As far as ORM patterns go, ActiveRecord is the simplest. Propel is not a good comparison as it does not use the ActiveRecord pattern, it uses the Data Gateway patterns I think (see Martin Fowler, Patterns of Enterprise Application Architecture).Yes. I try to keep with very straight-forward SQL when available. Although it is nice to use the odd MySQL or SQLite feature.
Maybe I have missunderstood the benefits of ActiveRecord. I only know that without any ORM I've managed to save myself lots of time and effort by rendering db query results directly to XML.
When putting the data into the db I've always found that straight SQL is much easier than ORM methods, and once the stuff's in there, I've no need to manipulate it when pulling it back out. ORM seems redundant when you think of it like that, IMHO. Maybe I've got things wrong?
Do you really think a SQL INSERT statement is easier than this:
Or even shorter:Code:@user = User.new @user.name = 'Luke Redpath' @user.email = 'hello@world.com' @user.age = 23 @user.username = 'lukeredpath' @user.save
Code:@user = User.create( :name => 'Luke Redpath', :email => 'hello@world.com', :age => 23, :username => 'lukeredpath' )The easiest thing to do is post in this forum and ask for specific examples.Still, it would be useful if there were a good PHP to Ruby tutorial, like the ASP to PHP ones in the old days.
HTH.
Yes please do some research before making such blatantly false statements about ruby on rails. If you want separation of markup from logic then use this:
http://amrita2.rubyforge.org/Rails.html
Its a plugin for rails that exposes a completely different templating engine then erb that separates html or xml from presentation data.
If its xml databases you want then look here:
http://rubyforge.org/forum/forum.php?forum_id=4729
"Xampl is a tool for developing Ruby programs. It facilitates the 'M' part of an MVC architecture. It is meant to be very easy to use, supportive of idiomatic Ruby usage, and mostly invisible."
You can swap out ActiveRecord for any other data model system you want to use. There is even a pure ruby database that is very powerful, and since its pure ruby it is portable in the ultimate sense of the word. There is also work being done on KirbyRecord which is an ActiveRecord style interface for kirbybase:
http://www.netpromi.com/files/kirbyb...l#introduction
There are many other great reasons why rails does live up to the hype surrounding it. Mainly it is the fastest environment I have found yet for creating web applications with database backends or not. And also has many nice features such as the prototype and scriptaculous libraries built in for doing easy ajax style apps as well.
Just look into something a little closer and maybe try it out yourself before making sweeping denouncements of a style of development that you obviously haven't really tried to grasp the good points of. Maybe try to ask questions before making blanket statements as well?
k thx bye!
-Ezra
And if you use AJAX, wait until you've seen RJS Templates
Luke, thanks for your comments. I'll check out the references you've given me, and already have a load of questions lined up.
Why not just swap out the default rendering model for one that outputs JSON? I mean, its just the same layer that outputs XML, just outputting data in a different format.
Hmmm... I'll look into this further, but from a cursory glance it seems to connect data objects directly with html elements by the "id" attribute. Not too clever, IMHO, as this detracts from the true use of the attribute, and also will be confusing should a developer have to use a template designed by a CSS designer. With ids going missing after population elements of design could be broken.
From the examples I've found online I was under the impression that RoR's built-in AJAX support actually output raw JS. This is terrible, as JS should be abstracted to the behaviour layer and kept completely seperate from the model and presentation. I build all my apps to work without JS, then sprinkle on AJAX afterwards in such a way that it could be used if available but the functionality would go unmissed should it not.And also has many nice features such as the prototype and scriptaculous libraries built in for doing easy ajax style apps as well.
I'm sure every developer works with AJAX in this way, however.
In all honesty, I did. Though this is the first forum I've come across that supplies decent answers to my questions.Just look into something a little closer and maybe try it out yourself before making sweeping denouncements of a style of development that you obviously haven't really tried to grasp the good points of.
I have very specific ideas on the way I want/need to develop my apps. XSLT is a must. XML output without having to hard-code anything is a must. Being able to switch output from XML to JSON/YAML is a must. The ability to implement a very simple REST interface to my apps is a must. Same for XML-RPC and SOAP. The ability to work with persistance layers other than SQL is a must.
Quick research into RoR/Ruby has yeilded little result when I take into account the above requirements.
I think I'll just get my questions on here and see where I end up in a couple of weeks.
Presumably because a) it keeps things nice and simple and b) it follows the "one-language-to-rule-them-all" principle, being that it uses Ruby.
I can't disagree with you there and the embedding of Javascript directly in the HTML is a weak point of Rails' AJAX implementation. However, Rails does still make it easy to specify alternative actions for people without JS and the concept of easier maintenance through separation is less of an issue because of the template helpers Rails provides.
That said, it would be nice to see something like the behaviour library built in, for example. There is some discussion on this here:
http://article.gmane.org/gmane.comp....by.rails/32447
Of course, there is the issue of how to collect all generated JS statements and place them into the head. Its not a simple task. Also, this is only a problem if you are using the built-in Rails helpers. There is nothing stopping you from implementing AJAX using your own functions (with the help of the Prototype library) and placing your own hooks into your markup (probably using the class attribute).
It's quite clear that out of the box, Rails isn't very suited to your requirements, although personally I find some of them a bit strange. I like to KISS and Rails lets me do just that. Regarding the web services layer, have you looked at ActionWebService?
Sorry, I'm thinking in Mojavi terms. There's a abstract rendering object which is extended with whatever rendering object is required, the default being intermixed PHP/HTML (similar to the way RoR does things). I've just set up a couple of special rendering classes - XML/JSON/YAML - which I can switch between by passing a parameter. A filter picks it up and switches from the default renderer (XML in my case) to JSON or YAML. So when I'm doing AJAX calls I don't have to do any rendering work (not even XSLT), as I just switch to returning a JSON representation of my "output" object.
I'll have to look into whether I can do the same using RoR. If I can, then I'm sure I'll find it just as useful as Mojavi.
Thats probably the main thing I like about Mojavi compared to all the other frameworks I've looked at - its simplicity. There's no "goodies" built-in to detract from doing things correctly. Its the lightest MVC I've come across, keeping things like AJAX/Persistance/Interfaces out of the core so the developers can just get on with building things correctly and not have to worry whether that bit of JS that the model's outputting automatically is going to work in Opera and Safari. That's for later on when the app's working.I can't disagree with you there and the embedding of Javascript directly in the HTML is a weak point of Rails' AJAX implementation. However, Rails does still make it easy to specify alternative actions for people without JS and the concept of easier maintenance through separation is less of an issue because of the template helpers Rails provides.
That said, it would be nice to see something like the behaviour library built in, for example.
Good. I've already got my own framework for AJAX, which is framework independant. I've always found it worth while to keep my layers completely seperate, just in case I need to swap them out (which I've had to do in the past).There is nothing stopping you from implementing AJAX using your own functions...
Mojavi gives me the same freedom. Splitting off my layers to such an extent means that I can swap each one out if there's a problem and not have to worry about re-coding everything.I like to KISS and Rails lets me do just that.
Can you imagine completing a project in RoR and AJAX to find that your client's been taken over by a bigger company with strict SOPs who then state that the app has to be re-done in PHP? Nightmare, let me tell you. If you can just re-code your MVC and leave the presentation and behaviour layers alone its not so much work.
Lots of people think KISS means keeping it as simple as possible. If that were true, we'd all be coding proceedurally with no test cases. KISS should be thought through just as much as the problem/project itself: "How can I be 'lazy' and get the job done? How can I limit having to re-work large parts of the project if a tech turns out to be a dud? How can I keep the client interested (always my favourite)?". There's lots more questions like this I've collected over the years that I ask myself before every project, and I think I'm a better developer because of it.
I'm going have to delve into RoR to see whether I can implement some extensions to the core so I can fulfill my requirements. Ruby is a great language, and if I can I can see a switch to RoR in the near future!
Amrita2 doesn't separate anything, it just shifts some HTML generating stuff to places where it doesn't belong. Your model/controllers shouldn't depend on your view. Your view should collect data from your controllers and modeld, but the controllers and models shouldn't be aware of it.
But ontopic:
Seems terribly wrong.PHP Code:public $has_many = "notes";
Is even worse. Ugly hacks compared to Rails.PHP Code:public $belongs_to = array("assoc1" => array("foreign_key"=> "weird_key"),
"assoc2" => null,
"assoc3" => array("conditions" => "age > 25"),
etc ...
);
But PHP has 1 advantage: more hosting services available.
Why does it? Doesn't Java do it that way? Perl does it similar. Are they wrong? Doesn't C++ do it the same? I believe D does.
Just looking through Why's poignant guide to ruby it seems as though variables with capitals in them are actually constants. This can't be right, can it? Typing variables using CamelCase is common practice among developers. It saves having to mess about with the ugly underscore so much. (And yes, I know that built-in functions in PHP use underscores, but when using OOP in PHP you tend to hardly use them).
So, if I wanted to use:
This will throw an error because isSuccess is actually a constant? Maybe I've got it wrong, but that seems wrong to me.Code:isSuccess = true; if db.saveRecord.== false do isSuccess = false; end
If constants just depend on the first character being uppercase, then great. Otherwise... I can see myself getting very annoyed every quickly.
We all get comfortable with the syntax we use the most. I'm sure if I use ruby a lot, I'll become very comfortable with it. Then when I start to learn OCaml, I'll want to shoot every OCaml developer in the head and announce Ruby as the true overlord.
Posting Permissions
Bookmarks