Microsoft Dynamics GP "12" Web Client Architecture - Part 3
This is article 3 of 3 from the series Microsoft Dynamics GP "12" Web Client Architecture. Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation.
In Part 2 we explored the Microsoft Dynamics GP "12" Web Client's Rendering Engine and how it had to be decoupled from the overall Dexterity Runtime Engine functions, in order to create a Generic Window Object that could be rendered as a Windows Form or a Silverlight interface.
Today this article discusses how a Generic Window Object is transformed into a Windows form or a Silverlight UI, but before, let's remember that the Window Manager, a former part of the Dexterity Runtime Engine, is still in charge of processing the UI events while the Rendering Engine presents the interface to the end-user.
Now that the Dexterity Runtime Engine has been freed of these tasks, the resulting Generic Window Object must be processed to produce either interfaces. For this, the Development team has created Template Processor.
Template Processor takes a generic representation of a window and is able to deliver an XML version of its content (fields, buttons, and events in the case of a traditional Dexterity window), called a Window Template, but as well delivers a version that the Dexterity Runtime Engine can still display in the classical client, also known as coreTemplate. The technique of processing a Generic Window Object into an XML Window Tempalte and a coreTemplate has been labeled Dynamics Form Rendering.
The XML Window Template is then delivered to Silverlight via a browser application - explicitly Internet Explorer given the use of Silverlight - where the Rendering Engine uses a Converter to serialize into a Silverlight UI. Since the Dexterity Runtime Engine retains the ability to understand the coreTemplate elements, displaying a Windows form is still a natural function.
The result will still allow developers to create traditional Dexterity customizations against the classic client UI or the XML Window Template generated by the Template Processor.
On a closing note, GP "12" aims to provide additional deployment methods to the traditional classical client deployment, where the client is either delivered as an installation at desktop level or in a Terminal Server or Citrix environment. With the Silverlight client, users can rely on their Internet Explorer browser and the Silverlight plug-in to run their Microsoft Dynamics GP application, while retaining the feature rich functionality of the classical client.
To make things even more interesting, a deployment environment can take advantage of both the classical client and the Silverlight client at the same time. Why would you need both? I suspect certain application functions like maintenance are best executed from the classical client, however in the scheme of things, it allows for a smooth end-user transition.
Finally, I hope you enjoyed this series of articles and I will continue to work with the Microsoft Dynamics GP Product Management team to deliver information to you as it becomes available (and needless to say, not deemed a trade secret). There is more to all this than meet the eyes.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
In Part 2 we explored the Microsoft Dynamics GP "12" Web Client's Rendering Engine and how it had to be decoupled from the overall Dexterity Runtime Engine functions, in order to create a Generic Window Object that could be rendered as a Windows Form or a Silverlight interface.
Today this article discusses how a Generic Window Object is transformed into a Windows form or a Silverlight UI, but before, let's remember that the Window Manager, a former part of the Dexterity Runtime Engine, is still in charge of processing the UI events while the Rendering Engine presents the interface to the end-user.
 |
| Dynamic Form Rendering with Template Processor |
Now that the Dexterity Runtime Engine has been freed of these tasks, the resulting Generic Window Object must be processed to produce either interfaces. For this, the Development team has created Template Processor.
Template Processor takes a generic representation of a window and is able to deliver an XML version of its content (fields, buttons, and events in the case of a traditional Dexterity window), called a Window Template, but as well delivers a version that the Dexterity Runtime Engine can still display in the classical client, also known as coreTemplate. The technique of processing a Generic Window Object into an XML Window Tempalte and a coreTemplate has been labeled Dynamics Form Rendering.
The XML Window Template is then delivered to Silverlight via a browser application - explicitly Internet Explorer given the use of Silverlight - where the Rendering Engine uses a Converter to serialize into a Silverlight UI. Since the Dexterity Runtime Engine retains the ability to understand the coreTemplate elements, displaying a Windows form is still a natural function.
 |
| Dynamic Form Rendering - Developer's Experience |
The result will still allow developers to create traditional Dexterity customizations against the classic client UI or the XML Window Template generated by the Template Processor.
On a closing note, GP "12" aims to provide additional deployment methods to the traditional classical client deployment, where the client is either delivered as an installation at desktop level or in a Terminal Server or Citrix environment. With the Silverlight client, users can rely on their Internet Explorer browser and the Silverlight plug-in to run their Microsoft Dynamics GP application, while retaining the feature rich functionality of the classical client.
To make things even more interesting, a deployment environment can take advantage of both the classical client and the Silverlight client at the same time. Why would you need both? I suspect certain application functions like maintenance are best executed from the classical client, however in the scheme of things, it allows for a smooth end-user transition.
Finally, I hope you enjoyed this series of articles and I will continue to work with the Microsoft Dynamics GP Product Management team to deliver information to you as it becomes available (and needless to say, not deemed a trade secret). There is more to all this than meet the eyes.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Comments