You are not logged in.

API ease for constructing consolidations

Dear visitor, welcome to Palo Community Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Qudus

Trainee

  • "Qudus" is male
  • "Qudus" started this thread

Posts: 2

Date of registration: Mar 1st 2007

Location: Cologne

  • Send private message

1

Thursday, March 1st 2007, 5:11pm

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

arnd

Master

Posts: 73

Date of registration: Sep 6th 2006

  • Send private message

2

Friday, March 2nd 2007, 12:35pm

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

Qudus

Trainee

  • "Qudus" is male
  • "Qudus" started this thread

Posts: 2

Date of registration: Mar 1st 2007

Location: Cologne

  • Send private message

3

Tuesday, March 6th 2007, 4:40pm

RE: API ease for constructing consolidations

Hi arnd,

Thanks for your reply.

Quoted

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
2
3
4
5
6
7
8

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


Quoted

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
2

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


Marvin
Rate this thread