Account Info Detail Replacement

Hello everyone,

I've been trying to finish up the Account Information
plug-in, but I've 
had a problem with the actual updating process. I talked
with Yana about 
it a bit and I think we'd need to make a change to details
in general, 
so I was hoping for some thoughts.

The way it works now, the
OperationSetServerStoredAccountInfo has a 
replace method that takes two details: the old one and the
new one that 
is replacing it. The problem is that both of these details
need to be of 
the same type. The way we display all of these details takes
into 
account certain special details that have unusual detail
values, for 
instance, a Calendar. Besides that, regardless if it's an
InterestDetail 
or an ObscureHobbyDetail, the detail value is just a string,
so we stick 
it into a text area.

That level of blindness works out fine until we go to
replace the 
details. To retrieve the available details there is the
method 
getAllAvailableDetails, but it returns an iterator that we
can only get 
objects from. The best we can do right now is cast to a
GenericDetail, 
but without knowing exactly what we need, there's always an
error when 
trying to replace because the detail types do not match.

So if anyone has any suggestions for how to get around this
problem, I 
would very much appreciate it. Thank you very much!

Adam

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Adam,
See inline:

On 8/20/07, Adam Goldstein <abgoldsteingmail.com> wrote:
> Hello everyone,
>
> I've been trying to finish up the Account Information
plug-in, but I've
> had a problem with the actual updating process. I
talked with Yana about
> it a bit and I think we'd need to make a change to
details in general,
> so I was hoping for some thoughts.
>
> The way it works now, the
OperationSetServerStoredAccountInfo has a
> replace method that takes two details: the old one and
the new one that
> is replacing it. The problem is that both of these
details need to be of
> the same type. The way we display all of these details
takes into
> account certain special details that have unusual
detail values, for
> instance, a Calendar. Besides that, regardless if it's
an InterestDetail
> or an ObscureHobbyDetail, the detail value is just a
string, so we stick
> it into a text area.
>
> That level of blindness works out fine until we go to
replace the
> details. To retrieve the available details there is the
method
> getAllAvailableDetails, but it returns an iterator that
we can only get
> objects from. The best we can do right now is cast to a
GenericDetail,
> but without knowing exactly what we need, there's
always an error when
> trying to replace because the detail types do not
match.

I'm no expert in the area, but I think you might hack a
solution to it
by using reflection (see
http://java.sun.com/j2se/1.4.2/doc
s/api/java/lang/reflect/package-summary.html
for more info). This way you could determine at runtime the
class of
each detail and cast the object returned by the iterator
appropriately.
I'd like to hear more from you if you decide to go this way,
or if
what i'm saying is a total mess 

> So if anyone has any suggestions for how to get around
this problem, I
> would very much appreciate it. Thank you very much!
>
> Adam

All the best,
Mihai

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Adam,

In two words: add fromString() to GenericDetail and its
children  
(most of the functions should be trivial.. I hope

The rest of the mail discusses this solution and some issues
related  
to it.

****************



I also agree that reflection may not be the best solution in
this  
case. I mean it's doable, but would require some implicit
conventions  
to be defined (like always having a constructor with some
fixed  
parameters).
I'm not the designer of the service, so I can't tell you
what was the  
intended usage, but I think that using a factory can be a
good idea.

One (simple) solution could be to define a non-static method
 
"GenericDetail fromString(String value)" to the
parent class of all  
details (GenericDetail). Currently, when you don't know what
to do  
with a given type of detail (like the ObscureHobbyDetail you
mention)  
you do a toString() and put the result into a text field. If
the user  
changes the contents of the text field you can simply say  
hobby.fromString(textField.getText()) which would return you
a  
GenericDetail object, which you can then pass on to the
replace method.

The disadvantages: such method must be added to
GenericDetail and all  
inheriting classes that need some special parsing of the
string (if  
the "replace" function is not clever enough this
may require that ALL  
inheriting classes should override this function.. ouch).
Another  
potential problem is that there might be some details that
cannot be  
parsed easily from strings, BUT I think that they should be
addressed  
with special controls anyway, so this is less of a problem.
In order  
to allow some kind of general treatment of all details one
may add a  
method like "isFromStringEnabled" which would
indicate if the  
fromString method actually works, or just throws an
exception like  
UnsupportedOperationException. This way, you as a GUI
implementor,  
would know to put the given detail in a read-only text
field.


Why this should work:
The nice thing is that when an object provides a toString
method it  
does not simply generate a random string (in the common
case) -  
instead it builds up a string representation of its data. A
Calendar  
object may (depending on its locale) return something like 

"01-02-2005". It is not meaningless to suppose
that in some cases it  
will be able to extract some information from a given string
(if the  
user changes the date in the previous example to
"10-10-2006" the  
calendar might be clever enough to understand the new
value). This is  
exactly what the fromString method should do - create a new 

CalendarDetail object and put in the correct data. If it
fails (like  
the user has filled in something like "I love SIP
communicator, can I  
get a cookie?") it might just throw an exception
(something like  
java's IllegalFormatConversionException) thus indicating you
to  
inform the user, that they won't get a cookie unless they
fill in a  
date in the correct format.


This is a very big subject, and one can do tons of stuff
making it as  
flexible (and complex) as possible.

What do you think about this?
Alex




Le 21 août 07 à 08:00, Adam Goldstein a écrit :

> Hey Mihai, everyone,
>
> Thanks for the recommendation. I hadn't heard of the
reflection  
> class before, but it does seem like it might be able to
provide a  
> pretty good solution to the problem I've been having.
Even though  
> it would fix what's going on now, it seems like it
might be  
> worthwhile to actually change the way the details
themselves work  
> so there's a more robust solution that might prevent
more hassle in  
> the future. Your idea is definitely better than my
original which  
> was to put some really long block of conditionals and
instanceof's  
> and some sort of mess like that.
>
> Yana and I were talking a bit about it and it would be
nice if  
> there were some sort of detail factory that could give
us all of  
> the proper types so we can use them, but I don't know
how  
> complicated that would be to actually make. I'd be
happy to try to  
> do it or to help do it if that seems like the best
answer to this  
> though. Does that seem like the way to go?
>
> Adam
>
> Mihai Balan wrote:
>> Hi Adam, See inline: On 8/20/07, Adam Goldstein  
>> <abgoldsteingmail.com> wrote:
>>> Hello everyone, I've been trying to finish up
the Account  
>>> Information plug-in, but I've had a problem
with the actual  
>>> updating process. I talked with Yana about it a
bit and I think  
>>> we'd need to make a change to details in
general, so I was hoping  
>>> for some thoughts. The way it works now, the  
>>> OperationSetServerStoredAccountInfo has a
replace method that  
>>> takes two details: the old one and the new one
that is replacing  
>>> it. The problem is that both of these details
need to be of the  
>>> same type. The way we display all of these
details takes into  
>>> account certain special details that have
unusual detail values,  
>>> for instance, a Calendar. Besides that,
regardless if it's an  
>>> InterestDetail or an ObscureHobbyDetail, the
detail value is just  
>>> a string, so we stick it into a text area. That
level of  
>>> blindness works out fine until we go to replace
the details. To  
>>> retrieve the available details there is the
method  
>>> getAllAvailableDetails, but it returns an
iterator that we can  
>>> only get objects from. The best we can do right
now is cast to a  
>>> GenericDetail, but without knowing exactly what
we need, there's  
>>> always an error when trying to replace because
the detail types  
>>> do not match.
>> I'm no expert in the area, but I think you might
hack a solution  
>> to it by using reflection (see http://java.sun.
com/j2se/1.4.2/docs/ 
>> api/java/lang/reflect/package-summary.html for more
info). This  
>> way you could determine at runtime the class of
each detail and  
>> cast the object returned by the iterator
appropriately. I'd like  
>> to hear more from you if you decide to go this way,
or if what i'm  
>> saying is a total mess 
>>> So if anyone has any suggestions for how to get
around this  
>>> problem, I would very much appreciate it. Thank
you very much! Adam
>> All the best, Mihai  
>>
------------------------------------------------------------
--------- 
>>  To unsubscribe, e-mail: dev-unsubscribesip- 
>> communicator.dev.java.net For additional commands,
e-mail: dev- 
>> helpsip-communicator.dev.java.net
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hey Alex, Emil, Everyone,

Thank you very much for the e-mail you sent. I've been
thinking about it 
for awhile and I really appreciated the thoughts. In
general, I 
completely agree with the idea behind the fromString method.
Do you 
think it would be better to implement that and alter each
detail class, 
or do you think it would be better to have some sort of
dedicated class 
that would basically be one consolidated location for all of
the 
detail's fromStrings?

If we choose to manage it in each detail class, rather than
having some 
sort of boolean value like isFromStringSupported, I think it
might be 
worth making an interface called Replaceable. All
implementing classes 
would have to have a fromString method and we would then
know that any 
details that are not of the type Replaceable should be
read-only. I like 
the idea of keeping everything in one dedicated class, but
it's probably 
better style and a little more intuitive to actually alter
each detail 
itself.

In any case, let me know what you think. Thanks again very
much for the 
thoughts.

Adam

Alexander Pelov wrote:
> Hi Adam,
>
> In two words: add fromString() to GenericDetail and its
children (most 
> of the functions should be trivial.. I hope
>
> The rest of the mail discusses this solution and some
issues related 
> to it.
>
> ****************
>
>
>
> I also agree that reflection may not be the best
solution in this 
> case. I mean it's doable, but would require some
implicit conventions 
> to be defined (like always having a constructor with
some fixed 
> parameters).
> I'm not the designer of the service, so I can't tell
you what was the 
> intended usage, but I think that using a factory can be
a good idea.
>
> One (simple) solution could be to define a non-static
method 
> "GenericDetail fromString(String value)" to
the parent class of all 
> details (GenericDetail). Currently, when you don't know
what to do 
> with a given type of detail (like the
ObscureHobbyDetail you mention) 
> you do a toString() and put the result into a text
field. If the user 
> changes the contents of the text field you can simply
say 
> hobby.fromString(textField.getText()) which would
return you a 
> GenericDetail object, which you can then pass on to the
replace method.
>
> The disadvantages: such method must be added to
GenericDetail and all 
> inheriting classes that need some special parsing of
the string (if 
> the "replace" function is not clever enough
this may require that ALL 
> inheriting classes should override this function..
ouch). Another 
> potential problem is that there might be some details
that cannot be 
> parsed easily from strings, BUT I think that they
should be addressed 
> with special controls anyway, so this is less of a
problem. In order 
> to allow some kind of general treatment of all details
one may add a 
> method like "isFromStringEnabled" which would
indicate if the 
> fromString method actually works, or just throws an
exception like 
> UnsupportedOperationException. This way, you as a GUI
implementor, 
> would know to put the given detail in a read-only text
field.
>
>
> Why this should work:
> The nice thing is that when an object provides a
toString method it 
> does not simply generate a random string (in the common
case) - 
> instead it builds up a string representation of its
data. A Calendar 
> object may (depending on its locale) return something
like 
> "01-02-2005". It is not meaningless to
suppose that in some cases it 
> will be able to extract some information from a given
string (if the 
> user changes the date in the previous example to
"10-10-2006" the 
> calendar might be clever enough to understand the new
value). This is 
> exactly what the fromString method should do - create a
new 
> CalendarDetail object and put in the correct data. If
it fails (like 
> the user has filled in something like "I love SIP
communicator, can I 
> get a cookie?") it might just throw an exception
(something like 
> java's IllegalFormatConversionException) thus
indicating you to inform 
> the user, that they won't get a cookie unless they fill
in a date in 
> the correct format.
>
>
> This is a very big subject, and one can do tons of
stuff making it as 
> flexible (and complex) as possible.
>
> What do you think about this?
> Alex
>
>
>
>
> Le 21 août 07 à 08:00, Adam Goldstein a écrit :
>
>> Hey Mihai, everyone,
>>
>> Thanks for the recommendation. I hadn't heard of
the reflection class 
>> before, but it does seem like it might be able to
provide a pretty 
>> good solution to the problem I've been having. Even
though it would 
>> fix what's going on now, it seems like it might be
worthwhile to 
>> actually change the way the details themselves work
so there's a more 
>> robust solution that might prevent more hassle in
the future. Your 
>> idea is definitely better than my original which
was to put some 
>> really long block of conditionals and instanceof's
and some sort of 
>> mess like that.
>>
>> Yana and I were talking a bit about it and it would
be nice if there 
>> were some sort of detail factory that could give us
all of the proper 
>> types so we can use them, but I don't know how
complicated that would 
>> be to actually make. I'd be happy to try to do it
or to help do it if 
>> that seems like the best answer to this though.
Does that seem like 
>> the way to go?
>>
>> Adam
>>
>> Mihai Balan wrote:
>>> Hi Adam, See inline: On 8/20/07, Adam Goldstein

>>> <abgoldsteingmail.com> wrote:
>>>> Hello everyone, I've been trying to finish
up the Account 
>>>> Information plug-in, but I've had a problem
with the actual 
>>>> updating process. I talked with Yana about
it a bit and I think 
>>>> we'd need to make a change to details in
general, so I was hoping 
>>>> for some thoughts. The way it works now,
the 
>>>> OperationSetServerStoredAccountInfo has a
replace method that takes 
>>>> two details: the old one and the new one
that is replacing it. The 
>>>> problem is that both of these details need
to be of the same type. 
>>>> The way we display all of these details
takes into account certain 
>>>> special details that have unusual detail
values, for instance, a 
>>>> Calendar. Besides that, regardless if it's
an InterestDetail or an 
>>>> ObscureHobbyDetail, the detail value is
just a string, so we stick 
>>>> it into a text area. That level of
blindness works out fine until 
>>>> we go to replace the details. To retrieve
the available details 
>>>> there is the method getAllAvailableDetails,
but it returns an 
>>>> iterator that we can only get objects from.
The best we can do 
>>>> right now is cast to a GenericDetail, but
without knowing exactly 
>>>> what we need, there's always an error when
trying to replace 
>>>> because the detail types do not match.
>>> I'm no expert in the area, but I think you
might hack a solution to 
>>> it by using reflection (see 
>>> http://java.sun.com/j2se/1.4.2/doc
s/api/java/lang/reflect/package-summary.html 
>>> for more info). This way you could determine at
runtime the class of 
>>> each detail and cast the object returned by the
iterator 
>>> appropriately. I'd like to hear more from you
if you decide to go 
>>> this way, or if what i'm saying is a total mess

>>>> So if anyone has any suggestions for how to
get around this 
>>>> problem, I would very much appreciate it.
Thank you very much! Adam
>>> All the best, Mihai 
>>>
------------------------------------------------------------
--------- To 
>>> unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net 
>>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Adam,

Some more thoughts on the fromString method (should we go
with a  
dedicated factory or should every class define such method)
and the  
isFromStringSupported method (should we use an interface to
mark a  
class as supplying a working fromString method instead).

My opinion on this is that we should keep it simple and let
each  
class define it's own fromString method (if necessary) and
define an  
isFromStringSupported method.

The rest of the mail explains why.

********************

I'm glad you liked the "fromString()" approach ;)
I think I like having each detail class supplying its own
fromString  
a little better than delegating the work to an external
class, but I  
must underline that don't know the entire framework behind
the  
"details". In fact, you are proposing the creation
of a full-blown  
factory, that will be able to produce all kinds of details,
which  
also has its advantages.

I'd go with the fromString-per-class solution, because this
way we're  
going to have a symmetry in the code (toString-fromString)
and it  
would be less prone to errors (if someone changes one of the
method,  
he/she is then obligated to change the other one as well -
and I  
think that having to go and change the code in some other
class would  
be more prone to errors). Furthermore, if at a later stage
we decide  
that we want the factory stuff after all, we can always
write a short  
class that uses a little bit reflection and calls the
fromString  
method of the class it's supposed to instantiate.

On the other hand, a factory is almost always a good
solution when it  
comes to creating objects without knowing their type in
advance.  
Moreover it seems to be a cleaner solution, in the sense
that you  
don't need to have an entire object to create a new instance
(you  
need just the class, which in absolute terms is less
information).  
However, given the current usage of the details this is not
that much  
of an advantage (you always have an object to replicate).

So, to summarize this issue: I'd go with
fromString-per-class out of  
aesthetics and most importantly - following the KISS rule.


The Replaceable interface seems as a good idea, but (there's
always a  
but;) you're going to have problems if one detail is
Replaceable and  
its child is not.. well doesn't want to be. The thing is
that I don't  
think that it's a good idea to mix the implicit information
contained  
in the class hierarchy (which is - what is the type of this
object?)  
with the information about its functionality (which is
explicit and  
is coded in its methods). In the current context, it
translates to  
the case when the HobbyDetail is Replaceable, but its child 

OrderedHobbyDetail doesn't want to be, but cannot do
anything about  
it (which is for example when the author of the latter class
didn't  
provide appropriate parser). If you look from class point of
view,  
the OrderedHobbyDetail is indeed a child of HobbyDetail
(adding just  
the order to it), but requires additional functionality,
which may or  
may not be implemented. If you have a method
isFromStringSupported  
you can simply override it and return false. Finally, it is
quite  
probable that one could be able to add a fromString method
to  
GenericDetail, and if GenericDetail is marked as a
Replaceable, then  
every class underneath it is going to be Replaceable, which 

effectively eliminates its utility. Finally, I think that
even if you  
decide to go with the interface solution you should think of
another  
name for the interface, because it should only state that
you can  
create objects of this type out of strings (e.g. one may
perfectly  
well be able to call fromString, but the protocol provider
may be  
unable to replace this kind of details - it's not really
Replaceable,  
but FromStringable sort of thing).


That's from me for now, I hope that you'll find these
comments  
useful. Surely, there are some cases that I didn't think
about, so  
don't hesitate to give some examples where these things
don't work  
that well.

Regards,
Alex


Le 27 août 07 à 09:47, Adam Goldstein a écrit :

> Hey Alex, Emil, Everyone,
>
> Thank you very much for the e-mail you sent. I've been
thinking  
> about it for awhile and I really appreciated the
thoughts. In  
> general, I completely agree with the idea behind the
fromString  
> method. Do you think it would be better to implement
that and alter  
> each detail class, or do you think it would be better
to have some  
> sort of dedicated class that would basically be one
consolidated  
> location for all of the detail's fromStrings?
>
> If we choose to manage it in each detail class, rather
than having  
> some sort of boolean value like isFromStringSupported,
I think it  
> might be worth making an interface called Replaceable.
All  
> implementing classes would have to have a fromString
method and we  
> would then know that any details that are not of the
type  
> Replaceable should be read-only. I like the idea of
keeping  
> everything in one dedicated class, but it's probably
better style  
> and a little more intuitive to actually alter each
detail itself.
>
> In any case, let me know what you think. Thanks again
very much for  
> the thoughts.
>
> Adam
>
> Alexander Pelov wrote:
>> Hi Adam,
>>
>> In two words: add fromString() to GenericDetail and
its children  
>> (most of the functions should be trivial.. I
hope
>>
>> The rest of the mail discusses this solution and
some issues  
>> related to it.
>>
>> ****************
>>
>>
>>
>> I also agree that reflection may not be the best
solution in this  
>> case. I mean it's doable, but would require some
implicit  
>> conventions to be defined (like always having a
constructor with  
>> some fixed parameters).
>> I'm not the designer of the service, so I can't
tell you what was  
>> the intended usage, but I think that using a
factory can be a good  
>> idea.
>>
>> One (simple) solution could be to define a
non-static method  
>> "GenericDetail fromString(String value)"
to the parent class of  
>> all details (GenericDetail). Currently, when you
don't know what  
>> to do with a given type of detail (like the
ObscureHobbyDetail you  
>> mention) you do a toString() and put the result
into a text field.  
>> If the user changes the contents of the text field
you can simply  
>> say hobby.fromString(textField.getText()) which
would return you a  
>> GenericDetail object, which you can then pass on to
the replace  
>> method.
>>
>> The disadvantages: such method must be added to
GenericDetail and  
>> all inheriting classes that need some special
parsing of the  
>> string (if the "replace" function is not
clever enough this may  
>> require that ALL inheriting classes should override
this  
>> function.. ouch). Another potential problem is that
there might be  
>> some details that cannot be parsed easily from
strings, BUT I  
>> think that they should be addressed with special
controls anyway,  
>> so this is less of a problem. In order to allow
some kind of  
>> general treatment of all details one may add a
method like  
>> "isFromStringEnabled" which would
indicate if the fromString  
>> method actually works, or just throws an exception
like  
>> UnsupportedOperationException. This way, you as a
GUI implementor,  
>> would know to put the given detail in a read-only
text field.
>>
>>
>> Why this should work:
>> The nice thing is that when an object provides a
toString method  
>> it does not simply generate a random string (in the
common case) -  
>> instead it builds up a string representation of its
data. A  
>> Calendar object may (depending on its locale)
return something  
>> like "01-02-2005". It is not meaningless
to suppose that in some  
>> cases it will be able to extract some information
from a given  
>> string (if the user changes the date in the
previous example to  
>> "10-10-2006" the calendar might be clever
enough to understand the  
>> new value). This is exactly what the fromString
method should do -  
>> create a new CalendarDetail object and put in the
correct data. If  
>> it fails (like the user has filled in something
like "I love SIP  
>> communicator, can I get a cookie?") it might
just throw an  
>> exception (something like java's
IllegalFormatConversionException)  
>> thus indicating you to inform the user, that they
won't get a  
>> cookie unless they fill in a date in the correct
format.
>>
>>
>> This is a very big subject, and one can do tons of
stuff making it  
>> as flexible (and complex) as possible.
>>
>> What do you think about this?
>> Alex
>>
>>
>>
>>
>> Le 21 août 07 à 08:00, Adam Goldstein a écrit :
>>
>>> Hey Mihai, everyone,
>>>
>>> Thanks for the recommendation. I hadn't heard
of the reflection  
>>> class before, but it does seem like it might be
able to provide a  
>>> pretty good solution to the problem I've been
having. Even though  
>>> it would fix what's going on now, it seems like
it might be  
>>> worthwhile to actually change the way the
details themselves work  
>>> so there's a more robust solution that might
prevent more hassle  
>>> in the future. Your idea is definitely better
than my original  
>>> which was to put some really long block of
conditionals and  
>>> instanceof's and some sort of mess like that.
>>>
>>> Yana and I were talking a bit about it and it
would be nice if  
>>> there were some sort of detail factory that
could give us all of  
>>> the proper types so we can use them, but I
don't know how  
>>> complicated that would be to actually make. I'd
be happy to try  
>>> to do it or to help do it if that seems like
the best answer to  
>>> this though. Does that seem like the way to
go?
>>>
>>> Adam
>>>
>>> Mihai Balan wrote:
>>>> Hi Adam, See inline: On 8/20/07, Adam
Goldstein  
>>>> <abgoldsteingmail.com> wrote:
>>>>> Hello everyone, I've been trying to
finish up the Account  
>>>>> Information plug-in, but I've had a
problem with the actual  
>>>>> updating process. I talked with Yana
about it a bit and I think  
>>>>> we'd need to make a change to details
in general, so I was  
>>>>> hoping for some thoughts. The way it
works now, the  
>>>>> OperationSetServerStoredAccountInfo has
a replace method that  
>>>>> takes two details: the old one and the
new one that is  
>>>>> replacing it. The problem is that both
of these details need to  
>>>>> be of the same type. The way we display
all of these details  
>>>>> takes into account certain special
details that have unusual  
>>>>> detail values, for instance, a
Calendar. Besides that,  
>>>>> regardless if it's an InterestDetail or
an ObscureHobbyDetail,  
>>>>> the detail value is just a string, so
we stick it into a text  
>>>>> area. That level of blindness works out
fine until we go to  
>>>>> replace the details. To retrieve the
available details there is  
>>>>> the method getAllAvailableDetails, but
it returns an iterator  
>>>>> that we can only get objects from. The
best we can do right now  
>>>>> is cast to a GenericDetail, but without
knowing exactly what we  
>>>>> need, there's always an error when
trying to replace because  
>>>>> the detail types do not match.
>>>> I'm no expert in the area, but I think you
might hack a solution  
>>>> to it by using reflection (see http://java.sun.com/j
2se/1.4.2/ 
>>>>
docs/api/java/lang/reflect/package-summary.html for more
info).  
>>>> This way you could determine at runtime the
class of each detail  
>>>> and cast the object returned by the
iterator appropriately. I'd  
>>>> like to hear more from you if you decide to
go this way, or if  
>>>> what i'm saying is a total mess 
>>>>> So if anyone has any suggestions for
how to get around this  
>>>>> problem, I would very much appreciate
it. Thank you very much!  
>>>>> Adam
>>>> All the best, Mihai  
>>>>
------------------------------------------------------------
------- 
>>>> -- To unsubscribe, e-mail:
dev-unsubscribesip- 
>>>> communicator.dev.java.net For additional
commands, e-mail: dev- 
>>>> helpsip-communicator.dev.java.net
>>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip- 
>> communicator.dev.java.net
>>
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip- 
> communicator.dev.java.net
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net