Re: solutions to hidden setters?
[email protected] Thu, 21 Jul 2005 09:39:57 +0200
| Newsgroups | gmane.comp.embedded.carlsbad-cubes |
|---|---|
| Organization | http://freemail.web.de/ |
| Message-ID | <[email protected]> |
List for Users of Carlsbad Cubes' Technologies and Products <[email protected]> schrieb am 21.07.05 02:29:59: > > Hi All, > > Swix is great, we have been adding stuff to it and found it > gives us flexibility to do (almost) anything :-) > > While trying to use a jlist like this: > <list id='foo' ListData="abc:def:geh:zzz" /> > > with a custom convertor that parses the string into a Vector, it doesn't work. > After looking at the code I suspect the culprit is that JList has two setters: > > public void setListData(Object[] listData) > public void setListData(Vector listData) > > Is there any way to use the second setter? Hm, I could only imagine something like this: inherit JList and provide a method like setVListData(Vector listData). The problem lies in the fact Swixml only looks for one method setlistdata without taking into account the real return value type of the converter. > > Also we use many swing engines because we have many client objects mapping to > different swixml (xml) UI files. I thought of extending SwingEngine so that > I override the function mapMembers so that I can use it for a custom client. > > Essentially it would be cool to say: > SwingEngine sw = new SwingEngine(); // note: no 'this' > for(;;){ > ClientObj c = new ClientObj(..); > sw.getIdMap().clear(); > sw.setClient(c); > sw.render( file /*for client c*/); > /* make sw maps ids to public (and with #144, also private) members of c */ > sw.render( file /*for client c*/); > } > > Does this sound like a bad idea? Am I missing something in my conception of > swix? Or is this possible. I wonder if someone with knowledge of the internals > of swixml could tell me if can be achieved somehow.. > > Does each new swixml engine take up memory permanently, or is it eventually GC'd > .. ie does anyone else store refs to SwingEngines? IMHO this is'nt worth the hassle because the SwingEngine itself does not take up much memory itself. If you render large xml files, the idMap may be a problem, though. But then, if you do not need the map, clean it. Or null the swingengine if she is a field, it will sooner or later be gc'ed, along with the idmap... Frank