[dev] Re: whups: Batch changes on tickets

[Jan Schneider]

Zitat von Auke Bruinsma <air2 at dds.nl>:

> 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.

Makes sense. I wasn't sure (because I was too lazy to look at the code) 
if we already have a ticket object or manipulate tickets through a 
functional interface of the sql driver.

>>> 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.

The latter. It's a wrapper class only for code readability anyway, so 
it should be rather verbose.

>>> 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;
> }

Ah, no, I don't think this is necessary. We should stick to either concept.

> 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)

A seperate class, like we do elsewhere in Whups. But you can probably 
put them into one file. Again, look at how we do it with other classes 
in Whups.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/