Web dashboard : code improvement ?

craymore

Hi All :)

I am a new pfSense user : I recently bought a wall-mountable appliance in order to have it handle all the network tasks / features on my network (DHCP / DNS / FW / PPPoE / QoS).

I had it configured in a few days – with the help of the provided guide & some tutorials --, and it has now superbly replaced my former crappy so-called-router in a most satisfying way 8)

The pfSense features are very good, the software itself looks very stable but ..... but .... why is the web GUI code so messy ?! :-[

For the professional web-developer I am, this is just horrible :

[list]

use of W3C non compliant tags
tags not being closed
embeded styles instead of full css usage
no respect of the semantic
tag declaration where it isn't allowed
unencoded ampersands in URLs
non existant REFC delimiters

All of these aspects generate a lot of page layout issues, formular bugs etc :-\

I don't know if there are any plans to re-write the front-end GUI code for the upcoming releases, but I would definitely vote for it !

I would love to see a modern web GUI for pfSense :D (htm5 use, non intrusive JS, full CSS support, full DOM usage etc), and that would also certainly be a huge time saver for code maintenance & improvement.

:)

dhatz

I don't know if there are any plans to re-write the front-end GUI code for the upcoming releases, but I would definitely vote for it ! I would love to see a modern web GUI for pfSense (htm5 use, non intrusive JS, full CSS support, full DOM usage etc), and that would also certainly be a huge time saver for code maintenance & improvement.

The full sources are available at https://github.com/bsdperimeter/pfsense

Feel free to submit patches ;-)

cmb

@dhatz:

The full sources are available at https://github.com/bsdperimeter/pfsense

Feel free to submit patches ;-)

This.

We're network and security guys, not web design guys. That said, everything works fine and there generally aren't any layout or other issues. But we'd be happy to see your contributions.

craymore

I just checked some of the sources for the frontend GUI :

They're all coded in a very procedural way, with no clear distinction between the core logic, the presentation logic or the view code.

< business logic code snipet >
< presentation code >
< view code >
< business logic code snipet >
< presentation code >
…

While this is very convenient to develop quickly and have a clear overview of what a code page does, it is afterward very difficult to maintain when it comes to corrections & adding new features :P

On top of that, all the presentation code snipets include hardcoded styles & formatting variables

e.g :

| |
[…]
|

… instead of something like this :

– HTML code --

[…]

| | |

– CSS code / external stylesheet --

table.tabcont {
border: 0;
border-collapse: collapse;
border-spacing: 0;
width: 100%;
}

table.tabcont * td {
padding: 6px;
}

Same goes for the JS code that is written directly along with the core logic / presentation / view code …

…while it should be defined as external scripts using DOM : [function js_class()
{
var ATTRIBUTE_tableLinks;

//– private function(s) --

var initParameters = function()
{
ATTRIBUTE_tableLinks = [ 'link1' , 'link2' , 'link3' ];
};

//– public function(s) --

this.global_init = function()
{
initParameters();
var element = null;
var i = 0;

for(i = 0; i < ATTRIBUTE_tableLinks.length; i++) {
element = window.document.getElementById(ATTRIBUTE_tableLinks_);

element.addEventListener('click' , functionToExecute, false);
}
};
}; // end of class

//– code execution start --

var js_class_script = new js_class();
window.onload = js_class_script.global_init;

@__cmb__ : Indeed, generally, it looks fine from a user perspective , but it doesn't mean that everyting is working as expected ;)

Depending on the doctype – in this case it's a transitionnal one --, the browser compensates for most of the issues found in the code served to the client so that the page can finally be displayed, but there are still some glitches in the end.

If you issue a W3C validation request for the source code served to the client, it gives a zillion of errors & warnings ( :o ) when -- if the code was built strictly W3C compliant -- it should be equal to 0._](#)

Supermule

Why not get on with it?? Or post a bounty?

I bet many would contribute to this and could be finis
hed quickly! We need it….

Would be nice to see it reworked and actually beeing able to use a widescreen layout :)

stephenw10

I could get behind a bounty a bounty on this, something that potentially benefits the entire community.
Not that I've experienced any issues with the webGUI myself.

Steve

marcelloc

@cmb:

We're network and security guys, not web design guys. That said, everything works fine and there generally aren't any layout or other issues. But we'd be happy to see your contributions.

I second that :)

Improvements to avoid these browsers auto fixes will be useful but moving code to a web designer only understanding just to be up-to-date could get hard for non designers to maintain. :P

Supermule

But maybe it will just work….instead of all the other things breaking when things get updated....

Guest

The whole of the GUI really needs to be restructured, with an API between the system and HTTP(S).