Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Update on View Updates
03-05-2014, 08:21 PM,
#21
RE: Update on View Updates
(03-05-2014, 08:11 PM)opto Wrote: So I would opt to improve those UI parts that are in daily use.

Well the menu options are used all the time by everybody so that part of the UI is the most common used, which is why I mentioned it.

Then I am talking about having the ability to hide fields that a company will never use. This could easily be done in the table view class.

Tim
Reply
03-05-2014, 09:56 PM,
#22
RE: Update on View Updates
(03-05-2014, 01:40 PM)Exsonqu_Qu Wrote: 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.

Hi Exson,

I am not sure why you think the view classes will have an impact on performance. I agree jquery does, but do not see why you think the view classes themselves will.

Readability is an incredibly subjective thing. We all believe our own work (whether its code, prose, or rhyming couplets) to be the most readable. Because we wrote it, we intuitively understand exactly what it means.

Here is the account sections data using the new table view class:

while ($myrow = DB_fetch_array($result)) {
$tablerow = array();
$tablerow[] = $myrow['sectionid'];
$tablerow[] = $myrow['sectionname'];
$editRow['content'] = _('Edit');
$editRow['link'] = htmlspecialchars($_SERVER['PHP_SELF'] . '?SelectedSectionID=' . urlencode($myrow['sectionid']), ENT_QUOTES, 'UTF-8');
$tablerow[] = $editRow;
if ($myrow['sectionid'] == '1' or $myrow['sectionid'] == '2') {
$tablerow[] = '<b>' . _('Restricted') . '</b>';
} else {
$delRow['content'] = _('Delete');
$delRow['link'] = htmlspecialchars($_SERVER['PHP_SELF'] . '?SelectedSectionID=' . urlencode($myrow['sectionid']) . '&delete=1', ENT_QUOTES, 'UTF-8') . '&delete=1';
$tablerow[] = $delRow;
}
$accountSectionsTable->addRow($tablerow);
} //END WHILE LIST LOOP

and here using the current code:

while ($myrow = DB_fetch_array($result)) {
if ($k==1){
echo '<tr class="EvenTableRows">';
$k=0;
} else {
echo '<tr class="OddTableRows">';
$k++;
}
echo '<td>' . $myrow['sectionid'] . '</td><td>' . $myrow['sectionname'] . '</td>';
echo '<td><a href="' . htmlspecialchars($_SERVER['PHP_SELF'] . '?SelectedSectionID=' . urlencode($myrow['sectionid']), ENT_QUOTES, 'UTF-8') . '">' . _('Edit') . '</a></td>';
if ( $myrow['sectionid'] == '1' or $myrow['sectionid'] == '2' ) {
echo '<td><b>' . _('Restricted') . '</b></td>';
} else {
echo '<td><a href="' . htmlspecialchars($_SERVER['PHP_SELF'] . '?SelectedSectionID=' . urlencode($myrow['sectionid']) . '&delete=1', ENT_QUOTES, 'UTF-8') . '">' . _('Delete') . '</a></td>';
}
echo '</tr>';
} //END WHILE LIST LOOP

Which is more readable? Well I guess if you asked around some would say the first, others will say the second. It's a very subjective thing.

I think the first thing to do is to put programming jargon such as mvc etc out of your mind, and concentrate on the code. The view class certainly makes the creation of data tables easier and in a more standard way, but the trade off is a level of abstraction (remember we already have lots of abstraction in webERP).

Tim
Reply
03-05-2014, 10:58 PM,
#23
RE: Update on View Updates
(03-05-2014, 06:43 PM)Forums Wrote: Hi @serakfalcon when I was talking about how options are presented I meant menu options, not select boxes.

Ah ok my bad, sorry about that. I assumed you were talking about <option>s...

Ok so essentially what we're looking at in terms of the view class for menus the overall structure can be almost the same as MainMenuLinksArray.php, and actually will probably load the information from there by default.

So, my overall idea would be a class for each list, that essentially describes in broad strokes, the Main Menu, top menu, and all the others like Transaction/Maintenance. essentially taking the information from MainMenuLinksArray and reorganizing it for display.

Data-wise we have menus, which have a certain display class, and elements which consist of a url/description pair, which should be loaded in a certain order. In and of itself that's simpler than the forms class by a long shot.

Right now, of course, the menus could be reconfigured (for everyone) by changing MainMenuLinksArray.php but what it seems you want is a user-specific override. A user-specific override is going to require one of three things,
1) we add tables to the database to track that information, (to save on speed we could keep the default in MainMenuLinksArray and only have user-specific options in the table, and cache their settings so it only has to load from the DB once per session, or after they change their settings)
2) we write the information to disk (xml or JSON or something like that), which makes it possible for people to configure by hand but a little less easy for the server to work with.
3) we write (or compile) a custom file for each user configuration. Sounds kind of silly to me after writing it, but it's also a potential solution.

So, to keep our options open the menu class should have the handlers to receive information built into the class, that way we don't need to decide which way to use yet, and if we can't decide we can allow both, or, neither (for the purists). So basically that means each menu class is going to need some identification information passed to it knows what information to retrieve and where it should retrieve it from or all the menu classes should be rolled into $MainView and $MainView can decide what to display after it knows what page it's on and whatever user setting we end up using that keeps track of whether we're using a custom interface or not.

I would like to make it possible to completely re-arrange things purely in the theme, so for example, in one theme maybe each of the menus could be 'tabs' that you can shuffle through, in another all the menu items are included in a top bar-- I am still thinking through the implications of this and how to make the information well-structured, able to fully represent what currently exists, but also flexible enough to look totally different.

I'll give a trial go at the class structure either tomorrow or the next day.
Reply
03-05-2014, 11:21 PM,
#24
RE: Update on View Updates
Yes I know about the MainMenuLinksArray code, I wrote it :-) I was trying to pull the discussion into a much more generalised one about how the whole UI works. Everybody has their own unique workflow and it would be interesting to think about how each individual could customise their interface to best match their workflow. For instance the use of breadcrumbs in the interface has been mentioned before, but no code ever written.

The UI of webERP is based on and still looks like the old CLI accounts systems of the eighties, and rather than just prettify it with jquery plugins what I am talking about is completely new thinking about how the users interact with the application.

Tim
Reply
03-06-2014, 12:54 AM, (This post was last modified: 03-06-2014, 12:54 AM by serakfalcon.)
#25
RE: Update on View Updates
(03-05-2014, 11:21 PM)Forums Wrote: Yes I know about the MainMenuLinksArray code, I wrote it :-) I was trying to pull the discussion into a much more generalised one about how the whole UI works. Everybody has their own unique workflow and it would be interesting to think about how each individual could customise their interface to best match their workflow. For instance the use of breadcrumbs in the interface has been mentioned before, but no code ever written.

The UI of webERP is based on and still looks like the old CLI accounts systems of the eighties, and rather than just prettify it with jquery plugins what I am talking about is completely new thinking about how the users interact with the application.

Tim

I'm all ears for any sort of UI change. You all have a lot more experience than me with the webERP UI and with accounting in general I'm sure, so I'm all ears. For now I'm more concerned with making any sort of UI change easier to implement and easier to change, but I don't have a lot of ideas as to what the best UI should be. I like the way PhreeBooks does their UI (top bar menu with dropdowns for items), or a lot of software packages use icons for the submenu menu items. I like Peachtree's workflow oriented model also. Of course, we'd probably want a customizable dashboard, where users can add items they use commonly from any tab.
Reply
03-06-2014, 06:36 PM,
#26
RE: Update on View Updates
Hi, Tim,

(03-05-2014, 09:56 PM)Forums Wrote: I am not sure why you think the view classes will have an impact on performance. I agree jquery does, but do not see why you think the view classes themselves will.

I think the View Class introduced will add overhead, which in another word, will affect the performance. Although there is argument about this topic, you can find some data here http://www.theserverpages.com/articles/w...n-OOP.html

Since I have no idea how those php code are compiled, there is a reasonable way to understand it:
Before we introducing the View class, the table, form etc texts can be available immediately. After using the class, the same texts cannot be available until a complex calculation has been done. Does the calculation do not need extra resource, such as memory, cpu time etc?
And we can get more evidence to support this point, there are lots of project which using abstract classes,mvc etc today, you can find that their performance is quite poor comparing with webERP.

If we introduce the View class, it'll almost be included in every page, it's almost inevitable to impact webERP's performance.

Although there are classes in webERP too, it's just be used as minimal as possible. Moreover, it's also introduced bugs hard to debug too, even still there is here now.

To program fast is one thing, to make a fast program is another. To introduce abstract method will improve program and maintenance speed, but those view point most of time is from programmers. As a user, they hope to get a fast program. Someone thinks programmer's time is more expensive than machine time, I believe webERP is on the other side: Machine time does matter. It's a project which is managed and maintained by community which organized by lots of talents like you instead of projects driven by business profit target.

My opinion maybe full of errors, I'd like to correct them if I'm wrong.

Exson








Reply
03-06-2014, 06:47 PM,
#27
RE: Update on View Updates
(03-06-2014, 06:36 PM)Exsonqu_Qu Wrote: I think the View Class introduced will add overhead, which in another word, will affect the performance. Although there is argument about this topic, you can find some data here http://www.theserverpages.com/articles/w...n-OOP.html

Hi Exson, that article is written about PHP 4.3.4. I would agree that the implementation of objects in PHP 4 was not that good but things have come a long way since then. I would be interested to see any benchmarks you have comparing serakfalcons view classes and the current implementation.

I'm sure you are also aware that there are many areas of webERP where Phil has consciously sacrificed performance for what he has considered readability, so if there does turn out to be a marginal loss in performance it would not go against how we have built webERP in the past.

Tim
Reply
03-06-2014, 10:15 PM,
#28
RE: Update on View Updates
what is good performance? That is difficult to decide.

In our case, it is the server/internet connection.
Waiting for a BOM list with 100 items is less annoying than waiting for 5 webpages with 20 tems each. (Although the wait is longer) - the processing of the resulting webpage is faster.

Waiting 10s for a webpage with integrated edit where I do not have to wait for other webpages may be convenient, even if there is more overhead and wait in the beginning. Compare use of phpmyadmin with in table edit..

Waiting for the server while I can do something else is ok, even if a few seconds longer.
All these little waits which are too short to look at another webpage in between are the really annoying ones.

Can I solve that by server performance, client performance, ...??
Reply
03-08-2014, 03:34 AM, (This post was last modified: 03-08-2014, 03:35 AM by serakfalcon.)
#29
RE: Update on View Updates
So I'm a little delayed on getting the forms done but I've added a menu view class and implemented it for index.php.

To address some of the speed concerns, I tried testing out a rudimentary cache, but I doubt it'd make a difference unless you had hundreds of users, also the cache needs to be aware of what security settings you have, (is there a way to do that? I don't want to use $_SESSION['FormID'] because that would increase the amount of files in the cache over time, and UserRealName could work but then the cache generates for every unique user, and if two users have the same real name but different security settings the cache won't know who to load for what). Its commented out in the files I uploaded to Github but you can test it.

I added in control rows, so controls multiple controls can be on the same row, and have a width. I didn't get height working the way I wanted, I will likely have to add css classes for the custom theme I'm doing, but it will be easier to implement using classic.

Implementation goals: The menu view custom settings (aka classes of items etc.) should be configurable by the theme, and there should be a mechanism to override the default menu items/ items order from MainMenuLinksArray with a custom interface. I did a quick test adding a 'dashboard' to the main menu but it had some unanticipated side-effects probably due to security settings. Since I'd have to not only modify security settings but also add a form to make the dashboard work properly I'll put that on pause until I feel happy with the forms.

Here's a sample of progress so far:
   

Reply
03-09-2014, 06:43 AM,
#30
RE: Update on View Updates
Hi serakfalcon, couple of points,

Would it make the code clearer to use <fieldset> tags in the form rather than lots of <div> tags?

Secondly it would be nice to have the ability to choose what fields to show based on a stored template by user or implementation? For instance in East Africa the concept of an "address" doesn't really exist, mostly businesses are described by a PO box and a town. All those address fields just serve to confuse users, but I don't want to have to keep changing the code. There are many other such fields that mostly (but not always) should be hidden. Also would be nice to change whether a field is mandatory or not based on this template, but I may be going too far there. Smile

Tim
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)