> > * about a RESTFul CMS: several advantages: > > * easy automate functionnal testing > > > You have examples of this ? Or resources ?
I'm personnly implementing it in a project (not a generic CMS though). The big idea is that once you stick with a RESTful crud model Rails automatically scaffholds basic functionnal testing (as well as unit testing) for your. Functionnal testing basically tests through your Restful controllers via HTTP. Of course, you need to go a bit further than the scaffolding testing, but this alone laready test lots of things (good old 20-80 Pareto rule). Here is an example: http://nutrun.com/weblog/testing-nested-restful-resources-in-rails/ My point is not about usig Rails or not, it's only that a good metaprogramming associated to simple CRUD conventions can keep code simple and testable (not what Jahia controller and view layers are currently I think). Btw Grails is probably better than Struts1 and other pretty static XML bloatters. But I don't think it's as big as Rails (either on REST, neither on AJAX helpers, neither on community, neither in enginnering momentum). I saw you folks were using Groovy where I would probably have done so at the time (to provide a non HTTP scripted env). No flame war here, by the way Groovy just implemented the Ruby method missing thing after some Jruby help http://graemerocher.blogspot.com/2007/07/method-missing-in-groovy-part-2.html http://headius.blogspot.com/2007/07/alioth-numbers-for-jruby-10.html Now consider the importance of that method in generating dynamic accessors in ActiveRecord, I don't think GORM is competting in term of agility (may be in pure speed though). Also keep in mind that Groovy code compilation is done AOT if ever it's done. This isn't really flexible. Jruby on the contrary is achieveing flexible speed by using JIT compilation (seconded by the JVM JIT), and there are runtime optimization/deoptimizations beging developped. I mean I think Nutter and its team are going to achieve both superior speed and flexibility while bridging two large communities together. > > * easy to be crawled by an external search engine. Currently with > > Jahia, when a content is found inside a container list, we have to put > > a filter in that container list so that you actully find the content > > you were looking for, cause it's hardly found with a unique URL! I do > > believe, solutions like Google Ajax Search can compete with Lucene and > > y'll have all this for free at least on a public website once you are > > REST. Being REST doesn't mean you can't have some extra presentation > > views that aren't REST (Ajax panels typically that actually request > > REST URL's to update the titles). > > > Why do you say you need a filter ? You could very well search with the > global search. Again, you mention Google Ajax Search, but this again > assumes that you are on a public website, whereas most of Jahia > installations are private intranets now. Sure and Lucene isn't that bad, it's even pretty good, that's not my point. My point is about whether or not your content is fully indexable in a Restful way. What sucks is that once you get a macth from Lucene, I think the Jahia API will give you the page of the containerList that matched the result, but not the real page where the the content actually matched. For instance, if your containerList is paginated in some way, then you'll have to specifically retrieve the right parameters that will force the container list to show the right page. And this assume the containerList should have a filter activated on it to do that. Still, this might be a misuse of Jahia on my side. Do you have any hint for that? I'm just opposing that specific dev to automatic indexation. > REST does have the issue of security, Do you have any clue for that? Your REST api can use a private key (Flickr for instance) or basic authentication (Delicious) or even be SSL, so I think that's no different, is it? What can be a little different is the extended security chain when you start consuming REST wrapped in cross domain JSON (such as Google AJAx search), but that's isn't REST itself and web sites can decide who are going to trust or not. Ok, nice to hear you have such a refactoring roadmap, cause anyway the company I'm working in currently (Smile.fr) is pretty sticked with Jahia. best regards, Raphaël Valyi _______________________________________________ dev_list mailing list [email protected] http://lists.jahia.org/cgi-bin/mailman/listinfo/dev_list
