Hi Kevin!
Thank you very much for looking into the problem! I got something working more
or less ;-) by
deleting items whenever I can. That won't work in a multiuser environment, but
it's only a demo.
And I hope somebody comes up with a solution for booking and scheduling a cargo
in
the dddsample port.
Christian
________________________________________
From: Kevin Meyer - KMZ [[email protected]]
Sent: Tuesday, February 12, 2013 9:19 PM
To: [email protected]
Subject: Re: Porting dddsample app
Hi Christian,
It probably doesn't help you, but I managed to get something like what
you're probably after, using the HTML viewer...
I ignored your execution plan chooser class, and used your
"choicesExecutionPlan" on the ToDoItem itself.
I left the execution plan choices as transient.
In the HMTL viewer, when I then edit a ToDoItem, I can select one of
the 3 transient execution plans.
When I choose "Save", I edited the HTML viewer's EditTask class to
persist any transient properties - which would then persist the 1
execution plan selected above.
Anyway - what this proves is that your problems are with the Wicket
viewer implementation...
Perhaps there is a way to edit the Wicket viewer to achieve the same
kind of functionality.
It's not ideal..
One real question is "Why does the choicesXXX method get called so
many times in the Wicket viewer?"
Regards,
Kevin
On 11 Feb 2013 at 23:33, Christian Steinebach wrote:
> Hi Kevin!
>
> As mentioned in another post, I've uploaded a simplified version of what I'm
> trying to do [1]
>
> The idea:
>
> A ToDoItem might have associated with it an execution plan with tasks. The
> plan is something like
> go somewhere
> do that
> go somewhere else
> and do something else
>
> Several execution plans are generated and the user should select one to
> fullfill the ToDoItem. For 'Buy Milk' it could be
>
> (1) - Go to the supermarket
> get some milk
> pay for the milk
> go home
>
> (2) - Go to the farm
> milk a cow
> pay the farmer
> go home
>
> etc. etc.
>
> In short:
> class ExecutionPlan{
> List<ArrayList> getTasks();
> }
> class Task{
> properties where and what
> }
> class ExecutionPlanService {
> List<ExecutionPlan> getExecutionPlans(ToDoItem td);
> // to generate candidates of execution plans
> }
> class ToDoItem{
> setExecutionPlan(executionPlan ep);
> List<ExecutionPlan> choicesExecutionPlan(){
> return executionPlanService.getExecutionPlans(this);
> }
> }
>
> I've introduced another class
> @NonPersistable
> ExecutionPlanChooser{
> ......
> public List<ExecutionPlan> choicesExecutionPlan(){
> return eps.getExecutionPlans(toDoItem);
> }
> .....
> }
>
> trying to follow a Process Object Pattern (from Dan's book).
> In ExecutionPlanChooser the choicesExecutionPlan() is called 34 times before
> I even hit the drop-down list once.
>
> To run what is there:
> - install the fixtures
> - Select 'all not completed yet'
> - Select a ToDoItem
> - Click on 'Choose Execution Plan' (in the upper right corner)
> - Edit the displayed ExecutionPlanChooser
> - Select an execution plan from the drop down list (there are 34*3 now
> already)
> - click OK
> - Click on 'Do It' in the upper right corner. That will attach the selected
> execution plan to the ToDoItem.
>
> Next time someone tries to choose an execution plan, there will be 69*3
> execution plans to choose from. :-(
> I'm obviously on the wrong track, but I'm out of ideas now.
>
> Any help is very much appreciated
>
> Christian
>
>
>
> [1] https://github.com/chris58/ToDoItemExecutionPlan.git
>
