> On Feb 19, 2018, at 9:52 AM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
> 
> Hi Dale,
> 
> well regarding your suggestion ... well an address is sort of just the 
> starting point, you still need a type and size to fully qualify a request.
> And another thing is, if we did it this way the information address, type and 
> size would be duplicated a huge amount of time and would have to be cleaned 
> up.
> Next is that this way we would have to parse each address every time. 
> 
> The way we currently have it, we prepare the request once and then it's 
> re-used for every following read operation.

I’m willing to believe I might not be thinking hard enough :-)  I’m also 
willing to believe the annotation scheme may be nicer but I’ll have to see the 
response on that thread regarding response code access as well as details of 
the using these annotated classes with the API to make requests and access 
items in responses.


More to your questions/observations on this suggestion...

The example does show a (implicit) size=1 and a size>=1 based ctor.
The example does show creating a request once and reusing it.

> I do guess we could make "address" use an Address object instead of a String 
> to reduce the amount of work for every request.

If you mean PlcDataItem have an Address instead of String, there’s a gotcha.  
In my example a PlcDataItem is protocol independent.  You can create and use 
them outside of the context of a PlcConnection. That’s convenient.  It strikes 
me that PlcDataItem almost just a different representation of your annotation 
scheme/info.

Where / when will the annotation info get turned into a collection of items / 
requests and how will that avoid redundant work, etc?  (lets follow up on that 
in the other annotation thread :-)

I’m still unclear on the benefits/needs of separate request vs response item 
types.  Same for separate read vs write item types.

I’m not sure a ResponseItem having an associated RequestItem is valuable for 
the *user* of the API.  Do they really want/need that object association?  With 
the request builder they may never have directly created a RequestItem - is it 
just noise to them?  Do they just want ResponseItem accessors that give them 
the info directly - e.g., get{Address,Type,Size}()? (the protocol impl could 
have a ResponseItemImpl that has an associated RequestItem and just returns the 
info from it).

If something like PlcDataItem could replace the 6 
[{Read,Write}]{Request,Response}Item classes there would be less surface area 
to the API and a simplified class hierarchy too :-)

> But I'm not 100% locked into keeping it this way ... so all others ... your 
> opinion is required here ;-)
same here

> 
> Chris
> 
> 
> 
> Am 19.02.18, 15:30 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
> 
>    Hmm… looks like this never really got sent by by my system :-(
>    Sending it again and then follow up on Chris’s recent mail on this topic.
>    — Dale
> 
>> On Feb 5, 2018, at 6:03 PM, Dale LaBossiere <dml.apa...@gmail.com> wrote:
>> 
>> 
>>> On Feb 5, 2018, at 5:43 AM, Christofer Dutz <christofer.d...@c-ware.de> 
>>> wrote:
>>> ...
>>> I was also thinking about how we could make this easier. I think this is 
>>> also a general problem we probably have solve in the "normal API" too.
>>> 
>>> While working on some Jackson Yaml parsing code, I thought that it might be 
>>> an option to create Pojo classes with properties, that are annotated with 
>>> PlcAnnotations that provide the Addresses in the PLC. The downside of this 
>>> approach would be that this way the address string is hard-coded inside the 
>>> program.
>>> 
>>> An Alternative would be to have an additional annotation with a property 
>>> name. Then we could provide the type as well as a "Propteries" object that 
>>> is passed to the API.
>>> 
>>> @PlcAnnotation("INPUTS/1.0")
>>> private byte myProperty;
>>> 
>>> or 
>>> 
>>> @PlcAnnotation("some.property.id")
>>> private byte myProperty;
>>> 
>>> Then the adapters could extract the name and the addresses from the pojo 
>>> class itself and hereby greatly reduce the code needed to create a request.
>>> 
>>> What do you think?
>> 
>> I don’t have experience with defining annotations/processors or java code 
>> generators so bear with me :-)
>> Maybe you could flesh out a simple batch usage example involving a couple of 
>> types to clarify the overall story, including response code access, etc.
>> 
>> I would *guess* that “hardcoding” a data-item’s address in the application 
>> wouldn't be an issue.  It would be a problem if one was trying to build an 
>> interactive application that probed/read items as described by user commands 
>> (e.g.,  “read byte INPUTS/1.0”) :-)
>> 
>> 
>> Based on a couple of hours perusing the latest API, I think a user would 
>> really like the ability to easily use a more type specific 
>> batch-of-hetero-data-items class.  Here’s a thought exercise — that doesn’t 
>> involve annotations.  You may have already gone through this sort of 
>> exercise.  Sorry if that’s the case.
>> 
>> Does the user really want/need separate request vs response item types?  
>> Can’t an item just be an: Address, Value, ResponseCode?
>> Not clear to me there’s a need for separate read vs write items.
>> 
>> class PlcDataItem<T> {   // not an existing plc class.
>>      ...
>>      public String getAddress() { … } 
>>      public T getValue() { …}  // throw if code != OK?, or return null?
>>      public void setValue(T value) { …}
>>      public ResponseCode getCode() {…}
>>      public void setCode(ResponseCode) {…}
>> }
>> 
>> // Define a my batch of data items
>> class MyBatch {
>>      private final PlcDataItem<Byte> fooItem = new 
>> PlcDataItem<>(“INPUTS/1.0”);
>>      private final PlcDataItem<Float[]> barItem = new 
>> PlcDataItem<>(“INPUTS/2.0”, 3/*count*/);
>> 
>>      PlcDataItem<Byte> getFooItem() { return fooItem; }  // comple time 
>> typesafe
>>      PlcDataItem<Float[]> getBarItem() { return barItem; }
>> }
>> 
>> PlcConnector connector = …
>> 
>> // only need to do this once.  introspects MyBatch to get data item info
>> PlcBatchReadRequest<MyBatch> readRequest = 
>> PlcReadRequestFactory.newBatchReadRequest(connector, MyBatch.class);
>> 
>> while (true) {
>>      PlcBatchReadResponse<MyBatch> readResponse = 
>> connector.getReader().readBatch(readRequest).get();
>> 
>>      MyBatch myBatch = PlcReadResponseFactory.fillDataObject(readResponse, 
>> new MyBatch());  // compile time typesafe
>>      // or if you prefer: MyBatch myBatch = readResponse.getBatch();
>> 
>>      System.out.println("batch: " + myBatch);
>> 
>>      // do typesafe access of the data items with named accessors
>> 
>>      if (myBatch.getFooItem().getCode() == ResponseCode.OK) {
>>              Byte value = myBatch.getFooItem().getValue();  // comple time 
>> typesafe
>>              System.out.println("foo: " + value);
>>      } else {
>>              ...
>>      }
>> 
>>      JsonObject jo = gson.toJson(myBatch);
>>      System.out.println("json: " + jo);
>> 
>>      sleep(1000);
>> }
>> 
> 
> 
> 

Reply via email to