The exceptions are those that would normally occur when calling
.remove(Object) on a hashmap... null pointer if idmap didn't exist or if you
passed in a null object.
Personally I love exceptions being thrown but in this case I think the
preferred functionality is to just keep working... if you couldn't remove
the thing then it's pretty much guaranteed to not be there, which is what
you were shooting for in the first place. If you massed in a null object,
well then, there was nothing to remove anyway. Now, if something can't get
*added* to the idmap well then yes, exception good.
For an example of where we needed it see the attached image (colors are
crappy because I tried to make it a smaller file) ignore the horrible date
formats we're still early in this app. Anyway, clicking on one of the table
rows renders the text at the bottom, the keyframes, the button, and assigns
an action to the button.
Now, the button text and the labels that hold the images are modified after
swix gets them. swix renders it, we check if the image exists, set the label
to hold the image if it does or text if it doesn't. The button is specific
to the particular video the person is looking at, if the video doesn't exist
the button says "missing video" and doesn't do anything. Otherwise clicking
it starts playing the video.
In order to do all that After swix gets it the labels and the button have to
have ids.
So far so good. then a user selects another row, then clicks the initial
row. The id's are already taken and SwingEngine complains.
simplest solution is to have SwingEngine forget about the id as soon as
we've called find() on it and assigned the resulting object to something
local. We can't use the normal assignment method via reflection because we
never know how many objects there will be, and it could potentially be in
the thousands. And yes, forgetting about the id but NOT affecting the
rendered object is exactly what we want. We just need the ID to retrieve it.
After that we don't care.
Yes, we could look up the info before rendering and that would take care of
the button text and the labels but not the action associated with the
specific button.
As a side note all of our XML for Swixml is templates with replacements
happening just before rendering, as you can see from the ${broadcasterName}
in the title bar that hasn't been replaced.
In some other places we're rendering from JDom objects. :) Damn I love this
stuff. Makes swing usable.
-Kate
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 2:51 AM
To: [email protected]
Subject: Re: [Forum] fuhgeddaboudit
[EMAIL PROTECTED] wrote:
> org.swix.swixml.SwingEngine
>
> /**
> * Removes the id from the cache.
> * @param id <code>String</code> assigned name
> */
> public void forget(final String id){
> try {
> idmap.remove(id);
> } catch (Exception e){
> // ignore it
> }
> }
>
>
> we needed that... Figure it might be useful to add in to the main . Didn't
> want to call it remove, or clear, or flush, because that implies that it
> affects the object, when all we're really doing is making it forget about
> it.
Hello Kate,
I have something to add about this. First, which exceptions might occur
during the remove call? Should we really catch *all* exceptions without
notice? This might lead to some bugs hard to find. (I had a discussion
with Wolf about using "catch/throw[s] Exception" -- I'm no friend of
that at all because this led me to sometimes bad solutions). If the id
is not in the map, no exception is thrown. The
UnsupportedOperationException is not very likely because we have the
source code and decide which Map is the underlying implementation...
Second, why you do'nt want it to keep the name you are using inside?
Like every other remove(), this does not affect the object given
(java.util.List) or referenced by via key-value binding (Map).
Perhaps you can show some example?
Frank
_______________________________________________
Forum mailing list
[email protected]
http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com
