More Theme Progress

This is further progress report about the rethemed BlueOnyx.

Another three weeks have passed and yet again I spent almost every day coding on BlueOnyx to finish the re-theming effort.

In the last progress report I mentioned that most obstacles were out of the way and two things needed to be done:

• Modifying ~60 UIFC classes to render UI elements for the new theme.
• Coding 200 GUI pages using the modified UIFC classes.

I'm now done with about half of the UIFC classes. All the important ones and frequently used ones are translated. A few of the rarer ones will be done when I catch up coding the pages that actually use them.

About two weeks ago I finished porting CompositeFormField.php, which allows to render a single Formfield that contains a label and multiple additional Formfields. A prime example for this is the Formfield where you enter hostname and domainname. CompositeFormField.php is used for that and renders a Label and the two individual Formfields.

Aditionally I tackled AutoFeatures.php, which is used whenever a GUI page can be extended with additional PHP elements, which may or may not be provided by stock modules or third party modules.

However, most of the last week was unfortunately spent chasing one minor nuisance: "Labels"

This requires a bit of an explanation: A Sausalito "Label" is the header of a Formfield. The text (and mouseover helptext) that explains what the Formfield is for. At an earlier point of the re-theming effort I made a design choice which started to bite me in the ass later on.

Back in "the old days" whenever a Formfield was rendered, the "Label" and the actual Formfield (checkbox, input-field, radio selector or pulldow) were rendered separately. Due to the tables that were used for the layout and due to the place where this was stuffed together, it made sense. My design choice was to render label and Formfield together. In most cases the Label ID and Formfield ID are identical anyway.

But later on I realized: There are enough places where Label ID and Formfield ID differ. When parsing form submitted data this is of relevance, as the Formfield ID or Label ID is used for the name of the variable that contains the submitted data. It also matters for the localizations. Because if the Label ID and the Formfield ID are different, then we might not have a translation string for the Formfield ID, but one for the Label ID.

So I went back and tried to get the function getLabel() working, which renders the Label ID. Oh boy - what a mess!

There is uifc/Label.php which renders the LabelObjects. Then there is uifc/HtmlComponentFactory.php, which (via uifc/FormFieldBuilder.php and a hell of other UIFC Classes) renders the actual Formfields. It comes together in uifc/BxPage.php, which renders the actual GUI pages of the new GUI.

Like said: The actual Formfields are rendered (mostly) via uifc/FormFieldBuilder.php. That is where I need access to the LabelObjects that uifc/Label.php generates. However, I was at best able to get the lates few LabelObject, but not all of them. Due to the joys of object oriented programming this took a whole week, a lot of debugging and a lot of trial-and-error to sort that one out. Naturally the class that renders the LabelObjects is instantiated multiple times all over the place. And whenever a new instance of it fires, the previous LabelObjects become inaccessible. Even if they're still there, uifc/Label.php is instantiated in a way that it's objects are out of reach for uifc/FormFieldBuilder.php.

This required a whole new round-about via BxPage.php, which both classes (actually all Classes of the new GUI) have access to. So I expanded it with functions to record all LabelObjects that uifc/Label.php generates and to also report the given LabelObject of a certain Formfield back to whichever Class needs to know that info. Then I had to go through like 40 other UIFC Classes to both remove debugging code and to add the routines that use the new poll method to ask uifc/BxPage.php for the current LabelObject data.

Once I had decided on this work around it took like four hair raising and very stressful days to make it happen. But it's all good now.

I just updated the Demo with the latest build of the GUI:

BlueOnyx Demo:

URL: http://demo.blueonyx.it:444/login
Username: admin
Passsword: demo123

What's new:

• Browser compatability: Problems with Internet Explo(d/r)er have been fixed.
• "Site Management" / "Add Site" has been updated and is now final.
• "Server Management" / "Network Services" / "Web" has been added.
• Pen-Icon for active submenu entries has been added.
• Method for automatically opening active submenus has been revised.
• "Demo Mode" has been added for real. If /etc/DEMO is present, the "Save" button is disabled on all pages but "Personal Profile". But even then it will not set a new password for user accounts. Disabled "Save" buttons will show "Save (Demo)" instead and the mouse-over helptext will explain that the server operates in demo mode.

During the next two or three weeks I'll hope to crank out more GUI pages and to deal with more of the remaining UIFC classes that need adapting. However, with most of the fundamental ground-work now out of the way things should progress a lot more rapidly now.

This has already taken a lot longer than I initially anticipated, but it was time spent very well. I'm looking forward to the day that we'll be able to release the new BlueOnyx.