(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.