API ease for constructing consolidations

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • API ease for constructing consolidations

      Hi

      I had a look at the latest JPalo version with Palo 1.5.

      It's a really nice API. But there are a few things, that should be easier.

      One example is the way to construct consolidations on a dimension. First the updateConsolidations() method should be overloaded to take a java.util.List (instead of an array). This would be a lot easier to handle. And there should be a method to retrieve a specific consolidation from a dimension instance and from the parent element (two separate methods for the same thing).

      But it would be much easier, if the updateConsolidation() method would just be removed from the API. It should not be necessary in this form. If I add a consolidation to a dimension (there should be an appropriate method on the Element class, too), if could be stored internally and when I'm ready with the dimension structure a simple (parameterless) call to updateConsolidations() or updateDimension() would be sufficient to commit the modified structure. This would also guarantee the most efficient handling of this task.

      Are there any plans to change this?


      btw. Why isn't the getElement() method not simply overloaded? There are two methods getElement() and getelementByName(), which could be both named getElement() (one for int and one for String).

      Marvin
    • RE: API ease for constructing consolidations

      Hi Marvin,

      thank you for your remarks regarding the jpalo api.
      In fact the handling of consolidated elements is a little bit awkward and we may change that in the 2.0 version of the api. So we will come back to your suggestions then... Overloading the updateConsolidation() method is not a big thing, neither it is to call it with '(Consolidation[])list.toArray(new Consolidation[0])' as parameter ;)

      Regarding the Dimension#getElement(int) method:
      actually this method is called getElementAt(int). And in this sense we thought that dimension.getElementAt(index) or dimension.getElementByName(nextElName) is better to read within source code than e.g. dimension.getElement(index) or dimension.getElement(name). Of course this is personal style and flavour. (And personally I like the overloading stuff more, but pssst ;) )

      Once again, thank you for your valuable comments.


      Regards,

      arnd
    • RE: API ease for constructing consolidations

      Hi arnd,

      Thanks for your reply.

      Originally posted by arnd
      In fact the handling of consolidated elements is a little bit awkward and we may change that in the 2.0 version of the api. So we will come back to your suggestions then... Overloading the updateConsolidation() method is not a big thing, neither it is to call it with '(Consolidation[])list.toArray(new Consolidation[0])' as parameter ;)


      Well, this call might be ok, but it is certainly not very convenient. And at least it is not the most efficient way.

      Referring to the fact, that the current API only takes arrays, this would be faster (but of course also not very convenient ;) :(

      Source Code

      1. public void addConsolidation(Element elem, Consolidation cons)
      2. {
      3. Consolidation[] consolis = elem.getConsolidations();
      4. Consolidation[] consPlusOne = new Consolidations[ consolis.length + 1 ];
      5. System.arrayCopy( consolis, 0, consPlusOne, 0, consolis.length );
      6. consPlusOne[ consolis.length ] = cons;
      7. elem.updateConsolidations( consolis );
      8. }


      Originally posted by arnd
      Regarding the Dimension#getElement(int) method:
      actually this method is called getElementAt(int). And in this sense we thought that dimension.getElementAt(index) or dimension.getElementByName(nextElName) is better to read within source code than e.g. dimension.getElement(index) or dimension.getElement(name). Of course this is personal style and flavour. (And personally I like the overloading stuff more, but pssst ;) )


      Overloading is simply the Java way ;)
      And if you choose your variables names that the type is indicated, the overloaded call will be as well readable.

      Source Code

      1. dimension.getElement( name ); // 'name' will never be expected to contain an int
      2. dimension.getElement( index ); // 'index' will never be expected to contain a String


      Marvin