On 27.09.2012 00:11, Michael T. Pope wrote:
> One of the uses of the Unit constructor that takes an Element argument
> is in a brutal debug hack of mine in TilePopup to add a new unit to a
> tile. Indeed TilePopup and DebugMenu have quite a few such routines,
> which might be better aggregated together in a DebugUtils class, as
> they tend to manipulate both client and server data in intrusive ways,
> or give access to normally hidden information, and share some common
> patterns. The obvious place for this would be under
> net.sf.freecol.common.util, but I am interested in other ideas,
> particularly from Paolo who cares about a tidy class hierarchy:-).
>
Actually, I don't see what distinguishes the debugging use cases from
what happens in the course of a normal game. Can't we just add a create
object message that gets rejected unless the server is in debug mode?
> My method of getting rid of the Unit(Game,Element) constructor was to
> continue to add the unit on the server side, but now use
> updateFreeColGameObject on the client side to update the location the
> unit has been put. updateFreeColGameObject requires an
> XMLStreamReader to update from, so I tried this:
>
> StringWriter sw = new StringWriter();
> try {
> XMLStreamWriter xsw = XMLOutputFactory.newInstance()
> .createXMLStreamWriter(sw);
> ((FreeColGameObject)loc).toXML(xsw, serverPlayer, true, true);
> xsw.close();
>
> XMLStreamReader xsr = XMLInputFactory.newInstance()
> .createXMLStreamReader(new StringReader(sw.toString()));
> while (xsr.getEventType() != XMLStreamConstants.START_ELEMENT) {
> xsr.next();
> }
> if (carrier != null) { // Update client-side carrier
> carrier.updateFreeColGameObject(xsr, Unit.class);
> } else { // Update client-side tile
> tile.updateFreeColGameObject(xsr, Tile.class);
> }
> xsr.close();
> } catch (Exception e) {
> logger.log(Level.WARNING, "Add unit fail: " + sw.toString(), e);
> }
>
> However this fails, throwing the exception and complaining that the
> XMLStreamReader is not in the START_ELEMENT state. This is true.
> Poking at it reveals that its state is START_DOCUMENT. So I tried
> bracketing the toXML() call with xsw.write{Start,End}Document(), but
> that still throws the exception. What does work is adding:
>
> while (xsr.getEventType() != XMLStreamConstants.START_ELEMENT) {
> xsr.next();
> }
>
> before calling updateFreeColGameObject. This is rather non-obvious.
> Any ideas of what is the Right Thing to do is here?
>
> Cheers,
> Mike Pope
This also bit me quite recently. What we usually do is to call
"xsr.nextTag()" to jump to the beginning of the data we are interested
in. But I have the nagging feeling that we are not using the stax api as
designed anyway, since all the examples seem to assume one big damn loop
that goobles up the entire stream, checks every event and calls suitable
methods, whereas we know exactly what we are expecting to find and act
accordingly.
Regards
Michael
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Freecol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freecol-developers
