microsoft / AL

Home of the Dynamics 365 Business Central AL Language extension for Visual Studio Code. Used to track issues regarding the latest version of the AL compiler and developer tools available in the Visual Studio Code Marketplace or as part of the AL Developer Preview builds for Dynamics 365 Business Central.
MIT License
733 stars 243 forks source link

Need GUI driven development environment for AL code development #4592

Closed Rama-M closed 9 months ago

Rama-M commented 5 years ago

VS code environment currently used for AL code development is not working very well for a large scale, real life development work. It is lacking high level visual design feature. Developers are spending more and more time working on the nitty-gritty of syntax error rather than concentrating on design work on objects such as Pages and Reports for example. Even after getting speed with working with AL code, the VS code environment is quite considerably slowing them down working on AL code. To address this can Microsoft come up with similar development environment like the current C/SIDE development environment. This high level development environment needs to have an inbuilt and integrated source code repository stored in the database as current as well. Such high level visual (WYSIWUG) development environment will significantly speedup and improve project delivery using AL code. Having the source code stored in the database (such as in Object/Object metadata table) will help the customer to switch partners easily. Something Microsoft is encouraging now a days. To help this process it is essential the source code for any changes needs to be stored in the database rather than in an outside source (.al file) as currently done in VS code environment.

yrest commented 5 years ago

This seems to be a somewhat duplicate of https://github.com/Microsoft/AL/issues/1542 and https://github.com/Microsoft/AL/issues/1958 but is still true! To all questions "Where is my F5", the answer is "It's not there"...

Rama-M commented 5 years ago

My point is more than adding feature to intelligence. To have a new visual development environment for AL and to abandon VSCode. It is not a suitable development environment for NAV/Business central. Also please note my request to have a centralised and integratef code storage stored in NAV/Business Central database. So my request is quite different from the one highlighted in previous comment.

pborring commented 5 years ago

Thanks for the feedback. We are not going to abandon VS Code, but we are aware of the visual designer gaps and efficiency impact, and have plans to invest in this in the future.

As to source code availability, extensions can contain source code, allowing customers to download this from their tenant when/if switching partners. This requires ShowMyCode to be true.

Rama-M commented 5 years ago

How about source code management for on premises version of Business Central ?

tfbtrading commented 5 years ago

Having used NetSuite extensively prior to working with Tenant Specific Extension on Business Central, I can tell you all have their drawbacks. NetSuite with it's database driven configuration of fields, custom form variations and workflow designer are far ahead in terms of empowering power users to work with the solution.

Yet where Microsoft is heading is powerful and has potential. Using Visual Studio Code gives them access to a lot of sophistication baked in. Even NetSuite and SAP B1 are both coding down the coding route for power developers and partners. You can see them trying to work from two ends with their personalisation and visual designer.

If they can keep their cadence up they might end up in 2 years being ahead. But you can see a massive engineering effort is required to drag the dinosaur onto the web (whilst trying to make it a beneficial transition from the windows client).

I can see 2019 is the year in which the substantial (user facing) transition is complete. I'd imagine they had better in 2020 start adding significant functional differentials leveraging cloud - from global enterprise search, semantic understanding of relationships to improve navigation.

Personally I'm not a coder and my main criticisms isn't so much with the tooling, but with the lack of concrete examples, documentation and the fact that I need to look into forums and ask questions for even relatively simple patterns. That is where an interactive visual designer helps, but a much better modern pattern database and examples would also go a long way.

Rama-M commented 5 years ago

Having a WYSIWYG designer for objects such as Pages, Report, XML Port, Table with the ability to manipulate its property using the GUI interface will significantly (by 3 folds) changing/designing in AL language (using Visual Code editor) compared to CSIDE Development Environment. Going from CSIDE Development to Visual Code editor environment without similar GUI interface is a huge step backwards and will affect the industry as a whole in big way.

With the industry (with NAV) for the last 22 years, I can tell, Microsoft need to recognise one of the secret behind NAV's success is the ease in which you can alter/customise things to fine adjust any solution to suite customer's requirement. One critical in this is the property driven GUI driven development. When you have finished with the design work on can export the changes as txt. Now we almost have to interact and manipulate the txt representation of the change which is rather inefficient and prone for many syntax errors. What we are proposing is to have the same the current development environment and have a feature as to save as .AL file. That is what we really want.

tfbtrading commented 5 years ago

There are a lot of drawbacks in their own way and you hit many limitations pretty quickly. I’d say Microsoft has the largest scale engineering team in terms of trying to get productivity from the environment. The fact that they are using the same environment as customers and partners seems to be driving some fairly rapid innovation, but also huge demand for improvement – for example support for interfaces, intelligent dependency management.

My assessment remains the same. Essentially everyone prior to 2020 is an early adopter of Business Central. They won’t really have all the tooling in place to satisfy existing customers and a level of robustness until then. 2018 was a start. 2019 is to get across high priority items and I’d hope 2020 is to consolidate and start to deliver solid and tangible benefits from the new environment.

If you want what you’ve got with no downside and only upside then wait. If you want to get onboard early, so you are an expert by the time it get’s finished then start learning.

From: Rama-M notifications@github.com Sent: Tuesday, 26 February 2019 6:05 AM To: Microsoft/AL AL@noreply.github.com Cc: Russell Kallman russell@tfbtrading.com.au; Comment comment@noreply.github.com Subject: Re: [Microsoft/AL] Need GUI driven development environment for AL code development (#4592)

Having a WYSIWYG designer for objects such as Pages, Report, XML Port, Table with the ability to manipulate its property using the GUI interface will significantly (by 3 folds) changing/designing in AL language (using Visual Code editor) compared to CSIDE Development Environment. Going from CSIDE Development to Visual Code editor environment without similar GUI interface is a huge step backwards and will affect the industry as a whole in big way.

With the industry (with NAV) for the last 22 years, I can tell, Microsoft need to recognise one of the secret behind NAV's success is the ease in which you can alter/customise things to fine adjust any solution to suite customer's requirement. One critical in this is the property driven GUI driven development. When you have finished with the design work on can export the changes as txt. Now we almost have to interact and manipulate the txt representation of the change which is rather inefficient and prone for many syntax errors. What we are proposing is to have the same the current development environment and have a feature as to save as .AL file. That is what we really want.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/AL/issues/4592#issuecomment-467138577, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AooDXvc_cBRL0GCSyRQqN9J6NwhM5sYWks5vRDPjgaJpZM4a0M7l.

erikrijn commented 5 years ago

No true developer would prefer a visual designer over a clean light-weight editor like VScode. There's a reason why VScode is one of the most popular editors out there. Saying file based coding doesn't work and that code belongs is the application database is a laughable remark.

yrest commented 5 years ago

@erikrijn your statement reads to me as following (because there are reasons for all sorts of things). "No true driver would ever sit on a bicycle or in electric vehicle". I agree with your last sentence though and everybody should embrace file based programming.

erikrijn commented 5 years ago

@yrest would you take a web dev serious if he/she uses a visual designer?

yrest commented 5 years ago

@erikrijn I would take seriously anyone who's professional and proficient in the tools they use and prefer. It's not only about development, part of work we all do with this product is design - of pages, reports, etc.

Rama-M commented 5 years ago

We all should appreciate each other’s views, not to take this too personal. I have done programming since high school, university and something I do for living at the moment. During these 35 years I have done coding in a range of programming language such as Assembly Language to C++ to C# to Visual Basic to C/SIDE to TSQL.... My comments about the lacking visual designer for AL was actually came after losing some of my hair trying to convert our vertical to be an extension using AL code.

I like to bring to the attention of @erikrijn that in NAV C/SIDE there are very high level objects (such as Table,Query,Page,Menu,Report,XML Port). You can achieve a lot simply manipulating the properties and the code element is only there as a "glue logic" and for many instance it is a very minority part when it comes to any customisation. This is true for 90% of the practical work we do in a day by day basis (ie we do not touch / modify the code in many instance). In fact you spend 60% of your time planning / Considering/Impact access your change and you only spend 30% actually coding. Further many of the NAV consultants up there are not developers and they do changes like changes to Pages, XML Port, Adding table field (without validation code) and they do not anywhere near writing code. Any such coding work is left for developers such an myself. Any seasoned NAV developer would back the above practice.

Now in AL code even to add a field to an existing page would require a fair amount of coding knowledge. It would be almost impossible to train all these people to be a hardcore developers only to add a field to a page. Which is currently achieved by simply achieved by dragging and dropping the field. Currently coding in AL language reminds me writing something like 100 line of code to add two line of code to add two decimal numbers in assembly language. End of the day everything runs in computer in binary and one could argue it is the most light wait most efficient coding language. I also have to agree with @erikrijn view on this. But why we are not using it ? the answer is to boost productivity and hence other high level languages are invented to boost productivity.

To summarise C/SIDE is a high-level language compared to AL in current form (without a similar visual designer). Going from a high level language (C/SIDE) to AL is like going from C# to Assembly language where you manipulate the register address and it's value in hex !!.

In my opinion we all are sleep walking towards a major disaster to the NAV industry (to make the implementation and customisation much much expensive and hard to make change, etc...) By replacing C/SIDE by AL without a visual designer, which is only a good fit to only replace the Codeunit Object but not the rest of the objects such as (Table,Query,Report,XML Port, Page, Menu).

This is the over whelming opinion of the NAV community and the industry and having a visual designer will go a long way to mitigate this issue. Microsoft need to appreciate this fact.

tfbtrading commented 5 years ago

Rama-M has some very good perspectives. Again, coming from outside the legacy dinosaur ecosystem, I can take a step back.

Business Central in its current form (along with all the design tooling) is not ready to be out there. It just isn’t. I congratulate Microsoft are being very ‘lean’ thinking in getting a product to market and iterating. Anyone adopting it is by definition an early adopter. You need to put up with all sorts of constraints and limitations. The fact is, I doubt they can credibly go head-to-head with other solutions until 2019 October Release.

My bigger issue is them not resolving underlying usability issues in terms of task flow and simplicity. I see at the moment a company obsessed with reinventing a technology solution on the web, but in the process not solving fundamental business process problems. Where are the intelligent menus that understand your context and workflow state, where is the global search for information that helps you resolve business queries fast?

Microsoft really has until 2020 to be actually breaking new ground and innovating with Business Central – not simply slightly improving on features that had already existed in a Windows client. Otherwise Acumatica, Sage, NetSuite and yes (even tired old SAP B1) will catch up or exceed them with their web interfaces. In 2019, even little old open source Odoo is far more advanced and fully featured with their Studio offering.

That said, for the price – it is rather impressive. Even a relatively modest person like myself has been able to extend and add fields and achieve complex functionality that was extremely difficult and cumbersome in NetSuite. The ideas place seems fairly responsive and there are promising extensions appearing in AppSource.

I don’t think Microsoft is sleep walking – but I think they are going way too slow given the competition.

From: Rama-M notifications@github.com Sent: Saturday, 9 March 2019 6:02 AM To: Microsoft/AL AL@noreply.github.com Cc: Russell Kallman russell@tfbtrading.com.au; Comment comment@noreply.github.com Subject: Re: [Microsoft/AL] Need GUI driven development environment for AL code development (#4592)

We all should appreciate each other’s views, not to take this too personal. I have done programming since high school, university and something I do for living at the moment. During these 35 years I have done coding in a range of programming language such as Assembly Language to C++ to C# to Visual Basic to C/SIDE to TSQL.... My comments about the lacking visual designer for AL was actually came after losing some of my hair trying to convert our vertical to be an extension using AL code.

I like to bring to the attention of @erikrijnhttps://github.com/erikrijn that in NAV C/SIDE there are very high level objects (such as Table,Query,Page,Menu,Report,XML Port). You can achieve a lot simply manipulating the properties and the code element is only there as a "glue logic" and for many instance it is a very minority part when it comes to any customisation. This is true for 90% of the practical work we do in a day by day basis (ie we do not touch / modify the code in many instance). In fact you spend 60% of your time planning / Considering/Impact access your change and you only spend 30% actually coding. Further many of the NAV consultants up there are not developers and they do changes like changes to Pages, XML Port, Adding table field (without validation code) and they do not anywhere near writing code. Any such coding work is left for developers such an myself. Any seasoned NAV developer would back the above practice.

Now in AL code even to add a field to an existing page would require a fair amount of coding knowledge. It would be almost impossible to train all these people to be a hardcore developers only to add a field to a page. Which is currently achieved by simply achieved by dragging and dropping the field. Currently coding in AL language reminds me writing something like 100 line of code to add two line of code to add two decimal numbers in assembly language. End of the day everything runs in computer in binary and one could argue it is the most light wait most efficient coding language. I also have to agree with @erikrijnhttps://github.com/erikrijn view on this. But why we are not using it ? the answer is to boost productivity and hence other high level languages are invented to boost productivity.

To summarise C/SIDE is a high-level language compared to AL in current form (without a similar visual designer). Going from a high level language (C/SIDE) to AL is like going from C# to Assembly language where you manipulate the register address and it's value in hex !!.

In my opinion we all are sleep walking towards a major disaster to the NAV industry (to make the implementation and customisation much much expensive and hard to make change, etc...) By replacing C/SIDE by AL without a visual designer, which is only a good fit to only replace the Codeunit Object but not the rest of the objects such as (Table,Query,Report,XML Port, Page, Menu).

This is the over whelming opinion of the NAV community and the industry and having a visual designer will go a long way to mitigate this issue. Microsoft need to appreciate this fact.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/AL/issues/4592#issuecomment-471038997, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AooDXgk0CvDSLvrOOKybQfN0eWs4xXg2ks5vUrOtgaJpZM4a0M7l.

thpeder commented 9 months ago

Hi, Please go ahead and post this to our Ideas forum at https://aka.ms/BusinessCentralideas, or vote up the idea if its already there. We're constantly monitoring top Ideas and will consider them for a future release. If you wish to continue the discussion, please do so on Yammer.