Modern Theme Progress report

Posted by: mstauber Category: General

The BlueOnyx demo has been updated with the latest progress of the new theme.

The last 14 days were again spent working fulltime on the new GUI. Except for the three days that I spent on the BlueOnyx API project. However, progress was quite slow due to various factors. I still have about 23 UIFC classes to port to the new GUI. At the moment there are 82 UIFC classes, including the few that I created from scratch.

I worked my way through the GUI pages under "Server Management" / "Network Services" and created the new pages in the order they appear in the menu. I started with "Web" and just today I got as far as "MailMan", which is about half of that menu. "Web" had a few complications, as it has many formfields of various types. For some of which I still had to do their corresponding UIFC classes. Once it was done, I used it as a template for the next couple of pages such as "Sub Domains", "FTP", "Tomcat" and "Email".

But "Email" turned out to be a big bugger and even a bigger bother. The first tab of it ("Basic")? Cheesy. Just simple checkboxes. Easily done. The "Advanced" tab? More diverse Formfields, including ones of two UIFC classes I had not yet ported. That took a bit longer. See below:

But "Secondary Mail-server" and "Blacklisting"? Three bloody days!

I had modified the class UIFC/PagedBlock.php to use jQuery Datatables. Datatables don't have an "Add" button at the top, which we need for those two tabs. Additionally you can't have two Datatables on the same page (even if tabbed and only one is shown at the most) if they share the same ID and function names.

So I had to diversify the PagedBlock Class to allow for multiple Datatables in one page. But adding the "Add" button to it needed to be done another way. I had to create a new UIFC class called ButtonContainer which provides the function getButtonContainer(). It allows to add a button row anywhere on the page.

That's visible here for example:

The "+ Add" button at the top is inside a ButtonContainer, which is separate from the Datatable below it. Now when you click on the "+ Add" button, it opens a new page where you can enter the Blacklist host you want to add. I wanted to make this "inline" first. So when you click "Add", it would fold out the formfields in the same page (without reloading!) between the button row and the datatable. That would have been really slick.

But it would also have been awfully complicated. The hiding and showing of elements isn't that complicated. But the form handling gets really, really tricky. Because hidden elements might have the "required" tag set and although they might not be visible, they're then still "required" to have data on form submit. To get around that I would not only have to dynamically add or remove the class that hides elements, I would also have had to dynamically add/remove the "required" class from all hidden formfields that had it. That's no fun, as it would require to go through +70 classes to add these provisions. So although slick as it might be, I skipped that idea. At least for now.

But as said: When you click on the "+ Add" button it opens that new page where you can add or edit the mailhosts for MX or RBL like I mentioned. That created a new problem as well. These two subpages of "Email" are not directly accessible from the menu and can only be reached via the "+ Add" buttons on the "Email" page. But as these two pages don't have menu entries (or menu.xml files!), the GUI doesn't know which page they belong to. So the GUI wouldn't open the "Network Services" menu and tick the "Email" menu entry as open either. To fix that I had to extend the class BxPage (which renders the new GUI pages) with a new override function that can be set in a GUI page to open the correct menu at the desired place to highlight the correct parent page. Small things like that eat quite some time, as you suddenly have the knife sticking in various parts of code all at once and better not loose track of what you were about to do in which GUI class.

Once that was settled, there were a ton of problems with buttons. Some buttons are straightly created with the Button UIFC class (or a subclass of that like "AddButton", "ModifyButton" or "CancelButton"). Others are created as "ImageButton" via the ImageButton class and it's children.

The Button class is getting quite messy with 700 lines to cover all eventualities that cropped up so far. The class FormFieldBuilder.php is somewhat worse with 1100 lines of code so far. It's the most widely used class and almost all UIFC classes eventually call a function inside FormFieldBuilder.php to finally render a GUI element.

Anything that renders a TextField such as getFullName(), getPassword(), getInteger(), getIpAddr() or therelike will eventually call makeTextField(). Anything that has a TextArea will eventually call makeTextArea() within FormFieldBuilder.php. If it's something that has Radio's or Checkboxes, it'll eventually call makeSelectField() and so on.

However, many of the functions are quite diverse. Some need to show a unit or which range of numbers is a valid input. Or they need to verify the input against certain things like "valid email", "number", "alphanumeric plus" or others. All these eventualities have to be coded in and/or set to defaults for those classes that don't need them. So for a simple makeTextField there are 159 lines of code in FormFieldBuilder.php alone, plus another 20-80 in the classes that call that function.

Sometimes it is necessary to extend such a function or class with things that one bloody new class needs. That usually takes 20% time for coding and 80% of time to check if it has broken that function for all the other classes that use it.

However, the more fundamental challenges like this are overcome, the more rapidly the actual coding of the new GUI pages goes. The "MailMan" page for example was done in 5 minutes by just copying my template GUI page over and adjusting a few variables and strings here and there to show the right formfields and to retrieve and submit the data of the correct CODB object.

Now the next page is one I am not really looking forward to: "DNS". That's a sucker as well. The original page of 5100R vintage is coded in a deprecated coding style which doesn't use UIFC. So instead of at least being able to borrow the formfields from it, I have to write it entirely from scratch. Fun and games!

But yeah, there is progress, but it's slow. During the next two to three weeks I hope to get "Network Services" and "Security" entirely ported. But we'll see.

BlueOnyx Demo:

Username: admin
Passsword: demo123

Jul 18, 2013 Category: General Posted by: mstauber
Previous page: Development Next page: Mailing List