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

["Julian Feinauer (JIRA)" <ji...@apache.org>]

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

Julian Feinauer commented on PLC4X-113:
---------------------------------------

[~splatch], [~Mathi_LTAZ] adressing that to you, as you where the most active ones on this discussion.
I just had another thought about that and what do you think of just using a Structure similar to what JSON Parising libs (like Jackson) use for their Node tree.
Generally we should be somewhat fine if we support all what JSON supports, or?
Something like a "CallNode" or so could always be added, if we want to support something like that, or?
See here: https://access.redhat.com/webassets/avalon/d/red-hat-jboss-enterprise-application-platform/7.0.0/javadocs/com/fasterxml/jackson/databind/node/BaseJsonNode.html
for the base description of how Jackson does it.

> 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
(v7.6.3#76005)