[fw-general] Looking for community review
Its been sometime now and we haven't gotten any comments, so just hoping to put it in the spotlight. http://framework.zend.com/wiki/display/ZFPROP/Zend_View_Helper_TimeSince+-+Geoffrey+Tran http://framework.zend.com/wiki/display/ZFPROP/Zend_View_Helper_TimeUntil+-+Geoffrey+Tran http://framework.zend.com/wiki/display/ZFPROP/Zend_View_Helper_XmlDeclaration+-+Geoffrey+Tran http://framework.zend.com/wiki/display/ZFPROP/Zend_Auth_Adapter_Chain+-+Geoffrey+Tran http://framework.zend.com/wiki/display/ZFPROP/Zend_Navigation -- View this message in context: http://www.nabble.com/Looking-for-community-review-tp8623p8623.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Overriding Zend_Controller_Plugin_ErrorHandler
Well there are basically two ways you could do it. 1. Disable the existing errorHandler with the 'noErrorHandler' front controller param or 2. Unregister it from the plugin broker and register your own. We chose the latter for our own ErrorHandler modifications on lines 261 to ensure compatibility with 'noErrorHander' param http://code.google.com/p/zym/source/browse/trunk/library/Zym/Controller/Plugin/ErrorHandler.php but setting noErrorHandler and registering your own @ 100 should be fine rather than overriding the frontcontroller. Geoffrey Tran Matthew Weier O'Phinney-3 wrote: -- Tim Nagel [EMAIL PROTECTED] wrote (on Monday, 27 October 2008, 02:47 PM +1100): I am trying to override the ErrorHandler plugin and I have run into an issue: I have created a plugin, Infinite_Controller_Plugin_ErrorHandler, derived from Zend's copy, and if i register the plugin at stack position 100 (as the current one is done in the Front Controller), I'll get an exception thrown that there is already a plugin registered there when I dispatch. So: 1) Am I doing it wrong? Should I be registering it earlier? 99 instead of 100? Seems an aweful waste to load 2 ErrorHandlers. 2) Should I be setting noErrorHandler to avoid the Front Controller from creating a Zend_Controller_Plugin_ErrorHandler? Seems like this wouldnt be the solution to me This is exactly the solution. 3) Should I be overriding the Front Controller as well? Also seems a bit much to change the ErrorHandler. 4) Is there an issue with the Plugin Broker that it is purely checking the class type in hasPlugin, rather than checking for instanceof? It's not an issue; it's simply the original design of the broker. It existed before we solidified our plugin architecture. 4.1) Should there be a feature or bug request to modify the dispatch function in the Front Controller to use a class variable for where it should look for the ErrorHandler? That's what solution 2 is doing, in essence. ;) Any guidance would be appreciated. -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/ -- View this message in context: http://www.nabble.com/Overriding-Zend_Controller_Plugin_ErrorHandler-tp20181400p20195181.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Subdomains and Zend Framework
If your looking to route requests based on subdomains, I created a route that does just that a few months ago for Zym. http://trac2.assembla.com/zym/browser/trunk/incubator/library/Zym/Controller/Router/Route/HttpHost.php Basically it routes based on the domain... ':user.*.*' would match SpotSec.Foo.Com SpotSec would be the user var and * would be a domain -- View this message in context: http://www.nabble.com/Subdomains-and-Zend-Framework-tp17125088p17236088.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Zend_Controller_Action naming
Just wondering why it's Zend_Controller_Action compared to Zend_Controller_Action_Abstract ;) Breaking naming conventions should always be specified. -- View this message in context: http://www.nabble.com/Zend_Controller_Action-naming-tp15078219s16154p15078219.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Subclassing Zend_Controller_Action, possible ?
http://www.spotsec.com/blog/archive/2008/1/12/extending-zend-controller-action-and-keeping-init/ -- View this message in context: http://www.nabble.com/Subclassing-Zend_Controller_Action%2C-possible---tp14956815s16154p14975968.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] One person's opinion...
NOTE: I am just giving my opinion (biased of course) and hopefully some constructive criticism. This is because I believe that a project should have those who criticize it rather than a complete loyal fan base because criticism does bring about improvement does it not? First of all, ZF has made a lot of progress since last year and I am very happy about the way it turned out. It does seem like there was a real rush to push 1.0 out the door considering RC2, RC3 and 1.0 were all released in a one month period (RC3 to 1.0 was a little over a week if I remember). While I do realize that fact that this is a project geared towards enterprise customers as they do pay the bills :thinking:, I do hope that the target now is to fix up some nasty areas and concentrate a little bit more on developer friendliness. Of course, there should still be a balance between what you call rapid development features vs code design. While I am very pro code design rather than using rapid development tactics such as placing a commonly functions everywhere, I do think that a many people were hoping for a rails-type feel and a little bit doesn't hurt. Now that I got that out of the way. There are some things that I feel that ZF is lacking, hopefully everyone realizes it already. Zend_Cache at the moment doesn't feel very up to par as I saw a few areas that could be improved such as the removal of the constructor array params checking which is inconsistent with other designs such as in Zend_Db. Another wierd thing question I've got to ask is Why are the backends and frontends hardcoded?. On top of that, being able to provide default configuration for backends/frontends would be nice. Well that is one component, other components I feel that were lacking love in were Zend_Translate, Zend_Date and Zend_Mail could use a getDefaultTransport function to be able to use the default transport when sending multiple mails, but that could be debatable. One thing that I thought was wierd was this http://framework.zend.com/issues/browse/ZF-2314 (Thought I'd throw this in hoping Matthew would explain ;) ). Obviously I have too much to rant about, so I'll end it about here and keep you guys from getting bored of reading. Wishlist: Abstraction of the Bootstrap process I do have an attempt at this, although it sounds like you are heading towards code generation... (http://www.assembla.com/wiki/show/zftalk/SpotSec_Application) Zend_Log_Writer_Syslog Fix up Zend_Cache quality Fix wierdness in a few areas of Zend_Db Ralph, Fix the Zend_Auth_Adapter_DbTable and the object FETCH_MODE bug Don't make me nag you on #zftalk ;) Model Loading? Zend_Acl and Zend_Auth pattern This seems to be confusing as to a good design for many people Zend_View_Helper_BaseUrl (returns baseurl) Ok this is kinda on the lazy side, but it does reduce a lot of typing ;) That being said, I am looking forward to the future and have followed the progress of Zend_Layout and Zend_Form since the beginning; however, I do hope that some of your attention is diverted to the cracks in ZF before your next release. End of ridiculous rant, SpotSec -- View this message in context: http://www.nabble.com/One-person%27s-opinion...-tp14476650s16154p14476650.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] One person's opinion...
*nabble may have formatted the previous message* NOTE: I am just giving my opinion (biased of course) and hopefully some constructive criticism. This is because I believe that a project should have those who criticize it rather than a complete loyal fan base because criticism does bring about improvement does it not? First of all, ZF has made a lot of progress since last year and I am very happy about the way it turned out. It does seem like there was a real rush to push 1.0 out the door considering RC2, RC3 and 1.0 were all released in a one month period (RC3 to 1.0 was a little over a week if I remember). While I do realize that fact that this is a project geared towards enterprise customers as they do pay the bills :thinking:, I do hope that the target now is to fix up some nasty areas and concentrate a little bit more on developer friendliness. Of course, there should still be a balance between what you call rapid development features vs code design. While I am very pro code design rather than using rapid development tactics such as placing a commonly functions everywhere, I do think that a many people were hoping for a rails-type feel and a little bit doesn't hurt. Now that I got that out of the way. There are some things that I feel that ZF is lacking, hopefully everyone realizes it already. Zend_Cache at the moment doesn't feel very up to par as I saw a few areas that could be improved such as the removal of the constructor array params checking which is inconsistent with other designs such as in Zend_Db. Another wierd thing question I've got to ask is Why are the backends and frontends hardcoded?. On top of that, being able to provide default configuration for backends/frontends would be nice. Well that is one component, other components I feel that were lacking love in were Zend_Translate, Zend_Date and Zend_Mail could use a getDefaultTransport function to be able to use the default transport when sending multiple mails, but that could be debatable. One thing that I thought was wierd was this http://framework.zend.com/issues/browse/ZF-2314 (Thought I'd throw this in hoping Matthew would explain ;) ). Obviously I have too much to rant about, so I'll end it about here and keep you guys from getting bored of reading. Wishlist: Abstraction of the Bootstrap process I do have an attempt at this, although it sounds like you are heading towards code generation... (http://www.assembla.com/wiki/show/zftalk/SpotSec_Application) Zend_Log_Writer_Syslog Fix up Zend_Cache quality Fix wierdness in a few areas of Zend_Db Ralph, Fix the Zend_Auth_Adapter_DbTable and the object FETCH_MODE bug Don't make me nag you on #zftalk ;) Model Loading? Zend_Acl and Zend_Auth pattern This seems to be confusing as to a good design for many people Zend_View_Helper_BaseUrl (returns baseurl) Ok this is kinda on the lazy side, but it does reduce a lot of typing ;) That being said, I am looking forward to the future and have followed the progress of Zend_Layout and Zend_Form since the beginning; however, I do hope that some of your attention is diverted to the cracks in ZF before your next release. End of ridiculous rant, SpotSec -- View this message in context: http://www.nabble.com/One-person%27s-opinion...-tp14476650s16154p14476668.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] One person's opinion...
First of all, I would like to thank the ZF team for replying extremely quick considering it is the weekend and we are very near christmas (it is family time right ;) ). The work already done on ZF is one of the best out there and I'm sure all of you realize that. My point and hopefully it was already in your minds was that with all the momentum about further progress, we do not forget about the problems/issues currently in lost limbo. I would rank ZF as one of the best PHP libraries out there at the moment and the loose-coupled design is very flexible; however, the lack of some coupling between some components when using ZF as an application framework or in a rapid devel type of manor does seem a bit hackish (that is only how I feel). Obviously ZF is not a rails type/cake type of framework and I hope it does not become one. Also from listening to other users opinions I think that ZF could set down a few guidelines or opinions about application design etc... (model design, directory layout) I am very grateful that it is an open source project rather than a proprietary one and that you guys spend time reviewing opinions (hopefully you don't take me too seriously as I am just throwing things out that come to mind). It is very great to see that developers listen to its users opinions because it is very easily to not realize tiny issues. Thomas, yes I was referring to just Zend_Mail, this was my experience with and may not apply to others, but I'm just bringing issues I had to light. (If you set a default transport in the bootstrap, how the heck do you use it in the controller without reverting to creating a new instance or the registry ;) ) Sinclair, I have been monitoring the Zend_Build proposals; however, I have not had time to look into it with detail yet... As for my little design, it is just an experiment as a different approach to the Zend_Application proposal by Bill and it does have its own issues. Happy Holidays! -- View this message in context: http://www.nabble.com/One-person%27s-opinion...-tp14476650s16154p14482673.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] BUG? Zend_Config_Xml
*bump* -- View this message in context: http://www.nabble.com/BUG--Zend_Config_Xml-tf4704756s16154.html#a13576486 Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] BUG? Zend_Config_Xml
It appears that there is a bug in Zend_Config_Xml when using it without
specific sections ($conf = new Zend_Config_Xml('file.xml', null);).
Since the _toArray() function does not check if the simplexmlobject only
contains a string, an empty Zend_Config obj is returned.
This only happens on the 2nd level element in the xml files as specifying
null in will use the first level elements to extend from.
Examples:
application
home../application/home
namespace
foofoo/foo
/namespace
/application
$conf-home will return an empty Zend_Config obj not the expected string.
$conf-namespace-foo will return as expected a string.
I simply added an if else to check if the simplexmlobject has children, if
not then return the string.
Zend_Config_Xml
/**
* Returns an associative and possibly multidimensional array from a
SimpleXMLElement.
*
* @param SimpleXMLElement $xmlObject
* @return array
*/
protected function _toArray($xmlObject)
{
$config = array();
if ($xmlObject-children()) {
foreach ($xmlObject-children() as $key = $value) {
if ($value-children()) {
$config[$key] = $this-_toArray($value);
} else {
$config[$key] = (string) $value;
}
}
} else {
$config = (string) $xmlObject;
}
return $config;
}
--
View this message in context:
http://www.nabble.com/BUG--Zend_Config_Xml-tf4704756s16154.html#a13448031
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] CLI for ZF
I started something similar but have never had time to work/fix it. I kind of stopped messing with it until I can think of a better way to template files such as a controller etc... And I also need some time to create a db schema component for a more generic model-generator -- View this message in context: http://www.nabble.com/CLI-for-ZF-tf4616757s16154.html#a13195861 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend Framework Web Application (best practices, structure, skeleton)
I'll join in as long as I'm not the only one working on it ;) Ian Warner-4 wrote: Maybe it would be cool if we can organise a group of developers to create some sort of Joomla like project, utilising the Zend Framework of course, always good to have an end focus to work too. This can have the aim of providing a best practice selection of reusable classes and modules. I would be interested to help organise and create such a group and even provide some hosting space etc. As always the hard thing with something like this is starting and maintaining the momentum. If anyone is interested then please let me know. Cheers Ian Ralf Kramer wrote: It would be nice to have a Best practises page on the Wiki and also a basic but powerful skeleton demo capable of handling large web applications. I feel the Zend Framework would benefit from a such 'one-stop-shop' for new developers who would like to use it as their framework of choice for large web applications. Hi Antonio, It seems like there is a proposal for such demo application in the pipeline: http://framework.zend.com/wiki/display/ZFPROP/Zend_Application+-+Bill +Karwin I agree with you. Having an official approach will put - at least for me - a lot of added value to the framework. So I can turn my focus back to the business logic, and be sure that the community keeps my applications on the bleeding edge of technology... But if I get it right, its just a matter of time ;-) Best regards /Ralf -- View this message in context: http://www.nabble.com/Zend-Framework-Web-Application-%28best-practices%2C-structure%2C-skeleton%29-tf4496725s16154.html#a12853082 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Layout Status ?
I sure hope default module layouts and a setConfig() feature are added to zend_layout :( config production !-- Layout view path -- path../application/layouts/path !-- View script suffix -- file_suffixphtml/file_suffix !-- Default layout name -- defaultdefault/default !-- Configure layout requests -- layouts !-- default.phtml -- default requests !-- ?php echo $this-menu; ? -- menu moduledefault/module controllerlayout/controller actionmenu/action !-- Request params array -- params menu_typefull/menu_type /params /menu /requests /default /layouts !-- Default module layouts -- modules admin nameadmin/name !-- Requests overrides? -- requests/requests /admin !-- Blog module uses blog.phtml -- blogblog/blog /modules /production staging extends=production /staging /config Matthew Weier O'Phinney-3 wrote: -- Kamil [EMAIL PROTECTED] wrote (on Friday, 17 August 2007, 03:25 PM +0200): What is the status of http://framework.zend.com/wiki/display/ZFPROP/Zend_LayoutZend_Layout or Zend_View Enhanced . Before version 1.0 there was big discussion about it ,so is layout management will be in version 1.1 ? I'm currently in the process of reviewing Zend_Layout and Zend_View_Enhanced. At this point, it looks like most of Zend_View_Enhanced will be accepted with minor changes and minus the layout support and Zend_View changes it suggests. I am also actively working with Ralph and Padraic to finalize the Zend_Layout proposal and scope. Both will be available for 1.1.0. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- View this message in context: http://www.nabble.com/Zend_Layout-Status---tf4285662s16154.html#a12211014 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] forms and getBaseUrl()
I would suggest using the url helper massivo wrote: Hi. I have a problem with forms (method=post) and the action attribute (the same page that have the form). Why if use: 'form action=' . $this-getRequest()-getBaseUrl() . ' method=POST' don't receive my POST variables with: $this-getRequest()-getParams( in my action controller or my helper? However, if use 'form action=' . $_SERVER['PHP_SELF'] . ' method=POST' or send with method=GET, everything goes well. I don't like to use $_SERVER['PHP_SELF'], because, if my uri is www.mydomain.com, when press the send button, it changes to www.mydomain.com/index.php (for example). How I would have to specify the action property in the form to receive it in the same page with post? I think that's a newbie question, I know... Thanks for help. -- View this message in context: http://www.nabble.com/forms-and-getBaseUrl%28%29-tf4278416s16154.html#a12211053 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Layout Status ?
I was trying to put into consideration, setting a default layout for a specific module. One may have a blog or admin module with uses a completely different default layout. I am not sure if Zend_Application would suggest us to create module controller to extend from because of the namespaced registry (I'm probably wrong, as I only skimmed the proposal). The question is would xend/zend_layout handle setting default module layouts on top of a global default layout or should we create a controller and set the default module layout in init()? Being able to change a module or even a controllers layout outside of the module would allow modules to less dependent on it's environment. I guess this also depends on how you use zend_layout too, if each action is a layout section (menu, body, sidebar), the page content can be changed dynamically rather than having a layout section be set by a subrequest in a module etc... It's just a rant, but I would like your thoughts? -( Matthew Weier O'Phinney-3 wrote: -- PotatoBob [EMAIL PROTECTED] wrote (on Friday, 17 August 2007, 11:33 PM -0700): I sure hope default module layouts and a setConfig() feature are added to zend_layout :( Ralph and I were discussing Zend_Layout yesterday. The current design we're looking at would have a default layout, and allow specifying the layout to use either via a setLayout() accessor or as an argument to a render() method. I'll take into consideration a setConfig() feature. Matthew Weier O'Phinney-3 wrote: -- Kamil [EMAIL PROTECTED] wrote (on Friday, 17 August 2007, 03:25 PM +0200): What is the status of http://framework.zend.com/wiki/display/ZFPROP/Zend_Layout Zend_Layout or Zend_View Enhanced . Before version 1.0 there was big discussion about it ,so is layout management will be in version 1.1 ? I'm currently in the process of reviewing Zend_Layout and Zend_View_Enhanced. At this point, it looks like most of Zend_View_Enhanced will be accepted with minor changes and minus the layout support and Zend_View changes it suggests. I am also actively working with Ralph and Padraic to finalize the Zend_Layout proposal and scope. Both will be available for 1.1.0. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- View this message in context: http://www.nabble.com/Zend_Layout-Status---tf4285662s16154.html#a12217687 Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Regex route and url assembling
I seem to have a problem with the regex route and assembling urls with the
redirector helper.
!-- Paste route (/123) --
paste
typeZend_Controller_Router_Route_Regex/type
route(\d+)/route
defaults
moduledefault/module
controllerindex/controller
actionview/action
/defaults
map
id1/id
/map
reverse%s/reverse
/paste
Where id = (integer)
$this-getHelper('Redirector')-gotoRoute(array('id' = 1), 'paste', true);
does not work
$this-getHelper('Redirector')-gotoRoute(array($id), 'paste', true); does
work
--
View this message in context:
http://www.nabble.com/Regex-route-and-url-assembling-tf4164403s16154.html#a11848685
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Inconsistencies with the frontcontroller and the request's getBaseUrl
I'll add it to my todo list of stuff to report ;) Matthew Weier O'Phinney-3 wrote: -- PotatoBob [EMAIL PROTECTED] wrote (on Tuesday, 17 July 2007, 01:53 AM -0700): This is more of an unexpected problem than a bug I guess, but just to let you guys know, the frontController sets the requests baseUrl if you set it via the controllers setBaseUrl method. You can then grab it via the getBaseUrl accessor, but the problem is the getBaseUrl method does not grab from the request object but from the $_baseUrl var which is only set if you set the base url using the front controllers setBaseUrl method. Good catch! Could you please post an issue in the tracker regarding this? -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- View this message in context: http://www.nabble.com/Inconsistencies-with-the-frontcontroller-and-the-request%27s-getBaseUrl-tf4095633s16154.html#a11649931 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] ZF Application Variables?
Matthew, as far as I can see, Zend_Cache defines what backends you can load, so writing our own backend at the moment doesn't seem possible without editing the Zend_Cache factory to include our class. Matthew Weier O'Phinney-3 wrote: -- Laurent TAUPIAC [EMAIL PROTECTED] wrote (on Friday, 29 June 2007, 02:35 PM +0200): To expand on what Bill mentioned previously, the combination of Zend_Config + Zend_Cache + Zend_Registry would accomplish the same functionality: * Zend_Config for the actual variable storage. * Zend_Cache for caching to disk (or database) between requests * Zend_Registry to make it globally available in the application Basically, everything you need is already present. Imho, database is the best way to manage easily race condition. Disk storage will lead to problems, especially if you have many fronts. Zend_Cache can use either memcached or Zend Platform for backends, and you can also write your own backend. The benefit to a setup like this is that the developer can test locally using filesystem or sqlite, and then push live without changing any code but the backend used. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- View this message in context: http://www.nabble.com/ZF-Application-Variables--tf3996469s16154.html#a11371622 Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] ViewRenderer inconsistency with routes and view scripts
ViewRenerer is inconsisteny with the default routes and possibly custom routes because instead of rendering 'actionName.phtml' which would be consistent with the name of the action it renders the action specified in the url. An example of this would be valid urls /foo/fooBar and /foo/foo_bar which would route to the same action in controller foo and action fooBarAction(). The problem here is with ViewRenderer, it will use the action supplied in the url for the name of the view script. So /foo/fooBar would render fooBar.phtml while /foo/foo_bar would render 'foo_bar.phtml' this is a problem because it would throw a 'cannot find view script' exception on a valid url from the router's point of view. Some may argue that this doesn't matter, but VR should be consistent with the rest of the framework. A route that is valid should be translated no matter the view script name. Suppose only intended the user to visit /foo/foobar, but the user visits /foo/foo_bar then they would get a 'view script' not found exception (usually caught by the errorController) but the point is that the action was dispatched, so VR should render the view. If you still don't understand what I just said (I know, it's confusing), but the problem is VR translates whatever was provided by ':action' in the spec as the view script to render. The solution I believe is that VR should stick to a solid naming convention for view scripts either by actionName.phtml or something. -- View this message in context: http://www.nabble.com/ViewRenderer-inconsistency-with-routes-and-view-scripts-tf3996483s16154.html#a11349989 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] ZF Application Variables?
I don't think so, there really isn't a need for it with all the current features... Registry etc... Another reason is it looks like bad practice to me. -- View this message in context: http://www.nabble.com/ZF-Application-Variables--tf3996469s16154.html#a11350087 Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] RE: Model Loading helper
Well, when you get into a modular directory structure, we don't have the
simplicity of just setting the models folder for every model into the
include_path. Then again we could do require_once('../models/MyModel.php');
Bill Karwin wrote:
Here's what I'm doing in the bootstrap (index.php) of a demo app I'm
working on:
require_once 'Zend/Loader.php';
Zend_Loader::registerAutoload();
$appDir = dirname(dirname(__FILE__)) . '/app';
set_include_path($appDir . '/models' . PATH_SEPARATOR .
get_include_path());
Following this, I have no problem loading models. Isn't this simpler
than using another helper class? Am I missing something?
However, I realize that in more complex apps, it may not be quite this
simple.
Regards,
Bill Karwin
From: PotatoBob [mailto:[EMAIL PROTECTED]
Sent: Monday, June 18, 2007 11:47 AM
To: fw-general@lists.zend.com
Subject: [fw-general] Model Loading helper
Normally models are loaded through require_once() or
Zend_Loader::loadClass() with painfully long paths similar to
module/models/Model.php or module/models/controller/Model.php and
more likely ../models/controller/Model.php. After a few discussions on
#zftalk with ralphschindler,
SpotSec_Controller_Action_Helper_ModelLoader came to existence.
ModelLoader does exactly what the name says, it makes loading models one
step simpler by determining the path to the models folder so all you
have to do is specify the model's class name.
Anyways I just wanted to see some feedback, as I never actually
tested it and feel it is useless...
If you are using the conventional modular directory structure
then ModelLoader is already setup and ready to go. If you are not then
you can setup ModelLoader using __construct();
Usage: $this-_helper-ModelLoader('UserModel');
link in proposal form: ModelLoading helper
http://svn.ralphschindler.com/repo/ZendFramework/Zend_Controller-ModelL
oader/library/Zend/Controller/Action/Helper/ModelLoader.php
SpotSec http://www.spotsec.com
View this message in context: Model Loading helper
http://www.nabble.com/Model-Loading-helper-tf3942096s16154.html#a111815
98
Sent from the Zend Framework mailing list archive
http://www.nabble.com/Zend-Framework-f15440.html at Nabble.com.
--
View this message in context:
http://www.nabble.com/Model-Loading-helper-tf3942096s16154.html#a11181906
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Server_Reflection
Matthew Weier O'Phinney-3 wrote:
-- PotatoBob [EMAIL PROTECTED] wrote
(on Saturday, 26 May 2007, 07:10 PM -0700):
There seems to be a problem that I've found when brought up by someone on
#
zftalk. It seems that Zend_Server_Reflection has problems with the use of
func_get_args() when there is an @param php doc stating extra params.
This will be difficult to resolve; Zend_Server_Reflection iterates
through the params in the docblock and then uses PHP's Reflection API to
determine additional information (default values, whether or not it's
optional, type hints, etc.); if the Reflection API has no knowledge of
the param, you'll get errors like this.
However, I can probably add some logic to check first that the parameter
is found by Reflection, and if not, mark it as optional.
Could you log this as an issue in JIRA for me so I can track it better?
Thanks!
Example:
/**
* Internally redirects one action to another
*
* @param string $action The new action to be redirected to
* @param mixed Any other parameters passed to this method will be passed
as
* parameters to the new action.
* @access public
*/
function setAction($action) {
$this-action = $action;
$args = func_get_args();
unset($args[0]);
call_user_func_array(array($this, $action), $args);
}
Error msg: ( ! ) Fatal error: Call to a member function isOptional() on a
non-object in Zend/Server/Reflection/Function/Abstract.php on line 346
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Unfortunately I don't have a jira account otherwise I would of posted one
already :S
--
View this message in context:
http://www.nabble.com/Zend_Server_Reflection-tf3822461s16154.html#a10827860
Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Zend_Server_Reflection
There seems to be a problem that I've found when brought up by someone on
#zftalk. It seems that Zend_Server_Reflection has problems with the use of
func_get_args() when there is an @param php doc stating extra params.
Example:
/**
* Internally redirects one action to another
*
* @param string $action The new action to be redirected to
* @param mixed Any other parameters passed to this method will be passed
as
* parameters to the new action.
* @access public
*/
function setAction($action) {
$this-gt;action = $action;
$args = func_get_args();
unset($args[0]);
call_user_func_array(array(amp;$this, $action), $args);
}
Error msg: ( ! ) Fatal error: Call to a member function isOptional() on a
non-object in Zend/Server/Reflection/Function/Abstract.php on line 346
---
http://www.spotsec.com SpotSec
--
View this message in context:
http://www.nabble.com/Zend_Server_Reflection-tf3822461s16154.html#a10821733
Sent from the Zend Framework mailing list archive at Nabble.com.
