So I have 10.2.600 installed on a VM to check out the new bits. I can see the customisations for the Kinetic screens is possible however I can’t see a code editor for the screens. I am assuming they are still working on that but just wanted to check if it is hidden somewhere…Wouldn’t be the first time I havn’t seen something right in front of me 
Brett
No code editor
In our upgrade release calls they said the app studio for kinetic editor ability is coming in 10.2.600.3. We are currently on 10.2.600.2
OP indicated they can see the Kinetic customization but no Code Editor. As @josecgomez indicated there is no code editor available.
I have 10.2.600.3 installed and you can indeed customise the kinetic screens. I guess that is with the “App Studio”. I haven’t looked at it depth but on the face of it it looks easier to do the simpler customisations like add a new textbox, button, tab etc. That should lower the barrier to let people customise Epicor which is a good thing.
If you are after the more complex customisation that require code, I guess we have to wait for a future release. I expect allowing code customisations is not an easy thing to build into Epicor so it will take time.
Cheers
Brett
Epicor spent a lot of time during the move to Vantage 8 and the ICE Toolset separating out the UI from the Business logic. It’s a solid architectural practice. I try to prevent business logic from leaking into the UI since that code will need to be duplicated on every screen, every DMT, and every REST interaction.
But maybe more importantly, from an IT strategy standpoint, if Epicor’s product line is moving toward a web-based UI (which is great from a client management and hopefully a performance standpoint) then how much effort should we be putting into complex screen customizations today? Doing so slows my ability to upgrade easily and the effort might have to be done again in the not-too-distant future.
I wonder if we can build our own business logic within Epicor functions and access those from the kinetic screens??
Brett
I know that calling eFx from customizations is/was on the list but don’t know where it is right now. Maybe others know…
What I can also see is users developing an API and then using whatever UI framework they like and then call into Epicor from there. I can see clients in the JS frameworks (React, React-Native, Angular (used by Kinetic), Vue, Sveldt, …), Blazor WebAssembly, SharePoint Framework, or even using things like Jupyter notebooks which combine code and documentation. Epicor Functions is a game changer IMHO.
I think the Code Editor is ways out, and I think the App Studio should be coming sometime in 600.
It’s in current 600.3 I was playing with it in production yesterday a bit.
Does that mean we can add fields, just no code customizations? I feel like we are kids in a candy store. looks at all the good stuff, just cannot touch. lol
There is no client side code editor in 10.2.600 in App Studio. However there are Rules (like Row Rules) and Events that let you do things that previously required code. All Row Rules in the smart client wrote code now its no code and declarative and that is how all Kinetic apps work, you can do more types of rules across data views without code.
Likewise Events can be used for (IFTTT) “If this then that” type of logic, when a field changes, or something happens perform a search or ask a question or call a BO or a server side Epicor Function.
So you can keep the UI as presentation logic and keep business logic on the server.
I will not commit on when, but we do have planned client side function support that would give you more control for edge cases.
It is - we provided a convenience classes for calling functions from customizations so people could begin to refactor business logic to where it should live on the server and allow you to test in more manageable units. Then you can easily hook into this from app studio when ready.
Just my 2 cents, but I hope you realize no code editor (in one form or another) means no migration to Kinetic until there is one for 90% of our customers with UI customizations, not just “edge cases”… Kinetics in its current form is fine to add the random UD fields to a screen, but even in a web page, most code runs on client side, not on the server. You don’t want to call the server for every field validation, and you don’t necessarily want to wait for an update to validate the entire screen either.
Just put yourself in the shoes of a new Epicor customer who paid hundreds of thousands of dollars in the last 2-3 years to implement their very specific tailor made processes in Epicor. Kinetics comes along, and now they have to redo it all again. It gives them a nice opportunity to evaluate the competition, since either way they have to start over from scratch.
I don’t expect plug and play functionality with old code, but I DO expect 1:1 equivalent functionality before I can contemplate migrating any customer with any customization slightly more involved than adding a few fields. The customer having to adapt to a new UI is one thing, but having to adapt to new processes because we can no longer reproduce the old ones is quite another…
I don’t see the big difficulty either way, C# is defined as an ECMA script, and can be integrated directly in a web page… And even if it has to be JS, that’s fine too. The biggest difficulty is just the code framework around it.
I think looking at open source www.aras.com they figured out alot of it for the most part. You can do Client Side JavaScript, HTML etc… Server Side C#. You create drop down types, field events, row events, etc… You can even debug the C# in browser and also Connect your code to VS… Their UI is a bit clunky but I think alot can be learned from their way of doing things (prob better ways now, but still it plants a seed).
Not Blazor?
Not yet I think they have some catching up to do still using popups instead of modals etc…
I think alot of lessons can be taken from then, they have been doing this since like IE 5 lol.
Another way to deal with all of this would be to allow us to define client side code through Epicor Functions. Just compile all the client functions into one DLL, transmit the DLL from the server to the client cache when Epicor opens up, and reference it so it is accessible from everywhere client code is. This way we could actually start migrating while still maintaining a modicum of control on the server calls.
