Hi Raphaël Raphaël Valyi a écrit : > 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. > > Actually our integration of Groovy was to provide a Java-like scriptable syntax that would *not* be JSPs, so that integrators could easily write event listeners. Groovy actually compiles to Java classes, and therefore beneficiates of all the JVM JIT compilation just as Java classes do.
Thank you for the resources, they are interesting indeed. I will be watching the Ruby & Rails space more frequently I think :) > 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. > Hmm... Indeed I think you are right about this limitation. Did you create a JIRA issue for this ? But it doesn't require a filter, as pagination is simply a GUI that the template developer introduces to display a container list, much like a GUI builder would do. The difficulty in Jahia is that you can display container lists in very flexible ways, using filters, searcher, sorters, pagination, all of them optional. We have customers that build huge container lists, while others use thousands of pages. It is the problem of being a product company like Jahia's, you need to accomodate all usages and it's sometimes a bit overwhelming :) What I'd really like is for the opportunity to build more outside people (like yourself) into the equation, because many eyeballs are often better, but we have been so focused on our releases lately that we have not communicated enough. The good news is that we will be doing more effort to open up everything. Stay tuned. >> 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. > Well I did my share of SOAP authentification in the past, but I was mostly thinking here about our granular ACL system that controls access on content objects, but I guess you could simply map that through the REST resources if mapped carefully enough. As I said we have done mapping of our content to WebDAV resources, and in such a way this is similar to REST, although not as powerful. > 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. > Don't worry, we will be doing a lot more, and I'm always open to discussing ideas of where to go next, because as I said I think it is best to openly discuss this since this will make the product a more solid one, and hopefully serve it's intended users (both integrators and end-users) better. Please don't hesitate to come back with problems or ideas such as the ones you've been discussing. Please understand I am in no way against rewriting all of Jahia in Ruby or another language, but I want to know why, how, and what the benefits for the end-users are :) More pragmatically, I'm really looking for a way to modify the front-end in a maintainable and RAD way, so that we can easily expose all the back-end functionality (and there is a lot !). Regards, Serge Huber. _______________________________________________ dev_list mailing list [email protected] http://lists.jahia.org/cgi-bin/mailman/listinfo/dev_list
