Easier: AddObject, AddVariable, AddProperty and AddFolder about freeopcua HOT 8 CLOSED

Is there any particular reason why there is no function with the
following prototype:

Node Node::AddFolder(const std::string& name) const

In fact there was such methods. But we removed them to force users to think
correctly. Namespaces are importants so before creating nodes you should
always start by getting your namespace index or registering a new one. Then
use this index in all node creations.

In addition there were many places were inheriting namespace was directly
wrong don't remember where.

from freeopcua.

Hi all.

Folder is an object. Node is a common thing.

It is wrong to add method AddFolder to node. With node you should be able
only manipulate attributes and add other subnodes.

It is better something like this:
Create class FolderType inherited from ObjectType and initialize it with
some NodeID folder type. And also required class Folder which is inherited
from Object class. Folder class can be initialized with either NodeID or
FolderType..
Add method AddFolder to Server and to Folder classes.

Folder classes hierarchy should have folder behavior. :)

2015-01-11 9:57 GMT+03:00 oroulet [email protected]:

Is there any particular reason why there is no function with the
following prototype:

Node Node::AddFolder(const std::string& name) const

In fact there was such methods. But we removed them to force users to think
correctly. Namespaces are importants so before creating nodes you should
always start by getting your namespace index or registering a new one. Then
use this index in all node creations.

In addition there were many places were inheriting namespace was directly
wrong don't remember where.

—
Reply to this email directly or view it on GitHub
#110 (comment).

Best regards,
Alexander Rykovanov.

from freeopcua.

Hi all.

Nice to see that you're back :-)

Folder is an object. Node is a common thing.

Things are not that simple. opcua defines a folder type. it also defines a
variable types, but then you have properties but properties are of variable
type with a reference of type property. In fact you can create crazy things
like a node of type folder which is linked to its parent as a property or
component and create custom links....

It is wrong to add method AddFolder to node. With node you should be able
only manipulate attributes and add other subnodes.

At the beginning I thought about create FolderNode, VariableNode, ...
classes but then found out that those objects were just the common ones and
many other types were possible, so I just created a Node class with a few
helper methods (CreateFolder, CreateObjects, etc...).

I saw that you created ServerNodes, VariableNodes, but I think it would
just make things more complicated to expose those. I am now quite sure that
a Node object is sufficient and more flexible. If you really want them ,
they should at least inherit from Node. No need to duplicate code.

But maybe the methods AddFolder, AddVariable, etc should not be part of the
Node class at all, maybe they should be part of the Server or Client
objects og maybe just member functions of OpcUa namespace

It is better something like this:
Create class FolderType inherited from ObjectType and initialize it with
some NodeID folder type. And also required class Folder which is inherited
from Object class. Folder class can be initialized with either NodeID or
FolderType..
Add method AddFolder to Server and to Folder classes.

Folder classes hierarchy should have folder behavior. :)

2015-01-11 9:57 GMT+03:00 oroulet [email protected]:

Is there any particular reason why there is no function with the
following prototype:

Node Node::AddFolder(const std::string& name) const

In fact there was such methods. But we removed them to force users to
think
correctly. Namespaces are importants so before creating nodes you should
always start by getting your namespace index or registering a new one.
Then
use this index in all node creations.

In addition there were many places were inheriting namespace was
directly
wrong don't remember where.

—
Reply to this email directly or view it on GitHub
#110 (comment).

Best regards,
Alexander Rykovanov.

—
Reply to this email directly or view it on GitHub
#110 (comment).

from freeopcua.

One more argument agains having specialized classes for folder, objects etc
is that it creates many issues.
for example when browsing we get a list of nodeids, unless we create a
filter,we know these are Nodes, but we have no ideas if they are folders,
variables, etc. to find out we need to do more network queries (performance
issue), or only return Node objects, but then users will need to
cast/instanciate specialized objects. Same problem for almost any query to
address space.

So my conclusion was that having specialized classes was both unnecessary
and would raise many issues with no good solutions.

It is better something like this:
Create class FolderType inherited from ObjectType and initialize it with
some NodeID folder type. And also required class Folder which is inherited
from Object class. Folder class can be initialized with either NodeID or
FolderType..
Add method AddFolder to Server and to Folder classes.

Folder classes hierarchy should have folder behavior. :)

2015-01-11 9:57 GMT+03:00 oroulet [email protected]:

Is there any particular reason why there is no function with the
following prototype:

Node Node::AddFolder(const std::string& name) const

In fact there was such methods. But we removed them to force users to
think
correctly. Namespaces are importants so before creating nodes you should
always start by getting your namespace index or registering a new one.
Then
use this index in all node creations.

In addition there were many places were inheriting namespace was
directly
wrong don't remember where.

—
Reply to this email directly or view it on GitHub
#110 (comment).

Best regards,
Alexander Rykovanov.

—
Reply to this email directly or view it on GitHub
#110 (comment).

from freeopcua.

Yes, I am reading you. :)

Well, this a subject for discussion... :)
If you are implementing a lamp controlling it is better to have a class
Lamp which will hide lamp details and nodes manipulating. From outside it
will be still a set of nodes and attributes. :)
When you will implement for example a Room you will have corresponding
class several vectors with lamps, switches etc. From outside it will be
still a set of nodes and attributes.

Folder has: node class - Object, Reference - HasType->FolderTypeID. Class
Folder can hide and maintain all this details automatically.

But in python may be reasonable to export only Node class and implement
required classes in python...

for example when browsing we get a list of nodeids, unless we create a
filter,we know these are Nodes, but we have no ideas if they are folders,
variables, etc. to find out we need to do more network queries

I agree that for such things is better to manipulate nodes.
Specialized classes should be developed to have as little queries as
possible.
They just for convenience when implementing some model.
For python may be reasonable to export only node class and implement
required classes with python.

2015-01-11 13:34 GMT+03:00 oroulet [email protected]:

One more argument agains having specialized classes for folder, objects
etc
is that it creates many issues.
for example when browsing we get a list of nodeids, unless we create a
filter,we know these are Nodes, but we have no ideas if they are folders,
variables, etc. to find out we need to do more network queries
(performance
issue), or only return Node objects, but then users will need to
cast/instanciate specialized objects. Same problem for almost any query to
address space.

So my conclusion was that having specialized classes was both unnecessary
and would raise many issues with no good solutions.

It is better something like this:
Create class FolderType inherited from ObjectType and initialize it with
some NodeID folder type. And also required class Folder which is
inherited
from Object class. Folder class can be initialized with either NodeID or
FolderType..
Add method AddFolder to Server and to Folder classes.

Folder classes hierarchy should have folder behavior. :)

2015-01-11 9:57 GMT+03:00 oroulet [email protected]:

Is there any particular reason why there is no function with the
following prototype:

Node Node::AddFolder(const std::string& name) const

In fact there was such methods. But we removed them to force users to
think
correctly. Namespaces are importants so before creating nodes you
should
always start by getting your namespace index or registering a new one.
Then
use this index in all node creations.

In addition there were many places were inheriting namespace was
directly
wrong don't remember where.

—
Reply to this email directly or view it on GitHub
<
https://github.com/FreeOpcUa/freeopcua/issues/110#issuecomment-69485747>.

Best regards,
Alexander Rykovanov.

—
Reply to this email directly or view it on GitHub
#110 (comment).

—
Reply to this email directly or view it on GitHub
#110 (comment).

Best regards,
Alexander Rykovanov.

from freeopcua.

In addition there were many places were inheriting namespace was directly wrong don't remember where.

The "Objects" folder is in namespace 0. But everything the user adds to this folder must be in a different namespace as only standard-defined nodes can be in namespace 0.

from freeopcua.

Well, this a subject for discussion... :)
If you are implementing a lamp controlling it is better to have a class
Lamp which will hide lamp details and nodes manipulating.

I completely agree, I am just saying that at our level there are so little
difference form a folder to a variable, and so many possible objects, that
we should handle everything as Node and let users implements the
specialized classes

from freeopcua.

I think this can be also closed... If not we can reopen it...

from freeopcua.