Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Update on View Updates
02-28-2014, 01:12 AM
Post: #1
Update on View Updates
OK so I won't post the code for this yet because I'm not quite happy with it, I need time to ensure that I have proper templates/classes that will balance keeping things simple but also flexible.

There's not much point to me releasing it until I've gone through most of the existing code to find output patterns, but while it does involve a lot of changes to the code structure it doesn't actually change anything in terms of output or functionality.

Some updates on the approach, to at least give an idea of where i'm heading with this:

I have implemented a class, called tableView

to display a table using the class, we'd start with any custom css classes,
which in general seems to be 'selection'.
so to use it we'd do the following:
Code:
$randomTable = new tableView
$randomTable->setClasses('table','selection');
then we'd add headers: tableView expects it as an array.
If an element is an array, it will look for specific things 'content', 'link', 'classes','span'.

Code:
$headers[] = 'Title 1';
$headers[] = 'Title 2';
$headers[] = 'Title 3';
$specialheader['content'] = 'Title 4, 2 span & link';
$specialheader['link'] = $someurl;
$specialheader['span'] = 2;
$headers[] = $specialheader;

$randomTable->setHeaders($headers);
so now the headers are ready, what about content.

Content is prepared the same way, each row is added one at a time
Code:
$newrow[] = "First cell";
$newrow[] = "Second cell";
$specialrow['content'] = '3 span cell';
$specialrow['classes'] = 'some-css-class';
$specialrow['span'] = 3;
$newrow[] = $specialrow;

$randomTable->addRow($specialrow);
Finally, we use the output by calling
Code:
$randomTable->display();

Ultimately, the class connects between the 'workhorse' code and ensures that everything will be passed in a way that the template can use easily.
And lastly, the templates are in separate files, they are basically html with placeholders for the pieces of information. Also, it makes the code a bit more understandable since you don't have to think about <tr> and <td> and all that mess. It also allows for those to even be replaced by div's or other formatting down the road.

For an idea of what it looks like in production code here's a revised AccountGroups.php

Let me know what you think, I will post more once I have the classes/templates more worked out.


Attached File(s)
.php  AccountGroups.php (Size: 20.16 KB / Downloads: 7)
Find all posts by this user
Quote this message in a reply
02-28-2014, 11:37 PM
Post: #2
RE: Update on View Updates
OK another update,

I'm starting to work in Bootstrap, and since Bootstrap needs jQuery I decided we could also get a proper tablesorter as well, so as you notice the table can be sorted by multiple columns (in this case, descending on the second and ascending on the first, in that order).
   

You can't see it from this example but the reason I implemented it was because the current table sort is doing a text sort on numbers, which causes some issues when they aren't the same length: an ascending sort will have 5 placed after 40 for example.

I have also created classes to describe forms and controls but it's still a work in progress, the table class should work fine for most applications but I wouldn't use the forms and controls just yet.

Attached is a compressed file of the additions I'm making, note that the tablesorter code comes from http://tablesorter.com/ if you're interested. It's all new files except for two small changes to header.inc and footer.inc to 'hook in' the new logic. Note that tables won't look like the picture unless they are implemented using the tableView class.

to 'hook in' add these lines to header.inc and footer.inc
before default.css is linked in header.inc i.e. before line 40:

Code:
include($_SERVER['DOCUMENT_ROOT'] . $RootPath . '/views/views-header.php');

after the last </div> but before </body> in footer.inc:
Code:
include($_SERVER['DOCUMENT_ROOT'] . $RootPath . '/views/views-footer.php');

Also attached is the modified AccountGroups.php that will display the table as shown. Note that I'm developing the css for aguapop first so it'll look weird with other themes, but I'll roll all the themes into the new design once I'm done.


Attached File(s)
.zip  webERP-Bootstrap.zip (Size: 247.13 KB / Downloads: 16)
.php  AccountGroups.php (Size: 19.94 KB / Downloads: 3)
Find all posts by this user
Quote this message in a reply
03-01-2014, 01:53 PM (This post was last modified: 03-01-2014 01:55 PM by phil.)
Post: #3
RE: Update on View Updates
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?
This is what it currently looks like - the differences seem to be the icon for the sorting - which is actually done without any graphic to save bandwidth and the wider row height - I am sure we could do this with a modification to the css theme.

   

I really don't understand why we would even consider re-writing the application with all this additional overhead?

If you wish to sort numbers as numbers then the cell just needs to be of class="number"!

If there are practical reasons for doing this or it gives us great flexibility in some other way then I am all ears...

Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Visit this user's website Find all posts by this user
Quote this message in a reply
03-01-2014, 03:53 PM (This post was last modified: 03-01-2014 04:09 PM by serakfalcon.)
Post: #4
RE: Update on View Updates
(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.
Find all posts by this user
Quote this message in a reply
03-01-2014, 07:13 PM
Post: #5
RE: Update on View Updates
Phil, As you know I agree with you on the subject of jquery (though you might have expressed yourself better), but I do think you should look again at the ideas serakfalcon is putting forward regarding views. By using a standard way of displaying an array of data in a table it could actually make the code more readable to a non-programmer. I would certainly not want to include a large external framework into webERP, which is why I like what is being proposed here where we have a nice simple class that takes all the <td> <tr><th> tags out of the main code and just leaves what the person coding is really interested in, the data.

Tim
Visit this user's website Find all posts by this user
Quote this message in a reply
03-01-2014, 09:50 PM
Post: #6
RE: treating numbers as 'numbers'
(03-01-2014 01:53 PM)phil Wrote:  If you wish to sort numbers as numbers then the cell just needs to be of class="number"!

Hi Phil,

I am not quite sure why you complain that the poster uses a method for sorting other than your preferred. This would not come up if numbers were treated as 'numbers', just as you describe.
To me, this sounds a bit unfriendly although the code change only came up because number sorting did not seem to work.

if I understand the post correctly, the current view implementation does not treat numbers as numbers. Having an ERP system sorting numbers in a wrong way feels undesirable.

So even if no jquery - I think the question seems valid why currently numbers are not class='number'? Is someone willing to review that?
I see problems for long lists and untrained assistants who might nor remember to look for 5... entries behind 4, 40, 400, 400000...

cheers, Klaus
Find all posts by this user
Quote this message in a reply
03-01-2014, 10:00 PM
Post: #7
RE: Update on View Updates
Hi Klaus, what Phil is saying is that numerical columns are sorted correctly if that column is of class number. In Account groups, and account sections scripts the columns are not of class number. In AccountGroups.php change line number 322 from

<td>' . $myrow['sequenceintb'] . '</td>
to
<td class="number">' . $myrow['sequenceintb'] . '</td>

and the sorting will then take place correctly.

Tim
Visit this user's website Find all posts by this user
Quote this message in a reply
03-01-2014, 10:08 PM (This post was last modified: 03-02-2014 12:39 AM by opto.)
Post: #8
jquery, table sorting, column reordering, in table edit, validation
and also multi column sorting, multi column search across tables, pagination etc.


I can see that bandwidth is a problem in certain locales.
Even on DSL, I encounter that I suddenly have to wait for Amazon pages (being multi-MB), so this is a very valid issue.

On the other hand, Jquery greatly improves the user experience.
If by default jquery is not transmitted, the table simply falls back to the standard table at low bandwidth.


In web2project, I am currently adding table sorting, hiding columns, storing preferences in cookies, providing 'in table' edit, edit verification, search against multiple table columns, just to name a few, using datatables and an independent but related edit and verification plugin.

This comes on top of the standard website. On low bandwidth just don't transfer jquery and plugins, and the site falls back to what you have now. With jquery, enhanced user experience. Put the decision into a system setting, and the user can decide.

No extra code is necessary but adding thead, /thead, tbody and /tbody to the tables. So no impact on readability.
In addition, add the plugins and set their cnfiguration parameters.
Even 'in table' edit (for user experience compare e.g. recent phpmyadmin) is only a line to tell which script to send to.

The user could use a system parameter to indicate whether jquery should be loaded. Default could even be set to no to keep standard bandwidth as low as it is now.

Klaus
if you are interested, I could do that for BOM's, for example (our line of interest).

If you add a system setting disabling jquery by default, nobody would loose anything. (no extra bandwidth).

But if a users decides to use jquery, the above mentioned functionality would be there.
I think the overhead by the thead's and tbody's is negligible.

The extra work makes only sense for me if there is at least a chance to get it into the current code. If it is a clear no from the beginning,
no problem.

Klaus
Find all posts by this user
Quote this message in a reply
03-03-2014, 09:38 AM
Post: #9
RE: Update on View Updates
Dear all,

I'm worrying about webERP would loss the speed merit if we introduced more framework and classes into it just hoping to improve the interface. There are lots of users choosing webERP instead of other projects usually because webERP is fast obviously.

Interface is important. But fast and low brand is still very important in current business environment.

And since webERP use table everywhere, so I think responsive is not a problem and it has been used by tablet very long before.

Thanks and best regards!

Exson
Find all posts by this user
Quote this message in a reply
03-03-2014, 10:44 PM
Post: #10
RE: Update on View Updates
why not give the user the option to choose and integrate both?

This way, weberp can exist in both worlds.

1) Have a system checkbox which decides whether jquery etc will be send. All pages strictly fall back to the current layout if jquery is not transmitted.

2) Each table (only !!!) needs 4 extra html tags: thead /thead tbody /tbody. It is easiest to send those even if jquery is deselected.
Together, the four tags don't create much overhead - it is 30 extra characters for the four tags (30 bytes - not kbytes) for users deciding for higher speed.

Altogether, that is al lthat would be need to be transmitted to those not having the bandwidth. We also transmit data in the tables: rows and columns have content, and that is significantly more than 30 charactrers.

So I think this actually is not a decision between two seperate ways - both worlds can easily be combined without disadvantages for the users not using one or the other.

Some scenarios even bring speed:
Editing inside a table cell can bring speed, because I do not need to transfer the whole table upon every edit. Only the edited cell (e.g. a price) will be posted to the server and will be returrned as acknowledgement that the edit went fine. This substantially saves bandwidth.

For users with fast lines this will bring usage enhancement.
For users on slow lines, it is more difficult to decide: if tables (data) are really big, jquery can actually speed up because more can be done in the browser without loopback to the server.

I know from personal experience - for a long time, we were still on ISDN lines when all Germany already was into DSL. So I well know how one suffers if all webpages are big and need 50s to display in an ISDN line. So having the fast option is a good decision.

But I think the user friendly can be added with very little code that is only transmitted to users selecting it, because jquery can fall back to the current implementation if not transmitted.

Klaus
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)