Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Update on View Updates
03-09-2014, 10:51 PM,
#31
RE: Update on View Updates
I know this might be a little off topic, but the content generally in this thread is similar to a few others in that we are proposing new functionality. I might throw in a spanner for a few secs (please excuse).

Should we not have some plan for webERP into the future (eg >= php 5.5) that not only takes into account proposed 'view' changes but also other changes in the code.

I would love to see a planned approach to agreed improvements in webERP that we could introduce in planned version releases. Each thread with the requirements cleanly listed, and research and best practice added with steps for implementation. I find it hard here to keep track in the forums wading through many threads (most likely me).

For me I get concerned as change in one area of the code is often not isolated from others and may have impact on implementation chosen elsewhere.

Thanks for your time,

Cheers,

PS: One of the issues I have now is that we are mixing the HTML output with the code (and i'll not go into pros cons here). And i know the issue with loading speed, abstraction levels etc previously raised. While not an option now, perhaps it will widen the discussion - for those interested I have customer scenarios where:

1. Always have a fallback from javascript in the code (no matter if it is jquery or other) - can be turned on/off as required

2. Templated output using TWIG (light weight template engine with caching) - fixes the view issues (been slowly going thru changes) and allows easier PDF of anything without the probs we have now for PDF reports.
Reply
03-10-2014, 04:58 AM,
#32
RE: Update on View Updates
I have been using Selenium to write tests for any changes I do to my code. It seems very good, and testing is something webERP desperately needs.

Tim
Reply
03-10-2014, 04:08 PM,
#33
RE: Update on View Updates
(03-09-2014, 06:43 AM)Forums Wrote: Hi serakfalcon, couple of points,

Would it make the code clearer to use <fieldset> tags in the form rather than lots of <div> tags?
Probably. If the templating system makes sense and is easy enough to use we can go back through and fix all that. For now I'm focusing on getting the intermediate layer working good and then we can tweak the templates after.

(03-09-2014, 06:43 AM)Forums Wrote: 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

With the existing system, you could create a new theme that would have if statement in the forms.html.php template that would suppress the address fields. So if you need to see addresses, you use one theme, if not you use the other. A better approach would probably be to introduce security settings on form fields, so you could disable fields for a certain set of users.

(03-09-2014, 10:51 PM)icedlava Wrote: I know this might be a little off topic, but the content generally in this thread is similar to a few others in that we are proposing new functionality. I might throw in a spanner for a few secs (please excuse).

Should we not have some plan for webERP into the future (eg >= php 5.5) that not only takes into account proposed 'view' changes but also other changes in the code.

I would love to see a planned approach to agreed improvements in webERP that we could introduce in planned version releases. Each thread with the requirements cleanly listed, and research and best practice added with steps for implementation. I find it hard here to keep track in the forums wading through many threads (most likely me).
That'd make sense. I didn't see any particular great development goals and so I figured I'd start something and see what happens. The changes I want to make will be useful to me but if we can all work together it'll be less work for me Tongue and I don't mind changing things to match the consensus view of what's best.

(03-09-2014, 10:51 PM)icedlava Wrote: For me I get concerned as change in one area of the code is often not isolated from others and may have impact on implementation chosen elsewhere.
For myself, right now I am keeping track of all updates to the main branch and trying to isolate my changes so that it will be mergeable with no change in functionality. That will likely become difficult if I keep going without merging, it's true. I would be really happy to see this, we could start a thread about desired functionality, who wants to work on it, and timelines for implementation plus a discussion of what wishlist developments are likely to conflict?

(03-09-2014, 10:51 PM)icedlava Wrote: 1. Always have a fallback from javascript in the code (no matter if it is jquery or other) - can be turned on/off as required

2. Templated output using TWIG (light weight template engine with caching) - fixes the view issues (been slowly going thru changes) and allows easier PDF of anything without the probs we have now for PDF reports.
TWIG looks interesting, I'll give it a look, I'm a bit concerned about having a lot of random dependencies but using code that already exists is better than writing from scratch, it's a pity I've finished about half of the code for templating already though.
I do agree about always having a fallback. It's not difficult to implement. Ideally we could have forms posting if js is disabled to the same place that AJAX scripts are posting to.

Reply
03-10-2014, 04:53 PM,
#34
RE: Update on View Updates
(03-10-2014, 04:08 PM)serakfalcon Wrote: I don't mind changing things to match the consensus view of what's best.
I'm in a similar position and currently maintain a few different branches of the code.

Quote:For myself, right now I am keeping track of all updates to the main branch and trying to isolate my changes so that it will be mergeable with no change in functionality. That will likely become difficult if I keep going without merging, it's true.
Yes I have the same issues. Subversion is not ideal for branch management so I keep the code in an additional SCM to Subversion where I can more easily manage the branching and merging.

Quote: ... thread about desired functionality, who wants to work on it, and timelines for implementation plus a discussion of what wishlist developments are likely to conflict?
I find the forums a little cumbersome but I'd be happy with that.

Quote:TWIG looks interesting, I'll give it a look,
I already know that a templating system is not currently on the books for webERP from prior discussion. That's fine, but I need it to reduce updating/maintenance of all the views in webERP. I'm happy to keep my custom branch updated and still have some views to go. Perhaps it might be an option in the future and I'll have something 'nearly' there already we can convert.

As to TWIG, I've used a number of template systems and wary of them depending on the objectives. However TWIG is very lightweight, has a good caching system, and the pros seem to out weight any cons that I can think of for webERP.

Again, thanks for the feedback,

Cheers,
Reply
03-19-2014, 07:12 PM, (This post was last modified: 03-19-2014, 07:13 PM by serakfalcon.)
#35
RE: Update on View Updates
I've been working on fleshing out the code for different themes.

Right now, what is called 'themes' will be renamed 'styles' since it only affects css, whereas 'themes' will be used for broader changes, like different templates (or even templating systems).
The 'classic' theme will represent webERP as it exists now, 'default' will be the new theme that has Datatables etc. and 'TWIG' will be an experimental theme that uses TWIG as a proof of concept.
This will require altering the code wherever the theme or default theme can be set. I think I'll keep the $Theme variable untouched for now and use values stored inside $MainView, for backwards compatibility before everything has switched over to the new way of doing things.

Also, while I was working on UserSettings.php I realized it would be really helpful to allow for select boxes to be filtered based off other selectboxes. So, if you give add the setting 'childselect' with the value being the ID of the child select, and add the setting 'hasparent' (boolean true/false) and of course give it an ID the code knows the select boxes are linked. The child select options just need to be passed another value - the index of the relevant parent option that they belong to, and then a javascript code will filter the child 'automagically'. I haven't yet built in a backup for if javascript is disabled, however.
I also added some documentation, here is the documentation for the table class:
https://github.com/serakfalcon/wERPy/wik...able-Class
Reply
04-04-2014, 03:03 PM,
#36
RE: Update on View Updates
I updated Views to include Twig.

I'll add Views to the working directory so you can try it out. It would involve overwriting header.inc,session.inc and footer.inc so instead I will make copies header-views.inc,session-views.inc and footer-views.inc so you can compare. The full theme functionality needs UserSettings.php to be overwritten (you can see it on the github page) and will require the insertion of a row into www_users to keep track of the theme style. (this is not implemented in the code I've written but will be easy to do.)
Reply
04-04-2014, 06:12 PM,
#37
RE: Update on View Updates
(04-04-2014, 03:03 PM)serakfalcon Wrote: I updated Views to include Twig.
Hi serakfalcon,

Oops - clash

i'd discussed some months ago with Phil to add twig and he then gave me the go ahead last week to add it to the new branch. I have just finalised updating the new Twig version along to my branch and about to push along with caching system, and template integration to the new webERP branch. The method allows running with and without twig depending on a switch.

Unfortunately due to some personal issues (thus my absence) the last week, I've only prepared it with updated Twig today (wanted it the latest before I push it) a today - and just about ready for pushing to the webERP new branch now when I saw your message.

Unfortunately, except for the include/Twig directory the integration is different.

I'm happy for you to continue yours but I will probably create yet another branch for the work that I have as it's being used now on websites and I am not about to change it again.

It means I can't work on this new webERP branch otherwise i'd be adding yet a third repository to upkeep.

Let me know if you want to try any of the integration I have. It uses themes and theme overrides as well.

cheers,


Reply
04-04-2014, 07:24 PM,
#38
RE: Update on View Updates
(04-04-2014, 06:12 PM)icedlava Wrote:
(04-04-2014, 03:03 PM)serakfalcon Wrote: I updated Views to include Twig.
Hi serakfalcon,

Oops - clash

i'd discussed some months ago with Phil to add twig and he then gave me the go ahead last week to add it to the new branch. I have just finalised updating the new Twig version along to my branch and about to push along with caching system, and template integration to the new webERP branch. The method allows running with and without twig depending on a switch.

Unfortunately due to some personal issues (thus my absence) the last week, I've only prepared it with updated Twig today (wanted it the latest before I push it) a today - and just about ready for pushing to the webERP new branch now when I saw your message.

Unfortunately, except for the include/Twig directory the integration is different.

I'm happy for you to continue yours but I will probably create yet another branch for the work that I have as it's being used now on websites and I am not about to change it again.

It means I can't work on this new webERP branch otherwise i'd be adding yet a third repository to upkeep.

Let me know if you want to try any of the integration I have. It uses themes and theme overrides as well.

cheers,


Oops, sorry. You hadn't posted anything in a while so I thought I might go ahead and do it myself. You can undo my changes, I have them safe on Github anyway so it's not a big deal
Reply
05-07-2014, 07:07 PM,
#39
RE: Update on View Updates
Status update:

I've been quiet for a while, thought I'd let people know what's going on. I have a massive deadline for some other work due in June so I put a hold on development for this for now. However, the good news is I have ported the classes to that work to speed some things along and integrated AJAX into them. All I need is to port the modified classes back, which will just be a day or two of work once I'm done.

To explain how the AJAX will work, for tables I used DataTables along with X-editable, which submits to a function that handles session security etc. Forms use AJAX when the submit button is pressed, and send the data to the server, which responds back with a success message. If the form is linked to a table, it will update the table. Forms can also be declared modal, so they will 'pop-up' when you click on a button.

However, these changes will complicate backwards compatibility, as they basically rely on javascript a lot more. I haven't figured out how to get things to work without it, any thoughts?
Reply
12-10-2015, 05:13 PM,
#40
RE: Update on View Updates
(03-01-2014, 03:53 PM)serakfalcon Wrote: 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.

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):


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.

appreciate information
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)