allykzam/amazingant.fsharp.typeexpansion.templates

Templates for use with the Amazingant.FSharp.TypeExpansion tool

amazingant.fsharp.typeexpansion.templates's Issues

[FromXml] Include the target property name when throwing an exception because TryParse failed

While working with the same XML sample that led to #14, got an exception stating Invalid value '' could not be parsed as a 'System.Int32'. Notably missing from the message is any indication of which property it was trying to parse an int for.

[ImmutableViewModel] Add new template

Had a crazy idea quite some time ago for a template that builds a view model suitable for use with WPF bindings, and bases it on an immutable data model. Creating an issue here so that the current code can be placed in an appropriate branch.

[FromXml] Add support for sum types?

Still just playing with an idea, documenting it here so I can come back and read this later to see if it sounds insane or not.

Initial thought, given the following sum type:

type SumType =
    | OneOption of Value : int
    | OtherOption of Text : string

Any of the following could be processed as OneOption(4):

<Thing>
    <OneOption>4</OneOption>
</Thing>

<Thing>
    <OneOption>
        <Value>4</Value>
    </OneOption>
</Thing>

<Thing>4</Thing>

And any of the following as OtherOption("Test"):

<Thing>
    <OtherOption>Test</OtherOption>
</Thing>

<Thing>
    <OtherOption>
        <Text>Test</Text>
    </OtherOption>
</Thing>

<Thing>Test</Thing>

The first XML option in either set assumes that sum type cases will only ever contain a single field, and therefore the matching node's contents can be used. The sum type case names can then be matched as a node or attribute name as is currently done for product type fields with no attributes.

The second option is a bit strict, but would easily allow any number of fields so long as they had names. If the fields do not have names, perhaps we could fall back to the order of the fields and the order of the XML nodes? But that seems dangerous; it would be safer to disallow FromXml expansion on sum type cases with unnamed fields.

As with the first option, the final option also assumes that the sum type cases will only contain a single field. Instead of going by field name, this option would select the appropriate case based on which field can be successfully parsed. This also seems dangerous; what happens when one case contains a single integer field and the other contains a string? Putting a case with a string field near the beginning of the sum type declaration would cause that case to match before any of the others. Seems like this kind of support is better done by reminding myself that I can just add a static TryParse function on sum types, although it would be nice to provide an easy way to allow "nested" FromXml-expanded types as fields in a sum type's cases.

[FromXml] Add testing of input XML

Need to work up some sample XML files and test against them so that I can start playing with ideas for simplifying the generated code without breaking anything.

[Lenses] Add tests

[FromXml] Regression: Ignore underscores in node/attribute names

As of version 1.2.1, the FromXml template ignored underscores in node and attribute names. This was missed in f804462, and has caused some regressions downstream. Need to fix and add tests for this.

FromXml template tries to set properties that are not record fields

Should use the incorrectly-named isUnionField code from the lenses template

[FromXml] Some field names that are valid uppercased are not valid lowercased

Noticed that I can build a record with a field named In and another named Out and that compiles fine, but in the generated code, the lower-cased names for these two fields, in and out respectively, are F# keywords and cannot be used directly. Temporary solution is to turn off the type provider and gratuitously sprinkle back-ticks everywhere until the compiler errors go away.

[FromXml] Add processing of validation functions if they exist?

Would like to be able to perform validation after a record type is processed from XML; will want to either settle on a function name and signature to look for, or add an attribute to denote validation functions.

Add basic testing?

Should be easy enough to add some basic sample code for each template. Initial expectation is that for each template, there should be:

• Source types that test each of the expected valid cases
• A copy of what the expanded results should look like
• Any needed input files (XML files for the FromXml template)
• A script that:
  • Uses the expansion library on the source types
  • Uses any input files and validates the results
• One or more scripts that use invalid source types

With the above established, it should be possible to add a build target for testing which iterates through the test directories for each template and:

• Deletes the expanded source file if it exists
• Runs the good script and validates that it was happy with the expansion results
• Checks to see that a new expanded source file has been created
• Compares the new expanded source file to the sample expansion
• Runs the invalid scripts and validates that they are each unhappy

[FromXml] Handle validation methods whose names contain spaces

Need to wrap validation function names with backticks, so that they can have spaces in their names. Because I am a horrible person who puts spaces in function names.

[FromXml] Nested type in a list option results in malformed expansion

Including a (Thing list) option results in expanded code like this:

let ``field`` =
    let xs = findAllNodes children "nodename"
    |> Seq.toArray
    if xs.Length = 0 then None
    else xs |> Array.map Some.Type.Here.FromXmlNode |> Array.toList

When it should result in this:

let ``field`` =
    let xs = findAllNodes children "nodename" |> Seq.toArray
    if xs.Length = 0 then None
    else xs |> Array.map Some.Type.Here.FromXmlNode |> Array.toList |> Some

Or, more aesthetically-pleasing:

let ``field`` =
    let xs = Seq.toArray (findAllNodes children "nodename")
    if xs.Length = 0
    then None
    else
        xs
        |> Array.map Some.Type.Here.FromXmlNode
        |> Array.toList
        |> Some

This appears to be the source.

[FromXml] Improve handling of bad XML

Although it eventually leads to a useful point in the expanded code, the exceptions thrown when a given XML document is not valid are...less than helpful? Would be nice to add some validation code to improve the messages that come out.

[FromXml] Add nested type support for the XPath attribute

Going to want this at some point, as it is already bothering me that it does not exist. Will likely ignore for the moment and try to work on this sometime in the next few weeks?

Add a test build target

For each sub-directory under the tests directory, the test build target should:

• Delete the expanded source file if it exists
• Run the good script and validate that it was happy with the expansion results
• Check to see that a new expanded source file has been created
• Compare the new expanded source file to the sample expansion
• Run the invalid scripts and validate that they are each unhappy

[FromXml] Allow specifying nested node/attribute names

Would be nice to use the following XML and source type:

<Person>
    <PhoneNumbers>
        <Phone>123456789</Phone>
        <Phone>987654321</Phone>
    </PhoneNumbers>
    ...
</Person>

...
type Person =
    {
        [<XmlNode("PhoneNumbers/Phone")>]
        PhoneNumbers : string list;
...

It may be worth creating a new attribute that can be used to just specify an XPath to follow?

[FromXml] Helpers.tryInnerText does not return the inner text

[Lenses] Expanded results do not compile

Need to open Amazingant.FSharp.TypeExpansion.Templates.Lenses for each module, and need to update the calls to makeStaticLens -> MakeStaticLens and compose -> Compose.

[FromXml] Adjust optional fields to populate as `None` if the target node(s) are empty

Testing with some data at work, and finding that an exception is thrown when trying to parse out an int option from an empty node. Except this is exactly why I marked the field as optional. Need to adjust the behavior so that if the InnerText property for a node is an empty string, the value is automatically None if populating an optional field, otherwise I'll just end up marking these fields as string and writing more code that this template is supposed to take away from me.

[FromXml] Add tests for invalid source types