Hi,
Over the past week-or-so, I've been working like a mad on a branch in my repository ("master-fixup") which is a branch of - you guessed - master. So, what's going on?
Last week, I discovered that the migration to a frame-less setup is both great and has caused quite a bit of breakage. Great as in: pages seem to render much more quickly after the initial load, they look much more modern, etc.
But quite a bit of breakage in the sense that a number of techniques employed in 1.4 now fail in master:
- In 1.4 we have full pages in a frame, including CSS and JS (taken from the page's HEAD section)
in 1.5, the HTML from the body of the response is used and inserted into the active page, skipping over the JS and CSS in the HEAD section
- In 1.4 we rewrite the HTML in the main frame when the document finishes loading, in order to present nice dojo widgets
In 1.5, since there's no frame, we lost the "page is complete, now please rewrite" moment; dojo is rewriting the widgets for us upon inserting into the main page. This means the widgets have to be configured "just right" in the HTML delivered to the insertion handler
- In 1.4, where you can use the back button to get to the previous page (even though you lost the data entered due to the widget-rewriting), this doesn't work in 1.5 anymore: the back button gets you out of the LedgerSMB application all together.
So, what have I been doing on the branch?
- Converted all code to use dojo widget type declarations so the AMD parser can act correctly upon inserting the HTML in the main page
- Fixed up bad HTML in old code so the AMD parser can make sense of it
- Added dojo type declarations to most(all?) old-code form element tags
- Enhanced the 'elements.html' helper template code to make sure it identifies elements as the correct dojo widgets
- Introduced error reporting as a popup screen instead of replacing the active page with the error report (closing the error popup gets back the entered values now!)
- Cleaned/migrated templates (replacing "bare" form tags with calls to 'elements.html')
- Eliminated code duplication in both old and new code
- Eliminated the need for specialized LedgerSMB widgets derived from dojo widgets by making better use of dojo's options do pass constructor arguments
- Merge multiple JS
- Merge multiple CSS files
- Remove the entire manual DOM/widget construction (in favor of depending on the AMD parser completely)
All that we have left now is some processing of the final HTML document to attach onClick and onSubmit events to make sure the content is loaded into the right places in the destination DOM correctly
While going over all the screens (which I have only mildly tested so far, but enough to find these problems), I found a bad interaction between the move from DBObject - LedgerSMB's built-in "ORM" mapper - to PGObject and the move from frames to frameless. I'll send a separate mail later to present the problem and a solution design.
So, what's left to be done?
Well, lots of testing, of course. However, the following items are also required to be completed:
- Fix the fallout from the move from DBObject to PGObject
- Consolidation of the various CSS files into a single CSS file (because the in the frameless situation, the separate CSS files won't be loaded upon the page loads anymore)
- Rewrite the JS in the following files to leverage Dojo's widget system so the JS files get loaded dynamically when the AMD loader detects they're needed for the page being presented:
* payments_detail.js
* maximize_minimize.js
* asset.js
* preference.js
- Create some well-defined back-button behaviour; while the back button behaviour in 1.4 isn't exactly to my liking, it mostly works. In 1.5/master, since all documents are loaded into a single page, the webbrowser history won't get any changes after the initial '
login.pl' URL. Hitting "Back" once and you'll be out of the LedgerSMB webapp.
I'm expecting much of this work to be completed by the end of the week. At that time, it would be great if people could start experimenting with master/1.5 (not for alpha or beta, just playing with it) so we get a better idea of the quality of the code and the problems that are still there. I'll do so too, of course, but one/two persons can only test so much.
My aim is for the branch to be merged back to master as quickly as possible in order to get master in a stable state and work on further features/stabilization from there.
Thanks for listening! I hope you all join in on testing next weekend!
Regards,
--
Bye,
Erik.
Robust and Flexible. No vendor lock-in.