Poyan you're on the right track - adding more girth and complexity to Freenet in the form of an MVC framework, and a programmatic approach to producing output will bog things down more when you are only after an MVC paradigm and a simplified way to manage and produce your content.
Using a simple controller, it should be able to use a decorator pattern to handle the three(?) types of request: server management pages (a la JMX), plug-ins, and Freenet Sites. Abstract this, and you can look at this a just a controller that can direct requests to the correct plug-in, and routes any output to the request as a response. Using a servlet container begs the question of thread management in Freenet - containers are basically, thread management mechanism that speak HTTP. Do you want to add another thread manager to that's already there (given my ignorance here, I'm guessing given the NativeThreads classes etc), or just use an existing HTTP (in J6) interface to the existing thread management system and route everything through your controller? Velocity, or rather a templating engine, is the way to go: It will allow all output to to be managed in the form it will be presented in (i.e. HTML), and thus simplify it's generation by removing the hardcoded System.out.* peppered servlet style code that does not lend itself to easily managing UIs. But take a step back here too - Velocity adds a lot of value, and bulk, to it's basic function, but the crux of what it does can be easily replicated using Regex, some simple control logic and in the case of the UI, a well design bean a la JMX, to get and set system parameters. I say roll your own templating plug-in using basic Velocity syntax. SW >[pouyan] >>> httpserver delivered with the Java 6 is only a simple webserver and is >>> not a servlet container. on the other hand I don't think that it would >>> be complicated to imitate some vital functionalities of a servlet >>> container >>> Those for MVC architecture say "Ayeeeee" >[Ian] >> MVC is a nobrainer, the hard question is *which* MVC framework. Criteria >> are: >> >> Shallow learning curve (since regardless of which we choose, its likely to >> be unfamiliar to some developers) >> Lightweight (so that it doesn't increase the size of Freenet's >> distributable) >> Well supported >> Pleasant to use >> Ian Clarke > >We are not "forced" to choose between existing frameworks. IMHO, >Building a lightweight framework tailored for Freenet is the best >solution for the current situation. Following tools are needed: > >1. A servlet container (I suggest Jetty) [or adapt already existing >"SimpleToadletServer"] >2. A templating engine (Velocity is suggested) > >And following steps must be taken: > >i. Build a controller servlet/toadlet which handles http requests and >redirects them to responsible Toadlet. Servlet/Toadlet can be >configurable using a XML file (just like Struts) e.g managing >forwardings. >ii. Adapt Toadlet class to template engine and provide a mechanism to >register desired properties and methods to the templates context (can >be done elegantly using annotations). > >After doing so we have our own simple and configurable framework which >is based upon MVC architecture and suits freenet needs. The only >remaining step is to externalize toadlets view in JSP-like HTML pages >(which are processed by template engine). Moreover a toadlet can have >different views for different needs, so you could have all those fancy >javascript effects beside simple lame HTML elements. > >In case of Velocity, because of simple notation and tidy syntax, the >learning curve would be minimum, it is well supported however it is >not that pleasant to use :) but its a tradeoff between simplicity and >pleasure! > >This way we would make sure that the framework is as big as necessary >and as small as possible by avoiding all unnecessary features provided >by existing frameworks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110417/7cd11705/attachment.html>
