More Handlers

[ayushsingh01042003]

Description

• EDDGridSideBySideHandler
• EDDTableAggregateRowsHandler
• EDDTableCopyHandler
• EDDTableFromCassandraHandler
• EDDTableFromDapSequenceHandler
• EDDTableFromDatabaseHandler
• EDDTableFromAsciiServiceHandler

[7yl4r]

Looks good to me. Two thoughts:

1. would a map be more readable than a switch statement for the mapping of handler dataset type strings to handlers in the HandlerFactory?
2. anything we can do about the duplicated variables in each handler? eg:

  private ArrayList tDataVariables = new ArrayList();
  private int tReloadEveryNMinutes = Integer.MAX_VALUE;
  private String tAccessibleTo = null;
  private String tGraphsAccessibleTo = null;
  private StringArray tOnChange = new StringArray();
  private String tFgdcFile = null;

solutions to (2) might get into things better left alone like multiple inheritance or an entity-component pattern.

[ChrisJohnNOAA]

Looks good to me. Two thoughts:

1. would a map be more readable than a switch statement for the mapping of handler dataset type strings to handlers in the HandlerFactory?
2. anything we can do about the duplicated variables in each handler? eg:

  private ArrayList tDataVariables = new ArrayList();
  private int tReloadEveryNMinutes = Integer.MAX_VALUE;
  private String tAccessibleTo = null;
  private String tGraphsAccessibleTo = null;
  private StringArray tOnChange = new StringArray();
  private String tFgdcFile = null;

solutions to (2) might get into things better left alone like multiple inheritance or an entity-component pattern.

There are definitely possible solutions to 2, but I'm not sure they're worth doing at this time. It's a lot of boilerplate with the current approach, but the solutions to remove the duplication would make the code much more complicated. With the current approach it's 1 line to declare the variable and 1 line to do the parsing.

My first thought on how to reduce the duplication is a configurable class that would require you to specify each variable and it's type (which covers parsing approach and what type to store it as) for the dataset. Then have that handle the parsing, but it would either need to handle every variable or we'd still need some logic for datasets that have special/non-standard variables (like child datasets). I also don't know if this would be significantly less code overall (because configuring the parser would be close to the current amount of code).

[ChrisJohnNOAA]

Mainly comments on better typing which should allow us to avoid some of the loops.

[ChrisJohnNOAA]

If you make the tChildDatasets of type ArrayList<EDDGrid>, you should be able to just use tChildDatasets.toArray() instead of a for loop here.

[ChrisJohnNOAA]

If you make the tChildDatasets of type ArrayList<EDDTable>, you should be able to just use tChildDatasets.toArray() instead of a for loop here.

[ChrisJohnNOAA]

Similar to the above, you should be able to declare tDataVariables as ArrayList<Object[]> and then use tDataVariables.toArray() instead of the loop. (This also applies to the previous datasets that have data variables and axis variables.)

[ChrisJohnNOAA]

Same for this loop.

[ChrisJohnNOAA]

and another instance

[ChrisJohnNOAA]

Mainly comments on better typing which should allow us to avoid some of the loops.

The toArray method returns an Object[], not the specific type. There are a few ways to get a typed array (without a loop).

https://www.geeksforgeeks.org/arraylist-array-conversion-java-toarray-methods/

The best approach is probably their method 2, which looks like:

EDDGrid[] arr = new EDDGrid[tChildDatasets.size()];
arr = tChildDatasets.toArray(arr);

[ayushsingh01042003]

Pushed the changes