Re: [5.next] Refactoring save-to-XML
>Xerces still provide an XML Serializer, two actually
they all do, it is part of the standard Java XML API
see below, this way you don't have to import any outside libraries of the JDK
Filip
public static void writeXmlToFile(java.io.File f, Document d) {
Transformer transformer =
TransformerFactory.newInstance().newTransformer();
java.io.FileOutputStream out = new java.io.FileOutputStream(f);
StreamResult result = new StreamResult(out);
DOMSource source = new DOMSource(d);
transformer.setOutputProperty(OutputKeys.INDENT,"yes");
//depending on which library you have
transformer.setOutputProperty("{http://xml.apache.org/xalan%7dindent-amount","4";);
transformer.setOutputProperty("{http://xml.apache.org/xslt%7dindent-amount","4";);
transformer.setOutputProperty(OutputKeys.METHOD,"xml");
transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION,"yes");
transformer.transform(source, result);
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, July 30, 2004 11:57 AM
Subject: Re: [5.next] Refactoring save-to-XML
Shapira, Yoav wrote:
>Hi,
>I think a gradual transition might be OK. Server.xml, as Remy said, nicely conveys
>the structure of the server's configuration.
That's possible to replicate in a JMX- or JBoss-style configuration file, but it tends
to look uglier and more verbose IMHO.
However, your desired a good long-term goal also, I think.
>
>So for now I like the DOM + PropertyChangeEvent model that Remy has proposed.
>Especially combined with the increased use of
setAllProperties, the configuration will be both less verbose and easier to
save/restore.
>
>Xerces still provide an XML Serializer, two actually. One is what I think we should
>use, the DOM Level 3 Standard (meaning there's
a shot this thing is portable ;)):
http://xml.apache.org/xerces2-j/javadocs/api/org/w3c/dom/ls/LSSerializer.html,
specified in
http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/. But as you see these things
are fairly new, and as such might be buggy:
http://xml.apache.org/xerces2-j/dom3.html. There's also at least one unimplemented
method of the LSSerializer
(normalize-characters) but we might not need that one.
>
>
This is a big plus in favor of DOM 3. +1 for using it.
I see this stuff is available bundled on JDK 1.5 (like JMX and JMX
remote), so if we choose to use this, I think I'll advocate having the
default download for JDK 1.5, and a download for JDK 1.4 compatibility.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
Shapira, Yoav wrote: Hi, I think a gradual transition might be OK. Server.xml, as Remy said, nicely conveys the structure of the server's configuration. That's possible to replicate in a JMX- or JBoss-style configuration file, but it tends to look uglier and more verbose IMHO. However, your desired a good long-term goal also, I think. So for now I like the DOM + PropertyChangeEvent model that Remy has proposed. Especially combined with the increased use of setAllProperties, the configuration will be both less verbose and easier to save/restore. Xerces still provide an XML Serializer, two actually. One is what I think we should use, the DOM Level 3 Standard (meaning there's a shot this thing is portable ;)): http://xml.apache.org/xerces2-j/javadocs/api/org/w3c/dom/ls/LSSerializer.html, specified in http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/. But as you see these things are fairly new, and as such might be buggy: http://xml.apache.org/xerces2-j/dom3.html. There's also at least one unimplemented method of the LSSerializer (normalize-characters) but we might not need that one. This is a big plus in favor of DOM 3. +1 for using it. I see this stuff is available bundled on JDK 1.5 (like JMX and JMX remote), so if we choose to use this, I think I'll advocate having the default download for JDK 1.5, and a download for JDK 1.4 compatibility. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Refactoring save-to-XML
Hi, I think a gradual transition might be OK. Server.xml, as Remy said, nicely conveys the structure of the server's configuration. That's possible to replicate in a JMX- or JBoss-style configuration file, but it tends to look uglier and more verbose IMHO. However, your desired a good long-term goal also, I think. So for now I like the DOM + PropertyChangeEvent model that Remy has proposed. Especially combined with the increased use of setAllProperties, the configuration will be both less verbose and easier to save/restore. Xerces still provide an XML Serializer, two actually. One is what I think we should use, the DOM Level 3 Standard (meaning there's a shot this thing is portable ;)): http://xml.apache.org/xerces2-j/javadocs/api/org/w3c/dom/ls/LSSerializer.html, specified in http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/. But as you see these things are fairly new, and as such might be buggy: http://xml.apache.org/xerces2-j/dom3.html. There's also at least one unimplemented method of the LSSerializer (normalize-characters) but we might not need that one. Yoav Shapira Millennium Research Informatics >-Original Message- >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache >Sent: Friday, July 30, 2004 2:24 AM >To: [EMAIL PROTECTED] >Subject: Re: [5.next] Refactoring save-to-XML > >Remy Maucherat wrote: >> Costin Manolache wrote: >> >>> The major problem is intercepting the changes. It can be done: >>> - inside the jmx impl ( interceptors, etc ) >>> - using the property changed events >>> - by wrapping each mbean when it is registered. >>> >>> One important question is if we need to save server.xml, or >>> just say that server.xml is for legacy manual config, and use a >>> different jmx-oriented format for settings. >>> >>> Another radical approach is to use java settings api for >>> storing/retrieving the settings - again, deprecate server.xml and you >>> also need to intercept settings from jmx. >> >> >> So after thinking about it quite a bit this evening, I'm leaning towards >> DOM + using the property changed events. Obviously this will add a bit >> to the development time (good thing I didn't propose any release plan >> yet), as a replacement for digester is needed, the serializer (Xerces >> used to have one we could steal) as well, and the logic to keep the DOM >> tree and the Catalina objects in sync. > >We still have the problem of getting changes from JMX ( made via console >) into the config. Property change events are ok, but it means all >plugins will be required to support them. > >To be honest, I was hoping server.xml will disapear. Tomcat is now very >JMX based, it is easily integrable into a lot of apps, it is used in >large sites. I don't think server.xml is the right choice for long term. > >What we need IMO is to separate the setting storage ( including >updates). If tomcat is embedded in jboss, it should use jboss config >style. It should also be able to use LDAP, NDS, win registry ( via >java.prefs ) or any other config storage. >All we really need is a list of mbeans and some attributes for each. > >Costin > > >> >> Thanks for the comments from everyone about various technologies, but >> the big problem right now is that the save-to-xml really messes up the >> XML configuration,so that people won't want to edit it manually ever >> again once they start using the admin webapp (and then we know what >> happens, there's a limitation/bug in the tool, and the user is stuck - >> it's the M$ syndrome). DOM seems the only thing which keeps everything >> (of course, it's the reason why it's slow, bloated and everyone hates it >> ;) ). >> >> I'll keep on using the repackaged digester for web.xml parsing unless >> someone has a better idea. >> >> Rémy > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: The major problem is intercepting the changes. It can be done: - inside the jmx impl ( interceptors, etc ) - using the property changed events - by wrapping each mbean when it is registered. One important question is if we need to save server.xml, or just say that server.xml is for legacy manual config, and use a different jmx-oriented format for settings. Another radical approach is to use java settings api for storing/retrieving the settings - again, deprecate server.xml and you also need to intercept settings from jmx. So after thinking about it quite a bit this evening, I'm leaning towards DOM + using the property changed events. Obviously this will add a bit to the development time (good thing I didn't propose any release plan yet), as a replacement for digester is needed, the serializer (Xerces used to have one we could steal) as well, and the logic to keep the DOM tree and the Catalina objects in sync. We still have the problem of getting changes from JMX ( made via console ) into the config. Property change events are ok, but it means all plugins will be required to support them. To be honest, I was hoping server.xml will disapear. Tomcat is now very JMX based, it is easily integrable into a lot of apps, it is used in large sites. I don't think server.xml is the right choice for long term. What we need IMO is to separate the setting storage ( including updates). If tomcat is embedded in jboss, it should use jboss config style. It should also be able to use LDAP, NDS, win registry ( via java.prefs ) or any other config storage. All we really need is a list of mbeans and some attributes for each. Ah, ok. I thought you were ok with the DOM/server.xml solution. You mention technical problems, but there are none: container events will also need to be used. I think a JMX based config file would be more complex than server.xml to manipulate for end users (more verbose, even less error checking, because we won't be able to come up with a DTD or schema even if we wanted to, and finally it doesn't represent the actual server structure). So that's a number of problems as far as I'm concerned. A resource abstraction is quite complex as well (either it's XML or it's not ;) ), and I'm not going to do it. If you want some scheme where Tomcat gets its XML config files from somewhere on startup, then I'm ok with someone adding that. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
Remy Maucherat wrote: Costin Manolache wrote: The major problem is intercepting the changes. It can be done: - inside the jmx impl ( interceptors, etc ) - using the property changed events - by wrapping each mbean when it is registered. One important question is if we need to save server.xml, or just say that server.xml is for legacy manual config, and use a different jmx-oriented format for settings. Another radical approach is to use java settings api for storing/retrieving the settings - again, deprecate server.xml and you also need to intercept settings from jmx. So after thinking about it quite a bit this evening, I'm leaning towards DOM + using the property changed events. Obviously this will add a bit to the development time (good thing I didn't propose any release plan yet), as a replacement for digester is needed, the serializer (Xerces used to have one we could steal) as well, and the logic to keep the DOM tree and the Catalina objects in sync. We still have the problem of getting changes from JMX ( made via console ) into the config. Property change events are ok, but it means all plugins will be required to support them. To be honest, I was hoping server.xml will disapear. Tomcat is now very JMX based, it is easily integrable into a lot of apps, it is used in large sites. I don't think server.xml is the right choice for long term. What we need IMO is to separate the setting storage ( including updates). If tomcat is embedded in jboss, it should use jboss config style. It should also be able to use LDAP, NDS, win registry ( via java.prefs ) or any other config storage. All we really need is a list of mbeans and some attributes for each. Costin Thanks for the comments from everyone about various technologies, but the big problem right now is that the save-to-xml really messes up the XML configuration,so that people won't want to edit it manually ever again once they start using the admin webapp (and then we know what happens, there's a limitation/bug in the tool, and the user is stuck - it's the M$ syndrome). DOM seems the only thing which keeps everything (of course, it's the reason why it's slow, bloated and everyone hates it ;) ). I'll keep on using the repackaged digester for web.xml parsing unless someone has a better idea. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
Costin Manolache wrote: The major problem is intercepting the changes. It can be done: - inside the jmx impl ( interceptors, etc ) - using the property changed events - by wrapping each mbean when it is registered. One important question is if we need to save server.xml, or just say that server.xml is for legacy manual config, and use a different jmx-oriented format for settings. Another radical approach is to use java settings api for storing/retrieving the settings - again, deprecate server.xml and you also need to intercept settings from jmx. So after thinking about it quite a bit this evening, I'm leaning towards DOM + using the property changed events. Obviously this will add a bit to the development time (good thing I didn't propose any release plan yet), as a replacement for digester is needed, the serializer (Xerces used to have one we could steal) as well, and the logic to keep the DOM tree and the Catalina objects in sync. Thanks for the comments from everyone about various technologies, but the big problem right now is that the save-to-xml really messes up the XML configuration,so that people won't want to edit it manually ever again once they start using the admin webapp (and then we know what happens, there's a limitation/bug in the tool, and the user is stuck - it's the M$ syndrome). DOM seems the only thing which keeps everything (of course, it's the reason why it's slow, bloated and everyone hates it ;) ). I'll keep on using the repackaged digester for web.xml parsing unless someone has a better idea. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
Costin Manolache wrote: Remy Maucherat wrote: Hi, I'd like to make this feature less hardcoded (right now, it's ugly ;) ). A first step would be to extract the code to another helper class, but that's all I can think of. Does anyone have any ideas ? What I tried earlier ( but didn't finish ), and I still think is a good idea - use the old DOM, and have config changes reflected to the config tree _when they are done_, instead of pulling every property from each mbean. That's the idea. The major problem is intercepting the changes. It can be done: - inside the jmx impl ( interceptors, etc ) Yeah, well, I'm not too hot about that. We'd have to use broadcasters everywhere, etc. That code isn't especially nice if we have to do it for every single property event. I may have performance issues (on the listener side, you can use regexps for registration and filters: this looks rather expensive to me). So it might work, but I'm not sure about it right now. - using the property changed events Big advantage: they're already there, and we're sucessfully using them for stuff we really shouldn't (the naming context updates). - by wrapping each mbean when it is registered. But we'd have to do all property changes through JMX then, which is quite annoying. Actually, this DOM syncing would be a good job for some aspect ;) One important question is if we need to save server.xml, or just say that server.xml is for legacy manual config, and use a different jmx-oriented format for settings. That's a good question. I like the current server.xml, since it represents well the structure of the server. I don't see the JMX configuration as being that much simpler to save (and it's definitely more verbose). The advantage is that it faithfully represents the init process, and you could do the same in a Java program to instantiate the same server. Another radical approach is to use java settings api for storing/retrieving the settings - again, deprecate server.xml and you also need to intercept settings from jmx. java.util.prefs ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
On Thu, 29 Jul 2004 16:55:39 +0200, Remy Maucherat <[EMAIL PROTECTED]> wrote: > I think it's a start. You identified the downsides well enough, but > unfortunately, they're a showstopper for me. Additional tweaks are > needed. I see that others suggested other technologies, but we'd have > many issues as well (assuming XStream or the others can serialize the > Catalina tree to a XML which would be readable, I don't see how it would > possibly be able to restore it). the XStream API is super simple and I think it should be able to restore the object. XStream xstream = new XStream(); String xml = xstream.toXML(myObject); // serialize to XML Object myObject2 = xstream.fromXML(xml); // deserialize from XML the only catch I can see is it doesn't use attributes. In the case of JMeter, mike wrote a simple class to convert jmeter's hashtree to a simpler format. that resulted in smaller files and good performance. > > Another recurrent problems: > - None of these things support manual editing of the XML file (well, > they do, but any formatting, commets, etc is lost) > - The way stuff is saved is clearly quite bad (save evrything, rather > than just what is actually modified on one object) > you do loose comments with XStream. Not sure how important comments are. XStream is xml from a java perspective, so it's the opposite of DOM in that respect. > And this is where I think DOM might not suck after all: > - it's a very good representation of the XML document (unlike all the > other "fast" solutions, which usually discard the non meaningful stuff) > - by keeping the elements in memory, and using the ContainerListener > stuff that I want to remove, we could update the relevant DOM elements > as needed rather than blindly save all the non default properties of > every object (which doesn't work well with global config files to set > defaults, and as soon as you press save all the defaults appear in every > config file) > - when asked, we serialize the DOM trees to files; if the serializer is > good enough, we'll end up with the same as the original files, with only > the needed modifications > > The problems: > - it's slower (I think no, the files we're using are small) > - we would need a DOM Digester to read the internal config (server.xml, > all context files), while the usual Digester would handle the (much > bigger) standard deployment descriptors with SAX > > > > Rémy > another option might by Jibx, which is also xml from a Java perspective. It's much more flexible and allows for all sorts of mapping/conversion. peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
Remy Maucherat wrote: Hi, I'd like to make this feature less hardcoded (right now, it's ugly ;) ). A first step would be to extract the code to another helper class, but that's all I can think of. Does anyone have any ideas ? What I tried earlier ( but didn't finish ), and I still think is a good idea - use the old DOM, and have config changes reflected to the config tree _when they are done_, instead of pulling every property from each mbean. The major problem is intercepting the changes. It can be done: - inside the jmx impl ( interceptors, etc ) - using the property changed events - by wrapping each mbean when it is registered. One important question is if we need to save server.xml, or just say that server.xml is for legacy manual config, and use a different jmx-oriented format for settings. Another radical approach is to use java settings api for storing/retrieving the settings - again, deprecate server.xml and you also need to intercept settings from jmx. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
Shapira, Yoav wrote: Hi, I've done a bit of work in this space. One approach that I've seen work with very complex object graphs is: - Have an interface, e.g. XMLRepresentationI, with one method, String toXML(); - Have every object along the graph that needs to be saved implement this interface, e.g. Context, Host, Engine, etc. To save a complete Server, we'd call Server.toXML(). The Server would output its own start tag, then call its children containers, e.g. Engine, etc, and then the Server would output its own close tag. The Host would call toXML on all its Contexts, etc. The advantages of this approach include simplicity (each toXML method tends to be very simple), ease of debugging, and ease of extension by users who write custom classes. It's also obviously possible to do whatever we want with the Server.toXML() output, including writing it in an i18n stream (a current problem of the admin webapp is recurring issues with i18n and encoding), and conveying it over JMX or SNMP to controlling applications or monitoring dashboards. It's also possible to create something like ReflectionToStringBuilder (see Jakarta Commons-Lang API JavaDocs) to automatically generate these XML Strings. This in a sense is a sort of reverse-Digester. There are alternatives like XMLBeans, XPull, XStream that play in this space also, as others have mentioned. But these are additional dependencies and I'm not in a rush to add those. The downsides of this approach are: - If we add an attribute to something, we need to modify the toXML method. This is mitigated by using a ReflectionToXMLBuilder as I suggest above. - The writing code is all over the Catalina codebase, distributed to each component. Some people would prefer to have the writing code in one place, and I understand that. It's a valid design choice either way IMHO, but the latter can pose access problems (everything written would need to be public, can't be protected, whereas with the toXML approach above we easily write private and protected fields. So there's one idea... I think it's a start. You identified the downsides well enough, but unfortunately, they're a showstopper for me. Additional tweaks are needed. I see that others suggested other technologies, but we'd have many issues as well (assuming XStream or the others can serialize the Catalina tree to a XML which would be readable, I don't see how it would possibly be able to restore it). Another recurrent problems: - None of these things support manual editing of the XML file (well, they do, but any formatting, commets, etc is lost) - The way stuff is saved is clearly quite bad (save evrything, rather than just what is actually modified on one object) And this is where I think DOM might not suck after all: - it's a very good representation of the XML document (unlike all the other "fast" solutions, which usually discard the non meaningful stuff) - by keeping the elements in memory, and using the ContainerListener stuff that I want to remove, we could update the relevant DOM elements as needed rather than blindly save all the non default properties of every object (which doesn't work well with global config files to set defaults, and as soon as you press save all the defaults appear in every config file) - when asked, we serialize the DOM trees to files; if the serializer is good enough, we'll end up with the same as the original files, with only the needed modifications The problems: - it's slower (I think no, the files we're using are small) - we would need a DOM Digester to read the internal config (server.xml, all context files), while the usual Digester would handle the (much bigger) standard deployment descriptors with SAX Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Refactoring save-to-XML
Hi, I've done a bit of work in this space. One approach that I've seen work with very complex object graphs is: - Have an interface, e.g. XMLRepresentationI, with one method, String toXML(); - Have every object along the graph that needs to be saved implement this interface, e.g. Context, Host, Engine, etc. To save a complete Server, we'd call Server.toXML(). The Server would output its own start tag, then call its children containers, e.g. Engine, etc, and then the Server would output its own close tag. The Host would call toXML on all its Contexts, etc. The advantages of this approach include simplicity (each toXML method tends to be very simple), ease of debugging, and ease of extension by users who write custom classes. It's also obviously possible to do whatever we want with the Server.toXML() output, including writing it in an i18n stream (a current problem of the admin webapp is recurring issues with i18n and encoding), and conveying it over JMX or SNMP to controlling applications or monitoring dashboards. It's also possible to create something like ReflectionToStringBuilder (see Jakarta Commons-Lang API JavaDocs) to automatically generate these XML Strings. This in a sense is a sort of reverse-Digester. There are alternatives like XMLBeans, XPull, XStream that play in this space also, as others have mentioned. But these are additional dependencies and I'm not in a rush to add those. The downsides of this approach are: - If we add an attribute to something, we need to modify the toXML method. This is mitigated by using a ReflectionToXMLBuilder as I suggest above. - The writing code is all over the Catalina codebase, distributed to each component. Some people would prefer to have the writing code in one place, and I understand that. It's a valid design choice either way IMHO, but the latter can pose access problems (everything written would need to be public, can't be protected, whereas with the toXML approach above we easily write private and protected fields. So there's one idea... Yoav Shapira Millennium Research Informatics >-Original Message- >From: Remy Maucherat [mailto:[EMAIL PROTECTED] >Sent: Thursday, July 29, 2004 9:57 AM >To: Tomcat Developers List >Subject: [5.next] Refactoring save-to-XML > >Hi, > >I'd like to make this feature less hardcoded (right now, it's ugly ;) ). >A first step would be to extract the code to another helper class, but >that's all I can think of. Does anyone have any ideas ? > >Rémy > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Refactoring save-to-XML
XPull? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Refactoring save-to-XML
hey remy, have you tried XStream? the API is super simple and it's quite fast. Not sure if it would work, but we recently changed JMeter to use XStream instead. peter > > -Original Message- > From: [EMAIL PROTECTED] > Sent: 7/29/2004 6:56:40 AM > To: [EMAIL PROTECTED] > Subject: [5.next] Refactoring save-to-XML > > Hi, > > I'd like to make this feature less hardcoded (right now, it's ugly ;) ). > A first step would be to extract the code to another helper class, but > that's all I can think of. Does anyone have any ideas ? > > Rémy > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Refactoring save-to-XML
This is a computer-generated response confirming that your e-mail message was received by There. Please do not respond to this message. Thank you for contacting us. We will make every effort to respond to your message as soon as possible. Please do not send multiple e-mail messages (regarding the same subject) before you have received a response as this can cause confusion and possibly delay our response to you. Our Customer Support team is also available via the Live Help link on There Central, from the Help link on www.there.com, or in-world (Get Help>There Live Help). Live Help is available M-F, 2-8pm PT. Thank You, There Customer Support [THREAD ID: 1-20WYZD] -Original Message- From: [EMAIL PROTECTED] Sent: 7/29/2004 6:56:40 AM To: [EMAIL PROTECTED] Subject: [5.next] Refactoring save-to-XML Hi, I'd like to make this feature less hardcoded (right now, it's ugly ;) ). A first step would be to extract the code to another helper class, but that's all I can think of. Does anyone have any ideas ? RÃmy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.next] Refactoring save-to-XML
Hi, I'd like to make this feature less hardcoded (right now, it's ugly ;) ). A first step would be to extract the code to another helper class, but that's all I can think of. Does anyone have any ideas ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
