Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - daune_jf

Pages: [1]
1
Suggestions and Requests / Re: More 'usual' Java API
« on: January 29, 2008, 04:52:49 am »

Well, please, do not put words in my mouth. I have never suggested to 'build a new API from the ground up'.

I just suggest that wrapping of existing EA COM object model (i.e. native calls to SSJavaCOM.dll) could more Java-friendly.

That was the point of my example. There are only two little differences, not 'structural' at all: a) appropriate capitalization, b) use of Java built-in collections.

Those two 'little' improvements make a lot of differences to many Java tools.

So, to sum up, my suggestions is that EA keep their SSJavaCOM.dll, but slightly redesign wrapping classes.


2
Suggestions and Requests / Re: More 'usual' Java API
« on: January 28, 2008, 11:39:13 pm »
Having taken a look at Java API code, I really don't get it. Why a huge effort? Why should that have any impact on EA reliability?

Here is a sample of Package.java:

 public Collection<Diagram> GetDiagrams(){
   return comGetDiagrams(comObject);
 }

And how it could be improved:

 public Collection<Diagram> getDiagrams(){
   // CollectionWrapperUtils creates java.util.Collection
   return CollectionWrapperUtils.wrap(comGetDiagrams(comObject));
 }

Calling the method 'getDiagrams()' instead is one of the simplest refactoring. Modern IDEs handle such refactoring automatically.

I must be missing something. I guess the Java API is generated by some tool...

J-F

3
Suggestions and Requests / More 'usual' Java API
« on: January 24, 2008, 07:57:06 am »
Hi guys,

I am experimenting with Java API, and it is quite unusual in Java world.

Two examples:

1) You do not comply with JavaBeans naming convention (which requires getField() instead of GetField()). This prevents introspection.
2) You have implemented your own Collection.

One result: I cannot feed Velocity template engine with EA SDK classes (I try to export part of my model as XML)

Maybe you could change API before it is used by too many customers...

Best regards,

J-F

4
Uml Process / Re: Linking use case and sequence diagram
« on: January 23, 2008, 05:03:13 am »

I must have missed something...

If I create a diagram as a 'child' of a use case, and then drag it to a package, it is completely removed from the use case.

There is no remaining link.

5
Uml Process / Re: Linking use case and sequence diagram
« on: January 22, 2008, 05:17:39 am »

Mmmmhh. I see.

I must drag into my use case diagram each corresponding sequence diagrams, then delete them (to avoid a lot of references).

That's a pity there is no easier way.

I am surprised it is not possible to link elements to diagrams. It is very convenient.

Ideally, I would like to right-click on any element, and have a list of 'internal' hyperlink.

J-F

6
Uml Process / Re: Linking use case and sequence diagram
« on: January 22, 2008, 01:50:45 am »
How do you achieve this?

In the "Create Link" dialog, you can only choose an element as target.

Element of type "Sequence" are not sequence diagrams (a sequence diagram can contain one or more sequences)

7
Uml Process / Linking use case and sequence diagram
« on: January 22, 2008, 12:45:49 am »
Hi,

I would like to link sequence diagram to the use case that it 'realizes', but don't know how to do it.

I know I can put the sequence as a child of the use case, but we would like to keep all sequence diagrams in a same 'package'.

It seems only possible to link elements to elements, but not elements to diagrams. Am I right?

J-F

Pages: [1]