[dev] Re: whups: Batch changes on tickets

[Auke Bruinsma]

Jan Schneider wrote:

>Zitat von Auke Bruinsma <air2 at dds.nl>:
>
>  
>
>>As pointed out in ticket 1612 (http://bugs.horde.org/ticket/?id=1612)
>>some batch execution should be handy. So I am thinking about the best
>>approach of implementing such a feature. My approach would be to make a
>>new object (Whups_Batch) when its created an array of tickets must be
>>provided. The object has multple actions, like: Move, Change (this
>>includes assign, comment, new queue etc.), Delete, Commit.
>>    
>>
>
>This sounds like a nice, abstract solution, but wouldn't it be much 
>easier to change the existing methods that currently update tickets and 
>accept a single ticket ID, to also accept an array of IDs?
>  
>
This could maybe easier, but I think it would be confusing. A ticket 
object that represents a ticket and can execute actions at that ticket 
itself, but also actions on a batch of other tickets. So I thought it 
would be nicer to let the actual "doing someting to a ticket" stay in 
the Ticket class and to put the looping thru an array, the error 
handling (go on on error, or stop on error) etc. in a new class.

>>Maybe the Move already includes delete (move to nowhere) but the
>>downside of this is, that it is not possible to check for accedently
>>empty destinations. So I think there should be a protected _move and a
>>Move and Delete who both call this _move. But if Delete is totally
>>different from move, they must be seperated.But Move is also included in Change, so maybe just make only a Change
>>
>>implementation. Or make functions that call the change implementation.
>>Like done in the Ticket class.
>>    
>>
>
>This should be left to the concrete driver implementation. The only 
>driver we currently have, the SQL driver, would need different methods 
>for moving and deleting. Actually you shouldn't need to care about that 
>at all, because however you implement the batch "container", you would 
>still call the exiting methods for single tickets and don't have to 
>care about their implementations.
>  
>
I more was thinking about the functions that should be provided  by such 
a Batch class. Should it just provide an abstract change class, or 
functions like: Delete, Move, AddComment, NewState. This functions 
offcourse should use somekind of change, which calls, the change 
function of every ticket.
Like (ugly example only to point out what I mean :) ):

Batch::Move {
   $this->_change ['move'] = $newloc;
   $this->Change ();
   on error: do something
}

Batch::Change {
    loop thru $tickets
         Ticket::Change ($change);
         on error:
            do something..
    done
}

>>All the actions should optionally supplied with the ticket array. If
>>none is given, the one given when the Batch class was created should be
>>used. If none is given an error should be raised.
>>    
>>
>
>Huh?
>  
>
Like (again ugly example, hopefully make things more clear):
Batch ($tickets = null){
  $_tickets = $tickets;
}
function Move ($tickets = null)
{
     $usetickets = null;
      if (count ($tickets)) $usetickets = $tickets;
     else $usetickets = $_tickets;
     if (!count ($usetickets)) return error;
}

>><some bad idea>
>>    
>>
>That's a bad idea, unpredictable behaviour is inevitable with such a solution.
>  
>
I agree :-), but maybe it inspires someone and someone makes a good idea 
from it :-).

>Jan.
>
An other thought...
Should the forms gointo this Batch class, or should a seperate class 
contains the forms and then call the Batch class.
The first puts all together at one clear place (which can be a pro)
The second seperates the gui from the code (which can be a pro too)

(Personaly I should prefer the second method)
Auke