Raphaël Valyi a écrit : >> Migrating to REST models & Web 2.0, and such might seem tempting at >> first, but also assumes that non-Javascript browsers are no longer >> supported, which is a problem as Jahia is quite popular in large >> administrations, that usually do not evolve their IT systems rapidly. >> > > Hi, I'm well aware of that, but your assumption isn't quite true: > * if you move to GWT, that's sure, your back-office won't be > degradable and that's a real problem. In my opinion that's the major > point for not using GWT but rather stick with Prototype and eventually > Scriptaculous. > Basically what we have right now is : - Prototype in some templates - Zimbra everywhere else - Lots of logic in the interfaces
The plan is to move to : - in the short term, remove Zimbra & Prototype for something like GWT - Move the logic down, so that it can be re-usable on multiple front-ends. Ideally I don't really care about the front-end type, I just want to be able to change quickly. > * With well designed framworks such as Rails (works on the JVM too and > Sun heavily stands behind it with 4 dedicated engineers and a fast > growing community!), building a Web2.0 site that degrades nicely into > an accessible site is quite easy. > Take the "form_remote_tag" form the Rails API here: > http://api.rubyonrails.org/classes/ActionView/Helpers/PrototypeHelper.html > there is a fall-though URL for javascript disabled browsers: so either > you update a div with an AJAX request, either you send to an other > page while factoring the controller logic and the URL semantic! > Rails is simply full of such handy hooks. I can't see any J2EE > framework approaching. You can read the Ajax in Action book if you > want to find out more about inobstrusive and degradable AJAX. > Thank you but I was aware that JRuby and rails are available on the JVM. Maybe you also know Grails ? Anyway, as I said the idea is to be able to build as much re-usable logic as possible. So that we can easily choose between JSF, Tapestry, GWT, etc or whatever strikes our fancy. > * about a RESTFul CMS: several advantages: > * easy automate functionnal testing > You have examples of this ? Or resources ? > * 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. We have multiple plans for search, such as making the engine pluggeable, integrating other search engines, and in terms of indexation Lucene is not bad at all, it's really the text extraction that's the problem. > * no complex Web Services, everything stays simple > * integration with CMS and specific code is a headache currently. > The portlet stuff isn't that good. The main reason is that good web > apps aren't portlet. Let's take a good blog engine like Mephisto, it's > not a portlet and no porlet is competing to it. With a RESTful > approach integration can be achieve via HTTP. That might be less > standard, that's easier, easier to deploy on several machine and to > integrate heterogeous solutions. With a RESTful CMS you could directly > plug in into a Netvibes like portal, and again, being degradable is > possible, that's even easier when you keep the code base small and > well factored. > REST does have the issue of security, but actually we already have a WebDAV interface to our content objects, although in the longer term through the integration of the JCR (Java Content Repository) we will be able to provide all kind of interfaces over the content. > Well, I said that cause in the company I'v been working for last year, > Amadeus, the GDS air travel leader, they benched a lot the DB and > ended up in doing that. It's clear it has to be benched but sometimes, > the number of joins you can avoid is worth the XML parsing and even > zipping CPU overhead. Anyway, this was just a suggestion, I'm not > saying that in your case I'm sure it's a win. > Yes but at the same time by improving the model you might be able to remove all those joins too. And some databases are really optimized. Anyway, with our integration over time of the JCR, we will have the possibility to store in multiple back-ends, such as file-system, database, a mixture of the two, and all the XML you'd like :) > Overal, given the improvements you did to the Data Model layer and DAO > layer from Jahia 4 to 5, if you can do as good with the View and > Controller layers from now on, then I believe that becomes a > sustainable solution. Nice to hear you have such plans. > Don't worry, Jahia is moving forward with a lot of things, and we have a lot of work we want to do. Our main focus right now is on improving performance, but this also implies architectural changes that will allow us to move faster in the overall system architecture, while keeping as simple as possible for the end-user. Regards, Serge Huber. _______________________________________________ dev_list mailing list [email protected] http://lists.jahia.org/cgi-bin/mailman/listinfo/dev_list
