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

Convert model to Javabeans #83

Closed
frizbog opened this Issue Sep 27, 2015 · 6 comments

Comments

Projects
None yet
2 participants
@frizbog
Owner

frizbog commented Sep 27, 2015

(See Issue #79)
Model classes to be implemented as Javabeans

@frizbog frizbog added this to the Release 3 milestone Sep 27, 2015

@frizbog frizbog added the enhancement label Sep 27, 2015

@frizbog

This comment has been minimized.

Owner

frizbog commented Jun 22, 2016

Good reason to do this: JSTL and EL don't resolve public members as properties; they need the getters and setters.

@frizbog

This comment has been minimized.

Owner

frizbog commented Jun 23, 2016

Another good reason to do this: having getters would allow lazy instantiation of collections on first access, so that memory consumption is reduced significantly, at least immediately after parsing.

@frizbog

This comment has been minimized.

Owner

frizbog commented Jul 3, 2016

I've started working on this on branch v3-development

frizbog added a commit that referenced this issue Jul 4, 2016

@frizbog frizbog self-assigned this Jul 4, 2016

@dszqqjf

This comment has been minimized.

dszqqjf commented Jul 4, 2016

In the new object model classes has consideration been given to avoiding actually exposing the Java Collection Framework interfaces as part of the API so that it might possible to switch to different internal implementations in the future without needing to change the API? For example, in the Gedcom class in the v3-development branch I see it currently uses java.util.HashMaps internally and the associated getters and setters expose java.util.Maps. Might that limit the ability to support alternate internal implementations in the future such as a primitive collections framework like Trove or an in-memory database like MapDB? Instead could families, for example, be exposed by a new Families class that has methods to add, update, delete, get and iterate on the contained Family objects? That might also be more friendly to exposing the API via REST which would support modern web UI use of the library. From a REST perspective Families would be the natural resource between a Gedcom resource and a Family resource.

@frizbog

This comment has been minimized.

Owner

frizbog commented Jul 4, 2016

I hadn't considered that, no. I did look at the Trove framework as a possible aid to reducing the memory footprint but I didn't want to introduce transitive dependencies to users...but that doesn't mean I couldn't do what you're suggesting.

Seems to me like there is a lot of advantage in implementing the Java Collection Framework interfaces ... those interfaces are ubiquitous and everyone knows how to use them, including other tools. I suppose if this were done, and it interfered with some technology that expects things to implement Java collection interfaces (like JSTL and EL) then the non-Java collections could be wrapped in Java collections, perhaps.

That said, writing wrapper classes around all the collections (and there are LOTS of them) could be done.

This will require some thought.

@frizbog

This comment has been minimized.

Owner

frizbog commented Jul 16, 2016

Releaed in v3.0.0

@frizbog frizbog closed this Jul 16, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment