Skip to content

Web Interface

Stephen Oliver edited this page Apr 3, 2017 · 2 revisions

Introduction

Freenet uses FProxy as its web-based graphical interface. Currently all HTML code is generated by inside Fred and is returned to the browser. In context of Google Summer of Code 2012 the whole FProxy is to be reimplemented.

Motivation

Current implementation of web interface generates page structure (HTML files) internally and is hard-coded in Fred. It is only customizable through CSS files. Without prior Java knowledge, it is impossible to change page structure.

This project aims to separate the structure (HTML) from design (CSS) and both from Java code. This is done using Apache Wicket.

Wicket has been chosen because when comparing to similar frameworks (Apache Velocity, Ruby on Rails, etc), it uses pure HTML. Moreover it has some out-of-the-box features such as AJAX support may be interesting for the project.

Current Version

Current version is available here.

Just build the plugin as following

mvn clean install

for a successful build you would need both freenet.jar and freenet-ext.jar installed in your local maven repository.

You can install those manually jar falls as follows:

mvn install:install-file -Dfile=PATH_TO_JAR/freenet.jar -DgroupId=org.freenetproject -DartifactId=fred -Dpackaging=jar -Dversion=0.7.5.1410
mvn install:install-file -Dfile=PATH_TO_JAR/freenet-ext.jar -DgroupId=org.freenetproject -DartifactId=freenet-ext -Dpackaging=jar -Dversion=29

note that you need at least note version 0.7.5.1410 of freenet.jar and version 29 of fred.jar.

Fred Plug-in

After building the plugin, the generated file is called winterface-core-${winterface-version}-jar-with-dependencies.jar and can be found under /target directory. This file can be be used as Fred Plug-in. However to get it working, JarClassLoader.Java needs to be patched. A patch is also provided with Winterface and is available under the git root directory (JarClassLoader.diff).

Architecture

Winterface aims to externalize FProxy and replace current SimpleToadletServer with a servlet container (required for Wicket). It is also desirable to implement it in a manner so that it could be both used as a Plugin) and also as an OSGi bundle.

Apache wicket is used as templating engine (and more) to render theme bundles (see below). Wicket requires a Servlet container to run and Jetty, as a light-weight HTTP-Server and Servlert-Container, is the going to be utilized for this purpose. Jetty would replace the current Toadlet server and consequently all Toadlets are replaced by Wicket WebPage(s).

An intermediate layer is also desired in order to aggregate and collect necessary data for the web interface. This layer resides between Fred and the Winterface. This layer can also provide data to future (non web-based) UI implementations (e.g. with Apache Pivot). This layer can be provided as a separate Plugin or OSGi bundle. (Future work)

See Technical Specification for more.

Design & Theming

FProxy relies solely on CSS files for theming. Page structure (as mentioned above) is hardcoded and cannot be altered without changing Java code. Winterface allows using Theme bundles, which are simply a collection of HTML, CSS and JS (if desired). A nice feature would be to allow sub-theming an existing theme (see Drupal Zen Theme for example), which allows to override arbitrary templates and the rest is inherited from parent theme.

JavaScript

Currently, Fred is fully functional without JavaScript.

JavaScript is avoided mainly because of security and support (e.g. text-based browsers) issues However JS can give a great boost to the usability (both in sense of appearances and functionality).

One important issue is live updating: updating the content without having to refresh the page. If JavaScript is not available this can be done using "meta refresh". With JS enable this can be done using AJAX calls. Best case scenario is to have a single entity to make AJAX calls and share the data with other entities. This way a single connection is shared and the server is not exhausted with a burst of requests.

Progress

Done

  • A new front page (Dashboard) containing:

    1. list of bookmarks (manipulating the bookmarks and list is not possible yet)
    2. Fetch a FreenetURI knowing the key
    3. Summary of peers
    4. Version summary
  • Fetching files over Freenet

    1. Showing a progress page while downloading
    2. Showing an error page if an exception occurs
  • List all alerts

    1. Can choose which priority class to show
    2. Can dismiss
  • Insert a file

    1. Can choose using a local browser (is buggy in AJAX)
  • Notification Area in footer

    1. Contains all alerts
    2. Dismissible alerts can be deleted
  • A list of all global queues (Download / Upload)

To be implemented

No. Task Comment Depends on Difficulty (Time + Effort)
1 Fine tune fetching mechanism Some features such as blacklisting RSS feeds is missing, need to handle AJAX requests (no progress bar/maybe JSON response) none high
2 Complete QueuePage Not all features of QueueToadlet are implemeted (e.g. restart request), Add a select-all checkbox for each section in the queue pages. Implement queue sorting. Show a message when queues are empty none low
3 Statistics page Maybe generate images on the fly (dynamic resource) none moderate
4 Configuration page Add AJAX form submit. Add plugin pages to navigation. Limit access to this page Navigation menu moderate
5 Multi-user support Make it possible for multiple users to login on a single node none high
6 Advanced-Normal view Add variations for each page supporting advanced/normal view Multi-user support moderate
7 Make it possible to generate new themes Configure wicket to load resources from custom locations. Add fallback mode, if a required resource in not available none high
8 Plug-ins management page Load/Unload plugins. Related configuration. none low
9 Custom error pages Custom error message (Current → only "Run Rabbit Run"). Custom HTTP status code (Current -> only 404 Not found) none low
10 Move all util classes to own package This can be later used as own plugin, usable by other plugins none low
11 Support https and gateway mode A way for users to generate/manage SSL keys. Button to generate a certificate on the configuration page with instructions on how to add it to common browsers none moderate
12 Add/edit bookmarks Implement bookmark manipulation. Add a page/panel to edit bookmarks fred moderate
13 Wizard page Implement a convenient way for first time user to configure the node none moderate
14 Change language Add a drop down to footer to change language none moderate

Known Issues

No. Affects Comment Cause Difficulty (Time + Effort)
1 LocalBrowserPanel Changing the current directory is not possible in AJAX mode Wicket nested forms are buggy (should be solved in next release) n/a
2 FreenetURIPage Sometimes a new URI contained in an FetchException doesn't restart the page, rather it redirects to FetchErrorPage Checking for new URIs by initialization does not suffice → Check just before redirecting to FetchErrorPage low
3 AlertsPanel Dismissing an alert does not update the total number of alert in panel Use RefreshingView instead of RepeatingView low
4 BookmarkPanel Bookmarks cannot be removed/moved BookmakrManager should be a singleton object, provided by the Node (currently a new instance is initialized) low

Requested Functionalities

There has been some suggestions regarding enhancement of Fred's functionalities.

From Operhiem1

  • Collapse the wizard to a single page of choices.1

  • Display a release announcement / change log upon upgrade. 1

  • Stay on the same page after interacting with an alert instead of the current behavior of redirecting to the messages page. (See AlertsPanel)

  • Change the language link on the status bar to an auto-refreshing dropdown like in the setup. 3

  • Add a select-all checkbox for each section in the queue pages. This would let us change the current confusing behavior: if the user clicks remove and nothing is selected all items are removed. 4

  • Add an option to select items on the queue pages based on priority.

  • Display more information about starting plugins. 5

  • Display where files received over N2NTM are stored, 6 as well as an indication of transfer progress.

  • Display an indication of progress when downloading an update. 7

  • Display a progress bar during startup

  • Change the checkbox for the content filter (i.e. on the download queue) to enable the filter when checked, instead of disable the filter when checked.

  • Add the ability to rearrange and catagorize bookmarks by dragging them around.

  • Add the ability to add a bookmark directly to a category.

From TheSeeker

  • Serve default bookmarks to requestors without full access, or allow user to configure what will be visible from personal bookmark set.

  • Ajax image loading on webpages (revised web-pushing): don't wait for images, and only have one socket for all images, instead of one per image (the important part)

  • Make plugin access configurable by permission group. (?) Restrict access to plugins to requestors with fullaccess only, or make plugin access configuration

From ArneBab

  • Give the link to someone else (i.e. friends → N2N messages).

Technical Specification

Winterface seperates logic and template of Freenet's web interface, enforces a better modularization and makes theming easier.

Rationale

Current Freenet's web interface, FProxy, uses HTMLNodes in combination with ToadletServer to deliver HTML-Pages.

This has the disadvantage of mixed template and logic which makes it hard to separately make changes to each of them. Moreover debugging and understanding of code can be very exhausting.

Overview

Winterface is delivered as a Fred plugin:

  • It uses Apache Wicket as its component-based web-framework to generate HTML files from templates
  • Jetty (embedded) as a serlvet-container is used to deliver Wicket generated servlets.
  • It should completely replace replace FProxy, ToadletServer and associated Toadlets
  • It should make it possible to override Templates (HTML files) and design (CSS+JS)

What is to do:

  • Create HTML templates and corresponding Wicket logic for each existing Toadlet
  • Make reusable Wicket component (e.g. Panels) for reusable templates (e.g. Alerts)
  • Eventually add new functionalities

Winterface Workflow

The following is the general workflow of Winterface:

  • WinterPlugin is started by Fred and it starts Jetty
  • When Jetty is stated:
    • A WicketFilter is configured to handle Wicket-related requests
    • A resource servlet is configured to handle static resources (WicketFilter fallbacks to this servlet)
    • FreenetWrapper is initiated and put into servlet container
  • On requests:
    • A servlet filter (IPFilter) denies access to all hosts, which are not in whitelisted in plugin's config
    • A WicketServlet (handled by framework) looks for responsible WinterPage (subclass of WebPage)
    • WinterPage has an associated HTML-Markup and dynamically generates content and returns an HTML page
    • A WinterPage may consist of various Panels with their own markup files

Components

Wicket uses HTML templates (with its own XML attributes/elements) in order to dynamically manipulate/generate HTML markup. Components follow the MVC pattern and use a model to generate their content. This however causes more amount of code, since the template and logic are strictly separated.

WinterPage

WinterPage is a subclass of WebPage. Each WinterPage corresponds to a Toadlet with the difference, that It has its own Markup, which elements are manipulated upon each request.

Panels

Panels are reusable components with their own markup. Winterface starting page, Dashboard, uses for example various panels.

Clone this wiki locally
You can’t perform that action at this time.