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

Support for inserting events #79

Open
LukeDowell opened this issue Feb 5, 2016 · 1 comment
Open

Support for inserting events #79

LukeDowell opened this issue Feb 5, 2016 · 1 comment

Comments

@LukeDowell
Copy link

Hello,

I've been implementing support for inserting events:
https://developers.google.com/google-apps/calendar/v3/reference/events/insert

I'm a relatively junior developer so I figured I would ask some questions before making a pull request. The idea is to be able to say
Event responseEvent = google.calendarOperations().insertEvent("primary", newEvent, false);
with newEvent being a locally constructed org.springframework.social.google.api.calendar.Event.

I was unable to implement that without making Event 's constructor public, and adding a bunch of setters to the Event object and it's related inner classes. Is that bad practice? I can see that Event was initially protected to ensure that an Event had to be pulled from a calendar, is there any other architectural reason to leave it that way?

My code can be found here on the "insert_event" branch: https://github.com/LukeDowell/spring-social-google/tree/insert_event

Apologies if this isn't the correct place to discuss this, and thank you for your time!

@GabiAxel
Copy link
Collaborator

GabiAxel commented Feb 5, 2016

Thanks for contributing.

If you want to have a non-default constructor for deserialization, you need to add JsonConstructor on it. I chose not to use non-default constructors because it looks really cumbersome for large amount of parameters, didn't want to make the client code have nulls for every parameter it doesn't need, and didn't want to deal with changing the constructor signature or add another constructor when new versions introduce new parameters. Also, for update operations you would need setters anyway.

A good practice when a class has a lot of properties could be to add a builder. See DriveFile for example.

The calendar was WIP and I didn't get to finish it, so I welcome your help, and do feel free to change things you think should change according to your experience with the Calendar API. Just try to stick to the conventions of the rest of the project.

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

No branches or pull requests

2 participants