Hi Dan!
Thanks again for your comments. I'll try to implement your suggestions.
Christian
________________________________________
From: Dan Haywood [[email protected]]
Sent: Thursday, February 14, 2013 9:17 AM
To: [email protected]
Subject: Re: choices0XXX
On 14 February 2013 01:26, Christian Steinebach <
[email protected]> wrote:
> Hi Dan!
>
> Thanks a lot for all your comments! Took some time to digest them all. ;-)
> I didn't know that choices had to be persistent.
I don't know that it's documented anywhere :-( I guess more correctly they
should be persistent entities or values (eg strings)
> I ended up deleting the unwanted entities as you also suggested.
> That the choicesXXX methods are called so many times could be a problem.
>
With ISIS-330 [1] it is called nowhere near so many times... in fact it
wasn't called at all with your example until an instance of one of the
entities was rendered in edit mode.
> In my case I use it to find alternatives of shortest paths from one
> location to another.
> In a 'real world' application this search will not be idempotent. Service
> providers are coming
> and going, the list of offers is dependent on date and time etc. etc. So
> this search must
> only be initiated be a user request.
>
It does sound to me that you would want to persist each offer because there
is information to capture: when the search was made, how long it is valid
for, which service provider offered it and so on.
> Originally I wanted to display a table with alle the TransportPath
> alternatives with a check box in each row.
>
So, a further thought... perhaps this concept - a collection of alternative
TransportPaths - should be an entity in its own right. Lets call it
TransportPathSpecification. Thus, the parameters of the search would be
properties of this new TPS entity, and the available TransportPaths would
be a collection of this TPS entity.
In this case, the table you are rendering isn't a full-width standalone
table, its a parent table on the RHS of this entity.
> But I couldn't find out where I had to put the @Bulk annotation to make it
> happen. :-(
>
With your original design it would have gone on the TransportPath entities,
but they would have needed to know information about who requested them.
In my TPS design, this sort of behaviour would move up to the TPS entity.
HTH
Dan
[1] https://issues.apache.org/jira/browse/ISIS-330
