Hi, After paying a lot with ERXKey, I came to the conclusion that the current templates are correct. Using the collection as the type seems good at first but if you use aggregation functions they no longer works.
ERXKey have 2 typed methods to get the value: public T valueInObject(Object obj) public NSArray<T> arrayValueInObject(Object obj) When you know the value is an array, use the arrayValueInObject variant. It always works even when traversing toMany relationships to get all the firstName of contacts of some entity like this: NSArray<String> firstNames = SomeEntity.CONTACTS.dot(Contact.FIRST_NAME).arrayValueInObject(anInstanceOfSomeEntity); If you want the latest birthDate: LocalDate lastBirthDate = SomeEntity.CONTACTS.atMax(Contact.BIRTH_DATE).valueInObject(anInstanceOfSomeEntity); There is many operations available and it is probably not possible to determine the final type of an ERXKey chain (array or instance) and using the 2 value getters always works. For relationships, I do not think it can really create confusion but if your key represent an array of String or number values, you will probably use aggregate key one day that will no longer works as expected because your ERXKey have a NSArray type. Is there any benefit to specify the type as NSArray<T> for these ERXKey I do not see ? Regards, Samuel > Le 27 mars 2017 à 00:10, Paul Hoadley <pa...@logicsquad.net> a écrit : > > Hello, > > Say I have a ‘Foo' entity, with a to-many relationship ‘bars’ to a ‘Bar’ > entity. Every Velocity generation template I’ve ever seen will output > something like: > > public static final ERXKey<Bar> BARS = new ERXKey<Bar>(“bars”); > > or, even better: > > public static final ERXKey<Bar> BARS = new ERXKey<Bar>(“bars”, > ERXKey.Type.ToManyRelationship); > > But shouldn’t ERXKey there be parameterized as ERXKey<NSArray<Bar>>? > Admittedly, I’m struggling to see where it would make a huge difference—but > just for completeness? > > > -- > Paul Hoadley > http://logicsquad.net/ > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com > > This email sent to sam...@samkar.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com