how are you? I'm a new with OPC UA and I'm trying to create my first Server using the milo SDK. Just looking the ExampleNamespace we can see there are 2 types of objects to hold simple variables. Both looks the same to me, I'm talking about UaObjectTypeNode and UaFolderNode. I think there is not documentation for this SDK, if I'm wrong please show me a link or something to check it, it'll be apreciated.
Well, my questions are these:
What are the differences between both objects?
Could you give me an escenario where one can fit better than the other?
If you need additional information I will update my question, thanks!
ObjectTypeNode is not meant to hold simple variables the way a FolderNode is.
An ObjectTypeNode is like a template, and then there will be instances of these templates (ObjectNodes) that have all the members defined on the template.
A UaFolderNode is just what it sounds like - a simple ObjectNode instance (that has a type definition of FolderTypeNode), that you can add arbitrary Organizes references to, pointing at other ObjectNodes or VariableNodes.
You really should read some of the OPC UA specs, Part 1 and Part 3 at a minimum, so you have a basic understanding of how OPC UA works.
Related
I have inherited an anylogic model at work. It's my first contact with anylogic. There is hardly documentation, so I try to dissect the generated code to understand, what is going on.
There is one thing that appears all the time: _xjal
It appears in variable, member and method names - like _result_xjal, _value_xjal etc...
Usually it is easier to understand code when names make sense. That's why I hope, to easier understand the code, once this strange thing, that google does not know of, is deciphered.
What does it stand for?
"xj" stands for XJ-Tec (the former name of the company that develops AnyLogic).
"al" stands for AnyLogic.
"xjal" flags that this is code developed by the AnyLogic developers, i.e. it is neither standard Java code nor code from your model.
Nothing more and nothing less :)
I have heard people describe dynamic patching as a bit of a hack or at risk of breaking in future releases of Pd. This is reasonable enough, but it seems to imply that there are alternatives when building abstractions.
Dynamic patching seems to be useful for both instantiating a variable number of objects and connecting up to a variable number (a number defined at creation time - I personally don't need it to change after the fact, at this stage) of inlets and outlets within an abstraction.
Now I understand that the [clone] object can solve the problem of creating objects. I can see too that looping through send and receive objects would solve much of the connection issues with careful planning but what I do not understand is how objects like [trigger], [route] and [select] can be adjusted or replaced in some way? I fail to see how you would avoid using dynamic patching to, for example, create a [trigger f f] when the creation arg to your abstraction is 2, and a [trigger f f f] when the creation arg is 3. Again, the same with [route] and [select] and similar objects.
EDIT: The original question was perceived as too vague. I later posed a follow-up question in the comments which should really be here instead. As it happens, the answer to the follow-up provided a good answer to the original question, in my opinion. So to summarise and hopefully clarify, I was after a few "tools" to use when building abstractions so that I could limit my use of dynamic patching, if possible. These tools turned out to be:
using send and receive instead of inlets and outlets (although [initbang] can be used for creating inlets and outlets at instantiation).
using [clone]
chaining trigger, route and select objects using send and receive - for example, using [t b b] - [t b b] instead of [t b b b]. This means that the number of arguments in these objects can be defined at creation time with the help of [clone] for example. This is discussed in the Pd mailing list.
using [initbang] as indicated in the answer below.
After having attempted to build a drum machine with presets and an arbitrary number of tracks with my limited knowledge of dynamic patching techniques, I realised that there must be many ways of avoiding the problems I had when doing this, which were several! Of course, some things have to be done with dynamic patching and that's fine. It's just about creating manageable code.
This is really an answer to "follow-up question" in the comment¹, rather than the original question (which I consider too broad to be answered),
Is there a way to define an abstraction that has an argument that defines how many outlets the abstraction exposes?
Sure, just use $1 for that.
E.g. [gates 10] could create 10 outlets...
Presumably it could dynamically patch itself, but that doesn't seem like a good idea.
well, if you want an abstraction to have a dynamic API (that is: a variable number of inlets/outlets), then there is no way around dynamic patching.
Is this a good case for building your own external?
depends on what you actually want the external to do.
the iemguts library (disclaimer: of which I am the author) has everything in place to allow you to dynamically patch what you need.
Most important, there is [initbang], to create iolets before Pd tries to connect them (if you use [loadbang], the iolets will be created after Pd failed to connect to them).
It also includes a [canvasargs] object which allows you to get all the arguments to the abstraction (e.g. which simplifies the task of having the number of outlets equal the number of arguments - like [trigger] or [pack])
if instead you want to wrap the entire functionality of your abstraction into an external, that's of course also possible (and pretty simple in the realm of C).
Also keep in mind that other's might have already coded what you need.
¹ please don't abuse the comment field for follow-up questions. either update your original question (if the follow-up is a mere clarification of the original question) or post a new one.
I've just started my journey with REST, so please be patient while anserwing my questions.
I have some doubts how to cope with some situations. For instance, I read that evenry resource/entity should have its own, unique URL. But how to deal with examples like:
There is a list of objects.
Each object is described by some basic information and its state.
Basic info for object is for example its shape, color.
The state of object contains information like position in space, velocity etc.
Both two pieces of information (basic + state) are rather big objects (only examplary properties were introduced).
Now, we have the following questions:
Get all basic info about objects.
Get all object states.
Get basic info of object with ID=2.
Get state of object ID=5.
Get all info of object ID=7.
I tried to solve it in this way:
/rest/objects
/rest/states
/rest/objects/2/basic
/rest/objects/5/state (/rest/states/5)
/rest/objects/7
However, I've some doubts pointed in 4 - it doesn't look like to be correct. There are two ways to access the same information/resource/entity.
How to deal with it?
Isn't the "basic" just part of the resource? It seems not from your description, but you should consider it. In fact, all of "basic" and "state" might just be part of the resource. It's difficult to be authoritative without more information. For instance, how large is "rather big"?
It also doesn't seem like /state should be an independent endpoint, since a state is an integral part of an object, not something that lives on its own.
I might start with something like:
1. GET /objects
2. GET /objects?expand=state
3. GET /objects/2?expand=basic -- or -- GET /objects/2/basic
4. GET /objects/5?expand=state -- or -- GET /objects/5/state
5. GET /objects/7?expand=basic,state
If you need /state to be top level, then you have two options:
2. GET /states -- or -- GET /objects/states
Neither of those are really ideal. It is acceptable to have multiple paths to get to the same resource, as long as there's only one canonical URI for the resource. The issue is that it's harder for the end user to learn APIs that lean heavily on that style. The second style is also confusing. /objects/XXX is a specific object, unless XXX == states? That's a special case for your end user to have to remember.
From a caching point of view it makes sense to have "state" and "basic" in separate resources - "state" resources changes frequently and is thus non-cachable and "basic" changes seldom and should thus be cachable for a long time. If this is your goal, then go ahead, it sure makes sense (and is an often mentioned pattern). But usually, to keep complexity low, both sets of values are combined into one single resource (your "Object" in this case).
Your paths are pretty good, Eric's version is also fine - here is my suggestion:
/rest/objects (all complete objects info)
/rest/objects/basic (all basic info)
/rest/objects/state (all state info)
/rest/objects/7 (single complete object)
/rest/objects/2/basic (single basic info)
/rest/objects/5/state (single state info)
In the end it all boils down to a matter of personal preference as the exact URL doesn't matter much.
See for instance http://soabits.blogspot.dk/2013/10/url-structures-and-hyper-media-for-web.html for a longer discussion on this issue (disclaimer: that's my blog).
resource/entity
Don't confuse these concepts. REST has nothing to do how you store your data, and resources map to entities only by CRUD applications.
I read that evenry resource/entity should have its own, unique URL.
You should read the IRI standard. IRIs are for identifying resources. Without them you cannot tell the server what you want to manipulate.
However, I've some doubts pointed in 4 - it doesn't look like to be
correct. There are two ways to access the same
information/resource/entity.
How to deal with it?
It is up to you. You can choose either of them or both. There is no restriction about how many identifiers a resource can have or what IRI structure to choose.
I'm looking for an end to end example using dojo.store with dijit.Tree over REST.
There are many existing examples that use the older dojo api, dojo.data.api, but a dearth of ones using the dojo.store api.
Is the reason that dijit.Tree doesn't fully support dojo.store yet?
If so, do I need to use the dojo.data.ObjectStore wrapper to encapsulate dojo.store for use with dijit.tree?
I saw one example of working around this by extending StoreFileCache:
http://dojo-toolkit.33424.n3.nabble.com/New-object-store-and-dijit-Tree-td2680201.html
Is that the recommended option, or should I
a) stick to dojo.data.api until dijit.Tree supports dojo.store directly, or
b) use the dojo.data.ObjectStore wrapper
Thanks
There is now a tutorial on the DTK website that seems to cover pretty much exactly this topic.
http://staging.dojotoolkit.org/documentation/tutorials/1.6/store_driven_tree/
However, as I know linking to something without giving an answer is considered a poor practice, the general idea is that rather than using a dojo.data.ObjectStore to wrap around it and then potentially shoving it through a ForestStoreModel, you can simply augment your dojo.store-based store to add the methods that the Tree will look for. Here's a simple example from the tutorial:
usGov = new dojo.store.JsonRest({
target:"data/",
mayHaveChildren: function(object){
// see if it has a children property
return "children" in object;
},
getChildren: function(object, onComplete, onError){
// retrieve the full copy of the object
this.get(object.id).then(function(fullObject){
// copy to the original object so it has the children array as well.
object.children = fullObject.children;
// now that full object, we should have an array of children
onComplete(fullObject.children);
}, onError);
},
getRoot: function(onItem, onError){
// get the root object, we will do a get() and callback the result
this.get("root").then(onItem, onError);
},
getLabel: function(object){
// just get the name
return object.name;
}
});
It's worth noting that in this case, we're making some assumptions about what the data looks like. You'd need to know how your children relate and customize the methods below for that purpose, but it's hopefully fairly clear as to how to do that for yourself.
You can also just stick to dojo.data APIs for now, but this approach definitely feels more lightweight. It takes a couple of layers out of the stack and working with customizing a dojo.store-based store is much easier.
Given the two options you outlined, I'd say it's a matter of how well you know the different APIs.
dojo.store is more light-weight, and perhaps easier to understand, but the wrapper adds some overhead. If you think your project will live for a long time, this is probably the best way to go.
dojo.data is a legacy API, which will phased out eventually. If your project is short-lived, and only based on dijit.Tree, this might be your best option for now.
Personally, I'd go with dojo.store and write my own TreeStoreModel to get the best of both worlds. This approach is very similar to Brian's suggestion.
In case you're interested, I've written up a two-series post on how to use dijit.Tree with the ObjectStore wrapper, and implementing a JsonRest backend in PHP.
I have an extremely hard time figurering out how classes needs to communicate with eachother. In a current project I am doing, many classes have become so deeprooted that I have begun to make Singletons and static fields to get around(from what I get this is a bad idea).
Its hard to express my problem and its like other programmers dont have this problem.
Here is a image of a part of the program:
Class diagram
ex1. When I create a Destination object it needs information from Infopanel. How to do that without making a static getter in InfoPanel?
ex2. DestinationRouting is used in everybranch. Do I really have to make it in starter and then pass it down in all the branches?
Not sure if this makes sense to anybody :)
Its a problem that is reacurring in every project.
After looking at your class diagram, I think you are applying a procedural mind set to an OO problem. Your singletons appear to contain all of the behavior which operate on the records in your domain model and the records have very little behavior.
In order to get a better understanding of your object model, I'd try and categorize the relationships (lines) in your class diagram as one of "is-a", "has-a", etc. so that you can better see what you have.
Destination needs some information from InfoPanel, but not likely all information. Is it possible to pass only the needed information to Destination instead of InfoPanel?
What state is being captured in the DestinationRouting class that forces it to be a singleton? Does that information belong elsewhere?
There's just too little information here. For example, I am not even sure if MapPanel and InfoPanel should be the way they are. I'd be tempted to give the decorator pattern a try for what it's worth. I don't know why a Listener is a child of a Panel either. We need to know what these objects are and what system this is.