Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Allow to nest same path Segment or Element in SegmentGroup (not consume it) #97

Open
SylwesterZarebski opened this issue Jun 6, 2018 · 0 comments

Comments

@SylwesterZarebski
Copy link
Contributor

SylwesterZarebski commented Jun 6, 2018

I would like to allow to use Segment or Element with same path as SegmentGroup - reconsider #32 or #36.
This would allow this class definition as:

[EdiSegment, EdiPath("NAD")]
public class NAD
{
    [EdiValue("X(3)", Path = "NAD/0/0")]
    public string CodeQualifier { get; set; }

    [EdiValue("X(35)", Path = "NAD/1/0")]
    public string PartyIdentifier { get; set; }
}

[EdiSegmentGroup("NAD", "FII", "RFF", "CTA")]
public class SG2
{
    public NAD NAD { get; set; }

    public List<SG3> RFFs { get; set; }
}

instead of:

[EdiSegment, EdiPath("NAD")]
public class NAD
{
    [EdiValue("X(3)", Path = "NAD/0/0")]
    public string CodeQualifier { get; set; }

    [EdiValue("X(35)", Path = "NAD/1/0")]
    public string PartyIdentifier { get; set; }
}

[EdiSegmentGroup("NAD", "FII", "RFF", "CTA")]
public class SG2 : NAD
{
    public List<SG3> References { get; set; }
}

Both examples allow to reuse classes, but first one is clearer because it explicitly defines Segment property. It is also more intuitive for newcomers (i was bitten by it) than second form.

In general it could allow deeper type of "element" in outer one (like Segment or Element in SegmentGroup, but not SegmentGroup inside SegmentGroup).

This would change:

Classes that are decorated with Segment, SegmentGroup, Message, Group or Interchange consume the segment that defines the contrainer and cannot be reused inside them.

I'm not sure if it would break compatibility, but it should not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants