How to create a custom interface by using standard directus interfaces as a starter?
an answer in discord uses directus tarball in dependencies and a custom vue.config.js , but the rest of the import statements are still wrong.
Here is my custom interface source code:
Even If all import statements of custom interface's vue file are correct , directus-extension build can't build interface because of other import statements.
Is there a better way to use standard directus interfaces (file-image or input-rich-text) in custom interfaces?
There has not been enough information to provided to help with debugging your issues with the file interface.
Documentation for building interfaces can be found in the Directus Docs. https://docs.directus.io/concepts/interfaces/#interfaces
I have created an interface for Directus that uses the image interface. Perhaps providing the link will be a useful resource to you showing you how I have personally implemented it. https://github.com/resauce-dev/directus-image-scout
As we all know In asp.net Startup class there is a method ConfigureServices we can add custom Services. Services are made available through Dependency Injection.
ASP.NET Core includes a simple built-in inversion of control (IoC)
container that supports constructor injection by default, but can be
easily replaced with your IoC container of choice. In addition to its
loose coupling benefit, DI makes services available throughout your
app
My Question is how to Replace Built in IoC with my Own IoC?
Please provide me an example if you have.
There are a number of different containers currently available for ASP.NET Core, including
Autofac: http://docs.autofac.org/en/latest/integration/aspnetcore.html
StructureMap: http://andrewlock.net/getting-started-with-structuremap-in-asp-net-core/
SimpleInjector: https://simpleinjector.readthedocs.io/en/latest/aspnetintegration.html
DryIoc (RC2 only atm): https://bitbucket.org/dadhi/dryioc
Exactly how you use them differs in each case, but essentially they all follow the same pattern:
Register dependencies as usual using the built-in container
Create an instance of your third-party Container
Add any additional registrations to your third-party container
Populate the new container with registrations from the built-in container
Return an IServiceProvider from your third-party container
It might be worth taking note that there are a number of conversations happening around the way these libraries will integrate with the built in container going forward. The comment here provides a good summary of the conversation, or you can dive right into the discussions on GitHub here and here.
My question is about concept (I need some recommendation how to implement it right).
I've use MVC pattern when I build the UI,currently this UI serve two plug-in since the UI they should use are identical. so both plugin call to this UI and this is working fine.Now there is third(and four :)) plugins which should use some of the UI control and logic so instead of build new UI for this plugin's I want to provide some mechanism to enable to the user to decide which control he want to draw in the screen. so currently I need to break the view to sections but my question is what it the best way to do that ?
(from design and concept aspects)
The view is build from 6 controls that all the plugin must by default use two from them and the rest are optional . for example new plugin can use the mandatory two and provide in addition two more control.
Hard to answer without knowing the language and platform.
Each of your 6 controls you will have a view and controller. Each view/controller needs a reference to a model that exposes the data and methods appropriate for the view to display and the controller to call. So the question is how to connect up each plugin to the subset of the 6 possible controls.
In your case I would create 6 interfaces that expose the data and methods relevant to each of the 6 controls. Each plugin implements just the interfaces that are possible for that plugin. In addition it would expose a standard interface that all plugins implement. This standard interface would provide a list of the mandatory interfaces it requires shown, as well as the list of optional interfaces it allows to be shown.
Your master view then takes a plugin and asks for the list of mandatory interfaces. It creates those child controls and passed the relevant plugin interface to each of the child controls. It then looks at the optional ones are creates just two of them for display and hooks them up.
Hard to be more precise without more details.
You can try to use MVVM(Model,View,ViewModel) pattern, it's more convenient for shearing code, you can search in google 'MVVM', there are tons of articles about that.
In our web project we are using Ninject. Now we are adding plugins to our application. We want plugins to be able to add their own bindings. Ninject modules seems like a logical solution to this problem.
However, I don't see any guidance on how to avoid the following problem. What if a plugin adds a binding to an interface that already had a binding. Now the DependencyResolver will throw an exception when trying to resolve that interface.
I'm trying to make a change to our DependencyResolver that doesn't require rewriting all of the binding statements we've already written in the main application. I don't want a plugin to be able to break my main application. If a plugin needs to apply constraints to make it's bindings work then it is its responsibility.
So here's what I want.
A plugin would not be able to break the core app or another plugin because it added a binding.
It should not be necessary for any change to be made to core application or another plugin when I want to add a new plugin with its own bindings
Where there are multiple instances to choose from it should do the "logical" thing. The core app should get the instance it always would have gotten in the absence of the new plugins. The plugin should get the instance it specifically bound.
It seems like I should be able to override the resolving methods of StandardKernel so that it can implement these rules. It seems like knowing what module a binding was a part of would help resolving. But I can't find module or module name as part of the context, request, bindinginfo, etc.
Any thoughts on how to resolve this issue. I don't see that Ninject seems to answer what seems like a very obvious need for a modular system. A new module shouldn't be able to break an app. (It should only be able to "break" itself.)
You should have a look at Ninject.Extensions.ChildKernel. You could create a ChildKernel per plug-in and then load the plugins' module in their own ChildKernel.
This means that a plugin cannot rely on the bindings of another plugin, but a plugin may rely on the bindings of the Parent Kernel (root / application kernel). So you can provide certain types/services to the plugins.
By the way, if the implementation of Ninject.Extensions.ChildKernel does not match your needs, you might very well choose to implement your own extension. It's not that much code (see ChildKernel source)
what is the difference between these two terms, thanks in advance for any good simplifications and good examples.
A framework is a group of classes, interfaces and other pre-compiled code upon which or by the use of which applications can be built.
The API is the public face of a framework. A well designed framework only exposes those classes, interfaces, etc that are needed to use the framework. Code that supports the operation of the framework but that is not necessary to users of the framework is kept internal to the framework's assemblies/dlls. This keeps the public face of the framework small and encourages a "pit of success," or the quality of a framework which makes it simple to do the right thing.
(I provide an example from the .NET world)
The SqlConnection class is used to connect to a Sql Server instance. Its public API is pretty simple:
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open();
// Do work here; connection closed on following line.
}
However, this class depends on around 200 methods within the System.Data framework (in this case, an assembly), 3/4 of which are internal and not part of the public API of System.Data. Because the framework's API is kept simple, it becomes easy to use SqlConnection properly. If the user was required to deal with SqlConnectionFactory, SqlDebugContext, DbConnectionPoolGroup or any of the other internal classes required by the SqlConnection class, it would become exponentially more difficult to use SqlConnection properly. Because the API only exposes a small percentage of the framework, it is easier to create and use a connection.
An API is an interface to a (set of) component(s) encapsulating a functionality. For instance, the GoogleMaps API, the DirectX or OpenGL APIs.
A framework is more a set of tools, components aimed at helping the developer to develop his/her project in a given Frame. The framework usually sets some coding standards, provides useful components, ... For instance, Symfony/Cake are PHP web application frameworks. JUnit is a framework for unit tests in Java, ...
Frameworks can often bundle/provide a unified interface to some APIs.
Some APIs can be internally built using a framework.
API - application programming interface -> the contract you must obey when using a library's API
library - a set of classes/modules that solve a specific problem -> has an API
framework - a "bigger" set of libraries with a set of rules on how to use them
Since every library has an API, no point in giving examples.
A popular Java library for time is Joda time.
A popular Java framework is the Spring framework.
You must obey a lot of rules to use Spring well. You don't have to obey as many rules to use Joda time.
An API is something code has, not something it is. A framework has an API, but it is not itself an API.
API "Application Programming Interface" is set of prewritten packages, classes and interfaces with their respective methods. You can use it without much concern about internal implementations. API is used an interface between two or more applications and like REST API.
Framework is a skeleton that contains design patterns, classes, interfaces and libraries that can be used to build applications. Framework provides inversion of control which give the responsibility of program flow to the framework itself, also we can extend the framework without changing its predefined code. For example Spring is a framework that can be used to build web applications.
API's are pre-built-in from SDK (or from which you can include on to). Frameworks are loadable bundles wherein exposed functions of such bundles can be used. You can acquire expose functions of those frameworks by using pointer to functions.
Example:
API:
-stringWithString:
function from framework:
-myExposedMethod:
Framework is use to design an application, ie MVC, MEF. Like a model that you build on, almost a base for a certain set of functionality that you might want in your application.
API is for interaction between applications, your app would use the Facebook API to interact with Facebook.
Hope this is a bit more clear.
Java API simply means ...Application Programming Interface in which all the features describes of product or software.
Java Framework means semi-completed project or code. It provides an architecture to make project . Framework have own classes and methods etc..
An API is simply a library built with a particular language that developers can use to build applications.
Frameworks are a set of libraries, just like APIs however the syntaxes may deffer of the original language. So the developer may be writing a different syntax of PHP for example when using Symphony.
The main or core difference beteen framework and API is that framework allows developer to hook into the life cycle of the objects through lifecycle callback methods mechanism whereas API doesn't do that, API is only intended to perform a functionality only.
Another way to visualize it is this: (true of any programming language)
Any(!) "piece of software that is intended to be used by another piece of software" by-definition must have some "application program interface (API)," which represents the "knobs, switches and dials" that the other piece of software is expected (and, permitted) to use. All of the internal implementation details are not visible and cannot be reached.
"Frameworks" are tools that are designed to make it easier for humans to write a particular, common, type of application – such as a web-page. The framework implements "the stuff that every such application is going to need to be able to do," and does it in one, well-tested way, "precisely so that you (the application author) don't have to." Instead of redundantly writing "the same old thing, one more time, and fretting over whether you did it correctly," you simply leverage what the framework has already done for you.
After all...
Actum Ne Agas: Do Not Do A Thing Already Done.