I think it will be better to implemented this in Zend_Service_Amazon_S3 to avoid code duplication.

Hi Pawel,

This had crossed my mind, but I am not sure how that would work since the path to view helpers is 'Zend_View_Helper.'

I had also thought about somehow using a Zend_Service_Amazon_S3 object to help out, specifically with the keys. I'm still looking at this, but I don't want to introduce functionality to the view helper that it really has nothing to do with.

Thanks for the comment.

The following describes an issue I am dealing with. (posted on the mailing list also)

What is the preferred approach to supply constant values to a View Helper?

If a view helper requires configuration constants. For example, a google api key or amazon web services access keys, is it best to:

A) Make the developer put these values in a Zend_Config object and then access the config object in the View Helper's constructor?

B) Make the developer assign the values as view variables and access them with $this->view->var inside the view helper?

C) Pass the variables to the view helper when it is called in the view script?

I am not a fan of any of these choices, but if I had to pick one I'd go with A.

I like the fact that A centralizes the constants in a relatively secure spot. They would be sitting next to database passwords, etc. But I don't like the constraints it places on the developer. Not only would Zend_Config need to be used, but the config object would either need to be stored in a registry, or created inside the view helper. Even if I create the Zend_Config object inside the view helper, I would still need to pass the constant params needed for Zend_Config...

I don't like the idea of adding what could be sensitive information, the aws private key for example, to the view object, so that eliminates B and C.

I think C is the worst of all because it adds an extra var to supply when calling the view helper.

What other options are there if any? What would be acceptable dependencies for a Zend_View_Helper?

To make things slightly more complicated, I guess there is the possibility that these "constant" values could change during the life of a single request or on a page by page basis, thus they would no longer be constant. This could happen if someone uses two or more AWS accounts for example. This could be dealt with, but would add complexity.

I want to make decisions that result in the most flexible and easy to use view_helper possible.

I think this is the only issue holding up the completion of the prototype code.

The view helper I created to accomplish what is outlined in this proposal uses a Zend_Config object stored in Zend_Registry. While this works great and might be fine for my colleagues purposes, I am not sure it is a viable solution for a Zend Framework component.

Regarding my previous post. I have added accessor methods that will allow the AWS access and secret keys to be set prior to the view helper being called in a view script.

The finalized prototype will check Zend_Registry for each of the keys and set them if they exist in the registry and have not been set by the accessor methods.

Thanks to Matthew Weier O'Phinney for pointing me in the right direction.

I still think, using already available class Zend_Service_Amazon_S3 will be better. Why?
You can do in your bootstrap/controller/whatever:

Zend_Service_Amazon_S3::setKey($accessKey, $secretkey);

or pass whole object into registry.

Then in view heleper your method s3link can use that object. Or move that method to Z_S_A_S3 and proxy to it. Sometimes this link is needed in other places than view.

Only one simple patch in Zend_Service_Amazon_S3::addSignature to generate proper key. (or 2 if you wont to set something differ that sha1)

In my scenario you duplicate only code to build endpoint url. Or refactor this piece of code from _makeRequest to another public function.

Pawel,

Thanks again for the comment. I struggled a bit with the decision not to use Zend_Service_Amazon_S3 for the reasons that you mentioned, but, for now, I like the idea of separating the view helper from the Z_S_A_S3 class.

There is some code duplication, involving the setter methods for the keys and the endpoint. The computation of the signature, expiration time, and construction of the URL are specific to the view helper.

I can imagine a use case where Z_S_A_S3 is not used by the developer, while the view helper is. I also want to avoid dependency on a registry or bootstraping in order to use the helper.

I'm not discounting your thoughts, though I am interested in receiving more feedback about this before making a final decision.

I don't think the view helper object can access the AWS keys from the Z_S_A_S3 object as they are protected and accessor methods do not exist.

The other method you are suggesting is to include the methods that create the query string URL in the Z_S_A_S3 class, then using the view helper to retrieve the S3 object from the registry and call this method. Is that correct?

Perhaps there is some middle ground somewhere?

Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.