What is the scope and effect of the 'Render Hints' in the Ontology Management Application?
Do these only apply to aggregations and other widgets built in Object Explorer views or do they affect other object-based frontend apps like Workshop and Quiver, too?
Specifically for the 'Selectable' and 'Sortable' hints, what does turning these on/off actually do? I saw somewhere that turning on these flags creates additional Elastic Search fields in Phonograph but still do not quite follow how that makes them a requirement for some frontend charts and widgets.
Related
This a somewhat random question, but I wanted to figure out what would be the best tools to create a web app which uses node based connections similar to that of Blender's Shader nodes and Unreal Engines Blueprint system. I am new to web development and didn't know what tools to use to create such an UI system. Any help would be appreciated.
I was wondering about the same thing today and seeing the most relevant SO question being unanswered was a little discouraging.
Anyways, I took a little dive into the subject myself and came up with plenty of options. Hopefully, this list provides a good starting point.
Note: While the boundaries of "web app" are pretty extensive, I mainly focused on Javascript libraries.
React Flow
https://reactflow.dev/
Highly customizable library for building an interactive node-based UI, workflow editor, flow chart or static diagram
Rete.js
https://rete.js.org
Rete.js is a modular framework for visual programming. Rete allows you to create node-based editor directly in the browser. You can define nodes and workers that allow users to create instructions for processing data in your editor without a single line of code.
Baklava.js
https://github.com/newcat/baklavajs
Graph / node editor in the browser using VueJS, less than 60kb gzipped
Flume
https://flume.dev/
A React-powered node editor and runtime engine
CodeWire
https://github.com/ayushk7/CodeWire
CodeWire is a node based editor inspired by UE4 Blueprints which helps in better visualization of the code, and faster scripting of complex and repetitive tasks. It doesn't bind to any particular language. Multiple target languages can be added to added in the future.
Wire
https://github.com/emilwidlund/wire
Wire is a monorepo containing a set of libraries (artifacts) that makes it super easy to build blazing fast & reactive visual programming tools for the web. It offers a core data processing framework and a library with React-components that will get you started. Take a look at the underlying artifacts to learn more about Wire and its offerings.
SonarSource has said that they would be dropping support for Ruby on Rails. So assuming that we would need to use Web APIs from here onwards, what are alternate ways of writing your widgets? Has anyone tried any alternate ways of writing one? And how do you link said widget to the UI?
Short answer:
In upcoming versions of SonarQube, widgets and customizable dashboards will be progressively be removed. You will still be able to use the Web APIs to get all the data you want but you won't be able to contribute changes to the "dashboards" of the product.
Long answer:
SonarQube was initially designed to be able to inject and display any kind of information, mostly thanks to the customizable dashboards and widgets (that are indeed written in Ruby). While this helped getting widespread, the downside is that people started using it as a multi-purpose aggregator and reporting tool. One would add information coming from a bug tracker system, another one would add documentation information about projects, ...etc. The consequence is that soon, the global and project dashboards ended up being full of useless and useful information, everything mixed up together in a big mess.
So something had to be done to get back to what SonarQube is meant for: managing source code quality. Every information that can't be precisely linked to a source file should not end in SonarQube. Having said this, it becomes obvious that having a mechanism to define custom dashboards and widgets is just too generic. The web application must provide features that answer precise needs for a precise audience. This is why customizable global and project dashboards are progressively replaced by "hard-coded" pages which answer those use cases. This started with the new project home page introduced in the 5.x series of SonarQube and available in the latest 5.6 LTS. And we'll do the same with global dashboards in the 6.x series.
What is the better framework for development Windows Store application?
I have used http://metroprism.codeplex.com/ but now I want to use Caliburn.Micro or MVVM light for another project.
I have looked through several application examples for these frameworks but they were not complicated enough for me to estimate usage in bigger projects.
These two ones are completely documented but the problem I think is that documentation for winrt mixed with WP7, Silverlight and WPF and I doubt a bit in supporting all features and practices of using exactly for Windows Store application.
Could you give me advice what is the better one? Or what are the good practices in development for Winrt with modularity supporting like in Prism for WPF and Silverlight.
Thanks.
MVVM Light and Caliburn.Micro basically do the same thing but they do it using opposing "philosophies of development" in MVVM.
MVVM Light is a "view first" approach. In this approach the ViewModel is instantiated in by the View. In MVVM Light this is done via something called the ViewModelLocator, a static class that binds a public property directly to the DataContext of the View.
Caliburn.Micro is a "viewmodel first" approach. Here you find that the viewmodel and view are created by an IOC mechanism that binds the two together. You navigate from viewmodel to viewmodel, with the views being generated in response to the navigation to a ViewModel.
They both have different features:
MVVM Light has a really nice messaging system for allowing view models to communicate with each other in a loosely-coupled way.
MVVM Light has a really simple mechanism for injecting design-time data into your views. Basically it swaps out your runtime services with design-time services that feed data to your viewmodels and, in turn your view. This makes design time data really easy to use.
Caliburn.Micro has an amazing data-binding setup, where it handles most of your databinding scaffolding for you. Basically, it maps the names of methods and properties to the names of controls in the view and autowires them. This saves lots of code and is a really, really nice feature.
Caliburn.Micro uses a "Convention over Configuration" mechanism to map views to viewmodels. MainView maps to MainViewModel, etc. This means you've got no configuration, you just need to make sure that you've got your naming conventions sorted out.
I've used both frameworks (Caliburn.Micro for WP7 and MVVM Light for Windows 8 Store Apps) and like them both for different reasons. MVVM Light is easier to start using but Caliburn.Micro is probably more powerful. I've found them both more than adequate for writing moderately complex applications quickly.
Caliburn.Micro gives you clean XAML at the cost of some magic. MVVM Light is a clean and simple framework that is easy to understand and works well. Prism seems to be a bit heavier than MVVM Light and more business app oriented - it does more than just MVVM. There are many things to consider. Choosing what you already know will let you focus on adding features, but learning a new framework can certainly be a good learning experience helpful in future choices - so you could pick something you haven't used before if you want to learn. You could also write your own framework and only include what you need. I usually go somewhere between roll your own and MVVM Light because that is what I know, though if I were to build a bigger enterprise app - Prism might be better suited for the task. I haven't used Caliburn.Micro because the novelty of different MVVM approaches wore off for me and I just want to create apps. With WinRT a roll-your-own-framework approach is easier than with any platform before because the basic project templates already give you some foundations as I wrote in my Minimalistic MVVM blog post. I would recommend that approach if you already tried MVVM and want to use only the pieces you need - the framework will grow with your app. You can just grab pieces of code from other frameworks if you need them or write your own implementations of the patterns you need.
To summarize
If you want to learn - try something you haven't tried before or write your own framework
If you want to create an app quickly and it is not a huge app - use what you know or go minimalistic and don't use anything but what you get from the templates
If you are building a big app with lots of features - consider Prism or rather first think whether Windows Store is the right target platform for you since it seems to be focusing more on simple in and out tablet apps
Can anyone recommend the best web-based technology/language for rewriting a ms-access front-end? I've already converted the tables to MySql and moved all the queries into stored-procedures. The language will need to be able to handle multiple result sets.
Also, I need the GUI to be as similar as possible to the current ms-access front-end. So the new language will need to have features including full CRUD, tabbed forms, datasheet style sub-forms, combo-boxes and reports.
I've dabbled a bit with html, css, php, javascript and java but are any of these capable or suitable? I've heard that Ajax or jQuery might be the way to go.
This is a misguided goal.
Web UI uses completely different paradigms because a web front end is stateless, with unbound data, whereas Access apps are stateful and bound. A 1:1 translation will be a disastrous way to implement a UI in the web browser, unless you invest a HUGE amount in AJAX development.
That said, you should look into Access 2010 and Sharepoint Access Services, which allow you to createn Access front end with web forms and web reports that can be run in the web browser unchanged. This would likely be an order of magnitude cheaper than rolling your own AJAX-based replacement.
We are in the process of doing this. In order to keep the "spreadsheet-style forms" that we have with Access, and which include ordering and filtering capabilities as standard on all screens, we took the decision to go for silverlight + Infragistic toolkit on top of it. Up to now, we have already developped a few screens with these tools, and are quite satisfied with the result.
The shop that I am working part time with is new to Microsoft CRM. I just want to survey what projects have developers done to the system to extend its capabilities.
I can break the work I did into four sections:
Tailoring - Simple field level changes. A lot of this is just making sure the fields and language suited the business I was developing for.
Customisation - More complex changes, generally needing JavaScript and maybe ASP.NET. Some examples would be to use an IFrame and pass values to it from a CRM form. The IFrame would then do interesting things like mapping, charting or give you buttons to do other things. For buttons I would often times use JavaScript to replace the outerHTML in the HTML dom of an IFRAME to show a button rather.
Integration - using .NET to connect MSCRM to other systems. Connected it to Great Plains, Speech Server, SCOM (was called MOM back then), custom LOB systems etc... One interesting one I did was to develop a SSIS component that wrote into MSCRM via the web services.
Reporting - Building reports. In reporting services and in Excel. Excel made for great dashboards because of the dynamic update nature of it.
I have a few (war) stories up at http://www.sadev.co.za/taxonomy/term/7 if you are interested.
I (and others) have implemented a LINQ query provider for the web service layer http://www.codeplex.com/LinqtoCRM.
I did some work with CRM 3.0. My work enhanced the program and turned it into a Document Management app, where you could scan and upload documents based on a case, contact, customer, vendor etc. The .NET SDK back then could have used a bit more work, but I hear with newer versions of CRM it has gotten better. CRM allows for attachments but not at all levels, more at the case level.
We extended 3.0 to send text messages rather than email. There are tools available (for 4.0 at least) to do that now, though.
We also extended it to push service appointments through to Exchange, as due to the workforce being mostly mobile they did not have the CRM client for Outlook.
Two other major areas of development not yet mentioned are plugins and custom workflow assemblies.
Plugins allow you to intercept many of the messages that CRM processes to insert custom logic. The possibilities this gives you are endless because you can intercept all kinds of messages including Create, Update, Delete, and even Read!
Custom workflow assemblies are assemblies that you register with CRM that integrate with CRM's workflow UI. Often times, they perform simple tasks that are useful when modifying form data. Other times, they are more complex like sending status reports.
Custom workflow assemblies are always listed beneath the native options. In the screenshot, everything below "Stop Workflow" was added via a custom workflow assembly.