• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: how to obtain data and column names at client

 
Theo van Loon
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,
i'm having some trouble figuring this one out. First let me explain shortly what my design looks like. At least the part that has to be considered answering this question.
I have an interface DataEntrance implemented by two classes LocalDataEntrance and RemoteDataEntrance functioning as some sort of ClientFacade.
From these classes I can reach data through the interface given by Sun.
My Data class has a Helper class resposible for all I/O operations e.g. reading the header, column names, field lengths etc.
I need to have the data and the column names at the client side for filling the JTable, but the interface doesn't provide these methods.
Can anyone help me out on this? How I can make the data and information on field lengths, column names , etc. available throughout the application?
You would help me a lot !!
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Professor,
My goodness, what an unusual first name you have.
Originally posted by Professor Barabas:
How I can make the data and information on field lengths, column names , etc. available throughout the application?

What is preventing you from adding getFieldLengths, getColumnNames, etc. to the DataEntrance interface?
Hope this helps,
George
 
Theo van Loon
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by George Marinkovich:
Hi Professor,
My goodness, what an unusual first name you have.

I guess my parents already knew i was bound to end up trying to program in Java...

What is preventing you from adding getFieldLengths, getColumnNames, etc. to the DataEntrance interface?

Nothing, that's exactly what i'm trying to accomplish, but the DataEntrance can call the methods of the DBInterface given by Sun, but these methods aren't sufficient to get the fieldLengths etc.
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Professor,
Originally posted by Professor Barabas:

Nothing, that's exactly what i'm trying to accomplish, but the DataEntrance can call the methods of the DBInterface given by Sun, but these methods aren't sufficient to get the fieldLengths etc.

OK, what if you add these methods to the DataEntrance interface and implement them in the Data class (or at least make them accessible from the Data class even if implemented in a Data helper class)? Then wouldn't such a Data class in effect be an implementation of the DataEntrance class (containing the getFieldLengths and getColumnNames methods)? Certainly a particular class (in this case Data) can be an implementation of multiple interfaces, right?
Hope this helps,
George
[ February 04, 2004: Message edited by: George Marinkovich ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi PB,
Welcome to this forum!
I've unfortunately nothing to add to what George wrote above (as so often when coming after that guy BTW ), except that you should check our Naming Policy and change your displayed name accordingly. You can do it here. Thank you.
Regards,
Phil.
[ February 04, 2004: Message edited by: Philippe Maquet ]
 
Theo van Loon
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by George Marinkovich:
Hi Professor,

OK, what if you add these methods to the DataEntrance interface and implement them in the Data class (or at least make them accessible from the Data class even if implemented in a Data helper class)? Then wouldn't such a Data class in effect be an implementation of the DataEntrance class (containing the getFieldLengths and getColumnNames methods)? Certainly a particular class (in this case Data) can be an implementation of multiple interfaces, right?
Hope this helps,
George
[ February 04, 2004: Message edited by: George Marinkovich ]

Ok the Professor now officially changed his name
Let me visualize what my intention was:
CLient - DataEntrance - DBAccess - Data - dbfile
(Remote / Local) (Sun's interface)
In the DataEntrance class I access the Data class through the DBAccess interface, so that's why adding the getFields and getColumnNames to my Data class won't have any effect.
Do I have to rethink my design or are there other solutions?
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Theo van Loon:
Let me visualize what my intention was:
CLient - DataEntrance - DBAccess - Data - dbfile
(Remote / Local) (Sun's interface)
In the DataEntrance class I access the Data class through the DBAccess interface, so that's why adding the getFields and getColumnNames to my Data class won't have any effect.
Do I have to rethink my design or are there other solutions?

I think you could do the following:

So, Data still implements DBAccess which is required by the assignment instructions, yet Data implicitly implements DataEntrance as well.
Hope this helps,
George
 
Theo van Loon
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

So, Data still implements DBAccess which is required by the assignment instructions, yet Data implicitly implements DataEntrance as well.
Hope this helps,
George[/qb]<hr></blockquote>
Hi George,
i'm getting there but one thing confuses me. At client side this leaves me with one way to give the client the possibilty to call these methods and that's passing a reference to the Data class.
At first i did this by passing Data in the form of DBAccess so a user could only call the DBAccess methods.
Am i not giving a client too much freedom by passing the Data directly?
[ February 05, 2004: Message edited by: Theo van Loon ]
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Theo van Loon:
[QBAt first i did this by passing Data in the form of DBAccess so a user could only call the DBAccess methods.
[/QB]

How about passing Data in the form of DataEntrance so a user can only call the DataEntrance methods (which I assume are a superset of the DBAccess methods)?
Hope this helps,
George
 
Theo van Loon
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by George Marinkovich:

How about passing Data in the form of DataEntrance so a user can only call the DataEntrance methods (which I assume are a superset of the DBAccess methods)?


You mean my DataEntrance extends the DBAccess and adds the getData, etc.?
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Theo van Loon:

You mean my DataEntrance extends the DBAccess and adds the getData, etc.?

Yes, having DataEntrance explicitly extend DBAccess would be ideal. There may be reasons (involving perhaps your network communications solution) why this is not possible. If so, then it could be possible for DataEntrance to in effect extend DBAccess. By in effect, I mean that DataEntrance would support the same database operations as DBAccess (plus any additional database operations desired), and also that Data could be instantiated as an object of DBAccess or as an object of DataEntrance.
Hope this helps,
George
 
Theo van Loon
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks George, i'm giving it a shot!!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic