[jira] [Comment Edited] (PLC4X-113) Implement support for complex field types in the PLC4X API

["Alessandro Rossignoli (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PLC4X-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118171#comment-17118171 ] 

Alessandro Rossignoli edited comment on PLC4X-113 at 5/27/20, 11:58 PM:
------------------------------------------------------------------------

Sorry for my silly question: you mentioned that  "lists (arrays) as first class "ciitzens" ", but how is it possible to read arrays with OPC UA? I couldn't find any docs.

I would also like to contribute on this, given enough time to get into the project, as right now I am just a user of the library.


was (Author: itaross):
Sorry for my silly question: you mentioned that  "lists (arrays) as first class "ciitzens" ", but how is it possible to read arrays with OPC UA? I could find any docs.

I would also like to contribute on this, given enough time to get into the project, as right now I am just a user of the library.

> Implement support for complex field types in the PLC4X API
> ----------------------------------------------------------
>
>                 Key: PLC4X-113
>                 URL: https://issues.apache.org/jira/browse/PLC4X-113
>             Project: Apache PLC4X
>          Issue Type: New Feature
>          Components: API
>            Reporter: Julian Feinauer
>            Priority: Critical
>
> *This is a (possibly) incompatible change.*
> Currently we have support for primitives as well as lists (arrays) as first class "ciitzens" of the PLC4X model.
> Especially, when thinking about OPC UA, but also other protocols like ADS (and even S7) support complex objects in their programming model.
> Thus, it is necessary to refactor / extend the API to support these complex objects.
> I guess we need at least
> * primitives
> * lists
> * maps (should be equal to "structs")
> Basically, this should be roughly equivalent to what one can represent with JSON.
> Thus, the API could be structured i two ways.. first, we could use an internal Node Tree to represent the objects, but we could also provide to use someone elses NodeTree or structure to represent the Objects.
> For example Jackson.. this would even allow us to directly map these objects to POJOs via Jackson.
> As example for such a model, one can look at that of Apache Calcite: https://github.com/apache/calcite/blob/3fa29455664bec0056c436491b369e0cd72242ea/core/src/main/java/org/apache/calcite/rel/type/RelDataType.java
> They have an interface with methods
> {code:java}
> public interface DataType
> {
>     // Checker
>     boolean isMap();
>     boolean isList();
>     boolean isPrimitive();
>     // Getter for complex types
>     DataType get(String key);
>     DataType get(Long i);
>     
>     // Primitive getters
>     long getLong();
>     String getString();
>     //...
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)