[fw-general] Re: S3 and Queue
The main API should be close to frozen at this point and the Stream wrapper utilizes it. I have not had time to write any unit tests and documentation. The API could probably use a little more testing, specifically around how Amazon handles 100 Continue headers. I was trying to figure out a way to support that in the S3 class, but I think we'd need to add it to Zend_Http_Client somewhere (I submitted an issue on this). Range support on GET requests also seems a little off (the code works as intended, but Amazon wasn't returning just the specified ranges and would return everything, but I could have done something incorrectly). That's about it. I hope someone can finish it up. Thanks. -Justin Ralph Schindler wrote: So it looks like the API is looking pretty good at this point, and its somewhat different (in a better way) than the one laid out in the proposal. Is there any chance you can give us a state of the union on the component, and the directions you'd like it to go in? How much if any is done in the way of unit tests/docs. Etc. Just want to get a sense of what level of work is left. It appears a lot of people are interested in this! Thanks! Ralph On 1/27/09 11:46 AM, Justin Plock jpl...@gmail.com wrote: Correct. Thanks. -Justin On 1/27/09, Ralph Schindler ralph.schind...@zend.com wrote: Just to confirm, this is your code right: http://framework.zend.com/svn/framework/laboratory/library/Zend/Service/Amaz on/S3.php -ralph On 1/25/09 9:33 PM, Justin Plock jpl...@gmail.com wrote: Would anyone like to take over development of my two proposals: Zend_Service_Amazon_S3 and Zend_Queue? I don't have the bandwidth right now to complete these two projects and I hate to leave them sit in the laboratory and incubator. Thanks. -Justin -- Ralph Schindler Software Engineer | ralph.schind...@zend.com Zend Framework| http://framework.zend.com/
[fw-general] S3 and Queue
Would anyone like to take over development of my two proposals: Zend_Service_Amazon_S3 and Zend_Queue? I don't have the bandwidth right now to complete these two projects and I hate to leave them sit in the laboratory and incubator. Thanks. -Justin
[fw-general] Re: S3 Service / CDN using ZF
robert mena wrote: Hi, I've searched the archives but could not find anything new about a Zend_S3 (for Amazon's S3 service). The idea was dropped? I'd like to use Amazon's S3 to store image files and direct the users to their servers when they are not local. I'd need to use some GeoIP or other method to define the URL to serve the users. Thanks Zend_Service_Amazon_S3 is in the incubator if you'd like to try it out. You register it as a PHP stream and then use it like you'd access normal files. -Justin
[fw-general] Re: Zend_Net Package?
A.J. Brown wrote: Hello all, I wrote a library for matching IP addresses, ranges, and networks against eachother with support for subnet masks, CIDR, and IPv6 a few months ago. It's useful for writing IP filters (firewall-esque) and such. It uses bitwise mathematical calculations to do the matching, so it's quick and solid. I'd like to adapt it into Zend Framework. What are your thoughts on creating a Zend_Net package? Here are some quick off-the-top classes I think would be useful: Zend_Net_Address (for example) * Class to represent and translate IP addresses (IPv4 - IPv6 for example) * Class to represent and translate network addresses * Class to represent other protocol addresses, such as MAC address * Class to handle matching an input IP or range against a pool of classes from the above examples quick ex: $oNetwork = new Zend_Net_Address_Network_IPv4( '192.168.0.0', '255.255.255.0' ); // give me an array of Zend_Net_Address_Host_IPv4 objects within this network $aAddressesIp4 = $oNetwork-getAddresses(); // tell me the class of some IPv4 address $oHost = new Zend_Net_Address_IPv4( $sUserInput ); echo $oHost-getNetworkClass(); // is the address a private address? echo $oHost-isPrivate() ? 'yes' : 'no'; What are your thoughts? I can think of a few use-cases where this would be useful for rapid development and easy cooperation with the rest of Zend Framework. -- A.J. Brown Zend Certfied PHP Engineer HOME: http://ajbrown.me BLOG: http://coding-adventures.blogspot.com Hi A.J., I'd be interested in this class. Have you submitted a CLA to Zend? If so, why don't you submit a proposal at http://framework.zend.com/wiki/display/ZFPROP/Home Thanks. -Justin
[fw-general] View Helper Repository?
Does anyone know if there is some sort of site which is collecting
useful view helpers to use? Might be a good idea. In any case, here is a
view helper I use to convert a UNIX timestamp stored as UTC to a
user-defined timezone and locale:
class My_View_Helper_FormatDate extends Zend_View_Helper_Abstract
{
/**
* Format a timestamp in the user's locale and timezone
*
* @param integer $timestamp
* @param string $format
* @return string
*/
public function formatDate($timestamp, $format=Zend_Date::DATE_SHORT)
{
if (Zend_Registry::isRegistered('locale')) { // en_US
$locale = Zend_Registry::get('locale');
}
else {
$locale = null;
}
$date = new Zend_Date($timestamp, Zend_Date::TIMESTAMP, $locale);
if (Zend_Registry::isRegistered('timezome')) { // America/New_York
$date-setTimezone(Zend_Registry::get('timezone'));
}
return $date-get($format, $locale);
}
}
Then, as long as 'locale' and 'timezone' variables are set in
Zend_Registry, in my view I can do:
?php echo $this-formatDate($timestamp); ?
-Justin
[fw-general] Zend_Service_Amazon_S3 in laboratory
Hi Everyone, I recently committed Zend_Service_Amazon_S3 to the laboratory and am interested in any feedback anyone might be able to provide. This class is meant to be used as a PHP stream wrapper (stream_wrapper_register()) and that's primarily how my unit tests interface with the class as well. Since that is the way the class was intended to be used, should I try to test the class outside of the stream wrapper or leave the tests as-is? The tests do completely successfully when used with a valid AWS access key and secret key. Since each test case needs to have a valid bucket to test again, and I'm build and tearing down the bucket on each test, should I move that into the setUp() method instead? I haven't really written PHPUnit tests before so I'm looking for suggestions. Thanks. -Justin
[fw-general] ZF-compatible S3 class
Hi Everyone, I just wanted to let everyone know that I created a ZF-compatible Amazon S3 PHP user-stream wrapper available on Google Code. http://code.google.com/p/php-s3/ I'd be interested in feedback for this class. Thanks. -Justin
[fw-general] Re: Amazon SQS Class
Justin Plock wrote: Hi Everyone, Besides my S3 class, I also wrote a queuing class which interfaces with Amazon SQS. I was thinking of submitting a proposal for a Zend_Queue which had various backend adapters (SQS, Database, Files, Zend_Cache). Would anyone have a use for this? Thanks. -Justin Ok, I've started the proposal at http://framework.zend.com/wiki/display/ZFPROP/Zend_Queue+-+Justin+Plock I'll submit it for review after I finish it up. Thanks. -Justin
[fw-general] Amazon SQS Class
Hi Everyone, Besides my S3 class, I also wrote a queuing class which interfaces with Amazon SQS. I was thinking of submitting a proposal for a Zend_Queue which had various backend adapters (SQS, Database, Files, Zend_Cache). Would anyone have a use for this? Thanks. -Justin
Re: [fw-general] Re: a couple of suggestions on viewRenderer
Hi Matt,
Are there any plans for you to provide what *you* do as a sample MVC
application so some of us have some examples to go by? Digging
through the documentation is rather time consuming and I end up having
to look into the source code to figure it out anyway. (Yes, I have
RT*M)
Thanks.
-Justin
On 6/1/07, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote:
-- pat [EMAIL PROTECTED] wrote
(on Friday, 01 June 2007, 12:07 PM -0500):
I see, you have a view directory in each module, where as I have only one view
directroy above the modules..
modules/
default/
blog/
news/
views/site-wide templates are here
views/ commonly used view functions, wrappers, etc
Where would you put your site-wide templates? More importantly, with
so many different views you open the door to TEOM. The Evils Of
Multiplicity. If something changes in these views you have to go into
all those dirs and search all the views and make the changes.
I *always* have a sitelevel view directory I use. I do it like this in
my bootstrap:
// after I've already instantiated the front controller object...
$view = new Zend_View(array('basePath' = '/path/to/common/views'));
$viewRenderer =
Zend_Controller_Action_HelperBroker::getHelper('viewRenderer');
$viewRenderer-setView($view);
The ViewRenderer *adds* view paths to the view object, instead of
removing them. This allows me to do the above, and thus later inject
rendered content into the sitewide template (as well as set additional
variables to inject). It also allows me to define common templates used
and included elsewhere. However, typically, the views for a given module
are self-contained and do not need access to the sitelevel view scripts;
only the sitewide template itself would. Thus, changes are kept to a
minimum.
So, to the contrary, no EOM.
On a different subject.
This bit bothers me. It seems like double-speak.
It won't assemble it willy-nilly. That's the point of named segments --
they also allow you to order the output -- or later pull out the content
piece by piece to manually assemble the final output.
If it has already been rendered, where is the need to:
pull out the content piece by piece
If you are still mucking about with the view, it hasn't been fully
rendered.
I don't think of 'view' in the singular. I have many views, and a final
response made up of a composite of those views. Please read up on the
Two Step View pattern:
http://www.martinfowler.com/eaaCatalog/twoStepView.html
It's a common practice to render portions of the view and inject them
into a final composite view.
Lastly, on the subject of adding
renderToString('form');
I agree, it should be trivial to add this to the viewRender, so why
don't you?
Post-1.0 at the earliest. If you want this as a feature, please add it
to the tracker, and we'll see if the idea gets traction. I think most
people are fine rendering to the response object.
p.s.
Allowing us to change where the viewRenderer automatically looks for
the action script, should also be trivial.
This can already be done. Please read the ViewRenderer documentation.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] ViewRenderer Problems
I agree with Kevin. I prefer to keep all of my HTML open and close tags in one file and include self-contained sub-sections as necessary. I've begun using most of the other Zend-classes but this piece of MVC is a major stumbling block for me on adoption. Thanks. -Justin On 5/30/07, Kevin McArthur [EMAIL PROTECTED] wrote: List debate time =P The issue with this approach is that it becomes very difficult to visualize the end product -- and then, from the end product, to determine where a particular piece of HTML came from. Consider how difficult it can be to find a particular nested tag when traversing the DOM, for instance -- a container view is much more difficult to visualize for most people I'd think it'd be harder to figgure out the end product if its all in different templates and is being included from views controllers, plugins and helpers. The container approach is the same as OOP really, offering encapsulation. It also follows HTML, which is in-itself a container based appraoch (ie DOM). Consider the following templates layout.php --- html head ?= $scripts ? ?= $styles ? /head body ?= $body ? /body /html This is really easy to find a mismatched tag, and chase down unclosed elements. Sub elements can be sub-templates and so on... its all very separated. Thinking of this process linearly, is imho a lot more complicated as you have to match up a number of files that are not hierarchically distributed. I'm not sure why, in such a highly oop framework, the inclination would be to go to procedural style views? I try to limit exactly what templates a non-developer can work with, and in most cases, they should not have to do any logic; they simply indicate whether or not it should be included in the page, and what content should be passed into it. I also segregate templates into application templates (i.e., the general container for the application content), item templates (what individual items can be included into the application template), and finally the actual page-level template (which includes the header, footer, and sitewide navigation elements). Typically, any given content editor will only need to deal with the *content* for the application level, which might include choosing which items to utilize. It's a container approach, but differs from the one you propose as most of the actual work is done at the view level instead of within the controller. Templates should be easy to change and skin without bugging technical staff. This is a pretty common workflow. It's mostly for that workflow reason that I favor dumb templates with controllers doing all the work, especially when touching the model which might affect database state etc and make debugging a real super pain. Why would you want to have to trace templates (which were presumably coded by someone else) in order to follow the applications logic instead of simply tracing the controler/action chain. It's a question of centralized, clearly defined, demarcation of responsibility. However, I'm not going to try and convert you -- if the container paradigm works for you, then that's good, too. The question is how to make both paradigms easy to use for maximum adoption. I think for the bulk of those using ZF, however, the methods outlined for using the ViewRenderer and Two-Step View are going to work well, and something will be built on top of these for layout support. For those like yourself and Kevin, there will be alternate systems developed, but as to whether or not they will be included directly in ZF is another question. Two-Step view is too complicated right now. It requires understanding the dispatch process intimately, and authoring plugins (something i'd consider advanced, un-everyday use) This approach needs to be simplified with some sort of addMasterTemplate() + useMasterTemplate() or similar calls being added to the viewrenderer. Standardization on this is critical for easy adoption. I'm working on a solution, when I come up with something elegant, I'll share. Kevin On May 30, 2007, at 3:20 PM, Matthew Weier O'Phinney wrote: -- Kevin McArthur [EMAIL PROTECTED] wrote (on Wednesday, 30 May 2007, 12:59 PM -0600): Seems like a % of developers think about templates as a series of concatenated strings (header.tpl, content.tpl, footer.tpl) and others (like you+me) think about them as a series of containers. The viewrenderer somewhat presumes the former, but with a plugin can do the latter. I think of them as containers as well, but I also have each controller action doing a very discrete task, which means that any individual action is only rendering one chunk of the page. I then assemble my final view in a dispatchLoopShutdown() plugin. The main purpose of the named segment support in the response object was to facilitate exactly this sort of idea -- aggregate all your various content pieces, and then assemble them later in a larger container (or
Re: [fw-general] Really complications Zend_Controller is purpose ZF?
I'd love to see a tutorial, using ZF 1.0RC1 (or later) using Smarty.
I myself have been trying to figure out how to migrate an existing
code base where we used Smarty exclusively, over to the ZF MVC
pattern. I've ended up having to disable both the ViewRenderer and
the ErrorHandler plugin to start sifting through where to do the
migration.
Personally, I think the ZF MVC code should be a best practices of
sort. ViewRenderer seems very much like an after-thought to me
instead of integrating the View functionality into the Controller
directly.
I realize the time and effort people have put into all of this code,
but at some point, I think we need to step back and K.I.S.
That's my 2 cents.
Thanks.
-Justin
On 5/29/07, Gunter Sammet [EMAIL PROTECTED] wrote:
Matthew, thank you for your hard work and prompt responses. Here a few lines
on my experience so far:
I am pretty new to ZF and MVC. On top of that I want to implement Smarty as
the template engine. Been spending a few days on reading the documentation,
what I could find on the Internet and playing around with the zfdemo code.
Still don't get the whole picture but it makes more and more sense. Figure
it will take me another few days of playing around to understand it a bit
more.
Managed to get some views working through piecing together code pieces from
several tutorials and the zfdemo app. I followed the emails in the last few
weeks, so I knew that there were some changes that are not compatible.
That's why I upgraded today to 1.0.
This broke my setup with the Smarty view, injecting templates out of a
template directory. Since I am still not very proficient in debugging the ZF
and I had $frontController-throwExceptions(true) set, I
didn't get the error message that it didn't find 'index/index.phtml'. It
took me a few hours to figure it out and I am thinking about my potential
new structure.
Besides the above, I had to change my smarty view to use extends
Zend_View_Abstract instead of implements Zend_View_Interface which
required me to declare the _run method.
For now till I have my new template structure, I managed to bypass the auto
view settings by using the following lines of code;
$viewRenderer = new
Zend_Controller_Action_Helper_ViewRenderer($view);
$viewRenderer-setViewBasePathSpec($tmplPath)
-setViewScriptPathSpec('landing.tpl')
-setViewScriptPathNoControllerSpec('
landing.tpl')
-setViewSuffix('tpl');
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
//Zend_View_Controller_HelperBroker::addHelper($viewRenderer);
NOTE:
=
--The sample code at
http://framework.zend.com/manual/en/zend.controller.actionhelpers.html#zend.controller.actionhelpers.viewrenderer
(paragraph 7.9) wants you to implement
Zend_View_Controller_HelperBroker::addHelper($viewRenderer);.
However, I didn't find a HelperBroker there. Seems to be the
Zend_Controller_Action_HelperBroker that is meant there.
Your changes make sense and should make the default setup easier. I will try
to implement it as close as possible to be open for future refactoring.
That's why I didn't use the
$front-setParam
('noErrorHandler', true);
If I understand it correctly, that should have solved my problem without
changes. A good read for it is the migration page (
http://framework.zend.com/manual/en/zend.controller.migration.html#zend.controller.migration.fromzeroninethree)
Hope these lines help some other users to figure it out a bit earlier and
for you to understand the issues ZF newbies may face.
Gunter
[fw-general] Where should error checking occur?
I'm trying to convert over an existing site over to using Zend_Db and Zend_Controller. I've got some error checking code in my Zend_Db_Table classes to make sure all of my required values are populated. I'm just asking in terms of a best practice, should this sort of error checking be moved up to the Controller so it is easier to communicate the error messages back to the user or do you think it should be tied to the Zend_Db_Table? Just looking for suggestions. Thanks. -Justin
Re: [fw-general] Where should error checking occur?
Thanks for the comments. So if my model was going to throw an error about a duplicate row, for example, you'd throw that as an exception then let the controller deal with that (i.e. format a nice error message for the user, or something)? Thanks. -Justin On 5/16/07, Ralph Schindler [EMAIL PROTECTED] wrote: Think of the controller/action the place to take user input, filter it, and pass it to the model. Generally speaking, the controller should be completely aware of what inputs your view is sending back (via the form naturally). If the controller is not getting the values (from $_POST or wherever), its the controllers job to pass some information to the view to alert the user. I like to think of models in such a way that they can operate in a platform independent manner, or in other words.. I can drop the same models I use in a web app, into a commandline version of the same app, and the models should not have to be altered in any way. If for some reason, you have not satisfied a requirement for a model, I generally allow it to throw an exception (as Zend_Db_Table_* does) and handle it gracefully in the controller. Those are just some ideas to start kicking around. -ralph Justin Plock wrote: I'm trying to convert over an existing site over to using Zend_Db and Zend_Controller. I've got some error checking code in my Zend_Db_Table classes to make sure all of my required values are populated. I'm just asking in terms of a best practice, should this sort of error checking be moved up to the Controller so it is easier to communicate the error messages back to the user or do you think it should be tied to the Zend_Db_Table? Just looking for suggestions. Thanks. -Justin
Re: [fw-general] Where should error checking occur?
How would I do something like this: 1.) present a form to the user 2.) user submits it and an error is generated 3.) either the controller or the model throws an exception 4.) the user will be presented with the same form they filed out, with all of their values still populated, but an error message would be displayed. How would I do something like that using the ErrorHandler plugin? I somehow need to get back into the controller action which generated the form, but also interject an error message into my view. Would I use the ErrorHandler plugin to set the error message in the view, then forward back to the previous controller/action, pre-populate all of the form fields, then display the form to the user with the error message? Are there any tutorials or best practices on this stuff yet? :) Thanks. -Justin On 5/16/07, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote: -- Justin Plock [EMAIL PROTECTED] wrote (on Wednesday, 16 May 2007, 04:11 PM -0400): Thanks for the comments. So if my model was going to throw an error about a duplicate row, for example, you'd throw that as an exception then let the controller deal with that (i.e. format a nice error message for the user, or something)? Yep. Or you could ignore it in your controller, and use the new ErrorHandler plugin (enabled by default) to display an error message via your ErrorController. (I just moved the ErrorHandler controller plugin to core this afternoon.) On 5/16/07, Ralph Schindler [EMAIL PROTECTED] wrote: Think of the controller/action the place to take user input, filter it, and pass it to the model. Generally speaking, the controller should be completely aware of what inputs your view is sending back (via the form naturally). If the controller is not getting the values (from $_POST or wherever), its the controllers job to pass some information to the view to alert the user. I like to think of models in such a way that they can operate in a platform independent manner, or in other words.. I can drop the same models I use in a web app, into a commandline version of the same app, and the models should not have to be altered in any way. If for some reason, you have not satisfied a requirement for a model, I generally allow it to throw an exception (as Zend_Db_Table_* does) and handle it gracefully in the controller. Those are just some ideas to start kicking around. -ralph Justin Plock wrote: I'm trying to convert over an existing site over to using Zend_Db and Zend_Controller. I've got some error checking code in my Zend_Db_Table classes to make sure all of my required values are populated. I'm just asking in terms of a best practice, should this sort of error checking be moved up to the Controller so it is easier to communicate the error messages back to the user or do you think it should be tied to the Zend_Db_Table? Just looking for suggestions. Thanks. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
