I need to add functionality to my WPF application (in C#) that allows users to create their own rules and execute an action from a list of pre-defined actions. An example of what I need is the "Rules And Alerts" feature of Outlook.
I've just been recently introduced to functional programming and one part of me thinks this might be a perfect place to implement that. Another part of me thinks that workflows may be the best approach but I've never worked with workflows outside of SharePoint.
So, I'm looking for guidance from those who may have experience implementing such functionality. In my opinion, it is not so difficult to create a script (or whatever it's called), but the tricky part is parsing the script back into the designer.
Any other ideas will be greatly appreciated.
It sounds like for what you want, a scripting engine or Windows Workflow would be waaaay overkill. Those become interesting when there are custom actions to be defined with a high degree of flexibility but if it's really having normal users (without extensive training) select/customize a critera and then select/customize a pre-defined action, then I'd just mimic the Outlook approach you mentioned (also look at the "Conditional Formatting" feature in Excel)
Related
Environment
Windows 8.1 64bit
Microsoft Visual Studio
C#
What I'm trying to do
To implement a mini language in C#
My job in my company is to make a software which automates evaluation of the performance of company products. The evaluation involves opening valves, flowing chemicals, fetching signals from sensors, calculating some values, etc...
The issue is when a user wants to change the procedure and parameters like how long the reaction time is, the order of opening valves, whether reaction conduit is flushed out or not, the programmer has to change the source code and build another software every time the user requires it.
So I'm trying to implement a mini language in C#. A user can organize a procedure of measurement with the easy-to-understand language. The user writes a code in a txt file, my software reads it, parse each line of code, extract commands and parameters, call corresponding method in the software.
For example, a user writes a line of code like open_valve(3), my software reads the code and call an internal method send_commands_to_ADconverter(VALVE, 3) which sends appropriate commands to a target valve via an A/D converter connected to the computer. This is my conception.
However, due to lack of my programming skill, I have no idea where to start. What technology is available? What are the keywords to achieve the goal? How can I achieve this objective? Any help would be appreciated. Thanks.
Edit 1
c# - Adding scripting functionality to .NET applications - Stack Overflow doesn't refer to accessing external devices like sensors, valves via A/D converter which is crucial for my purpose, so it is unclear this is a duplicate question of the link above.
In order to create a language you need a "parser" of some sort. You will need to define a "grammar". Parsing your "progam" via the grammar will result in a structure that you can then call methods in your code that implement each feature of your language.
You are on a big learning curve here :) lots of strange things like EBNF. You will probably see lots of references to things like Gold and ANTLR. These are hugely capable but involve things like "compiler compilers" and add a level of complexity that can be confusing and require extra steps in you build pipeline.
Here are a couple of libraries I've used that allow you to define you grammar in c#.
https://github.com/picoe/Eto.Parse
https://irony.codeplex.com/
Irony is very good (I've used it for various projects) but hasn't been maintained for a while.
Eto.Parse is more recent. It also has built in parsers that allow you to create a Grammer by parsing BNF. This is very cool
If I understand, your goal is to parse a syntax written by your user and take a decision with what he typed.
I suggest you to use regular expression to match and split the user input.
There are several scripting languages which can be run directly from C#.
As your users doesn't seem to have programming knowledge it might help to use a verbose language like VBScript.
To run VBScript you can use the Scripting Control. See this question for samples: Use Microsoft Scripting Control to evaluate 'If' expressions (via c#)
IIRC the script control must be run as a 32bit application.
Well, the easiest option would be to use what you already have - C#.
You can compile C# code on the fly, and it's very easy and cheap with the new compiler, Roslyn. Then all you need to do is define your interface so that it's easy to use for the users, and put that code in a method you can call from your code. This allows you to easily support all the various development tools for C# as well, including Visual Studio/VS Code. In the simplest form, all you need to do is make your "script" implement some base class that has all the methods you want the users to have - there's certainly better approaches, but this one is very simple, which sounds like something you're looking for.
Of course, this only makes sense if you can trust your users. Making safely sand-boxed code in C# is a lot more complicated (though certainly possible), and you'd probably be better off using some ready scripting solution.
i am a junior c# programmer and would like to learn silverlight.
is silverlight for progrmmers or for designers?
It is for neither - Silverlight is simply the branding for the runtime engine, library set, etc. The only thing that "uses" Silverlight directly is (broadly speaking) the browser.
The important thing for developers is Visual Studio (regular or Express:Web), and for designers: the Expression suite. Both can contribute to a Silverlight project. Also consider that you may be targeting Moonlight, so even "Silverlight" becomes misleading.
Silverlight is for both developers/programmers and designers.
The User Interface of a Silverlight application is defined in XAML script, which is based upon XML.
Microsoft explicitly target the Microsoft Expression (specifically Expression Blend) suite of products at designers, whilst Microsoft's Visual Studio is aimed at developers (although Visual Studio 2010 can be used for design work as well).
If you have a designer and a programmer working together to create the overall Silverlight application, you can utilise a programming design pattern called MVVM (Model-View-ViewModel) to help separate the concerns between the UI and the back-end functional program code. This effectively allow the programmer to not really care about the names and ID values of specific UI elements that may have been defined by the designer, but simply to "bind" together specific User Interface elements with their "back-end" program code counterparts to create the complete Silverlight application.
It is for both.
Both,
As a programmer it's good to be familiar with the programming model, the related MVVM pattern, the object model etc.
As a designer you can build your designs in Blend and XAML. Then integrate them with the rest of the software
Both.
Usually a developer will do it all, but using the Expression products, designers and developers can work on the same project to utilise their skills.
I guess like most peep said, it is for both.
Being a developer myself, I tend to sway towards the coding.
But when I want to do animation, I will go back to xaml, which is way more simpler than doing in the code behind.
One good thing about silverlight that certainly prove that it is suitable for both is that, no matter how a designer place his UI and animations, and no matter how a developer codes, as long as 1 focus on functionality, another focus on UI.
Things will work out perfect, unless the designer deleted some UI that is suppose to have functionality. :)
It's for both.
However you're also going to need both developer and designer to make it quite good.
The software company I work for offers data conversion as a service for new clients who have previously used other similar software. I've written a VB.NET application to automate common conversion operations, and have separate logic between known vendors. A particular file layout has become rather common, but due to the nature of how this particular competitor's application stores information, certain fields mean one thing for one client, and another for a different client.
Certain elements within this vendor's format change every time, so I've written the application to account for that. Because some data fields mean different things to different vendors, I have to change my mapping code every time. This wasn't an issue when I had one of these every six months or so, but these are becoming much more common and I would much rather find a way to further automate this process.
I was thinking of implementing a simple interpreted scripting language that would allow me to save the conversion settings for the client in a text file, so I'm not having to feed the settings into my app every time I run it. My goal is to have the time spent in implementing this pay off in faster conversions in the long run.
This is the example I had in my head:
# this is a comment
RECORD INCLUDE(source[Class] != 'I' && source[Category] != 99);
FIELDMAP
destination[name] == source[name];
desintation[address] == source[mailingaddress1];
...
END FIELDMAP
BEGIN
# logic goes here
END
I don't want to make this more complicated than it needs to be. I admit that I've never even looked into scripting and am kinda clueless as to where to start or what other considerations need to be made.
Are there already scripting libraries for .NET that will do most of what I want? Is scripting the wrong way to go about this? I really don't want to reinvent the wheel if there is a better way.
Thank you for any help. :)
IronPython (one of the the DLR languages Jake referred to) is a .NET implementation of the Python scripting language. It allows you to access .NET code (including framework classes and class you've written) and would be an excellent choice for this sort of task.
It doesn't have any real dependencies (other than the .NET Framework) and you won't need to learn much learn much Python-specific syntax in order to get the job done.
(If you decide to go with IronPython, I recommend using Notepad++ as your editor.)
Rather than write a custom language, you could embed any of the DLR languages (IronPython, IronRuby, or JScript), or you can use compiler services to compile VB.NET from your application.
Another idea ... if you only need to change the mappings between variable names, maybe you could just come up with a little XML file that would define the mappings.
I am building a prototype for a web-based application and was considering building the front-end in HTML, which can then be reused later for the actual application. I had done a Flash-based prototype earlier, which embedded the .swf into a C# executable. Flash made for rapid turnaround time while the Windows application provided unlimited access to fancy API's for DB access and sound.
I want to consider something similar for this one too. Does this approach make sense? I am particularly concerned about the way the HTML would communicate with the container app. From what I understand out of preliminary research, it would be only through JavaScript, which might quickly get unwieldy. This is especially so because unlike the Flash-based prototype which implemented a lot of its functionality in the .swf, the HTML UI will depend entirely upon the shell to maintain state. Also, I don't need anything more than access to a database. So a desktop application might be overkill.
Another alternative that comes to mind is to build the prototype using PHP and deploy it with a portable server stack such as Server2Go or XAMPP. But I've never done something like this before. Anybody here shed some light on drawbacks of this approach?
The key requirement is rapid iterations of the UI, reusable front-end code and simplified deployment without any installations or configuration.
Some of the best programming advice I've seen came from Code Complete, and was along the lines of, "evolutionary prototypes are fine things, and throwaway prototypes are fine things, but you run into trouble when you try to make one from the other." That is, know which type of prototype you're developing, and respect it. If you're developing a throwaway prototype, don't permit yourself to use any of it, however tempting it may be, in the production system. And if you're developing an evolutionary prototype - one intended to become the production system - don't compromise quality in any way.
It sounds like you're trying to get both, the rapid development of a throwaway and the reusability of an evolutionary prototype - and you can't. Make up your mind, and stand by it. You can't have your cake and eat it, too.
I think you off to the wrong start, here. Why would you want your prototype to be fully functional? A prototype is intended to be throw-away and to help flesh out requirements and UI. If you need full functionality, why not just skip to the final product? If prototyping is really something you want to do, I suggest looking into a specialized prototyping tool.
Are you prototyping the user interface for a customer? If you are, consider something less unwieldy like paper prototypes or presentation software (like PowerPoint) until you get the UI nailed down. If you can establish the UI and are clear about the customer's requirements, you can then develop the application in whatever the actual platform is going to be with a clear model in mind.
In my current project, I prototyped the UI in PowerPoint first. In a subsequent iteration, I used static web pages and some jQuery plugins to simulate actual user interaction. That proved to be very effective in demonstrating the interface, and I didn't have to build the application first.
I would join in on folks suggesting paper prototyping as the "idea", but not necessarily the implementation. The biggest point here is that tools such as HTML or Flash let you get "bogged down" in the details - what does this color look like? What's the text on this thing? Lots of time can pass by that way. Instead, what you should be focusing on is user flows.
One tool that keeps the spirit of paper prototyping without all the "paper" drawbacks is Balsamiq: http://www.balsamiq.com/demos/mockups/Mockups.html. It was covered by Jeff and Joel in one of the Stack Overflow podcasts; I've been using it for my own projects for a while. It's freeware, and it does its job magnificently.
If you know C# then another option you can look at is Silverlight. You can then leverage your knowledge of C# and/or JavaScript and interact with a rich object model.
Would that do what you are looking for? The installation would be minimal on the part of the client - download and install the Silverlight plugin
If prototyping is something you truly wish to accomplish here, paper and pencil will be your best friends. You can draw out as many iterations as necessary. While none of this is ultimately useful later on once you begin coding, it is as quick and rapid is it goes.
As mentioned previously, there are many prototyping tools which have a bit of a learning curve, but an alternative to consider would be using a framework such as CakePHP or Ruby on Rails which make for fast application logic and leave customizing the front end being the primary hard work left. And plus, you're left with a mostly functional application when you're done with your prototyping which can be tweaked as needed.
In either scenario, you're paying with your time either upfront (in the case with learning a new framework), of over time in payments (with the case of prototyping on paper or coding by hand).
My company is currently in the process of creating a large multi-tier software package in C#. We have taken a SOA approach to the structure and I was wondering whether anyone has any advice as to how to make it extensible by users with programming knowledge.
This would involve a two-fold process: approval by the administrator of a production system to allow a specific plugin to be used, and also the actual plugin architecture itself.
We want to allow the users to write scripts to perform common tasks, modify the layout of the user interface (written in WPF) and add new functionality (ie. allowing charting of tabulated data). Does anyone have any suggestions of how to implement this, or know where one might obtain the knowledge to do this kind of thing?
I was thinking this would be the perfect corner-case for releasing the software open-source with a restrictive license on distribution, however, I'm not keen on allowing the competition access to our source code.
Thanks.
EDIT: Thought I'd just clarify to explain why I chose the answer I did. I was referring to production administrators external to my company (ie. the client), and giving them someway to automate/script things in an easier manner without requiring them to have a full knowledge of c# (they are mostly end-users with limited programming experience) - I was thinking more of a DSL. This may be an out of reach goal and the Managed Extensibility Framework seems to offer the best compromise so far.
Just use interfaces. Define an IPlugin that every plugin must implement, and use a well defined messaging layer to allow the plugin to make changes in the main program. You may want to look at a program like Mediaportal or Meedios which heavily depend on user plugins.
As mentioned by Steve, using interfaces is probably the way to go. You would need to design the set of interfaces that you would want your clients to use, design entry points for the plugins as well as a plugin communication model. Along with the suggestions by Steve, you might also want to take a look at the Eclipse project. They have a very well defined plugin architecture and even though its written in java, it may be worth taking a look at.
Another approach might be to design an API available to a scripting language. Both
IronPythonand Boo are dynamic scripting languages that work well with C#. With this approach, your clients could write scripts to interact with and extend your application. This approach is a bit more of a lightweight solution compared to a full plugin system.
I would take a look at the MEF initiative from Microsoft. It's a framework that lets you add extensibility to your applications. It's in beta now, but should be part of .Net 4.0.
Microsoft shares the source, so you can look how it's implemented and interface with it. So basically your extensibility framework will be open for everyone to look at but it won't force you to publish your application code or the plug-ins code.
Open source is not necessary in any way shape or form to make a product extensible.
I agree that open source is a scary idea in this situation. When you say approval by a production administrator - is that administrator within your company, or external?
Personally, I would look at allowing extensibility through inheritance (allowing third parties to subclass your code without giving them the source) and very carefully specified access modifiers.
Microsoft already did exactly this, resulting in Reporting Services, which has every attribute you mention: user defined layout, scriptability, charting, customisable UI. This includes a downloadable IDE. No access to source code is provided or required, yet it's absolutely littered with extensibility hooks. The absence of source code inhibits close-coupling and promotes SOA thinking.
We are currently in a similar situation. We identified different scenarios where people may want to create a live connection on a data level. In that case they can have access to a sinle webservice to request and import data.
At some point they may want to have a custom user interface (in our case Silverlight 2). For this scenario we can provide a base class and have them register the module in a central repository. It then integrates into our application in a uniform way, including security, form and behaviour and interaction with services.