Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Update on View Updates
03-04-2014, 12:35 PM,
#11
RE: Update on View Updates
(03-03-2014, 10:44 PM)opto Wrote: 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.

In fact, we don't even have to modify the existing table structure (which would break the existing sort scripts, though that can be fixed). I will put the settings for external script use inside the themes themselves. That way the existing themes can exist as-is, and will render the same way to the user as they currently do, but the bootstrap/jQuery/tablesorter version will be able to co-exist alongside the current version as a separate family of themes.

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

Programatically webERP is not very complicated, and this doesn't add much in terms of complexity on top of that. Even the current code could be optimized (for example, UPDATE queries update every single row, whether there was a change of information or not (the worst case of this being the translate pages, which don't even work if there are too many things not translated), and htmlspecialchars() gets called on $_SERVER['PHP_SELF'] twice per row for many tables, causing anywhere from 10-50+ unnecessary function calls (An O(n) operation that could be an O(1) operation)) but I doubt that's affected performance so far. In general there's no point to optimize until you find a real bottleneck since humans are generally bad at predicting where computers will get stuck.

(03-03-2014, 10:44 PM)opto Wrote: 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.

This also something I'm interested in that jQuery will help with. jQuery can certainly make coding AJAX easier, and not having to reload the entire table on every edit does reduce db load (of course, if you have many concurrent users you'll have to have some way to load in other users edits, but that's a whole other story for another day).

Here's the GitHub link of my progress. I'm only including things I've changed (either refactored code, or the new additions), and I have not included the changes to header.inc or footer.inc, to make it easier to compare the changes to existing code.

https://github.com/serakfalcon/wERPy
Reply
03-04-2014, 05:27 PM,
#12
RE: Update on View Updates
@serakfalcon

to have table functions, sorting, in table edit and verification of edits I use jquery-datatables, the makeeditable plugin for datatables http://code.google.com/p/jquery-datatabl...i/EditCell which can be connected to jquery validation plugin, which also allows to add custom validation/verification code for nonstandard entries.


These three plugins already work together and have all necessary for table handling, local storage of table view preferences, in table editing, validation etc.

Klaus
Reply
03-04-2014, 07:31 PM,
#13
RE: Update on View Updates
The table sorting routine could easily be made to use the <thead><tbody> tags, the only reason I didn't write it that way was to avoid large scale changes. The way it was written was just a question of adding a css class to the <th> tag. That said, it was a fun technical exercise to write it, but I'm not convinced that in reality table sorting brings a great deal to the user experience in webERP. The function could easily be extended for multi column sorting, but I would say that it adds even less to the experience.

My experience of jquery is that on very old hardware jquery enabled sites quickly deteriorate in speed. If you have some very old hardware (>10 years) try comparing a jquery enabled news site like http://abcnews.go.com/ against http://www.bbc.co.uk which uses their own lightweight javascript library. I know a bit of table sorting isn't going to change speed, but once jquery is in weberp there are so many fun plugins it will quickly spread into every corner :-)

It is a shame that this discussion has got caught up on jquery/bootstrap as to me the best part of the work that @serakfalcon has done is in the table and form classes, which I believe would bring something new and good to webERP. They deserve a lot more attention.

Tim
Reply
03-04-2014, 08:15 PM,
#14
RE: Update on View Updates
jquery: I am surprised to see that nobody reacts to the proposal to make that user selectable. I don't want to force that on anybody on old machines or slow internet lines (us, for example).

A single checkbox (maybe with default no jquery) is all that would be needed.


There are use scenarios where it helps. There are others where it is no good.

Table search is helpful. Find a specific screw in a long material list for a BOM. Sorting not so much for us.
Editing in a table cell without reload of the full page is very helpful. We are on a slow internet line and waiting for the updated webpage is very frustrating.
Whatever can be done in javascript in the browser makes waiting for the internet connection unneccesary.

Validation of entries in the browser is helpful. It also avoids a roundtrip to the server.


Klaus
Reply
03-05-2014, 02:17 AM,
#15
RE: Update on View Updates
(03-04-2014, 07:31 PM)Forums Wrote: It is a shame that this discussion has got caught up on jquery/bootstrap as to me the best part of the work that @serakfalcon has done is in the table and form classes, which I believe would bring something new and good to webERP. They deserve a lot more attention.

To be honest, my main goal is implementing view classes, the jQuery/Bootstrap elements are just to highlight some of the 'cool stuff' that is possible/easier to do once the classes are implemented.

(03-04-2014, 07:31 PM)Forums Wrote: once jquery is in weberp there are so many fun plugins it will quickly spread into every corner :-)

I think I'd like to enable that sort of thing, because plugins are great! While at the same time, allowing stripped down versions for people who want that sort of thing.

I've reworked my code so it doesn't automatically include jQuery etc., rather, themes themselves will decide if they need to include anything or not. I also reworked the classes to be instantiated by a master factory class, $MainView, which will be the main workhorse for all class-related activities. That also allows theme-specific custom classes to be built by extending the class $MainView is an instance of and overwriting $MainView with the new extended class. Hopefully that should make custom builds easier to manage.

I will go back through the code and create a new theme 'classic' which will look the same as present without jQuery, bells, whistles etc. It's pretty trivial since I'm building the classes around the current structure.

(03-04-2014, 05:27 PM)opto Wrote: to have table functions, sorting, in table edit and verification of edits I use jquery-datatables, the makeeditable plugin for datatables http://code.google.com/p/jquery-datatabl...i/EditCell which can be connected to jquery validation plugin, which also allows to add custom validation/verification code for nonstandard entries.
That's a great link! I can switch the code to use DataTables for the sorting etc. however for AJAX I am a little concerned that the current structure is not the best for making it work. Implementing AJAX on everything will be a goal for after this little project is complete.

I've published the latest changes to GitHub, forms are stable but only vertical forms are supported, and not all controls are implemented yet.
Reply
03-05-2014, 04:12 AM,
#16
RE: Update on View Updates
(03-05-2014, 02:17 AM)serakfalcon Wrote: To be honest, my main goal is implementing view classes, the jQuery/Bootstrap elements are just to highlight some of the 'cool stuff' that is possible/easier to do once the classes are implemented.

This was my point, the jquery discussion (and jquery has been debated to death on this project in the past) is hiding the discussion about the view classes.

Jquery plugins can add in some neat tricks to the current interface, but I would like to see some more fundamental discussion about the interface.

We have 200+ options for the user, how do we present those options to the user?
How can a user customise their interface to better suit their work flow? (in my 30+years experience in accounts department every one works differently)
How about customising the input fields that a user sees? Working in Africa lots of fields that are necessary in Europe have no meaning there, and only confuse the user.

There are lots of issues like this that I think are more fundamental than whether to have the fancy jquery tricks.

Just my thoughts :-)
Tim
Reply
03-05-2014, 01:40 PM,
#17
RE: Update on View Updates
Dear all,

It's apparently that webERP has some codes should be tided up. But it should not mean we do not care about the performance. Your expertise about this is highly appreciated!

webERP has 4 goals to keep. The introduction of class View at least broken 2 of them---Keep webERP fast and make it readable and modifiable for business man (IMHO).
webERP try to avoid abstract whenever possible since it add overhead and make the logic not so clear. Moreover, it also a overhead for some businessman to learn it.

I believe webERP pay more attention to business logic instead of popular "programming style" such as "MVC". The simple and concise coding style make the bug is easily detected and also make the code strong enough. webERP set up an example for business logic oriented style. It make the business operation looks so natural and intuitive, users can master it very quickly.

Thanks and best regards!

Exson


Reply
03-05-2014, 04:03 PM,
#18
RE: Update on View Updates
(03-05-2014, 01:40 PM)Exsonqu_Qu Wrote: webERP try to avoid abstract whenever possible since it add overhead and make the logic not so clear. Moreover, it also a overhead for some businessman to learn it.

I have to disagree with this line of thinking. The reverse is true: In order to edit a page now, a 'businessman' will have to have working knowledge of HTML,SQL, php,css and possibly javascript depending on their needs. If we use abstract view classes, then they only need to know the class functions and basic php around them. This greatly simplifies the learning curve for any edits. Similarly, putting the html code in-between business logic makes the code less clear to 'power users'.

We can't get around the use of SQL but for most use-cases we can make it so the user only has to know some SQL, a little bit of php (which they can copy from the existing code) and how to use the classes, which we'll have documentation on. Effectively, through abstraction we've removed the need to understand what the HTML, css and javascript codes are doing for most cases. Especially for the HTML, this is critical as an unclosed tag, or too many closures will completely mess up the page.

Or, while talking about clarity, it's not intuitive that <th class="ascending"> means that that column and by extension the table is sortable. I understand you've probably worked with webERP for some time now and that convention is clear to you, but I assure you, it's not clear for someone new to the code! On the other hand,
$sometable->sortable = true;
is immediately clear, without even having to add comments in the code.

(03-05-2014, 01:40 PM)Exsonqu_Qu Wrote: The simple and concise coding style make the bug is easily detected and also make the code strong enough.

I am overall happy with the way webERP has been coded to date, it is not too difficult to understand what each page does. I definitely don't want to change that understandability as I also see it as a strength. But, just because webERP's code is relatively clear and understandable does not mean that it is the most clear it can be!

Using similar code over and over where html is concerned both makes the business logic harder to follow, and does lead to errors and inconsistencies that would be caught faster if encapsulated in a view class. It shows- near every page I've been refactoring has minor bugs in the display code.
What I'm doing won't change readability, in fact it will make things simpler!
Likewise, some users (like yourself) prefer a stripped down, simple version. Others (like opto and myself) prefer a more fully-featured version. Right now, the code can support only one of these options. After implementing the view classes, both can exist simultaneously.
Performance is not an issue for the server-side changes. jQuery with lots of plugins on an 'ancient' computer is another story, but you won't be forced to use a theme that implements jQuery. The whole point of this exercise is that it enables webERP to look nice and have lots of cool GUI features WITHOUT forcing people who like it the way it is to have to change.

(03-05-2014, 04:12 AM)Forums Wrote: We have 200+ options for the user, how do we present those options to the user?
How can a user customise their interface to better suit their work flow? (in my 30+years experience in accounts department every one works differently)
How about customising the input fields that a user sees? Working in Africa lots of fields that are necessary in Europe have no meaning there, and only confuse the user.

There are lots of issues like this that I think are more fundamental than whether to have the fancy jquery tricks.

Yes, for the drop down boxes I think there could be some reworking there.
It's possible to have a text box that filters the options, that would require some javascript magic though. For tables, the DataTable jQuery plugin can solve that since it has a search bar.

Here's the new syntax, for forms:
Code:
$GLaccountsForm = $MainView->createForm();
$GLaccountsForm->id = 'GLAccounts'; $GLaccountsForm->setAction(htmlspecialchars($_SERVER['PHP_SELF'],ENT_QUOTES,'UTF-8'));
$GLaccountsForm->FormID = $_SESSION['FormID'];

The first statement sets up the form by creating a form class. The next three are necessary for the POST to work properly, I don't know if it will be possible to abstract these away, (will FormID always be = $_SESSION['FormID']? is setAction always PHP_SELF? I haven't checked all the use cases in webERP yet) but we can if we need to.

After that we get to the main workhorse of the form: addControl:
Code:
$GLaccountsForm->addControl(1,0,'static',_('Account Code'),$controlsettings);
From left to right there is a key, which allows you to reach it later (for example, to add options to a select box, or move the control around based on an if statement lower down in the code), a tabindex, so you can customize the tab order, a type, which includes all the HTML5 types but also some custom ones ('static' e.g. read-only,'yesno' which gives a dropdown with only yes and no).
after that you specify the caption which will be displayed with the control, and any settings, which are HTML properties, except 'required' and 'autofocus' can now be set to true or false instead of having to write out 'required="required"' for example.

I will add another setting, [row, order,height,width] where row is the row and order is the order within that row in which the controls will be displayed, and height/width determines how much space the control takes up (in units defined by the theme, for example, using bootstrap span[height] col-md-[width], in classic, colspan,rowspan) . For simple interface changes, changing these settings will allow complete reconfiguration of the form.

So, if a user doesn't want a control, they can simply comment out or delete the addControl() line, and if they want to reposition, they can modify [row, order,height,width]. If we wanted to be really fancy, we could store values for these items somewhere, and allow any form to be configured from the front-end. I don't necessarily recommend that though, as it should be pretty trivial to open up the .php file and change those values.

Finally, the form is displayed by calling $someform->display();
so before you make that call, anything can be changed.

If I completely had my way, I'd like to split each page in two, with the $_GET and $_POST being handled by one half, and the interaction between the results of that and what the viewer sees being handled by the other half. That would simultaneously make the pages less overwhelming for power users (since they can see what inputs are provided to the page, in the form of variables, and what outputs are expected, without having to see the code that facilitates all that) while also making every page more AJAX-friendly. That's beyond the scope of what I'm proposing now however.

GitHub version updated, now using DataTables.
Reply
03-05-2014, 06:43 PM,
#19
RE: Update on View Updates
Hi @serakfalcon when I was talking about how options are presented I meant menu options, not select boxes. I was trying to say that instead of prettifying the current UI with jquery plugins we should be looking at the general UI design.

Can I suggest this discussion is split into 2 threads? One about the view classes, and one about Jquery?

Tim
Reply
03-05-2014, 08:11 PM,
#20
RE: Update on View Updates
modify options versus table usage:

I would consider: how often does end user use the part of weberp
how much work to do to change

We, for example, would very much need in table search (for parts in long BOM part lists).
We need that on a daily basis.

Selecting some of the options looks crazy, but is done only once.
So I would opt to improve those UI parts that are in daily use.

Klaus
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)