Hi Raphaël, Just a few quick comments on your remarks.
Raphaël Valyi a écrit : > Very weird, even with exactly the same URL and no no-cache directive? > Never heard about that one. This explained while you rolled back that > change then. Guys you really should communicate better on your dev; me > and other people though this was simply package mistake while it was > actually simply a lack of communication. > Yes we know this is an area where we need to improve. In the specific case here, this happened as a solution to a specific client support ticket, and therefore the communication on this solution could not have been made public in such a form, and then things slipped. The packing solution is actually the one that Zimbra itself uses in their mail application, so apart from adapting it for Jahia, all of it is already available in Zimbra's source code repository. > We did that for some projects indeed. You could document that better > (how to start a clean project) if you have the resource. > We currently have projects underway to help solve this problem, although it is not as easy as it looks. Basically you have different types of target users : - end users who do not want to touch templates, but might want to customize position, colors. - "light integrators", mostly in-house integrators that want to do minimal template editing - "commercial integrators", that have a tendency to build a lot of custom logic into templates Finding a solution for all these different types of users is quite difficult, as the more you go down in custom logic, and the more you will have problems with the different Javascript libraries that might cause conflict. For example, you could integrate prototype in a template, and have a portlet in a page that uses DOJO. Also, we have been having the constant scriptlets versus taglib debate for the longest time, but a lot of customers/integrators do not care about the cleanliness of the code, and despite multiple warnings as to the maintainability, they prefer to gain time now, and work on improving them after the sale has been completed. Actually I don't really believe in Javascript-heavy solutions anyway. For me, the less Javascript there is, the stronger the solution. If you look at the leader in Javascript implementations (Google), they are well aware of this problem, and they do the maximum to minimize usage of Javascript. This is why they have designed GWT that minimize the Javascript to the actual need, rather than loading a library that will not be used fully. But at the same time Google is not using GWT in production for their apps, as they also have problems of migrating the Javascript code base, that they have spent so much time stabilizing for as many plateforms as possible. For some integrations, maybe even some non-browser based solutions might be better, and we are constantly trying to find a good balance between compatibility, quality, ease of use/integrating, etc. We have a lot of experience with DHTML as even Jahia 1 featured a full desktop-like interface for managing portlets, and we quickly realized that it was not going to be stable nor ready for production use (this was during the Netscape 4.7 era !). Things are looking a bit better now, but still one needs to be very careful into what you can do, and how it will scale. > Finally, it's only my view but I think Jahia is at a crucial time. On > one hand you have quite sustainable marketshare in the CMS, but on the > other hand, I see lots of code that seems really hard to refactor in a > REST and web2 way in Jahia. So I mean I had doubts Jahia could ever > take the web2.0 move. And when you know Google is buying companies > such as Jotspot, or if you think about the simplicity of Rails apps, I > wasn't so optimistic about the Jahia future. > Google's model is quite different. Google is trying to generate ad-revenue by having as many services online as possible, but this is a really hard sell for entreprises, who still like to manage their IT at least partially in-house. For individuals these are great solutions, but I believe there will still be quite a large market for in-house solutions, and Jahia is currently quite well positioned for this. Until version 5, we have been quite conservative in our changes to the codebase, in order to build features quickly, and offer a solid product. Despite this, we have completely changed the lower-end of the software product, going from hardcoded JDBC requests, to Spring with Hibernate integration. This hasn't happened yet on the front-end, but it is the next step, and will allow for more flexibility on building new interfaces rapidly. We will work on making a more clear split between the WCM part and the actual content repository, which will allow for multiple front-ends. > I'm glad you guys want to make the web2.0 move. I strongly believe > it's gonna be the minimum standard customers will ask. I think every > field should be editable in place without full page reload, much like > GMail, cause massive page edition really sucks currently. > Really what customers asks for are solutions that are fast enough, reliable, and that scale well. Jahia systems now are in the 10'000-30'000 pages range, and we will continue to improve the software to allow for large installations. At the same time we can deploy accross clusters of machines to better distribute various loads. > Still, I fear you kill the code even more by trying at any cost to > implement that over the already over bloated JSP/Struts 1 layer. I'm a > JRuby on Rails fan and really think this is a more sustainable model. > I mean, you could definitely use Struts tiles to achieve a clean > modularization of your pages. But still, you'll have no REST API (and > just how useful it is to have a free search engine in all the content > of your sitesuch as Google Ajax Search (currently Lucene sucks for > each paginated container cause it's not restful), the REST > contribution web services...) you would also miss an effective way to > factor ajax and non ajax code. Integrating that existing layer with > GWT might be very entropic too. > Although I like tiles, I'm not limiting future layout systems to this. There are a lot of interesting alternatives out there, and we are constantly checking them out. But again any changes here will impact any customizations that existing customers have done. > If I could, I would reinject your Spring layers and Hibernate models > in a JRuby on Rails app such as decsribded here: > http://mysterycoder.blogspot.com/2007/06/spring-jruby.html > and similar thing for Struts progressive migration: > http://www.newspiritcompany.com/railsandspringmvc/ > I would drop all the JSP and View/Controller layer at the profit of > Rails which I consider much better designed to achieve a Restfull and > web2 model. Just think how ERB (Rails template system) integrate > better than JSP or JSF when it comes to pass customized anonymous > function to the Javascript libs such as Prototype. ERB makes it a > simple hash parametrization while JSP or JSF will bloat it all in a > static non versatile taglib. > Again, and although it is indeed tempting to go this way, in order to build a reliable solution we must work the other way around. Currently at Jahia we are heavily focused on building as many test systems as we can, at the same time as improving the existing codebase, developing new features and providing support and more and more documentation. Now the other major issue is migration. Sure we could build a new Jahia completely differently, but what happens to all the currently installed systems that are running fine and that don't want to re-invest in new templates ? We are working hard on these problems, in order to improve Jahia for our customers, rather than filling our marketing pages with the latest buzzwords. 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. What seems crazier to me with all this talk about Web 2.0 and such, is that I wonder some times if Web 3.0 won't be heavy clients and we finish back where we started, with client-server applications. Because after Javascript applications, we might want do to more powerful layout, such as flash based, or even 3D as Microsoft was hinting to with their Avalon framework. Basically what I'm saying here is that it is not as clear cut as to which are the really time-tested solutions. What is certain is that the plateform must be as flexible as possible to accomodate for new user interface frameworks. > PS: and also: I feel like the data model might be more effective if it > were smaller with some XML blobs at strategic places instead of so > many table associations. But I might be wrong, just an intuition. > The database model is also undergoing a lot of tuning recently, and some major changes. XML is not necessarily a good solution because parsing can also be a heavy operation when the load on the server becomes important, especially when mixed with remote database access. Again, we have lots of ideas too do improve Jahia, but only so much time to actually do it. > Regards and good luck with your CMS. > Thanks for your input, and let me know if you're interested in getting more involved. We are growing quickly and constantly looking for people to help us ! Regards, Serge Huber. _______________________________________________ dev_list mailing list [email protected] http://lists.jahia.org/cgi-bin/mailman/listinfo/dev_list
