Postprocessing of documents returned by Template class before moving to final destination

[ghost]

Currently, Template class has the "save()" method with the followed signature.

/**
 * Save Template
 *
 * @param string $strFilename
 */
public function save($strFilename)
{
    ...
}

In most cases that's fine, but in some situations this approach it's not optimal enough.

For example, we have a batch of templates and we need to perform the followed actions with them.
a) Substitute macroses in each template.
b) Pack all the result documents in ZIP-archive and move this archive somewhere.

In such situtation Template class of current implementation allows us to do this, but it will require to save processed templates somewhere which involves unnecessary file copying. Moreover, we will have to delete these garbage files after archiving.

So, suggestion is to give options.

1. To save the processed template in the current location (temporary directory) with it's current unique name. This allows user to do whatever he wants with the document in temporary directory before the file will be moved to final destination.

/**
 * Save Template
 *
 * @return string
 */
public function save() {
    ...
}

2. To save the processed template in the user defined location with user defined filename.

/**
 * Save Template As...
 *
 * @param string $strFilename
 */
public function saveAs($strFilename) {
    ...
}

[Progi1984]

For improving this enhancement, you could do that :

public function save($strFilename = '') {
}

No ?

[ghost]

Yep, sure, this is good solution. This approach is backward compatible and takes minimum lines of new code. In the same time it has some disadvantages.
a) Not clear enough. An empty string doesn't seem to be a valid filename.
b) Logical issues. For example, I can't understand why API should "eat" an empty string on input just to save file in its current place. There is no logic.
c) Usage problems. Input string may be empty by a mistake. In your case API just saves the file instead of alerting somehow about the problem. My approach gives a chance to handle this situation (I didn't do that yet).

From the other hand, my approach makes the implementation more clear, logically correct and easy to use. In the same time it's not backword compatible and requires more lines of code than yours.

I thought that we are not competing here for some The Most Short Code award, so I gave preference to more clear and understandable code.

Does it makes sense?

[Progi1984]

Yes, now... I understand your approach and I agree with it. Thanks. I close your ticket.