Sunset Application Architect

[#1]

Having worked with both the pre-v7 web administrator and the Application Architect (AA), it is my understanding that AA was supposed to allow administrators, who are not necessarily coders, to customize the web client. To this end, AA is supposed to simplify the process by providing a visual IDE de-emphasizing code and library management. Anyone who has worked with AA knows that code and library management are significantly obscured in the interface. However, this strategy totally misses the objective of simplifying the process, due to the complexity in handling the build and deployment of the web app itself. The huge range of potential errors, and the inherent difficulty in troubleshooting them, puts the level of required technical ability well out of the reach of non-developers for all but the most basic of customizations (and sometimes not even those). On the other hand, AA is a poor IDE for experienced developers due to the aforementioned “dumbing-down” treatment it received. Some shortcomings include: no dedicated library management system; no source control; out-of-box functionality is obscured (although accessible using external tools); weak logging, tracing and debugging; weak IIS integration and deployment management; fussy compile-time error handling; application-level options are obscured; no build options (debug/release); painful upgrades due to inability to diff/merge customizations; and overall (rampant) instability, sometimes resulting in file integrity issues and broken builds. In summary, AA would need major improvements, one way or the other, to be successful in either role. In the “non-developer” role, some customizations can already be managed through the v8 web client Form Manager, presumably to be rolled into the Infor platform/framework at some point. Currently, the “developer” role remains underserved. My question: wouldn’t it make more sense to manage the web platform as a Visual Studio project, taking advantage of prebuilt library management, debugging and web deployment, and source control tools? Resources committed to further AA development would be freed. Critical AA functionality such as NHibernate entity management could then be parted out to other admin tools or to VS plugins. Resources committed to AA documentation could be applied to API and SDK development. At the very least, a roadmap for ISVs and developer partners could drum up some goodwill.

[#2]

It is not going to happen..

[#3]

Could you elaborate on that RJ? If there would be any time to do it, it would be now. Let developers use the tools they want to use.

[#4]

There has been no announcement, but I suspect that SLX/Infor CRM will move toward using Infor's Mongoose framework.  http://bit.ly/1utBTuA

[#5]

I would favor the Infor "Mongouse" approach and abandon the Visual Studio C# world completely. Development/customization of the "web client" needs to be brought to the level of Business Analysts and not back-room-c#-developers. 

The "new web" framework was such a signifocant departure teh vast majority of Saleslogix (installed base) customers completely avoided it for many years. A lot of those who did switch in teh early releases (v7.2.x) quickly dropped teh web and went back to teh Windows/LAN client and its very easily customization environment..

Nope - I will never support going full bore to Viausl Studio c# .NET - and I believe Infor will make (over time) significant changes to bring it (Saleslogix) into their framework/platform.

[#6]

My biggest gripe is having to work with 3 different types of codebases when working with SalesLogix.

LAN development, Web development and SalesLogix Mobile development are all vastly different from each other. I know it'll never happen but I'd love to be able to work in just one codebase and in one platform.

It's one of the things ACT! does really well. Customise the LAN client and it's immeidately changed in the web. It's useless comparing these two products now though because these two siblings have been placed in different homes.