Re: [wildfly-dev] Logging Model Changes and Questions
On 07/01/2013 02:58 PM, Brian Stansberry wrote:
Thanks for the input Brian. It really makes a lot of sense.
--
James R. Perkins
Red Hat JBoss Middleware
I don't see much benefit in B vs having 2 attributes,
"pattern-formatter" and "custom-formatter", with the current
"formatter"
just an alias for "pattern-formatter.format-pattern".
With a single "formatter" in B the attribute description is going to
have to describe how in the complex attribute there are two possible
keys "pattern" and "custom", only one of which is valid at a time. A
client is then going to have to figure out which of the two a given
response includes and parse accordingly.
Your option B really looks more like you have a child resource type
"formatter" instead of an attribute, with two legal values for the
resource name -- "pattern" and "custom".
Excellent points. I
think that does make the most sense. The only
problem I have with it is that there are 3 formatter options, but really
only one can be uses. Well 2 I guess with the
formatter/pattern-formatter. I'm probably just be picky and whiny at
that point though :)
> A model change
> like this would also require some transformers for backwards
> compatibility. Though that doesn't really bother me all that much.
>
It also breaks any existing clients who are expecting the "formatter"
attribute to be ModelType.STRING.
Again, good point. I hadn't thought about
that part. I'm glad I asked.