This is what Blazor actually does. 
1 Like
I have faith that in the end Epicor won’t be able to provide us with at least 99% flexibility we have today even if it’s approached a different way. If they don’t I suspect they know there will be a mass exodus (at least in terms of support contract cash flow) not worth the new prospects they are targeting with this shift.
RE: calls for every validation, as it stands most field validations in the WinForm app make server calls with much much larger payloads (OnChangeBinNum, OnChangeJobNum, ChangePartNum, etc) so that wouldn’t really be much of a shift from where we are today, with the exception of more concise and faster data transfers.
From a customizability standpoint EFX could play a significant role in making all our lives easier with regards to not relying on client code.
In the end starting at 2.200 years ago knowing where this was all headed, if you still embedded a ton of logic in the UI, then that was a critical error on the developers part.
I disagree. Server code is needed. Client code is also needed. Sure, you CAN do everything in server code, but that doesn’t mean you should. Calling server code has latency. Latency adds up. Let’s say I just need to validate that the input in a textbox is in the correct predefined format. Are you telling me I should call server code to evaluate a regular expression?
Of course not but that’s what the different control types are for all containing formatting properties familiar to TypeScript exposed by AppStudio. If you have a really funky format that you need to validate that 5% of the time then I don’t think it would be unreasonable to hit the server for that edge case.
Carl? Where are you?
But who decides what is “funky”? Why wouldn’t you let the developer do whatever he needs to within the confines of what is allowed?
I mean they aren’t they? You just don’t like what may or may not be allowed lol!
In the end we still don’t know what this will materialize into and I don’t think it’s super clear to Epicor how this will all pan out but rest assured at the end of the day scarcity will breed creativity, and just like today where there is A TON of stuff we can’t do out of the box we have figured out how to get it done another way, using UBAQs pre EFX, reflection, custom built libraries, etc, always ways to skin the cat.
Until this whole thing has been fully realized I’m going to continue to provide input as a preview customer, but am certainly not going to worry about its final form yet.
The point I was trying to make is that there is no way for Epicor to anticipate what all of their customers need to do. Having accessible client code makes this issue moot, as even if Epicor didn’t expect I would have to do something, I can still do it anyway. It makes our customers happy and they keep paying us as a result.
1 Like
I think Stephen’s point (and mine) is that Business logic/code belongs on the server and UI logic can exist on the client. If one has a monolithic client like WinForms then one might get away with letting that logic slip into the UI. But once you have to support a web-browser, mobile devices, and other clients that don’t understand WinForms, then the architecture is limiting.
1 Like
I just don’t see what is limiting or different in the end. You go from WinForms and C# to Kinetics and JS. That’s the thick of it really… What difference does it make on the architecture? It’s still a 3-tier architecture.
When it comes to something like Node, TypeScript and Angular the lines between what is considered the server and the client become a little more blurred and the development model shifts quite a bit from what we are traditionally used to. When supporting cross-platform devices the architecture makes all the difference.
It took me quite a bit to wrap my head around how to refactor my Angular mobile apps, but after a bit it started to make more sense to me. There is nothing to say that Epicor couldn’t allow EFX like functions shipped as part of the client min and you can use those in AppStudio.
I would recommend just for kicks build yourself a mobile app that uses Epicor REST as your endpoint. We basically rebuilt MES in a mobile app for our maintenance guys to use on tablets and I have to tell you it’s pretty glorious. And aside from displaying stuff on the screen, it doesn’t have a ton of logic in it that falls outside what TypeScript natively handles for rules and events. We specifically set out to build it using Kendo (Kinetics base) to get a feel for what we might be in for. Just build something small and it might become clearer how the approach will be different but you can still yield the results you desire.
2 Likes
Where does the client code run in a REST call? DMT? Service Connect? JitterBit? Having it at the server does not limit one to any imaginable client now and into the future.
I use the REST endpoints plenty, as well as the SOAP endpoints, when I need to call server code from outside Epicor. That’s not really the issue, the app you wrote still has client code, that you wrote. The issue is being able to write that client code in Epicor screens to begin with.
But anyway this is beating a dead horse at this point, we’ll just have to wait and see what ships. Pretty clear to me that currently Kinetics is unusable for existing customers with elaborate customizations though… Most of them would need to rethink their entire processes, and train all employees to use them.
Epicor never claimed it to be otherwise yet, but you are correct it’s a waste of time and energy to worry about it yet. Start using it where you can, provide feedback, I promise you they are listening.
I think from what we have seen and we have tested you can probably do 75-85% of what you could do before. The only element that is “missing” is client logic (outside of row rules and events)
I can’t think of a specific example of what you can’t do, though I’m sure it exists. File manipulation comes to mind though with eFX and a little lube maybe that can happen too.
I agree that a lot of current customers won’t have a direct upgrade path right now those heavily customized will have to do a lot of heavy lifting.
But i say let’s get into it and see how far we can get, then we ask for changes. Epicor is always lurking and listening.
5 Likes
In the context of a JS based application? Again the development model changes even from a normal website.
You are correct it’s just client code that does nothing but display data from REST. The argument you were making (a valid one) is for rules and validations. I think that may be where ignorance of the JS based app development tools (rules, events, properties) might be hanging you up a bit. If you have access to it explore the properties of a field in AppStudio. What we have available in the properties window today pales in comparison.
The only time I work with JS is in the context of a web application, so sure, I don’t know the tooling… But I still know how to write jQuery, JS scripts, bind to events, validate data, etc… It’s a different language but it’s the same thing in the end.
It really isn’t because those are not entire Frameworks. You have to do a lot manually in those, so I could see how it would become very cloudy. Think of JS as .NET and Angular/TypeScript/Kendo/Kinetic as the ICE tools. Can you do it all in .NET sure… but it would be brutal.
Why would you though? The point is not to rewrite the entire screen, it’s to be able to define client code snippets or functions I can then hook into from within the UI, through the binding of control events. Without having to call server code. Glue logic and the like. That doesn’t belong in server code.
Little late to the party but is there something that explains the technical implementation we can expect for currently customized forms and how those will be effected by new kinetic forms? I’m still not entirely sure what that means. I would imagine there has to be a way to re use, for example my heavily customized sales order entry form, In a way that That doesn’t require another few hundred hours of development and QA to regain functionality?
Not to mention the SOPs and work instructions reliant on the existing form flows. All for onward and upwards but I guess I’m left a little confused as to the direction we are being taken with all this. A little clarification would go a long way, maybe I’m in the minority
Also a little confused as the technology shift. I will be in a rough situation as the sole developer if we are switching technology used for client Side customization so any documentation on this roadmap from a technical perspective would be awesome
1 Like