[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Java question
Tim, JStud here :-). Since my cape is at the dryer, I will be your average Java guru and see if I can answer your questions. I must warn you that my ego is positively radioactive <g>. >I'd like for people who want to use Lark as just a WF checker to >avoid the overhead of downloading 60K of validation rubbish. Lark now >has a method called lark.validate(boolean) and if it's not turned on, >none of those textuality.validator classes will ever get invoked. >However, is an applet loader going to pull 'em all in over the >network regardless? Rules on that issue is very hairy depending on which browser and which version is used. The Netscape browser, for instance, will download referenced classes if there is no method involved. a = b where b is an instance of class B. a instanceof B will cause code verifier to download class B. However, a = b.foo(); will not. Their recommendation is that code like above should be wrapped inside a method like this: public class B { B foo () { return this; } boolean bar(Object a) { return a instanceof B; ) } Frankly, I find all this details troublesome and not worth two tablets of Advil. I recommend staying well clear of it. >I suppose if this is the case, I could create two different Lark >distributions, using the trick documented in the O'Reilly book >where I say > >private static final boolean sVALIDATE = false; > >and then bracket all refs to validation classes with > >if (sVALIDATE) >{ > >} > >which won't get compiled. Above trick causes too much code management problem and is typically used for debugging purposes only. I wouldn't recommend it either. >Or, should I provide stubbed-out class files for the only two classes >that are directly referenced, DTD and Validator? There is no need for stubbing. You can create an interface for the Validator and combine that with Class.forName(). For example: public interface XmlValidator { void doThis(XmlParser ctx); void doThat(XmlParser ctx); } public class XmlParser { public void validate () { ... XmlValidator validator = (XmlValidator)Class.forName("lark.SuperXmlValidator"); validator.doThis(this); validator.doThat(this); } } You will need to wrap Class.forName code with some exception catchers but above code basically allows late-binding to the SuperXmlValidator class and only when it is actually used. You will still need to have the lark.SuperXmlValidator code in the same Zip or Jar file since not all browsers support multiple Zip/Jar. The trick of using invisible applets to load multiple archives does not work either because the browser will use different classloader if Zip/Jar specification attribute is different. Anyway, interface + Class.forName scheme is better for code management since you will only have to change the make file rather than Java source files. >Or, is this worth worrying about? Or is there a standard way to >achieve this effect? Wisdom welcome. -Tim I think it is worth worrying about but there is no standard way. I am afraid that the browser war left the applet world still pretty much in the wild and wacky west state. Hope this helps, Don "JStud" Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|