problems customizing a transaction set about stupidedi HOT 3 CLOSED

Hey Alex, I'm going to close this issue. It sounds like you're okay with the proposed solution and I think a better looking solution will take more time than it's worth. I agree on having a guide that walks through various configuration scenarios, but I don't know that I'll be able to set aside time for that in the near future.

from stupidedi.

Hey Alex,

Thanks for the detailed report, especially the code. Now that I've actually read the full example, I can delete my very long response, and the issue is trickier than I anticipated! :-)

There's nothing wrong with your definition. I think the problem is how Stupidedi looks up the segment definitions when reading a file or building one with BuilderDsl. My recollection is that it goes like this: you call b.N1 then BuilderDsl looks up the definition for N1 in the SegmentDefs module for the version you're using (FortyTen). That association is made when you register the 4010 functional group in the Config. That FunctionalGroupDef refers to the N1 defined by Stupidedi, so your custom N1 definition isn't used.

Ideally you wouldn't need to do anything beyond what you've already written, and it would be handled behind the scenes. I need to do some thinking about how/if this could be possible though. The underlying assumption currently is that there's a single definition of a segment for each X12 version. Removing that assumption might be possible but tricky to do correctly.

But in the mean time, I think you can define your own FunctionalGroupDef with something like this:

module MySegmentDefs
  include Stupidedi::Versions::FortyTen::SegmentDefs
  N1 = ...
end

# Despite the capitalization, this is actually a singleton instance of an anonymous class
# that inherits from Values::FunctionalGroupDef. We need to override one method.
MyFunctionalGroupDef = Stupidedi::Versions::FortyTen::FunctionalGroupDef.clone

class << MyFunctionalGroupDef
  def segment_dict
    MySegmentDefs

    # You can also not use `include` in the module above and do this instead
    # Stupidedi::Reader::SegmentDict.build(super).push(MySegmentDefs)
  end
end

config.functional_group.register("004010") { MyFunctionalGroupDef }

There are a few different ways to write that, but I think that's clearest. Sorry that you need to write that to get it to work, it annoys me just looking at it... at least it's not a lot of code 🤷‍♂️. If I figure out a better way to handle it and I'll let you know, but it probably won't be soon.

from stupidedi.

@kputnam thanks a million for this input. i've tried out your suggestions and it seems to behave just as i'd expect. i can add/remove elements from segments with a minimum of fuss. this is excellent. (Much better than the dirty hacks we've been doing (like modifying Stupidedi::TransactionSets::FortyTen::Implementations::IM210.table_defs at runtime to patch in our modified segment definition...)

I think the problem is how Stupidedi looks up the segment definitions when reading a file or building one with BuilderDsl.

yes, and this was part of the stupidedi code i was never able to piece together on my own. your explanation clears it up nicely.

Ideally you wouldn't need to do anything beyond what you've already written, and it would be handled behind the scenes.

Perhaps, but so far it seems like the alternative you've offered here will serve nicely. I'll try unwinding some of our current hacks and see if I can straighten things out using the approach you describe here. Assuming that goes OK I don't see any need for further action - though a "how to customize segment definitions" guide might be a useful addition.

from stupidedi.