This project is read-only.

Questions and Answers

These can't be called FAQs yet but it's expected that these will be often-asked questions. This page is similar to the Notes page, just different format.

 

  1. Q: Why was the Microsoft 'xsd.exe' tool used to generate schema, and then to generate C#, compared to a tool like xsd2Code or xsdToClasses?
    A: I didn't want to introduce too many moving parts. Microsoft tools are simple to use and document, and everyone has them. Other tools might be better but they change periodically, have a learning curve (usually little documentation) and their own share of bugs. I'm just trying to get from point A to B here, and if this project relies on the stability of another one, then progress for anyone who uses this will be hindered, even though the results might be better when everything is working just right. I just want to minimize dependencies so that I don't wind up supporting someone else's project in the name of getting satisfactory results for this one - been there, done that. Also note that other tools generate code from XSD, they don't generate XSD from XML. So for a new release of TDL with new XML, we need xsd.exe anyway, and I didn't want to have to deal with yet another tool which might misbehave when presented with something new from XSD generated from xsd.exe.
  2. Q: Why not just use the code that xsd generates and be done with it?
    A: Just look at the code I've written over and above what's provided by XSD. If you want to use XSD-generated code, you've been able to do that for a long time.
  3. Q: Why create a new "SafeTask" class compared to making use of the Partial classes generated by XSD.
    A: XSD exposes properties based on the node names in the .tdl file XML. The ALLCAPS names are a bit annoying, sometimes inconsistent, and in a couple cases there are mis-spellings. This doesn't affect the ToDoList software at all, since by it's nature that is the one-and-only bit of software that needs to deal with these anomalies. Unfortunately user-developed tools that report on the XML via XSL have been building upon this. I decided not to start a whole new line of development based on anomalies - it's a chance to start over and I wanted to take it.
  4. Q: Why continue to use the classes generated by xsd.exe at all when SafeTask is all we need?
    A: The generated class provides assistance with serialization that I'd rather not handle manually. And because it's easy to regenerate that class from schema, and schema from a current .tdl file, the SafeTask "should" break if the underlying generated code changes. That's a good thing. We want to take every measure possible to ensure we don't trash our .tdl files.
  5. Q: Why isn't DataSet code generated from the XSD?
    A: The resulting code would be bound to the schema names. I'd rather have datasets bound to the more elegant SafeTask and related classes. So DataSet code will be built upon the wrapper classes.
  6. Q: What's with all the 'Get' and 'Set' methods for primary data types?
    A: This is centralized to allow for standard handling and especially error handling. Each data property is thus more concerned with the data on which it's operating, and not the mechanics by which it's processed from the underlying data source. In particular many XML nodes and attributes disappear from a .tdl file when the value is null. So the library supports a number of nullable data types. The Helpers functions help to ensure that we really do have null and other value values for data instead of spaces, or other type-specific defaults.
  7. Q: Why are some classes implemented with properties and others with public fields?
    A: I'm not a fan of unnecessary getters and setters. If a field requires special processing it will have a get/set. Otherwise not. That's not a rule, and there are exceptions. It's easy to change this without affecting app code.
  8. Q: The .xsd that comes with ToDoList is old and inaccurate. Does Dan get the new one from this project?
    A: Yes, he'll get a new .xsd every time there's a new one. See Sync. This should help people who want to use XSLT for reporting. Related to that, at some point soon we should be able to go the other way, and generate schema from the ToDoListLib classes. I haven't thought about this too much yet but it's possible that people might want to use this for reporting with strongly-typed data rather than the simple Strings and Arrays defined by the default TDL schema.

More Q&A will be added here based on feedback in the Discussions area and elsewhere.

Last edited Feb 17, 2014 at 3:21 AM by TonyGravagno, version 2