New feature for Role Tailored Client

generic

I was wondering of an idea that would lower the customization related to pages going forward.

If Nav introduces FieldGroup property to fields. On pages Standard NAv would be able to just specify the fieldGroups instead of fields.
And since Pages are rendered dynamically, it would display all the fields within that group.

That way if you add a new field you would just add the fieldgroup property and it will appear on all the pages.
[-o<

kine

It is something like in SAP B1... or in AX? :whistle:

I think that it will be not possible in the context how the application is working. To have some field on the page, you need to add the field to the page. On the page cannot be something which is not in the definition of the page. May be somewhen in future, but not in the nearest...

imurphy

Just using normal programming conventions would go a long way.

By this I mean classes, overloading, inheritance etc

The current functionality is mostly procedural rather than function calls which return results.

The over the top use of global variables would get nav rejected if it were presented as a first year programming project.

The massive undocumented functions with huge if then else blocks should be broken up into functions with a max of 1-200 lines.

Some sort of naming standardization applied so that you could actually work out what a variable was from its name.

If all this existed in a 'base' codebase from MS and we were able to 'override' class methods in a Granule.modifications file then it would be obvious where the base code was, what had been changed and what required changing.

These are compiler features and do nothing to affect the runtime speed so the only excuse is laziness or lack of interest on the part of the Nav designers.

Ian

generic

That's well put and to the point.

kine

It is thing of continuous developing and extending the functionality since firs version. ;-) Each change, extension etc. is "glued" to existing functionality, making the "growing" core. Of course, sometime the problem is there because e.g. function parameter limit - when you cannot use more than 20 parementers - you need to use global variables or another way how to pass the info. Sometime it is the complexity of the function which leads to the point, that all is written in one function (because there is no meaning of "dividing" it into more smaller parts, because each part as itself have no meaning). And of course, sometime it is just amaterism in the development. But I think that this applies to any software project, because everywhere are "only people".

Biggest "break" of the change is "backward compatibility and ease of upgrade". Because that, the changes in existing functionalities are minimized (no big "reprogramming"), because any big change in critical objects (e.g. posting codeunits) will lead to even higher cost of upgrade for all customers. And you must not forget that....