Recently I noticed some classes in Qt which is called Qt script module and according to documentation it's used to make an application scriptable! here is my questions :
What does it mean? making an application Scriptable?
And when should we use it?
Thanks in advance
What scripting is
~~~~~~~~~~~~~~~~~
Most of the super huge s/w come with lots of features. And quiet interestingly many of the new features that are added are the combinations of basic existing features. But one cant keep on adding new C++ code to create a simple feature...they can just write a script interactively which performs the existing operations in a tandem process and does the job of new feature.
Best examples..Blender(Python scripting). If can look in this scenario.. Blender has 1000s of features. Most of them are actually scripted features calling the existing features in an orderly fashion.
QtScript
~~~~~~~~
This module of Qt framework provides a javascript interpreter(Google v8 js engine) at your disposal. You can call your QObject classes and related methods from javascript as it they were native functions of js(Only in you application). QScriptable classes expose the internals of your c++ QObject's properties and methods to javascript engine.
When To USe
~~~~~~~~~~~
When you have a huge application with lots of modules, and you want to retain the programmability of your application even after compiling it into machine code, then you have to use scripting.
Related
I'm having to update one of our ancient Intranet applications that was written in Classic ASP and utilizes an in-house COM+ Service. I cannot find the source code to this object anywhere and it was not documented by the developer.
I can view the methods available in the Service through Start -> Administrative Tools -> Component Services but can't for the life of me figure out how to look inside the methods to see what they're doing.
Is there anyway to decompile these COM+ Services, or otherwise see what their methods do, or am I doomed to pure observation of the old application and try my best to mimic the behavior and data?
Note: I exported the service from the old server, installed in on my dev box, added the reference to a VS2010 project, and tried to discern these methods using the Object Explorer. Nothing...
COM services include type descriptions of what methods exist on the COM classes and their parameters so that automation controllers can figure out how to pass parameters to the COM methods.
Beyond that, though, there is nothing to indicate what the COM classes do internally other than the native x86 machine code itself. You can try using an x86 disassembler on the DLL, but unless you are already familiar with x86 machine code instructions, this won't be a lot of help.
Compiling source code down to native machine code throws away an enormous amount of information. Variable names, internal function names, none of that is needed for the CPU to execute instructions and perform the operations indicated by the original source code. It is virtually impossible for disassemblers to reconstitute these names that would be helpful clues as to what the code is intended to do. A disassembler can sometimes help figure out core logic, but it will require a lot of careful analysis and effort by a person to even scratch the surface. It's like trying to understand the forest by looking at individual blades of grass.
I'd like to know what are the best practices when creanting a complex and big flex modular application? particularly concercing internationalization, performance, remoting(service), skinning, caching, logging.
How to use theses common resources?
Imagine that many developers will work on the same project, but on different 'small' modules each, and they don't have to know how the entire application works. So every developer will create and compile his/her module (swf), and I'll just have to put these swf in their appropriate folders.
What do you think about this approach:
create a common library : myAppLibrary, which manage languages, services, caching, logging, debuging.. For example this library can have these functions : translate(str:String):String, callAmfService(class:String,methode:string,...params), loadCache(cacheKey:String):Object, etc
require that every module(developer) should use this library when handling languages, services etc. Eg within a module, a developper can do : langSingleton::getInstance()->translate('somestring') for example
make modules communicate by events
(sorry if my english's not clear)
Thanks
I added a MXML component in flex and selected the base as UIComponent. I want to make it accessible so that automated testing tools can Access it. I am using TestComplete for automated testing. As TestComplete uses Microsoft Accessibility classes. Now it treat my component as the Graphics.
How Can I do this??
It should work, if the application was correctly prepared for testing with TestComplete. Check the Preparing Flex Applications for Testing with Automation APIs topic to learn more.
You won't have much luck automating Flex using MSAA, because the object hierarchy and information reported by MSAA is very limited. To improve things, you could try compiling your application with accessibility enabled and also creating a custom accessibility implementation for your component. However, I doubt it will make much difference.
Having said that, you should really consider upgrading to the TestComplete 8.20, because this version has proper support for Flex. By "proper" I mean that it identifies all objects inside Flex applications (including custom components), provides extra test objects for automating Flex controls and also lets you automate controls using their native properties. In addition, this version can dynamically load the testing library into Flex applications, so that no changes to the application's source code or build process are required.
Please look at the official documentation about Creating Applications for Testing
Especially the part about instrumenting custom components
With NInject (preferably 2.0), what options do we have wrt wiring up our object dependencies in a web application?
Can they be defined in an XML configuration file?
Or does it have to be done via code?
There is an extension for xml based configuration: https://github.com/ninject/ninject.extensions.xml
You can do a lot more powerful binding in code though.
Ninject doesn't have XML configuration, sorry but I can't provide a direct link (cos their site has flash elements), but here is a quotation from ninject.org:
Free yourself from XML
Most other .NET dependency injection
frameworks are designed around the use
of XML to declare type bindings.
Rather than forcing you to write
cumbersome and error-prone text,
Ninject arms you with a fluent
interface, which lets you connect the
pieces of your application using
full-fledged code. This means you can
take advantage of the features of the
IDE and compiler, like code completion
and type-safety.
The problem I see with defining bindings in the code only is that you have to add reference to the dll.
You cannot change the binding without adding reference to new dll (removing reference to old one), change code and recompile.
If we had xml config I wouldn't need reference at all, and wouldn't have to recompile.
Right now I have MVC app that is using DI to pass repositories to Controllers. Nothing else then Ninject code for adding bindings uses the concrete implementations of repositories. And still I need to add reference to dll containing the implementations. For only one line of code!
Or maybe there is a possibility to achieve this using Ninject?
What are you looking to achieve? What sort of stuff are you looking to configure? Dynamically selecting a Strategy ? Passing in Port numbers? You could offer a lot more information as to what you're thinking in order to get a better answer [that you can acccept :P].
You need to split the concerns of:
known object wiring (DI)
configuration - generally you'll want to split those into small focused subsets e.g. Strongly Typed config elements vs having a global pool of settings in a big pile mishmashed together a la appSettings
plugins / unknown object wiring (MEF?)
In the first pool, doing it in Code is just the right way and I cant think of any advantage XML would give, esp. in the context of strong names etc.
We are developing a CMS in ASP.NET. We love the idea of add-ons (like in Wordpress, where any developer can add a menu button or a widget) and would like to enable developers to do the same with our system.
However I think that the fact that C# is a compiled language is an obstacle in the way of add-ons.
Am I right? Or is there a way to create add-ons for a ASP.NET application?
The fact that C# is a compiled language isn't a problem at all. In fact the .NET framework should make it relatively easy to load other code (just as Java does, for the same reason). Look into the Managed Extensibility Framework, which is all about loading Add-Ons in managed code.
It's not an obstacle at all. MEF has already been mentioned, you could also use:
System.Addin
Mono.Addins
I'm not sure for ASP.NET specifically, but in the only compiled programming language I know (Objective-C/Cocoa), there's the concept of Bundles that can be loaded dynamically. I'm not sure how that works on the backend, but I'd guess that there is some similar system for C#/ASP.NET.
I don't know how it's done in Wordpress, but there should be many ways. You can allow developers to upload their assemblies with compiled code or you can allow them to upload code in C# or IronPython or anything that supported and compile it dynamically. Maybe you can use WebParts for your task.
Microsoft has created the Managed Extensibility Framework (MEF), specifically for this problem: providing .NET plugins for .NET applications. It is the framework that (future versions of) Visual Studio use for writing managed plugins.
However, please consider using a dynamic scripting language for this! Problems like this are exactly what they are specifically designed for. If you host the Dynamic Language Runtime in your application, it not only means that your users can extend the application in a scripting language, but even in any dynamic language (scripting or otherwise) for which a DLR implementation exists: Ruby, Python, Smalltalk, Scheme, JavaScript, PHP, you name it. Biggest disadvantage: the DLR hasn't been released yet.
In C#, you can create any assemblies, link them as DLL files and then do whatever you want.
The usual case would be to define some kind of Plugin Interface which must be implemented by all the plugins.
Then you can load all plugins from the filesystem (by iterating over the plugin DLLs), find the class inside which implements the interface, instantiate it and work with it.
If you want to provide plugins with unloadability and security, you could create an application domain and load the plugins to that, increasing complexity, but also increasing stability (a bad plugin won't crash your app).
Please ask more specifically if you want a specific answer :-)
It's not too difficult to put hooks in place. You have to define in advance where the add-on features will appear. For example: when drawing a menu you can use reflection to search other dlls (with specific names and locations) for a "BuildMenu" function. You'll be defining the API for this function signature. It may have to return a list of items to be added to the base menu items collection.