My multi layer project has Datalayer, services, panel. dataLayer referenced to services, and services referenced to panel. i have an interface in datalayer, some thing like
public interface IJournalEntity
{
...
}
my services has a class that inherited from IJournalEntity,
public class OfflinePaymentService : IOfflinePaymentService, IJournalEntity
{
...
}
when i compile panel layer, unity config raise an error to add reference to data layer, how could i fix withoud referenced that?
You cannot fix without referenced that. The type is unknown to your project if you don't reference it.
Some similar questions:
Access interface methods without referring the class
C# Use a class that implements an interface without adding a reference to the assembly that defines the interface
If your datalayer is defined in a separate dll, you need to put that in Assets/Plugins/. This applied to Unity3D 4.x.
On Unity3D 5.x, just put the dll in Assets will work.
Documentation for plugins
Documentation for plugins on Unity3D 5.x
Related
I am currently working on two Flutter apps that share about 90% of their functionality. Because of this, I have built most of the code as a library, and then have the two projects set up to import that library. I can then plug in two different CMS instances, and different Firebase services ... super-efficient.
The problem I have is that my library code has certain references that I would need to override in my projects to allow for bespoke menu items, theme settings etc.
A good example is a MenuItem enum that is used throughout my library code for navigation and routing etc. It builds the entire app structure off a list of these MenuItem types. I need to define a MenuItem enum for both of my projects, but the error I get is a conflict between the project and the library.
{MenuItem menuItem}
The argument type 'MenuItem (where MenuItem is defined in /Users/xx/Documents/dev/xx Creative/dev/AR_Trails_app/ar_trails_app/lib/utils/menu_items.dart)' can't be assigned to the parameter type 'MenuItem (where MenuItem is defined in /Users/xx/Documents/dev/xx Creative/dev/AR_Trails_Lib/weald_ar_trails/lib/utils/menu_items.dart)'.dartargument_type_not_assignable
menu_items.dart(7, 6): MenuItem is defined in /Users/xx/Documents/dev/xx Creative/dev/AR_Trails_app/ar_trails_app/lib/utils/menu_items.dart
menu_items.dart(8, 6): MenuItem is defined in /Users/xx/Documents/dev/xx Creative/dev/AR_Trails_Lib/weald_ar_trails/lib/utils/menu_items.dart
I know that there is an option to use dependency_overrides in Dart but this is for overriding the entire library I think: https://dart.dev/tools/pub/dependencies#dependency-overrides
How can I do this but for just one file? Or maybe two or three?
UPDATE:
To be clear on the use-case here: my file menu_items.dart is in the library package, and it is used throughout to build the navigation and drawer etc. But it is only used in the library. What I need to do is override that file in each project so that the reference the library uses is the project's local version and NOT the one that is being referenced in the library. I thought that if I used as a path reference to the file like ../../utils/menu_items, and mirrored that in my project, it might use the local project version. It doesn't.
I'm looking for a document with the possible metadata property names and config parameters for a component.
There are many documents on the internet with such definition. The question is how I know if the name of a property/parameter setting is a valid name.
metadata : {
name : "XXXXX",
version : "1.0",
includes : [],
dependencies : {
libs : ["sap.m", "sap.ui.layout"],
components : []
},
rootView : "XXXXX",
config : {
resourceName : "i18n",
resourceBundle : "XXXX",
serviceConfig : {
name : "main",
serviceUrl : "XXXXX",
}
}
There is a document available here which describes all possible metadata. Since there is no real assistance during design-time, you have to have a look in the API to check the possible values. If you want to extend it with your own properties/parameters, just make sure that the name is not too generic since the Component can be extended with each new version of UI5.
The approach of defining component metadata in the component itself has been superseded by an approach using a manifest file. You will find all available properties in the documentation .
The Component class extends the ManagedObject class and provides specific metadata for components. The UIComponent class provides additional metadata for the configuration of user interfaces or the navigation between views.
The metadata defined in component.js is common for faceless components and UI components. The following parameters are available:
abstract: Specifies if your component class is an abstract class that serves as a base for other components
version: Version of your component; this parameter belongs to the design-time metadata and is currently not used; it may be used in the future in the design-time repository
includes: Array of strings containing the paths to CSS and JavaScript resources for your component; will be added to the header of the HTML page and loaded by the browser. The resources will be resolved relative to the location of Component.js.
dependencies: Used to specify all external dependencies, such as libraries or components. Like the includes for resources that are added to the application’s HTML, the dependencies are loaded by SAPUI5 core before the component is initialized. Everything that is referenced here can be used in your component code right from the start. Specify here external dependences such as libraries or components, that will be loaded by SAPUI5 core in the initialization phase of your Component and can be used after it.
libs: Path to the libraries that should be loaded by SAPUI5 core to be used in your component
components: Full path to the components that should be loaded by SAPUI5 core to be used in your component
ui5version: Minimum version of SAP UI5 that the component requires; it helps to be ensure that the features of SAPUI5 runtime used in this component are available. As SAPUI5 currently does not enforce the use of the correct version, it is only used for information purposes.
properties: Defined for components in the same way as for a control or view
library: Specify the library the component belongs to
config: Static configuration; specify the name-value pairs that you need in the component
customizing: Customizing for components and views, see Extending SAPUI5 Applications
sap.ui.viewExtensions: Used for providing custom view content in a specified extension point in the standard application
sap.ui.viewModifications: Used for overriding control properties in the standard application
sap.ui.viewReplacements: Used for replacing a standard view with a custom view
sap.ui.controllerExtensions: Used for replacing a standard controller with a custom controller
for more Information go to the url:
https://sapui5.netweaver.ondemand.com/sdk/#docs/guide/0187ea5e2eff4166b0453b9dcc8fc64f.html
Well, from the code you could check if the property exist with the get(Property Name) method that all elementes have.
Otherwise all the properties ad hoc are in this url that Tim Gerlach shared for you before.
If it is a regular development approach, you should ideally look at the API of the component class.
If you are using metadata driven approach for development and you might generate the required code then you should fetch details from metadata information provided by the class or read it from .js file. ".js" will be helpful if you are not using SAPUI5 runtime.
Hope, this helps.
.........
Good Luck
Final answer has to be by looking through the source code as nothing else, even the API documentation, will be able to be 100% accurate against the consuming source.
As mentioned in the documentation, the definition of Component's metadata has largely moved to a separate file named manifest.json (aka. Application Descriptor).
With the introduction of the descriptor for applications, components, and libraries, we recommend to migrate the component metadata to the descriptor. [...] For more information, see Descriptor for Applications, Components, and Libraries.
Besides just looking at the list of available parameters in the doc, the closest "assistance" you could get is the Descriptor Editor from Web IDE.
The Descriptor Editor provides available choices, placeholder suggestions, and input validation.
I've been busily getting with the future and migrating an old eclipse 3.7 application over to Eclipse 4 and whilst I'm happy with the application model for porting all the views I have a number of source providers that I am unsure about porting wise. I've been using a few tutorials on Eclipse 4 including this Tutorial from good old Lars but none seem to cover this particular element.
For a small amount of Context my existing application has a few classes extending AbstractSourceProvider that are registered in the org.eclipse.ui.services extension point. My views register themselves as listeners to these services using the ISourceProviderService.getSourceProvider(key) function from the workbench and update themselves if that source fires a sourced changed event. I also have a few providers that reference each other some times too so I'm wondering if this will still work with injection.
What sort of model is used in Eclipse 4?, should I just use the same old extension point? Can these extension point services be injected in to the views in the new cool anotationy way?
What gives?
You can create a service in a number of ways:
Create an instance of your service class and put it in the IEclipseContext. This is often done in an 'Addon':
public class MyAddon
{
#PostConstruct
void postConstruct(IEclipseContext context)
{
MyService myService = ContextInjectionFactory.make(MyService.class, context);
context.put(MyService.class, myService);
}
}
The 'Addon' is declared in the application.e4xmi file.
You could also create the service like this in the LifeCycle class for the RCP.
An OSGi service will automatically be added to the Eclipse context.
You can use a Context Function which uses an OSGi service but doesn't create the actual service until it is needed.
In all cases you reference the service by injection:
#Inject
MyService myService;
Note that injection is only done on objects created by Eclipse from objects described in the application.e4xmi. It is possible to do injection on other objects using ContextInjectionFactory.
What is the proper way to do that?
Let's say we have some third party library in our project and we need to provide an access to some controls which are sealed.
New widgets will be created and added to the application using MEF and they should be able to import some controls from the core application.
So how to export those controls properly?
If you cannot modify the original class (e.g. ThirdPartyComponent), then you can do the export via a property on another class (e.g. ThirdPartyComponentExporter):
public class ThirdPartyComponentExporter
{
[Export(typeof(ThirdPartyComponent))]
public ThirdPartyComponent Foo
{
get
{
return new ThirdPartyComponent();
}
}
}
For visual controls, you may have to use CreationPolicy.NonShared to prevent MEF from reusing the same instance in different locations.
What about wrapping the third party controls in "export" classes and then access this control through the wrapper?
I'm using Netbeans. When I create a Java class, I sometimes want to change it to be a GUI component so that I can visually edit it using the GUI Builder.
What is the necessary step to transform a regular Java class to a GUI component so that Netbeans would recognize it and allow me to use GUI Builder ? (i.e. switch between Source and Design)
NetBeans' Gui builder, Matisse, works off a .form xml file located adjacent to the source file. Matisse creates and maintains the .form file and the code generator creates/updates methods in the java source to reflect changes to the form.
Unfortunately, there is no support in NetBeans for free-form GUI construction.
The closest I've seen is FormGenerator. It's a contributed NetBeans module that adds a right click action to .java files that will attempt to generate a .form file from the .java source. It's very limited, but it's better than nothing. It works best if you've followed the coding style employed by Matisse.
http://netbeans.org/projects/contrib/downloads/download/Readme.txt
http://netbeans.org/projects/contrib/downloads/download/FormGeneratorModule.zip
To add a class to the Palette, all that's needed is for your class to conform to the Java Beans model. That is, your class must:
be serializable
have a public, no-argument constructor.
All fields that have getter and setter methods that are named properly, i.e.:
int count
int getCount()
void setCount(int c)
should by default be recognized as a property.
For a finer control of what properties should and should not be exposed to the GUI Builder, you can associate your class with an implementation of the BeanInfo interface. See this Sun tutorial for more details.
However, NetBeans has several tools to help you in designing a custom bean. You can create new beans using the built-in templates available in the new file dialog, under the "JavaBeans Objects" folder.
This tutorial will guide you through creating an Image Bean.
What you could do is create one from scratch, design it as you wish, and then look at the generated code to understand how you can modify your existing class.
Try to use properties (Java bean!) for properties which should be changed from the ui designer and look here for more info.