HalResourceSerializer not extensible

[th3morg]

All of the methods in HalResourceSerializer are private and therefor not extensible. Is there a particular reason you didn't make these methods protected?

I am interested in extending the class and modifying some of the behavior for writing links. In order to do that, I'll now have to copy the entire class to change just two methods and it's not very OO!

My request is that you please make the methods of this class as well as the Deserializer and any other class that could be extended protected rather than public.

If I get a response from you, I would be happy to fork the project and take on the work for this and the other open issue I have regarding Groovy integration.

Thank you for building this wonderful library!

[tfredrich]

As far as I can tell, HalResourceSerializer adheres to the HAL specification with the way it writes links. So, I'm interested to hear more about how it needs to write links differently. Thanks.

[th3morg]

Hi @tfredrich Indeed it does adhere to the HAL specification quite nicely. In fact, it is honestly the best library I found. What I'm getting at in my comment above is that I would like the option to only make use of certain fields for a HalLink and not necessarily all of them (type, title, hreflang... etc). All will be written with null values even if they aren't used. I can sort of get around this by telling Jackson to ignore null values, but then all of my resources' null fields are ignored along with the HalLink fields.

When expanding fields in a collection the response becomes enormous with eight descriptors for each link, given that I have a lot of links in my resources. In this way, it would great to have an option to set only certain HalLink fields to include or allow the Serializer/Deserializer to be overridden in a way that will allow me to do so myself.

Thank you again!

[tfredrich]

Sorry about the tardy response!

I take it by the statements above that you have Jackson serialize even null properties on resources, correct? If that's the case, I wonder how well HyperExpress will work for you since it only copies non-null properties from your domain model into the resulting Resource--which is then serialized. What I'm saying is that you may have to hack part of the AbstractResourceFactoryStrategy and extend/alter its copy functionality too.

Issue #4 is what I'm referring to...

Wondering if there's some sort of Strategy pattern we could do on the serializer/deserializer pair that would enable you to accomplish what you're after?

Interested in your thoughts.

Thanks,
--Todd