On 02.03.11 18:37, "Charles Moulliard" <[email protected]> wrote: >(2) Switch the existing architectural model to use frameworks like >Apache Wicket or Vaadin where the content is clearly separated from >the server side code. Apache Wicket and Vaadin librairies are already >osgified so their integration in project like karaf, sling or felix >will be done seamless even if we have the overhead to deploy them. But >this is also the same for bundles like PAX-Web, ...
>From a Sling perspective, which is a web application framework, using Sling to render the web console pages would be cool :-) However, I think there is a good reason that the web console implementation(s) are as simple as possible: if they rely on too much external bundles and services, chances are higher that things can break. The console is typically an important management interface that should always be running, even if the system it manages is mostly down (because bundles are updating, not resolved etc.). So if it is for example used to manage Sling, but also run by Sling, you get cyclic dependency hell and if Sling is down, the console has a problem, too. One could also embed those libraries in the web console bundle(s), but then you have to do it every single time, as most screens are provided as plugins, residing in their own bundles. Thus bundle sizes explode and version management can be difficult. So I think one should be careful in adding complex dependencies. The current plain servlets are very robust in this regard. But I agree that not having a templating mechanism such as JSP makes it hard to work on it. Just my 2 cents, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
