Developed the decision service in classic rule engine and at the end when i change the rule engine from Classic rule engine from Decision engine then all the Virtual Methods IRL has been removed and getters, setters also not available in the BOM project. Yes i'm aware Decision engine uses ARL and Classic Rule engine IRL.
How can i change to Decision Rule engine without loss of Virtual Methods, Getters and Setters?
Currently using IBM ODM 8.7.1.2 version
Your IRL should be translated to ARL when you first set the execution to be with the Decision Engine. This is explained here:
https://www.ibm.com/support/knowledgecenter/en/SSQP76_8.9.1/com.ibm.odm.dserver.rules.designer.run/executing_decision_topics/con_decision_engine.html
It is possible for some IRL code to not be translated as is noted in the article. If this happens, you end up with an empty function body. You must hand code these translations.
Related
Good day, I've been using ServiceStack for many years, I currently designing and planning a rewrite of an ASP MVC (Razor) project. #Script seems to be an almost perfect fit, without hands-on experience of the technology I have some doubts and questions.
My question is how relevant is #Script today and what is the future plans of this technology. I ask these questions because when I looked at GitHub example I noticed that there is not a lot of activity, and searching the internet I am also not finding a community around it.
As #Script's author I would say that #Script is a complete library for what it's designed for as an embeddable sandboxed .NET scripting and templating language that's ideal for exploratory programming with seamless integration into .NET APIs (including Win32 APIs) that includes a vast built-in library (1000+) of filters that's easily and highly extensible to the point that it's even able to natively support multiple languages (inc. built-in LISP Repl) within the same page that's been a joy to develop with thanks to its built-in Hot Reloading support where changes are instantly visible upon save - so technology-wise IMO it's pretty great.
If we were to compare it to comparable libraries in other languages like the Ruby's Liquid it should be pretty clear that #Script is vastly more capable where it scales from a user-friendly templating language to a powerful scripting language where it's capable of developing entire Windows Desktop Apps that fits in a Gist.
On the activity front, Liquid is also an established library with low activity with only a handful of commits in 2021, the difference is that it's vastly more popular and used in popular products like Jekyll as used in GitHub Pages which ensures it will always have a rich, vibrant ecosystem which is the most important indicator for assessing a technology's longevity.
Technology not as important as ecosystem
However in the end the technology doesn't matter nearly as much as its user base, community and ecosystem behind it which is where #Script is sorely lacking. Unfortunately this is the reality of libraries that compete Microsoft's defaults like Razor which are exclusively promoted for .NET and will always retain the majority of adoption in .NET.
#Script is a "complete" library in that I've added all the features I planned for it and there's basically nothing I can think of to add to it to make it more appealing, but facing the realization of its indefinite lack of adoption I wouldn't recommend using it for large living (i.e. multi-year) Websites, given it will never have the community and adoption enjoyed by other ecosystems since the benefits of a community and ecosystem are ultimately the most important attributes in order to continue investing in a technology.
Continue to be actively supported
Like all of ServiceStack, #Script is still an actively supported library with no outstanding issues so it's safe to use in that any issues will be promptly resolved should you wish to.
Website Development Recommendations
I'd say it's still a fine option for smaller definitively-scoped projects since its compile-time-free and Hot-Reload makes for a very productive Dev UX for server-generated dynamic pages. However even then I'd first evaluate if a static generated framework like Jekyll, Hugo or other popular static generators would be more appropriate since they enjoy a vibrant community and a statically generated site results in a more performant, resilient and cheaper to host and deploy website.
Static Site Generators
Having recently redeveloped the servicestack.net website to split it out into using Jekyll for static content and ServiceStack.Razor for dynamic content, my recommendation for large websites with large static and dynamic components is to use a static site generator for its static content which yields several benefits:
Although it does require a fair bit of overhead to setup as you're effectively maintaining 2 different websites however it greatly benefits if the static content is actively updated as there's a lot less friction to change and update content on a static generated site then a dynamic one and it results in a superior end user UX thanks to CDN Edge caches that's also cheaper to host from free sites like GitHub Pages and Netlify.
In order to preserve existing URLs we needed extra functionality not possible from a static host so our static content is deployed to a S3 bucket where we use CloudFront for CDN edge caching, CF Behaviors for proxying "external static" routes to our .NET5 dynamic website and a CF Function for supporting pretty URLs. For internally deployed websites you'll be able to accomplish similar functionality with reverse proxy and redirect rules.
SPA or Razor
For small websites or mostly dynamic websites that wont benefit from a content site split I'd recommend either an SPA Project Template if you prefer TypeScript and an established SPA FX like Vue, React, Svelte or Angular or Razor or MVC if you instead prefer C# server generated websites.
Progressive Enhancement
My personal preference is for read-heavy dynamic sites to use ServiceStack Razor utilizing API First Development approach so that all writes are made to the same clean ServiceStack APIs that Mobile and Desktop Apps would also call. This typically involves using some kind of progressive enhancement like our Client TypeScript Validation example which utilizes the Form & Validation Binding in #servicestack/client to take over <form> submissions to perform TypeScript API calls and apply any validation errors back to the Form's UI.
The Client jQuery example accomplishes the same thing without the tsc -w watched build step whose form & validation binding utilizes the older jQuery ss-utils.js library but it does mean you'd need to author logic in an older broadly ECMAScript 5 supported version of JS.
Future of #Script
As I don't expect #Script Pages will ever achieve any meaningful adoption required for self-sustained active development, it's unlikely we'll continue in investing in further development for usage in dynamic websites (i.e. the script project template), it's a complete and extensible library so further development isn't strictly necessary as it can be easily extended with your own local Plugins, Methods, Transformers and Blocks. But it does mean we're unlikely to be creating and including new methods/plugins designed for dynamic websites in the library OOB.
Still a critical ServiceStack component
#Script is still a critical component of ServiceStack where it's used to provide integrated SPA templates since it's able to render dynamic websites from static *.html pages in npm dev hot-reload servers which can't use Razor's *.cshtml pages. It's also what makes ServiceStack's Declarative Validation possible where validation rules can be defined on dependency-free DTOs as it allows defining binary-decoupled logic in dep-free attributes. It's also what makes vuedesktop.com Desktop Apps like ServiceStack Studio possible as well as command tools like Post Command - HTTP API Command Line Utils and cross-platform dotnet scripts which makes usage of its internal functionality, so it's going to continue on as a actively developed & supported library.
Good future use-cases of #Script
However I'd limit any #Script usage to where it excels, e.g. as an embeddable scripting .NET sandbox given it's more versatile & flexible than Razor for tasks like Rendering Emails, authoring & rendering Live Documents (e.g. if needing to maintain live user-generated reports in an RDBMS) or as an embeddable Template, JS or LISP DSL or for evaluating adhoc JS/LISP Expressions or .NET logic.
Future replacement project templates
For developing server-generated websites with ServiceStack we're looking at shipping a couple of new templates which encompasses our latest recommendations (e.g. embracing an API First Development style), if they result in a great Dev UX we're looking at:
An Integrated Static generated (e.g. Hugo/Jekyll) + Dynamic Project template
An API First MVC Pages + ServiceStack template with integrated progressive enhancement
Please follow #ServiceStack to get notified as soon as they become available.
I'm looking towards using viewflow to design a workflow app for my company. I would like to know about performance constraints of using the non-pro version of viewflow. Besides this I'd like know if using the unpayed version I can change the default front-end that comes with viewflow and if so in which direction should I start looking to do so.
mm, there is no pro/non pro performance specific constraints in the viewflow. Viewflow PRO adds additional functionality to the open source version.
Fo the customization options you could check the viewflow cookbook - https://github.com/viewflow/cookbook (custom views and custom UI samples)
It's described as a non-required field, but it's an enum (without any other listed options) and the description is vague: Used by the Application Insights system to determine what kind of flow this component was created by. This is to be set to 'Bluefield' when creating/updating a component via the REST API. - Bluefield.
My rule of thumb is don't include anything extra (KISS) that doesn't break my application, but if there's some benefit I can get out of it, I'd like to know. Thanks!
Reference: https://learn.microsoft.com/en-us/azure/templates/Microsoft.insights/components?toc=%2Fen-us%2Fazure%2Fazure-resource-manager%2Ftoc.json&bc=%2Fen-us%2Fazure%2Fbread%2Ftoc.json
Flow_Type and Request_Source Do not have any effect in the current version, and they might be deprecated in future versions of App Insights API
I need to override UserFinderImpl to execute custom sql queries. I developed this project using dynamic query. But I need to make it via custom sql.So please tell me how to do that? Thanx in advance..
UserFinderImpl is considered internal class and it's not meant to be extended / overridden / replaced. Before Liferay 7, doing such thing was only discouraged and considered bad practice. Due to monolith approach and EXT plugins, it was not possible to enforce such isolation.
The modular architecture or Liferay 7 (based on OSGi) allowed to encapsulate and isolate internal classes and only allow extensions via well defined public APIs. There is no extension point in Liferay 7 that allows you to override / modify UserFinderImpl. If you absolutely need to do that you would have to compile from source with your modifications in place (which is basically what EXT plugins were doing in a bit more sophisticated way before Liferay 7).
I'm beginning in semantic web. I want to develop a semantic web recommend-er system. The most important part of my project is moddeling. How can I start it? How long does it take? What soft-wares or tools can I use to develop that?
You can use Protege Ontology Editor to create your data models and create semantic rules with SWRL. Also you need a semantic rule engine too.