(03-01-2014, 01:53 PM)phil Wrote: Well you must forgive me for not taking this too seriously... 247kb compressed of bootstrap plus jquery overhead to do almost the same as we have? With a fraction of the code and more readable?
I'm not really interested in arguing the relative merits, I needed a ERP system to complement systems I already have, I could either build it from scratch, buy one that won't integrate with what we've got, pay through my nose to get other people to build it for me, or modify whichever open-source ERP suits the most of my needs, to fit the rest of them. Obviously, webERP is the ERP that I've picked, so good job!
I've been posting this information out of the general idea that since I'm planning on doing this anyway, I might as well keep you and everyone that might be interested in a more 'modern-looking', responsive and more interactive GUI: of course that will involve extra files. that is an inevitable trade-off but In my estimation the cost is negligible.
(03-01-2014, 01:53 PM)phil
' Wrote: If there are practical reasons for doing this or it gives us great flexibility in some other way then I am all ears...
Benefits
-Multi-Column Sorts
-Automatic column type detection
-Repeat Headers
-Table Pagination
-Responsiveness (automatic support for tablets/smartphone support is easy)
-Extensibility
-Improved legibility of program-flow logic (vs. trying to tease out what is program flow and what is display code)
As I mentioned, the tablesorter can sort by several columns not just one, which is new functionality, it can also sort by dates, percentages etc. without needing to add a class just to specify what sort of information is in the table. It can also do preset sorts on page load or on click of page elements (e.g. a button). There are other bells and whistles like table pagination that respects sorts but I'll develop that as it goes along.
For simple uses, all you have to do is add a class to the table so the site knows it should be sortable, and you're done. Complicated uses you can see the website, but there's a lot of neat things you can do with the code.
As I continue to mention, merging all the output code into one place does make 'skinning' the site simpler, ensures the output to the user will be more consistent and makes database interactions more obvious since you're not hunting through random outputs of html in every single 'user-facing' file in the project. It also allows some simplification of control flow since you aren't forced to display until the object is fully built.
If there are patterns that repeat themselves often, I will roll those into the classes.
All of that makes the logical flow more obvious instead of having to twist around display logic, and not having to worry about formatting so much reduces the work to add new functionality, which is exactly why I'm doing it.
A prime candidate for abstractification is htmlentities: that will avoid the whole 'storing html entities into the database randomly if you didn't think to unencode something you encoded' problem by restricting html encoding to the view only.
From the form class (updated code to come next week, I will probably add this all to GitHub once I am comfortable with the code):
From GLAccounts.php
Code:
echo '<input type="hidden" name="SelectedAccount" value="' . $SelectedAccount . '" />';
echo '<input type="hidden" name="AccountCode" value="' . $_POST['AccountCode'] .'" />';
becomes
Code:
$GLaccountsForm->addHiddenControl('SelectedAccount',$SelectedAccount);
$GLaccountsForm->addHiddenControl('AccountCode',$_POST['AccountCode']);
I've noticed throughout the code sometimes the hidden controls are added before the title, sometimes after, sometimes inbetween other controls. This way they are all inserted into the same place AND it is obvious what part of the site they come from, instead of having to look through the file to see where the input tags are being added.
There is similar inconsistency with the submit button, and random <br /> inserted in some forms and not others for no apparent reason.
Either way, it's always good to look through code just in case, for example, while I was implementing the form class for AccountGroups.php I noticed that
there is a spelling error in line 230 which causes the parent group to not be selected:
Code:
if (isset($_POST['ParentGroupName']) AND $_POST['ParentGroupName']==$RroupRow['groupname']) {
$RroupRow should be $GroupRow.
-Responsiveness
Another advantage is that bootstrap is responsive, or more accurately, it is easily reponsive, and should work fine for tablets and with a few adjustments here and there will work fine for pretty much any smartphone. Once I finish off the forms class they will always fit on your screen and tables will have a scroll bar to scroll horizontally (I will probably use the pagination plugin from tablesorter to fix long vertical tables but that is down the road). Bootstrap also supports 'off-canvas' menus which would allow pretty much full menu functionality for smartphones but that would be something to deal with later.
Cost
-40kb in code, 140kb in fonts (all cache-able)
-code refactoring
The load on the user is ~40kb for the bare minimum files necessary to run bootstrap, jquery and the tablesorter (all the css and js is minified). With browser caches & modern computers being what they are, of course, 40kb is nothing. With an extra 140kb you can add bootstrap glyphicons, which could replace most of the current images of any of the themes for approximately the same cost in size, but will take less http requests to do so.
I of course recommend downloading the whole package for programming purposes, for obvious reasons. (besides minification, a .less compiler sure makes themes a heck of a lot easier to put together!) but those files are purely for template designers to worry about.
To take advantage of the new classes, the old code will have to be rewritten but I'm already doing that so it's not like it's extra trouble for anyone else.
I forgot to mention in my previous post that the file viewcontroller.php would have to be included to make everything work, but I decided to roll the include into the views-header.php file for the next update (for simplicity). I'll post the form & control classes code sometime next week.
