Closed gokulvanan closed 5 years ago
String name based customization is already provided by DataBuilderInfo.
The usecases for these are as follows: 1) DatabuilderInfo -> use where components are loaded dynamically at runtime. 2) DataBuilderClassInfo -> Used primarily as a library, for type safety.
Do you see other usecases?
DataBuilderClassInfo enforces builder names in data attribute to to be Canonical name when serialized.. This is right as it prevents namespace collision. But it makes the whole data label verbose and hard to read.
In one of my use cases, I wanted to use class.Simplename() as my builder where named differently without any namespace collisions as this improved readability in JSON string of the DataflowInstance. I agree this can be done done with DatabuilderInfo but felt that using DataBuilderClassInfo shouldn't restrict the naming logic derived from the class Object.
enforcing this should be optional and will lead to collisions of name in large(ish) projects. You can go ahead with this change under a flag, but in general this should not be encouraged as it compromises (namespace) safety.
Upset the established order, and everything becomes chaos. I'm an agent of chaos. Oh and you know the thing about chaos, it's fair.
On Wed, Oct 14, 2015 at 11:51 AM, gokulvanan notifications@github.com wrote:
DataBuilderClassInfo enforces builder names in data attribute to to be Canonical name when serialized.. This is right as it prevents namespace collision. But it makes the whole data label verbose and hard to read.
In one of my use cases, I wanted to use class.Simplename() as my builder where named differently without any namespace collisions as this improved readability in JSON string of the DataflowInstance. I agree this can be done done with DatabuilderInfo but felt that using DataBuilderClassInfo shouldn't restrict the naming logic derived from the class Object.
— Reply to this email directly or view it on GitHub https://github.com/flipkart-incubator/databuilderframework/issues/12#issuecomment-147949580 .
agreed.. will keep this as optional parameter in an overloaded method to inject an optional NameResolver implementation along with registering @DataBuilderClassInfo annotation.
Reopen if you ever decide to send a patch.
With the annotation DataBuilderClassInfo we get to specify classNames rather than String names. But this involves using the canonical name of the class by default. We will need to provide ability to customize this and expose that to client configuring DatabuilderMetaManager such that they can choose to use their logic like using simpleName rather than canonicalName.