On Monday 18 October 2010 17:38:09 Ian Clarke wrote: > On Fri, Oct 15, 2010 at 10:28 AM, Christian Funder Sommerlund < > lists at zero3.dk> wrote: > > > IMHO it still boils down to actually implementing a theming engine (which > > has been discussed a couple of times earlier) so that it is actually > > possible to easily change the interface... > > > > The core problem is that we've basically rolled our own (rather crappy) Java > web framework, which is ridiculous when you consider the amount of effort > that goes into web frameworks like Wicket, GWT, Play, and many others. Of > course, reinventing the wheel is nothing new for Freenet :-/ > > The solution, as I've advocated many times, is to switch to an existing web > framework, and I favor GWT. Yes this entails a full redesign, but I think > this is necessary anyway. The current UI is way too developer-centric. Its > basically been designed from the back-end forward, rather than the right way > to do UIs which is from the user backwards. > > Switching to GWT has the following benefits: > > - Retheming it becomes as simple as modifying CSS > - Issues like MVC separation are taken out of our hands, and handled by the > framework > - Its pure Java > - User interaction is much easier and more powerful, it does stuff like > AJAX without having to think about it > - There are excellent free dev tools for it, like GWT Developer > > The arguments that have been presented against it are: > > 1) Javascript is insecure > > This argument is entirely specious, since the only Javascript the browser > would be running is that served up from the Freenet codebase. If they are > already running Java written by us, also running Javascript written by us > doesn't increase their risk in any way whatsoever. > > 2) What about people who don't have Javascript enabled or use terminal > browsers like lynx? > > Right now we have maybe 20k concurrent users. Google and other websites use > GWT for apps with millions, perhaps tens of millions of users. If Google is > prepared to make Javascript a requirement for mainstream web apps that serve > millions of users, then we should certainly be comfortable with doing-so for > our app that serves thousands. > > The idea that we should delay fixing our UI for even one second because lynx > users might not like it is laughable, when we are probably losing hundreds > of users per day to our current crappy user interface. > > Giving preference to the needs of a very small group of tech-savvy users at > the expense of the vast majority of potential users is exactly the flawed > thinking that has limited Freenet's growth over the last decade. We need to > get away from that attitude if we are to grow our userbase beyond Freenet's > current limited audience.
First, I concur with nextgens - we need mockups, far more than we need a good framework. However, if we want to talk about frameworks... Two obvious options which would let us keep Javascript support: 1. Use Wicket. This generates all the HTML on the server side, and gives low level access to it. It therefore provides fallback very cleanly (it is not suitable if latency between server and client is high or you need to do a lot of processing on the client). It requires the designers to create HTML, but it can assemble it in a clean templating way that doesn't mix code with HTML. If we are going to rewrite everything, then this will be cleaner than the next option. However, Comet (pushing) support in Wicket is new, not well documented, and probably does not meet our requirements. The web-pushing code implements its own efficient one-connection-per-browser comet system, (although it has some issues with unreliable event delivery), and uses it in 1) fproxy with inline images, 2) progress bars, and 3) various other places in the UI; this is all implemented in low-level GWT code. So we would probably end up using both GWT and Wicket - and on progress pages, *both at the same time*! 2. Generate HTML in fproxy (eventually using some other template framework or whatever, but right now we don't need to change it), and use low-level GWT code (similar to that used in web-pushing) to animate it. This is definitely easier if we are *not* going to rewrite everything. And IMHO rewriting everything is unlikely to be necessary for a completely new look and feel. I haven't checked out any of the other java-based web frameworks yet. If we use GWT, and give up on non-Javascript support, we may still need to keep the low-level GWT code in web-pushing, although there is a third party library for GWT-comet support which seems more mature than that for Wicket. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101018/a2fb6624/attachment.pgp>
