The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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/

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.

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.

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.

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.

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.

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.

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 ;-)

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.

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.

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.

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 ;-)

not quite a clone yet

Originally Posted by 33degrees

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.

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.

I'm also forced to intermix code and HTML. Erm, no. I stopped sucking my thumb when I was 4.

Only need to really learn one framework (instead of many) for all those who do both ruby and php.

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?

What libraries does ruby not have that you need?

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.

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.

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.

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 also forced to intermix code and HTML. Erm, no. I stopped sucking my thumb when I was 4.

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.

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.

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?

I fail to see how using RubyOnRails stops progression. Thats a pretty throwaway statement with no real explanation.

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?

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!

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.

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.

I'm not ruby bashing here.

Perhaps not, but you are doing a good job of coming across as pretty ignorant.

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 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.

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

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 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!

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.

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.

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.

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?

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.

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.

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.

Smarty was something I ran screaming from a long time ago.

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'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 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 fail to see how using RubyOnRails stops progression. Thats a pretty throwaway statement with no real explanation.

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.

Yes, I must have. I'll check further on those. Anything that will do quick XSL translation?

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?

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 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"!

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.

Yes. I try to keep with very straight-forward SQL when available. Although it is nice to use the odd MySQL or SQLite feature.

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.

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?

Perhaps not, but you are doing a good job of coming across as pretty ignorant.

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!

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.

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.

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).

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.

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'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.

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.

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.

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.

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?

I 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.

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.

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.

You should always separate your business logic from your output, and Rails does this. Consider the following...

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.

To improve separation, advanced presentation logic can be wrapped up in view helpers that are automatically available in the view.

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.

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.

So in addition to the users example above, we might have:

Code:

# in the controller...
def users_rss
@users = User.find(:all)
end

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):

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?

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).

"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:

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?

Its a plugin for rails that exposes a completely different templating engine then erb that separates html or xml from presentation data.

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.

And also has many nice features such as the prototype and scriptaculous libraries built in for doing easy ajax style apps as well.

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.

I'm sure every developer works with AJAX in this way, however.

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.

In all honesty, I did. Though this is the first forum I've come across that supplies decent answers to my questions.

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.

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.

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.

Originally Posted by neobuddah

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 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:

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).

Originally Posted by neobuddah

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.

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?

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.

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.

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.

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.

There is nothing stopping you from implementing AJAX using your own functions...

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).

I like to KISS and Rails lets me do just that.

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.

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.

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:

Code:

isSuccess = true;
if db.saveRecord.== false do
isSuccess = false;
end

This will throw an error because isSuccess is actually a constant? Maybe I've got it wrong, but that seems wrong to me.

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.