Re: [fw-general] Models as Singletons
Hi, Gladly I did not totally remove my singleton versions of my models. I'll see this thread through and decide then what to do with my models. -If there are this performance boost, it's a go-go for singletons -If there are too many (possible) problems, it's a no-go for singletons My models are just shared resources for dealing with some data (DbTables, Acl, Xml or whatever datasource). BUT if I'll go with the singletons, I need to get my head around state-issues on singletons. br, Marko Ed Lazor-3 wrote: Since I'm trying to get a better understanding, and since we seem to be mixing several issues here, let me try to clarify and see if you agree. As per Wiki, a global variable is a variable that is accessible in every scope They are usually considered bad practice precisely because of their nonlocality: a global variable can potentially be modified from anywhere, (unless they reside in protected memory) and any part of the program may depend on it. A global variable therefore has an unlimited potential for creating mutual dependencies, and adding mutual dependencies increases complexity. Singletons are considered bad practice, when used as a form of universal data storage, because, like global variables, they have an unlimited potential for creating mutual dependencies. I realize some people are saying that Singletons should never be used. If that's the case, why are they used in Zend Framework? For example, Zend_Auth, Zend_Registry, Zend_Loader_Autoloader, and Zend_Controller_Front. Aren't these good examples of where Singletons are beneficial? How do you know when it's ok to use Singletons? It seems like Singletons are beneficial, when used to share a single resource, because they have the potential for improving performance, and reducing application complexity. Let me use Michael's Factory class as an example. Sure, you could probably rename the class Singleton for clarity. In fact, the getInstance method could be moved inside the class of the objects being generated through the Factory class. To demonstrate this, you'd create a class called Users that extends Zend_Db_Table and you'd give it a method called getInstance. Doing this, you would effectively create a shared resource that serves as a link to the Users database. Whenever you would use $Users = new Users(); You could instead use $Users = Users::getInstance(); That way, instead of reinstantiating an instance of Users all over the application, you call getInstance and re-use the same object as often as you'd like - giving the 7X performance boost Michael was mentioning. And then, adding to the idea a little here, instead of manually adding the getInstance method to every one of your Zend_Db_Table objects, you could create a base class with this method that you can extend from. Or, if you don't have PHP5.3, you can achieve the same thing by using the Factory class that Michael presented. It might seem like a minor adjustment to use a common instance of a Zend_Db_Table object when working with a specific table throughout your application. If that 7X performance boost reduces your page load from 49 seconds to 7 seconds, isn't it worth it? Yes - I realize there are other performance enhancements available as well, cacheing, etc., but this one seems worthwhile also. Or... am I just barking up the wrong tree and asking for trouble later on? Make sense? What do you think? Matthew? -Ed -- View this message in context: http://www.nabble.com/Models-as-Singletons-tp24575704p24639257.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] file decorator not found, while present in latest trunk - gets even stranger
Could someone tell me how to set the viewscript for my file elements now
then please? This used to work untill updating the framework:
$element-setDecorators(array(
array('ViewScript',
array('viewScript' ='_docupload.phtml',
'id' = 'imageElement'
)
)
)
);
But now i get the file decorator not found error.
Thanks
Bart McLeod wrote:
That is brilliant indeed,
Bart
Thomas Weidner schreef:
In past you would just have wondered why file uploads do not work.
Now you get an exception and are directly pointed to the problem. :-)
Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com
- Original Message - From: Bart McLeod mcl...@spaceweb.nl
To: fw-general fw-general@lists.zend.com
Sent: Tuesday, February 10, 2009 9:56 AM
Subject: Re: [fw-general] file decorator not found, while present in
latest trunk - gets even stranger
ok, was in my grouping definitions once more, I have to preserve the
specific decorator for the file element
-Bart
Bart McLeod schreef:
But this testfile.php runs without any trouble:
?php
require_once 'Zend/Loader.php';
Zend_Loader::registerAutoLoad();
$view = new Zend_View();
$fileElement = new Zend_Form_Element_File('image');
echo $fileElement-render($view);
Beats me.
-Bart
Bart McLeod schreef:
both calls do no longer work in latest trunk:
$image = $this-createElement('file', 'image_upload',
array('label' = 'image'));
NOR
$image = new Zend_Form_Element_File('image_upload',
array('label' = 'image'));
This is the error:
Exception caught by form: No file decorator found... unable to
render file element
Stack Trace:
#0
E:\ZendFramework\library\Zend\Form\Decorator\FormElements.php(101):
Zend_Form_Element_File-render()
#1 E:\ZendFramework\library\Zend\Form.php(2595):
Zend_Form_Decorator_FormElements-render('')
#2 E:\ZendFramework\library\SpaceCMS\Form.php(46):
Zend_Form-render(NULL)
#3
E:\werk\cuddlefish\application\admin\models\forms\FormItem.php(93):
SpaceCMS_Form-render(NULL)
#4 E:\ZendFramework\library\Zend\Form.php(2610): FormItem-render()
#5
E:\werk\cuddlefish\application\admin\views\scripts\items\form.phtml(1):
Zend_Form-__toString()
#6 E:\ZendFramework\library\Zend\View.php(107):
include('E:\werk\cuddlef...')
#7 E:\ZendFramework\library\Zend\View\Abstract.php(787):
Zend_View-_run('E:\werk\cuddlef...')
#8
E:\ZendFramework\library\Zend\Controller\Action\Helper\ViewRenderer.php(902):
Zend_View_Abstract-render('items/form.phtm...')
#9
E:\ZendFramework\library\Zend\Controller\Action\Helper\ViewRenderer.php(923):
Zend_ in E:\ZendFramework\library\Zend\Form.php on line
2615br /
While in the filesystem, I can see both the element and the
decorator and I have autoloading enabled
Anyone? A few days ago, this element seemed to work, according to
the posts here.
Bart
--
View this message in context:
http://www.nabble.com/file-decorator-not-found%2C-while-present-in-latest-trunk-tp21915154p24639508.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Caching Zend_XmlRpc_Server decreases performances
Looks like Pear XMLRPC2 is faster http://pear.php.net/package/XML_RPC2/. I replaced Zend_XmlRpc_Server with PEAR XML_RPC2_Server and perfermances are better, with same functionality. Regards, Saša Stamenković On Thu, Jul 23, 2009 at 9:32 AM, umpirsky umpir...@gmail.com wrote: Hi zfers. I have XML-RPC client-server architecture witl Zend_XmlRpc on both, client and server side. My app with XML-RPC is 3-5 times slower with XML-RPC comparing to same app with pure PHP calls - pretty slow, huh. Some methods produce very large XML so I needed to page results in some cases and send in chunks. I attach only one server class with near 100 methods. I tried to optimize it with caching server definition like on http://framework.zend.com/manual/en/zend.xmlrpc.server.html#zend.xmlrpc.server.use.case7 , but it turned out I got even slower calls then without cache. Any idea why? I gained some speed by setting _skipSystemLookup to true. Do you think there can be some consequences? If I pass empty array for ex? Any general tips or idea how I can speed up my server? Regards, Sasa Stamenkovic. -- View this message in context: http://www.nabble.com/Caching-Zend_XmlRpc_Server-decreases-performances-tp24620747p24620747.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Models as Singletons
On Thu, Jul 23, 2009 at 11:22 PM, Ed Lazoredla...@internetarchitects.biz wrote: I realize some people are saying that Singletons should never be used. If that's the case, why are they used in Zend Framework? For example, Zend_Auth, Zend_Registry, Zend_Loader_Autoloader, and Zend_Controller_Front. Aren't these good examples of where Singletons are beneficial? It's a trade off between two types of complexity; coupling on one hand and abstraction on the other hand. You don't want coupling, because it makes it hard to reason about your program, but you don't want too much abstraction either. What is too much depends a whole lot on the individual programmer, so it can be tricky to pick an appropriate level. There's a certain class of problems where a global symbol doesn't hurt. This is in places where the language imposes global effects in any case. For example, PHP doesn't allow redefining classes, so therefore the autoloader is inherently global in any case. It's not that a global doesn't add coupling here - it's just that the language designers have already made the choice for you. Everything else is a judgement call. How do you know when it's ok to use Singletons? It seems like Singletons are beneficial, when used to share a single resource, because they have the potential for improving performance, and reducing application complexity. ... That way, instead of reinstantiating an instance of Users all over the application, you call getInstance and re-use the same object as often as you'd like - giving the 7X performance boost Michael was mentioning. Now you're mixing apples and oranges again. Global symbols do not improve performance. Shared resources improve performance. Globals are just one way to share resources, but it's not the only one. -- troels
[fw-general] Problem Adding New Pages to Existing PDF using Zend_Pdf
HI all, I want to create large PDF files using Zend_Pdf. I have approx 2 million records in database and I want to create PDf of that. I know that much array size would causing me Memoery Exhaustion error. So I decided to Add Some data to pdf file and then fetch next data and then try to append to that pdf files, Now problem is that when I try to append to that file, I get pages overwrite. so it increases Size but I can see only Last pages inserted before save not all. What could be solution for that? Thanks, Dhaval
[fw-general] Front Controller Plugin Problems
Hello
I am trying to implement some functionality via a couple of Controller
Plugins - my requirements are as follows:
1) load custom configuration and make this information available in the view
2) check the input URL contains a language code and re-route to holding page
(where they can select a language) if it does not
Obviously these are two completely separate requirements, hence I would like
to do this using two completely separate plugins.
Anyway, my first question is ... where do I register the plug-in? I am using
the Latest Release of ZF. The index.php generated when I created the project
does not obviously have anywhere to load my plug-ins. So, instead I have
created a new init method in my Bootstrap.php:
protected function _initPlugins() {
$front = Zend_Controller_Front::getInstance();
$front-registerPlugin(new MyPlugin());
$front-registerPlugin(new MyOtherPlugin());
}
Is that the right way to do this? If I register the plug-ins this way will
all hooks into the application stack (eg - routeStartup,
dispatchLoopStartup, etc) be available to my plug-in?
Okay, so assuming what I have done above is okay, onto plug-in (1).
I have a configuration file custom.ini that contains, among other things, a
Google Maps API key. I want to make this information available in all views
throughout the application, so I would do something like:
class MyPlugin extends Zend_Controller_Plugin_Abstract {
public function routeStartup(Zend_Controller_Request_Abstract $request)
{
$config = new Zend_Config_Ini('/path/to/config.ini', $this-env);
$this-view-google_maps_api_key = $config-google_maps_api_key;
}
}
Is that going to work? I am assuming that $this in this context is not
actually the Zend_Application, so $this-env will not yield anything useful,
likewise setting anything on $this-view is not going to make this attribute
available in the view. Is there someway to access the application via $this
- eg - $this-application-env.
Onto plug-in (2). I don't really have any idea how to implement this, but my
initial thoughts are:
- http://www.mydomain.com/ should show a holding page, where a language can
be selected
- http://www.mydomain.com/lang/ (where lang is a two-character language
code such as 'en' or 'de') is the home page for the language-specific
version of the site
- http://www.mydomain.com/lang/abc/ is a specific page on the
language-specific site
- the plug-in should check a valid language code is provided in the URL and
redirect accordingly.
- I don't want to provide duplicate controllers for each language, so the
following URLs should use the same controller:
http://www.mydomain.com/en/abc/
http://www.mydomain.com/de/abc/
In each case the view script should be lang.phtml, as oppose to the
default index.phtml, so that the language of the page can be easily defined.
The last bit is just thinking outloud. It might be easier to accomplish what
I want by splitting the views by the language at the top level of the
hierarchy - eg:
APPLICATION_PATH/views/scripts/en/abc/index.phtml
As oppose to:
APPLICATION_PATH/views/scripts/abc/en.phtml
I don't really mind either way. But I definitely do not want to duplicate
the controllers.
Anyway, that's what I need to do. Apologies for the lengthy post, but as you
can see there are quite a few issues I need to address, I think mainly
because I am new to ZF and still not fully sure how it all hangs together.
Any help would be appreciated :)
Thanks
Jay
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24642509.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Caching Zend_XmlRpc_Server decreases performances
-- umpirsky umpir...@gmail.com wrote
(on Thursday, 23 July 2009, 12:32 AM -0700):
I have XML-RPC client-server architecture witl Zend_XmlRpc on both, client
and server side. My app with XML-RPC is 3-5 times slower with XML-RPC
comparing to same app with pure PHP calls - pretty slow, huh. Some methods
produce very large XML so I needed to page results in some cases and send in
chunks. I attach only one server class with near 100 methods.
I tried to optimize it with caching server definition like on
http://framework.zend.com/manual/en/zend.xmlrpc.server.html#zend.xmlrpc.server.use.case7
, but it turned out I got even slower calls then without cache. Any idea
why?
I gained some speed by setting _skipSystemLookup to true. Do you think there
can be some consequences? If I pass empty array for ex?
Any general tips or idea how I can speed up my server?
This is a known problem, actually, and is due to how PHP handles
reflection.
There is a way around it that's more performant, but not documented. In
1.7, we created Zend_Server_Definition, which is simply a value object
containing the class = method mappings used by the various servers.
Since it's a value object, it does not rely on reflection, and as a
result, when autoloading is on, can be a ton more performant.
Instead of following the directions currently in the manual, do the
following:
* Use autoloading. This will ensure you don't have to load all classes
attached to the server on every request
* Cache the return value of getDispatchTable(). This caches a
Zend_Server_Definition, which is a value object with simply string
names for the classes and methods (not callbacks or reflection)
* On subsequent requests, pass the cached dispatch table to
loadFunctions().
It might look like this, then:
require_once 'Zend/Loader/Autoloader.php';
Zend_Loader_Autoloader::getInstance();
$server = new Zend_XmlRpc_Server();
// Fill in your own front/back-end options. Just make sure that
// autoserialization is on.
$cache = Zend_Cache::factory('Core', 'File', $frontendOpts, $backendOpts);
if (!$definition = $cache-load('xmlrpc-dispatch-table')) {
// Do your server definition here...
// ...
// and then cache the dispatch table
$cache-save($server-getDispatchTable(), 'xmlrpc-dispatch-table');
} else {
// Otherwise, load the server definition
$server-loadFunctions($definition);
}
echo $server-handle();
I haven't tested the above, but there *are* unit tests for passing
Zend_Server_Definition to loadFunctions(), so the theory has some basis.
:)
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
Re: [fw-general] Models as Singletons
-- Ed Lazor edla...@internetarchitects.biz wrote (on Thursday, 23 July 2009, 02:22 PM -0700): I realize some people are saying that Singletons should never be used. If that's the case, why are they used in Zend Framework? For example, Zend_Auth, Zend_Registry, Zend_Loader_Autoloader, and Zend_Controller_Front. Aren't these good examples of where Singletons are beneficial? Some are, and some are not. Zend_Auth, Zend_Session, and Zend_Loader_Autoloader are examples where they make sense. There is only one $_SESSION superglobal (Zend_Auth is a singleton because it utilizes Zend_Session under the hood), and only one spl_autoload registry; what they each operate on is singular in nature, and thus the singleton makes sense. (That said, because $_SESSION is globally available, Zend_Session could easily be refactored to remove the singleton as well.) Zend_Registry is an interesting hybrid. The main use case most people write towards is its global registry nature. However, it can also be instantiated directly and used as a local registry (Zend_Tool uses it in this way, as does Zend_Application). I personally only ever use Zend_Registry as a global registry when debugging -- I'll place a log object in it and pull that to log information from my controller, models, or views... but I *always* strip those calls out once the problem has been isolated. Zend_Controller_Front's reasons for being a singleton are not very good. At the time we decided to make it one, the argument was that for any given request, there could only be one front controller in play. However, there are some use cases where this actually is a hindrance -- one in particular is if you want to *extend* it to alter or add functionality. My plan for 2.0 is to remove the singleton. How do you know when it's ok to use Singletons? It seems like Singletons are beneficial, when used to share a single resource, because they have the potential for improving performance, and reducing application complexity. Remove the performance argument from this; you get good performance as well by simply passing dependencies into other objects, as objects are passed by reference. Also remove the reducing application complexity argument, because it actually makes maintenance harder. The more complex your application, you only compound the complexity further by introducing singletons, as it's harder to determine where and when values are set within the application lifecycle. If dependencies are always passed into other objects, you know that the caller is responsible for providing them -- making maintenance and backtracing simpler. The only place where they make sense is when the resource in question is truly singular in nature -- the autoloader is a good example of that. Let me use Michael's Factory class as an example. Sure, you could probably rename the class Singleton for clarity. In fact, the getInstance method could be moved inside the class of the objects being generated through the Factory class. To demonstrate this, you'd create a class called Users that extends Zend_Db_Table and you'd give it a method called getInstance. Doing this, you would effectively create a shared resource that serves as a link to the Users database. Whenever you would use $Users = new Users(); You could instead use $Users = Users::getInstance(); That way, instead of reinstantiating an instance of Users all over the application, you call getInstance and re-use the same object as often as you'd like - giving the 7X performance boost Michael was mentioning. That boost can also occur if you simply do metadata caching, per the performance recommendations. ;) Truly, that's the single easiest way to improve performance in Zend_Db_Table, and it has huge impact, particularly if you instantiate multiple copies of the table within your app. Using a singleton for performance reasons is almost always the wrong solution; look instead at how the objects that depend on it get the dependency. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] file decorator not found, while present in latest trunk - gets even stranger
See the ZF FAQ section in our wiki.
A file element must have a file decorator otherwise it can not be rendered
correctly.
Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com
- Original Message -
From: aSecondWill willjbar...@gmail.com
To: fw-general@lists.zend.com
Sent: Friday, July 24, 2009 8:51 AM
Subject: Re: [fw-general] file decorator not found, while present in latest
trunk - gets even stranger
Could someone tell me how to set the viewscript for my file elements now
then please? This used to work untill updating the framework:
$element-setDecorators(array(
array('ViewScript',
array('viewScript' ='_docupload.phtml',
'id' = 'imageElement'
)
)
)
);
But now i get the file decorator not found error.
Thanks
Bart McLeod wrote:
That is brilliant indeed,
Bart
Thomas Weidner schreef:
In past you would just have wondered why file uploads do not work.
Now you get an exception and are directly pointed to the problem. :-)
Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com
- Original Message - From: Bart McLeod mcl...@spaceweb.nl
To: fw-general fw-general@lists.zend.com
Sent: Tuesday, February 10, 2009 9:56 AM
Subject: Re: [fw-general] file decorator not found, while present in
latest trunk - gets even stranger
ok, was in my grouping definitions once more, I have to preserve the
specific decorator for the file element
-Bart
Bart McLeod schreef:
But this testfile.php runs without any trouble:
?php
require_once 'Zend/Loader.php';
Zend_Loader::registerAutoLoad();
$view = new Zend_View();
$fileElement = new Zend_Form_Element_File('image');
echo $fileElement-render($view);
Beats me.
-Bart
Bart McLeod schreef:
both calls do no longer work in latest trunk:
$image = $this-createElement('file', 'image_upload',
array('label' = 'image'));
NOR
$image = new Zend_Form_Element_File('image_upload',
array('label' = 'image'));
This is the error:
Exception caught by form: No file decorator found... unable to
render file element
Stack Trace:
#0
E:\ZendFramework\library\Zend\Form\Decorator\FormElements.php(101):
Zend_Form_Element_File-render()
#1 E:\ZendFramework\library\Zend\Form.php(2595):
Zend_Form_Decorator_FormElements-render('')
#2 E:\ZendFramework\library\SpaceCMS\Form.php(46):
Zend_Form-render(NULL)
#3
E:\werk\cuddlefish\application\admin\models\forms\FormItem.php(93):
SpaceCMS_Form-render(NULL)
#4 E:\ZendFramework\library\Zend\Form.php(2610): FormItem-render()
#5
E:\werk\cuddlefish\application\admin\views\scripts\items\form.phtml(1):
Zend_Form-__toString()
#6 E:\ZendFramework\library\Zend\View.php(107):
include('E:\werk\cuddlef...')
#7 E:\ZendFramework\library\Zend\View\Abstract.php(787):
Zend_View-_run('E:\werk\cuddlef...')
#8
E:\ZendFramework\library\Zend\Controller\Action\Helper\ViewRenderer.php(902):
Zend_View_Abstract-render('items/form.phtm...')
#9
E:\ZendFramework\library\Zend\Controller\Action\Helper\ViewRenderer.php(923):
Zend_ in E:\ZendFramework\library\Zend\Form.php on line
2615br /
While in the filesystem, I can see both the element and the
decorator and I have autoloading enabled
Anyone? A few days ago, this element seemed to work, according to
the posts here.
Bart
--
View this message in context:
http://www.nabble.com/file-decorator-not-found%2C-while-present-in-latest-trunk-tp21915154p24639508.html
Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] Problem with ReCaptcha element?
Nobody noticed this issue? Now I use a view script file as decorator for each form, and the only ReCaptcha that is rendered is the last one, not the first, anyway, not both as expected. Sergio Rinaudo From: kaiohken1...@hotmail.com To: fw-general@lists.zend.com Date: Thu, 23 Jul 2009 22:40:50 +0200 Subject: [fw-general] Problem with ReCaptcha element? Hi, before ZF 1.8 I wrote a couple of form using Zend_Form, that implement the recaptcha element ( I think with the 1.7 version of ZF ). They was working pretty well, both forms rendered in the same page/action. I did't use them for a while, and today I needed to use them again, but I noticed that recapcha can render only once, only the first one. I tried to switch forms as well, disable css but I get the same result. Does anybody noticed the same problem? I'm actually use ZF1.9 beta, but I tried as well with 1.8.1. Sergio Rinaudo Solo con Messenger, nuovi gadget gratuiti per te. Vieni a scoprirli! _ Condividi i tuoi ricordi online con chi vuoi tu. http://www.microsoft.com/italy/windows/windowslive/products/photos-share.aspx?tab=1
Re: [fw-general] Caching Zend_XmlRpc_Server decreases performances
Wow, great, now it's faster. Thanks Matthew.
Isn't automatic_serialization true by default in Zend_Cache?
Why isn't this implemented in Zend_XmlRpc_Server_Cache?
Regards,
Saša Stamenković
On Fri, Jul 24, 2009 at 2:21 PM, Matthew Weier O'Phinney
matt...@zend.comwrote:
-- umpirsky umpir...@gmail.com wrote
(on Thursday, 23 July 2009, 12:32 AM -0700):
I have XML-RPC client-server architecture witl Zend_XmlRpc on both,
client
and server side. My app with XML-RPC is 3-5 times slower with XML-RPC
comparing to same app with pure PHP calls - pretty slow, huh. Some
methods
produce very large XML so I needed to page results in some cases and send
in
chunks. I attach only one server class with near 100 methods.
I tried to optimize it with caching server definition like on
http://framework.zend.com/manual/en/zend.xmlrpc.server.html#zend.xmlrpc.server.use.case7
, but it turned out I got even slower calls then without cache. Any idea
why?
I gained some speed by setting _skipSystemLookup to true. Do you think
there
can be some consequences? If I pass empty array for ex?
Any general tips or idea how I can speed up my server?
This is a known problem, actually, and is due to how PHP handles
reflection.
There is a way around it that's more performant, but not documented. In
1.7, we created Zend_Server_Definition, which is simply a value object
containing the class = method mappings used by the various servers.
Since it's a value object, it does not rely on reflection, and as a
result, when autoloading is on, can be a ton more performant.
Instead of following the directions currently in the manual, do the
following:
* Use autoloading. This will ensure you don't have to load all classes
attached to the server on every request
* Cache the return value of getDispatchTable(). This caches a
Zend_Server_Definition, which is a value object with simply string
names for the classes and methods (not callbacks or reflection)
* On subsequent requests, pass the cached dispatch table to
loadFunctions().
It might look like this, then:
require_once 'Zend/Loader/Autoloader.php';
Zend_Loader_Autoloader::getInstance();
$server = new Zend_XmlRpc_Server();
// Fill in your own front/back-end options. Just make sure that
// autoserialization is on.
$cache = Zend_Cache::factory('Core', 'File', $frontendOpts,
$backendOpts);
if (!$definition = $cache-load('xmlrpc-dispatch-table')) {
// Do your server definition here...
// ...
// and then cache the dispatch table
$cache-save($server-getDispatchTable(), 'xmlrpc-dispatch-table');
} else {
// Otherwise, load the server definition
$server-loadFunctions($definition);
}
echo $server-handle();
I haven't tested the above, but there *are* unit tests for passing
Zend_Server_Definition to loadFunctions(), so the theory has some basis.
:)
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves schreef:
Hello
I am trying to implement some functionality via a couple of Controller
Plugins - my requirements are as follows:
1) load custom configuration and make this information available in the view
2) check the input URL contains a language code and re-route to holding page
(where they can select a language) if it does not
Obviously these are two completely separate requirements, hence I would like
to do this using two completely separate plugins.
Anyway, my first question is ... where do I register the plug-in? I am using
the Latest Release of ZF. The index.php generated when I created the project
does not obviously have anywhere to load my plug-ins. So, instead I have
created a new init method in my Bootstrap.php:
protected function _initPlugins() {
$front = Zend_Controller_Front::getInstance();
$front-registerPlugin(new MyPlugin());
$front-registerPlugin(new MyOtherPlugin());
}
Is that the right way to do this? If I register the plug-ins this way will
all hooks into the application stack (eg - routeStartup,
dispatchLoopStartup, etc) be available to my plug-in?
Yes, it is the right way to do this, but I don't see why you put it in a
function. Is this inside your bootstrap class? In that case I understand.
Okay, so assuming what I have done above is okay, onto plug-in (1).
I have a configuration file custom.ini that contains, among other things, a
Google Maps API key. I want to make this information available in all views
throughout the application, so I would do something like:
class MyPlugin extends Zend_Controller_Plugin_Abstract {
public function routeStartup(Zend_Controller_Request_Abstract $request)
{
$config = new Zend_Config_Ini('/path/to/config.ini', $this-env);
$this-view-google_maps_api_key = $config-google_maps_api_key;
}
}
I would say Zend_Registry::set('my_config', $config);
and retrieve this whenever you need it as Zend_Registry::get('my_config');
Is that going to work? I am assuming that $this in this context is not
actually the Zend_Application, so $this-env will not yield anything useful,
likewise setting anything on $this-view is not going to make this attribute
available in the view. Is there someway to access the application via $this
- eg - $this-application-env.
Onto plug-in (2). I don't really have any idea how to implement this, but my
initial thoughts are:
I don't have time to read all this, but I think you should be looking at
using a custom route.
$router = $front-getRouter();
$router-addRoute(-your new route-);
-Bart
- http://www.mydomain.com/ should show a holding page, where a language can
be selected
- http://www.mydomain.com/lang/ (where lang is a two-character language
code such as 'en' or 'de') is the home page for the language-specific
version of the site
- http://www.mydomain.com/lang/abc/ is a specific page on the
language-specific site
- the plug-in should check a valid language code is provided in the URL and
redirect accordingly.
- I don't want to provide duplicate controllers for each language, so the
following URLs should use the same controller:
http://www.mydomain.com/en/abc/
http://www.mydomain.com/de/abc/
In each case the view script should be lang.phtml, as oppose to the
default index.phtml, so that the language of the page can be easily defined.
The last bit is just thinking outloud. It might be easier to accomplish what
I want by splitting the views by the language at the top level of the
hierarchy - eg:
APPLICATION_PATH/views/scripts/en/abc/index.phtml
As oppose to:
APPLICATION_PATH/views/scripts/abc/en.phtml
I don't really mind either way. But I definitely do not want to duplicate
the controllers.
Anyway, that's what I need to do. Apologies for the lengthy post, but as you
can see there are quite a few issues I need to address, I think mainly
because I am new to ZF and still not fully sure how it all hangs together.
Any help would be appreciated :)
Thanks
Jay
Re: [fw-general] Caching Zend_XmlRpc_Server decreases performances
-- Саша Стаменковић umpir...@gmail.com wrote
(on Friday, 24 July 2009, 03:20 PM +0200):
Wow, great, now it's faster. Thanks Matthew.
Isn't automatic_serialization true by default in Zend_Cache?
It might be, I'm not sure. Check the API docs. :)
Why isn't this implemented in Zend_XmlRpc_Server_Cache?
Because it predates the Zend_Server_Definition. It needs to be
refactored.
On Fri, Jul 24, 2009 at 2:21 PM, Matthew Weier O'Phinney matt...@zend.com
wrote:
-- umpirsky umpir...@gmail.com wrote
(on Thursday, 23 July 2009, 12:32 AM -0700):
I have XML-RPC client-server architecture witl Zend_XmlRpc on both,
client
and server side. My app with XML-RPC is 3-5 times slower with XML-RPC
comparing to same app with pure PHP calls - pretty slow, huh. Some
methods
produce very large XML so I needed to page results in some cases and
send
in
chunks. I attach only one server class with near 100 methods.
I tried to optimize it with caching server definition like on
http://framework.zend.com/manual/en/zend.xmlrpc.server.html#
zend.xmlrpc.server.use.case7
, but it turned out I got even slower calls then without cache. Any idea
why?
I gained some speed by setting _skipSystemLookup to true. Do you think
there
can be some consequences? If I pass empty array for ex?
Any general tips or idea how I can speed up my server?
This is a known problem, actually, and is due to how PHP handles
reflection.
There is a way around it that's more performant, but not documented. In
1.7, we created Zend_Server_Definition, which is simply a value object
containing the class = method mappings used by the various servers.
Since it's a value object, it does not rely on reflection, and as a
result, when autoloading is on, can be a ton more performant.
Instead of following the directions currently in the manual, do the
following:
* Use autoloading. This will ensure you don't have to load all classes
attached to the server on every request
* Cache the return value of getDispatchTable(). This caches a
Zend_Server_Definition, which is a value object with simply string
names for the classes and methods (not callbacks or reflection)
* On subsequent requests, pass the cached dispatch table to
loadFunctions().
It might look like this, then:
require_once 'Zend/Loader/Autoloader.php';
Zend_Loader_Autoloader::getInstance();
$server = new Zend_XmlRpc_Server();
// Fill in your own front/back-end options. Just make sure that
// autoserialization is on.
$cache = Zend_Cache::factory('Core', 'File', $frontendOpts,
$backendOpts);
if (!$definition = $cache-load('xmlrpc-dispatch-table')) {
// Do your server definition here...
// ...
// and then cache the dispatch table
$cache-save($server-getDispatchTable(), 'xmlrpc-dispatch-table');
} else {
// Otherwise, load the server definition
$server-loadFunctions($definition);
}
echo $server-handle();
I haven't tested the above, but there *are* unit tests for passing
Zend_Server_Definition to loadFunctions(), so the theory has some basis.
:)
--
Matthew Weier O'Phinney
Project Lead | matt...@zend.com
Zend Framework | http://framework.zend.com/
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
Re: [fw-general] Models as Singletons
That boost can also occur if you simply do metadata caching, per the performance recommendations. ;) Truly, that's the single easiest way to improve performance in Zend_Db_Table, and it has huge impact, particularly if you instantiate multiple copies of the table within your app. Using a singleton for performance reasons is almost always the wrong solution; look instead at how the objects that depend on it get the dependency. Thanks Everyone - that helped clarify things =) -Ed
[fw-general] Retrieving already bootstrapped resources
I'd like to inject my own container into Zend_Application, for various reasons I'd like to do this at any point from a module bootstrap and not before. And so; I'd like to get a definitive list of the already bootstrapped resources so that I can grab them from the current container (Zend_Registry) and push them into my own. At this point I'll inject my container into zend_app. The protected member $_run would be, I think, the ideal list to grab but I don't see an accessor for it. Should i just extend the abstract bootstrap or is there a way to do this without maintaining my own base bootstrap? Cheers the noo, Graham
Re: [fw-general] Retrieving already bootstrapped resources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Graham Anderson wrote: I'd like to inject my own container into Zend_Application, for various reasons I'd like to do this at any point from a module bootstrap and not before. And so; I'd like to get a definitive list of the already bootstrapped resources so that I can grab them from the current container (Zend_Registry) and push them into my own. At this point I'll inject my container into zend_app. The protected member $_run would be, I think, the ideal list to grab but I don't see an accessor for it. Should i just extend the abstract bootstrap or is there a way to do this without maintaining my own base bootstrap? Zend_Registry is iterable, so the easiest way to get every element from it is to loop over it with a simple foreach on the instance itself. I have already done what you are proposing - replace the Zend_Registry with a DI container - by creating a new bootstrap resource, so it doesn't get loaded until it's triggered by the relevant configuration directive. I've blogged about it here - http://blog.tekerson.com/2009/07/06/dependency-injection-container-resource-in-zend-framework/ - - I'm using the yadif container, but it shouldn't be hard to alter for other containers. (It's my first attempt at writing a resource, so I'm not sure it's the best way and any feedback is appreciated.) - -- Brenton Alker PHP Developer - Brisbane, Australia http://blog.tekerson.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpqPxsACgkQ7bkAtAithusL+ACfan8ePRAtzg/E2JbM6C6o027K IwgAoIN2anKeJyQ938uugmRvulFI0b1J =qKPf -END PGP SIGNATURE-
[fw-general] namespace persistence
Hello, ok, so I'm starting up with Zend's framework and setting up a login procedure. I'm using a database table for session storage. In addition to the zend_auth namespace, i am using another namespace to keep track of other stuff. I've configured the database savehandler's lifetime to a specified duration which is used as an idle time duration. At the end of this duration, the session is cleared (both namespaces are unset) and redirection to the login page occurs. I'll worry about remember me cookie latter. What I want, however, is to keep the second namespace. In effect, only the zend_auth namespace should be unset (ie. removed from the data column) whilst the other would remain untouched. I know that is possible because if I call setExpirationSeconds (or hops) for the additional namespace, a third namespace (ie. __ZF) is created. This one remains untouched after the session has expired. So the session clear does not necessarily remove all namespaces. any help would be much appreciated. -- View this message in context: http://www.nabble.com/namespace-persistence-tp24653325p24653325.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] namespace persistence
On Fri, Jul 24, 2009 at 4:24 PM, hacheb henri.baeyens0...@orange.fr wrote: What I want, however, is to keep the second namespace. In effect, only the zend_auth namespace should be unset (ie. removed from the data column) whilst the other would remain untouched. I viewed the source for Zend/Session/Namespace.php and found a method called unsetAll which unsets the namespace. $oNamespacedSession-unsetAll(); - pw
