[fw-general] Overrinding Zend_Db_Adapter_Oracle::_connect() method
Hello,
I need to use a second database for my app and the connection method should
be easyconnect which is not supported by Zend Framework. I created the
following class (sort of):
class My_Db_Adapter_Oracle extends Db_Adapter_Oracle {
protected $_config = array(
'dbname' = null,
'hostname' = null,
'username' = null,
'password' = null,
);
protected function _connect() {
$this-_connection = oci_connect($this-_config['username'],
$this-_config['password,
'//' . $this-_config['hostname'] .
'/' . $this-_config['dbname']);
}
I saved this file as My_Oracle.php and placed it as and included file in the
controller which creates the connection, but when I call it, the original
Oracle adapter keeps being called.
I do not want to hack the code of my ZF's installation, I'd prefer extending
the class. How can I accomplish this in a elegant way?
Thanks!
--
View this message in context:
http://www.nabble.com/Overrinding-Zend_Db_Adapter_Oracle%3A%3A_connect%28%29-method-tp16698577p16698577.html
Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] chmod in Zend_Search_Lucene_Storage_Directory_Filesystem causes problems (ZF-2779)
Only file owners can chmod files. Since the apache user is usually a restricted user, with no shell, it's difficult to fire off cron jobs to update indexes out of band. This means that typically another user should do this. But the other user needs to take over ownership of the index files, and in that case, apache can no longer read the indexes and search breaks. Is anyone else having difficulty with this? Is there a workaround? As I am using an ant build to trigger the creation of an index, the index is owned by the user that triggered the build (in my local dev environment myself, and on our dev server this is cruisecontrol). However, apache of course runs as a different user. The only way I can get round this at the moment is running a chown on the index directory after the build takes place to make the owner the apache user. I of course have to reverse this before doing any index maintenance through our ant script... beyond the clumsiness of this is the issue that the index will be unavailable to users during each period of maintenance performed on the search. The only other way round this is to change the user that runs our ant script to that of our apache user... but that seems like quite a hack... Anyone else overcoming/struggling with this issue?
[fw-general] Zend_Form_Element_Select and null values
Hi!
How to handle null values in select elements?
For example I have table:
User {
region_id: foreign key, can be null
..ect
}
I have select with prompt:
select name=region_id
option value=-1Please select region/option
option value=1Region1/option
..etc
/select
in UsersController::createAction():
$form = new User_Form(); // Zend_Form instance
// handle $_POST data etc.
$data = $form-getValues(true);
// and very ugly:
if ($data['region_id'] == -1) $data['region_id'] = null; // !!
$user = new User(); // this is phpDoctrine record
$user-merge($data);
$user-save();
How to get rid of this redundant code?
Problem is very painful when I have large tables with FK or when I create
records in several places in the code.
--
View this message in context:
http://www.nabble.com/Zend_Form_Element_Select-and-null-values-tp16700805p16700805.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Changing view path in bootstrap
I think I could not express myself very well. Let's get to beginning with a
new clean $view object:
I create the $view. So it should have only one base path which is default.
Then I simply add my custom base path. Which is second added. Now this
custom base path becomes last in and should be first out isnt it?
When i execute, i see it renders the
default, first inned base path. So tell me is it FIFO or LIFO? Yes the
answer is FIFO.
And I want it to work as expected as LIFO. Nothing extra. Nothing default.
The path i have added last.
2008/4/14, Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- David Rogers [EMAIL PROTECTED] wrote
(on Monday, 14 April 2008, 10:49 AM -0400):
Well, the issue here is that kirpit may not be using the
array_(un)shift() functions to get his paths on the stack, initially,
like ZF does natively.
No, he is, because he's using Zend_View. His examples clearly show this,
too -- he simply wants a different behavior -- a FIFO stack.
The use of those functions for the LIFO stack
pattern is fairly well understood by many of us, but it's kinda
hackish... Like many things involving PHP and arrays. :D
On Apr 14, 2008, at 8:05 AM, Matthew Weier O'Phinney wrote:
-- kirpit [EMAIL PROTECTED] wrote
(on Monday, 14 April 2008, 10:12 AM +0300):
I disagree. Because the first on the stack which means index zero to
be executed.
We use array_unshift() to push new paths to the top of the stack,
which
means the *newest* path added to the stack is executed first. This is
the very definition of a LIFO stack, which is what Zend_View
implements.
When I add 2 base paths:
$view-addBasePath(realpath('./templates/default/'));
$view-addBasePath(realpath('./templates/fashion/'));
Script paths becomes like:
[0] = E:\htdocs\page\application\views\scripts\
The above is added by the ViewRenderer when a controller is invoked.
[1] = E:\htdocs\page\templates\fashion\scripts\
[2] = E:\htdocs\page\templates\default\scripts\
And exactly the index 0 is executed. If not exist it looks for index
1...
Which is exactly as it is designed. Script paths added later get
searched first, script paths added earlier get searched last -- again,
LIFO. This is so that you can have later script paths override
defaults.
If we did this as a FIFO stack, you would never be able to override
default paths with local paths.
I think the script paths should become like:
[0] = E:\htdocs\page\templates\fashion\scripts\
[1] = E:\htdocs\page\templates\default\scripts\
[2] = E:\htdocs\page\application\views\scripts\
Not going to happen, as it breaks the design goals and implementation
of
Zend_View.
If you want that behavior, you will need to subclass Zend_View
yourself
to do so.
2008/4/14, Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Serkan Kibritoglu [EMAIL PROTECTED] wrote
(on Sunday, 13 April 2008, 10:47 PM +0300):
2008/4/13, Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Serkan Kibritoglu [EMAIL PROTECTED] wrote
(on Sunday, 13 April 2008, 09:47 PM +0300):
Just in case or might be a feedback; The last added path is
supposed
to be used for rendering. But if there the default view folder
exists,
it still looks and renders it first. (ZF 1.5.1)
Hmmm... I haven't noticed that behavior at all. Can you show a short
reproduce script that reproduces the issue?
Here is the bootstrap:
$view = new Zend_View();
$view-addBasePath(realpath('./templates/default/'));
//$view-addBasePath(realpath('./templates/fashion/'));
/**
* Use our $view as renderer
*/
Zend_Controller_Action_HelperBroker
::getStaticHelper('viewRenderer')-
setView
($view);
Here goes the print_r($this-view); in an empty action.
Zend_View Object
(
[_path:private] = Array
(
[script] = Array
(
[0] = C:\xampp\htdocs\vpage\application\views\scripts\
[1] = C:\xampp\htdocs\vpage\templates\default\scripts\
)
This is correct. 'templates/default/scripts' is the first added
path,
and is therefor the last on the stack to be executed. No bug here.
If you don't trust this, put an index.phtml in each directory with
different contents, and see which one gets rendered (hint, it
will be
the one in application/views/scripts/).
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
[fw-general] interaction between controller plugin and front controller or view
Hi all,
i'm learning with zend framework and mvc architecture... and it's hard
for me :-)
Beause i want it for each controller in my app i made a plugin wich
purpose is to test if user is authenticated. I would like it, if true,
to pass the info to the view but it does not work, even i user is
authenticated, my view var is null. I suppose it's because the view
objetc is not yet initialised when the plugin is executed but i can't
see where or when to do this.
Here is my plugin :
class AuthPlugin extends Zend_Controller_Plugin_Abstract {
public function preDispatch(Zend_Controller_Request_Abstract $request) {
$auth = Zend_Auth::getInstance();
if ($auth-hasIdentity()) {
$this-view-user = $auth-getIdentity();
}
}
}
thanks for help
--
Denis
RE: [fw-general] interaction between controller plugin and front controller or view
As far as I know, a plugin is not View aware.
You can that functionality by:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
So your plugin could be like this:
class AuthPlugin extends Zend_Controller_Plugin_Abstract {
public function preDispatch(Zend_Controller_Request_Abstract
$request) {
$auth = Zend_Auth::getInstance();
if ($auth-hasIdentity()) {
$viewRenderer-view-user = $auth-getIdentity();
}
}
}
Cheers,
Holger
-Original Message-
From: Denis Fohl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 15, 2008 5:21 PM
To: fw-general@lists.zend.com
Subject: [fw-general] interaction between controller plugin and front
controller or view
Hi all,
i'm learning with zend framework and mvc architecture... and it's hard
for me :-)
Beause i want it for each controller in my app i made a plugin wich
purpose is to test if user is authenticated. I would like it, if true,
to pass the info to the view but it does not work, even i user is
authenticated, my view var is null. I suppose it's because the view
objetc is not yet initialised when the plugin is executed but i can't
see where or when to do this.
Here is my plugin :
class AuthPlugin extends Zend_Controller_Plugin_Abstract {
public function preDispatch(Zend_Controller_Request_Abstract
$request) {
$auth = Zend_Auth::getInstance();
if ($auth-hasIdentity()) {
$this-view-user = $auth-getIdentity();
}
}
}
thanks for help
--
Denis
RE: [fw-general] interaction between controller plugin and front controller or view
Sorry forgot to put $viewRenderer into the preDispatch function.
===
As far as I know, a plugin is not View aware.
You can that functionality by:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
So your plugin could be like this:
class AuthPlugin extends Zend_Controller_Plugin_Abstract {
public function preDispatch(Zend_Controller_Request_Abstract
$request) {
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$auth = Zend_Auth::getInstance();
if ($auth-hasIdentity()) {
$viewRenderer-view-user = $auth-getIdentity();
}
}
}
Cheers,
Holger
-Original Message-
From: Denis Fohl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 15, 2008 5:21 PM
To: fw-general@lists.zend.com
Subject: [fw-general] interaction between controller plugin and front
controller or view
Hi all,
i'm learning with zend framework and mvc architecture... and it's hard
for me :-)
Beause i want it for each controller in my app i made a plugin wich
purpose is to test if user is authenticated. I would like it, if true,
to pass the info to the view but it does not work, even i user is
authenticated, my view var is null. I suppose it's because the view
objetc is not yet initialised when the plugin is executed but i can't
see where or when to do this.
Here is my plugin :
class AuthPlugin extends Zend_Controller_Plugin_Abstract {
public function preDispatch(Zend_Controller_Request_Abstract
$request) {
$auth = Zend_Auth::getInstance();
if ($auth-hasIdentity()) {
$this-view-user = $auth-getIdentity();
}
}
}
thanks for help
--
Denis
Re: [fw-general] Changing view path in bootstrap
-- Serkan Kibritoglu [EMAIL PROTECTED] wrote
(on Tuesday, 15 April 2008, 06:05 PM +0300):
I think I could not express myself very well. Let's get to beginning
with a new clean $view object:
I create the $view. So it should have only one base path which is default.
Then I simply add my custom base path. Which is second added. Now this
custom base path becomes last in and should be first out isnt it?
When i execute, i see it renders the
default, first inned base path. So tell me is it FIFO or LIFO?
Yes the answer is FIFO.
And I want it to work as expected as LIFO. Nothing extra. Nothing default. The
path i have added last.
First off, don't look at how the path data is stored in Zend_View; it's
irrelevant. Look instead at the behavior. The behavior is documented and
tested as a LIFO stack.
You're claiming that you're not seeing this behavior, that instead
you're seeing a FIFO behavior, but since you don't provide any code or
scripts to recreate it, I cannot verify.
Here is what I've done to attempt to recreate what you're describing.
First, a directory tree:
test.php
views/
test1/
index.phtml
test2/
index.phtml
In views/test1/index.phtml and views/test2/index.phtml, I have the
following:
?= realpath(__FILE__) ?
In test.php:
$view = new Zend_View();
$view-addScriptPath('views/test1/');
$view-addScriptPath('views/test2/');
echo $view-render('index.phtml');
The actual output, as well as the expected result, is a string
containing:
views/test2/index.phtml
If you are getting different results, I need to know the ZF version, PHP
version, and OS you're using. If the above does not depict what you're
doing, please send in *code* -- NOT a description -- that reproduces the
behavior you're observing so I can test.
2008/4/14, Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- David Rogers [EMAIL PROTECTED] wrote
(on Monday, 14 April 2008, 10:49 AM -0400):
Well, the issue here is that kirpit may not be using the
array_(un)shift() functions to get his paths on the stack, initially,
like ZF does natively.
No, he is, because he's using Zend_View. His examples clearly show this,
too -- he simply wants a different behavior -- a FIFO stack.
The use of those functions for the LIFO stack
pattern is fairly well understood by many of us, but it's kinda
hackish... Like many things involving PHP and arrays. :D
On Apr 14, 2008, at 8:05 AM, Matthew Weier O'Phinney wrote:
-- kirpit [EMAIL PROTECTED] wrote
(on Monday, 14 April 2008, 10:12 AM +0300):
I disagree. Because the first on the stack which means index zero to
be executed.
We use array_unshift() to push new paths to the top of the stack,
which
means the *newest* path added to the stack is executed first. This is
the very definition of a LIFO stack, which is what Zend_View
implements.
When I add 2 base paths:
$view-addBasePath(realpath('./templates/default/'));
$view-addBasePath(realpath('./templates/fashion/'));
Script paths becomes like:
[0] = E:\htdocs\page\application\views\scripts\
The above is added by the ViewRenderer when a controller is invoked.
[1] = E:\htdocs\page\templates\fashion\scripts\
[2] = E:\htdocs\page\templates\default\scripts\
And exactly the index 0 is executed. If not exist it looks for index
1...
Which is exactly as it is designed. Script paths added later get
searched first, script paths added earlier get searched last -- again,
LIFO. This is so that you can have later script paths override
defaults.
If we did this as a FIFO stack, you would never be able to override
default paths with local paths.
I think the script paths should become like:
[0] = E:\htdocs\page\templates\fashion\scripts\
[1] = E:\htdocs\page\templates\default\scripts\
[2] = E:\htdocs\page\application\views\scripts\
Not going to happen, as it breaks the design goals and implementation
of
Zend_View.
If you want that behavior, you will need to subclass Zend_View
yourself
to do so.
2008/4/14, Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Serkan Kibritoglu [EMAIL PROTECTED] wrote
(on Sunday, 13 April 2008, 10:47 PM +0300):
2008/4/13, Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Serkan Kibritoglu [EMAIL PROTECTED] wrote
(on Sunday, 13 April 2008, 09:47 PM +0300):
Just in case or might be a feedback; The last added path is
supposed
to be used for rendering. But if there the default view folder
exists,
it still looks and renders it first. (ZF 1.5.1)
Hmmm... I haven't noticed that behavior at all. Can you show a short
reproduce
[fw-general] Zend_Config_Ini - keys as an array
Hi,
I've been using Zend_Config_Ini successfully in a number of applications. I'm
wondering if the following is the correct way to configure arrays? My concern
is that I don't see it documented anywhere to add brackets to the end of keys,
like plugin[]. I just happened on a comment at
[http://us.php.net/manual/en/function.parse-ini-file.php#75983] saying it can
be done. Does anybody else use 'key[]' to configure arrays? Thanks, Paul
Set config.php
---
[Production]
; plugins
plugin[] = Init
plugin[] = Authenticate
plugin[] = Access
plugin[] = Wrapper
Get array
---
$conf = new Zend_Config_Ini('config.php','Production');
$plugins = $conf-plugin-toArray();
Dump $plugins
---
array (
0 = 'Init',
1 = 'Authenticate',
2 = 'Access',
3 = 'Wrapper',
)
Re: [fw-general] Zend_Config_Ini - keys as an array
On 4/15/08, Paul Simon [EMAIL PROTECTED] wrote:
Hi,
I've been using Zend_Config_Ini successfully in a number of applications.
I'm wondering if the following is the correct way to configure arrays? My
concern is that I don't see it documented anywhere to add brackets to the
end of keys, like plugin[]. I just happened on a comment at [
http://us.php.net/manual/en/function.parse-ini-file.php#75983] saying it
can be done. Does anybody else use 'key[]' to configure arrays? Thanks, Paul
Set config.php
---
[Production]
; plugins
plugin[] = Init
plugin[] = Authenticate
plugin[] = Access
plugin[] = Wrapper
Get array
---
$conf = new Zend_Config_Ini('config.php','Production');
$plugins = $conf-plugin-toArray();
Dump $plugins
---
array (
0 = 'Init',
1 = 'Authenticate',
2 = 'Access',
3 = 'Wrapper',
)
I think you're supposed to do it like this:
Set config.php
---
[Production]
; plugins
plugin.0 = Init
plugin.1 = Authenticate
plugin.2 = Access
plugin.3 = Wrapper
Get array
---
$conf = new Zend_Config_Ini('config.php','Production');
// Now you can access them like:
echo $conf-plugin-0; // Displays 'Init'
// Or you could convert it to an array which would return the array
described
$plugins = $conf-plugin-toArray();
Dump $plugins
---
array (
0 = 'Init',
1 = 'Authenticate',
2 = 'Access',
3 = 'Wrapper',
)
--
Vincent
Re: [fw-general] interaction between controller plugin and front controller or view
now it works, it is possible to set the view object in the plugin. Your
post and some posts by Matthew help me to try this :
class AuthPlugin extends Zend_Controller_Plugin_Abstract {
public function preDispatch(Zend_Controller_Request_Abstract $request){
$view = new Zend_View();
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$viewRenderer-setView($view);
$auth = Zend_Auth::getInstance();
if ($auth-hasIdentity()) {
$view-user = $auth-getIdentity();
}
}
}
I have now my user authentification set automatically in all my
controllers and views... that's what i wanted for the moment, even if
its not the state of the art regarding MVC architecture.
Thank you.
Holger Lampe a écrit :
As far as I know, a plugin is not View aware.
You can that functionality by:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
So your plugin could be like this:
class AuthPlugin extends Zend_Controller_Plugin_Abstract {
public function preDispatch(Zend_Controller_Request_Abstract
$request) {
$auth = Zend_Auth::getInstance();
if ($auth-hasIdentity()) {
$viewRenderer-view-user = $auth-getIdentity();
}
}
}
Cheers,
Holger
-Original Message-
From: Denis Fohl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 15, 2008 5:21 PM
To: fw-general@lists.zend.com
Subject: [fw-general] interaction between controller plugin and front
controller or view
Hi all,
i'm learning with zend framework and mvc architecture... and it's hard
for me :-)
Beause i want it for each controller in my app i made a plugin wich
purpose is to test if user is authenticated. I would like it, if true,
to pass the info to the view but it does not work, even i user is
authenticated, my view var is null. I suppose it's because the view
objetc is not yet initialised when the plugin is executed but i can't
see where or when to do this.
Here is my plugin :
class AuthPlugin extends Zend_Controller_Plugin_Abstract {
public function preDispatch(Zend_Controller_Request_Abstract
$request) {
$auth = Zend_Auth::getInstance();
if ($auth-hasIdentity()) {
$this-view-user = $auth-getIdentity();
}
}
}
thanks for help
--
Denis Fohl
--
df-info
06 84 38 21 99
Re: [fw-general] Zend_Config_Ini - keys as an array
-- Vincent [EMAIL PROTECTED] wrote
(on Tuesday, 15 April 2008, 06:22 PM +0200):
On 4/15/08, Paul Simon [EMAIL PROTECTED] wrote:
Hi,
I've been using Zend_Config_Ini successfully in a number of applications.
I'm wondering if the following is the correct way to configure arrays? My
concern is that I don't see it documented anywhere to add brackets to the
end of keys, like plugin[]. I just happened on a comment at [http://
us.php.net/manual/en/function.parse-ini-file.php#75983] saying it can be
done. Does anybody else use 'key[]' to configure arrays? Thanks, Paul
Set config.php
---
[Production]
; plugins
plugin[] = Init
plugin[] = Authenticate
plugin[] = Access
plugin[] = Wrapper
Get array
---
$conf = new Zend_Config_Ini('config.php','Production');
$plugins = $conf-plugin-toArray();
Dump $plugins
---
array (
0 = 'Init',
1 = 'Authenticate',
2 = 'Access',
3 = 'Wrapper',
)
I think you're supposed to do it like this:
Set config.php
---
[Production]
; plugins
plugin.0 = Init
plugin.1 = Authenticate
plugin.2 = Access
plugin.3 = Wrapper
No, you can't do this...
Get array
---
$conf = new Zend_Config_Ini('config.php',
'Production');
// Now you can access them like:
echo $conf-plugin-0; // Displays 'Init'
... because the above is invalid PHP. (Try it; you'll get an unexpected
T_LNUMBER parse error.)
I hadn't tried what the original poster suggested before, but I've
verified it works... and I'll be using it in the future.
BTW, the equivelent XML would be:
?xml version=1.0?
configdata
Production
pluginInit/plugin
pluginAuthenticate/plugin
pluginAccess/plugin
pluginWrapper/plugin
/Production
/configdata
// Or you could convert it to an array which would return the array described
$plugins = $conf-plugin-toArray();
Dump $plugins
---
array (
0 = 'Init',
1 = 'Authenticate',
2 = 'Access',
3 = 'Wrapper',
)
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Zend_Config_Ini - keys as an array
On 4/15/08, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote:
-- Vincent [EMAIL PROTECTED] wrote
(on Tuesday, 15 April 2008, 06:22 PM +0200):
On 4/15/08, Paul Simon [EMAIL PROTECTED] wrote:
Hi,
I've been using Zend_Config_Ini successfully in a number of
applications.
I'm wondering if the following is the correct way to configure
arrays? My
concern is that I don't see it documented anywhere to add brackets
to the
end of keys, like plugin[]. I just happened on a comment at [http://
us.php.net/manual/en/function.parse-ini-file.php#75983] saying it
can be
done. Does anybody else use 'key[]' to configure arrays? Thanks,
Paul
Set config.php
---
[Production]
; plugins
plugin[] = Init
plugin[] = Authenticate
plugin[] = Access
plugin[] = Wrapper
Get array
---
$conf = new Zend_Config_Ini('config.php','Production');
$plugins = $conf-plugin-toArray();
Dump $plugins
---
array (
0 = 'Init',
1 = 'Authenticate',
2 = 'Access',
3 = 'Wrapper',
)
I think you're supposed to do it like this:
Set config.php
---
[Production]
; plugins
plugin.0 = Init
plugin.1 = Authenticate
plugin.2 = Access
plugin.3 = Wrapper
No, you can't do this...
Get array
---
$conf = new Zend_Config_Ini('config.php',
'Production');
// Now you can access them like:
echo $conf-plugin-0; // Displays 'Init'
... because the above is invalid PHP. (Try it; you'll get an unexpected
T_LNUMBER parse error.)
Ah, of course, stupid. I knew I was missing something, thanks for
correcting...
--
Vincent
RE: [fw-general] Zend_Config_Ini - keys as an array
Excellent find! Thank you! You have managed to solve an age old problem
for me :-)
- Robert
-Original Message-
From: Paul Simon [mailto:[EMAIL PROTECTED]
Sent: 15 April 2008 17:03
To: fw-general@lists.zend.com
Subject: [fw-general] Zend_Config_Ini - keys as an array
Hi,
I've been using Zend_Config_Ini successfully in a number of applications.
I'm wondering if the following is the correct way to configure arrays? My
concern is that I don't see it documented anywhere to add brackets to the
end of keys, like plugin[]. I just happened on a comment at
[http://us.php.net/manual/en/function.parse-ini-file.php#75983] saying it
can be done. Does anybody else use 'key[]' to configure arrays? Thanks, Paul
Set config.php
---
[Production]
; plugins
plugin[] = Init
plugin[] = Authenticate
plugin[] = Access
plugin[] = Wrapper
Get array
---
$conf = new Zend_Config_Ini('config.php','Production');
$plugins = $conf-plugin-toArray();
Dump $plugins
---
array (
0 = 'Init',
1 = 'Authenticate',
2 = 'Access',
3 = 'Wrapper',
)
This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 plc internal virus protection system.
This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 plc internal virus protection system.
Re: [fw-general] Is anyone processing Zend_Form forms manually in the views?
Thanks. But I don't see how can it be applied to a full form.
For example, a form created like this:
$form = new Zend_Form();
$form-setAction('/usr/login')
-setMethod('post')
-setDecorators(array(array('ViewScript',
array('class' = 'form
element', 'viewScript' = 'index/form-test.phtml';
// Create and configure username element:
$username = $form-createElement('text', 'username');
snip
Here, the viewScript is decorator is set to form-test.phtml, but I can't
decorate the whole form using the view script? I will have hundreds of files
if I have to create a view file for each element that needs more control
(and allows designers to edit).
Matthew Weier O'Phinney-3 wrote:
-- asadkn [EMAIL PROTECTED] wrote
(on Friday, 11 April 2008, 02:25 PM -0700):
I want to keep the forms separated in the views and thus would like to
parse
generated forms in views. Instead of relying on Zend_Form decorators
generated HTML, I would like to do it all manually. It gets extremely
messy
when I have to use decorators with few of my HTML-rich forms.
Please check out the ViewScript decorator in the documentation; this is
probably the best fit for your needs. Set your form to use this
decorator, and then you can customize the output of your form as you see
fit. You can find that documentation on the following manual page:
http://framework.zend.com/manual/en/zend.form.standardDecorators.html#zend.form.standardDecorators.viewScript
Perhaps I want to create div and other such HTML elements myself, but
use
Zend_Form's decorators to create the input, select, etc. (and obviously
have
them filled when editing). That still should save me from writing lot of
repeated code.
In views, I wish if something like this was possible: (where $this-form
is
a form created using Zend_Form in the controller)
div - ?php echo $this-form-getElement('username')-render();
?/div
In your view script (used with the ViewScript decorator, as recomended
above), you could do exactly that, only easier:
div?php echo $this-form-username ?/div
As I see it, each element's data is protected and thus cannot be accessed
from outside. Maybe I should try sub-classing Zend_Form each time but
that
still will require me to spend a lot of time to figure out how to do it
right.
Not true -- there are accessors for every member stored in the form
elements, and most metadata is actually directly accessible as virtual
members using overloading. Please read up on the documentation:
http://framework.zend.com/manual/en/zend.form.elements.html#zend.form.elements.metadata
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
--
View this message in context:
http://www.nabble.com/Is-anyone-processing-Zend_Form-forms-manually-in-the-views--tp16629046p16710256.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] custom form validator
Thanks for the reply. I fiddled with path and got it to work using:
$element-addPrefixPath('My','My/');
However, the same code does not work when I use add the prefix to the form:
$form-addElementPrefixPath('My','My/');
I thought that adding the prefex path to the form itself made the path
available to all of the elements? Am I missing something?
Thanks,
Sam
--
View this message in context:
http://www.nabble.com/custom-form-validator-tp16628634p16710350.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Is anyone processing Zend_Form forms manually in the views?
-- asadkn [EMAIL PROTECTED] wrote
(on Tuesday, 15 April 2008, 02:18 PM -0700):
Thanks. But I don't see how can it be applied to a full form.
For example, a form created like this:
$form = new Zend_Form();
$form-setAction('/usr/login')
-setMethod('post')
-setDecorators(array(array('ViewScript',
array('class' = 'form
element', 'viewScript' = 'index/form-test.phtml';
// Create and configure username element:
$username = $form-createElement('text', 'username');
snip
Here, the viewScript is decorator is set to form-test.phtml, but I can't
decorate the whole form using the view script? I will have hundreds of files
if I have to create a view file for each element that needs more control
(and allows designers to edit).
You can loop over the form and render each item separately, or pull the
items out individually to render them:
? foreach ($this-form as $item):
// iteration occurs over elements, sub forms, and display groups ?
?= $item?? // render an invidual form item ?
? endforeach ?
// or
form
some content
?= $this-form-foo ?
/form
You can use the ViewScript on the form object so that you can do a more
complex form layout, and continue using standard decorators on the
elements. Or you can pull information from the individual elements in
order to build the HTML:
input type=text name=username
value=?= $this-form-username-getValue() ? /
etc.
Matthew Weier O'Phinney-3 wrote:
-- asadkn [EMAIL PROTECTED] wrote
(on Friday, 11 April 2008, 02:25 PM -0700):
I want to keep the forms separated in the views and thus would like to
parse
generated forms in views. Instead of relying on Zend_Form decorators
generated HTML, I would like to do it all manually. It gets extremely
messy
when I have to use decorators with few of my HTML-rich forms.
Please check out the ViewScript decorator in the documentation; this is
probably the best fit for your needs. Set your form to use this
decorator, and then you can customize the output of your form as you see
fit. You can find that documentation on the following manual page:
http://framework.zend.com/manual/en/zend.form.standardDecorators.html#zend.form.standardDecorators.viewScript
Perhaps I want to create div and other such HTML elements myself, but
use
Zend_Form's decorators to create the input, select, etc. (and obviously
have
them filled when editing). That still should save me from writing lot of
repeated code.
In views, I wish if something like this was possible: (where $this-form
is
a form created using Zend_Form in the controller)
div - ?php echo $this-form-getElement('username')-render();
?/div
In your view script (used with the ViewScript decorator, as recomended
above), you could do exactly that, only easier:
div?php echo $this-form-username ?/div
As I see it, each element's data is protected and thus cannot be accessed
from outside. Maybe I should try sub-classing Zend_Form each time but
that
still will require me to spend a lot of time to figure out how to do it
right.
Not true -- there are accessors for every member stored in the form
elements, and most metadata is actually directly accessible as virtual
members using overloading. Please read up on the documentation:
http://framework.zend.com/manual/en/zend.form.elements.html#zend.form.elements.metadata
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
--
View this message in context:
http://www.nabble.com/Is-anyone-processing-Zend_Form-forms-manually-in-the-views--tp16629046p16710256.html
Sent from the Zend Framework mailing list archive at Nabble.com.
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] custom form validator
-- chinaski [EMAIL PROTECTED] wrote
(on Tuesday, 15 April 2008, 02:20 PM -0700):
Thanks for the reply. I fiddled with path and got it to work using:
$element-addPrefixPath('My','My/');
However, the same code does not work when I use add the prefix to the form:
$form-addElementPrefixPath('My','My/');
I thought that adding the prefex path to the form itself made the path
available to all of the elements? Am I missing something?
It does... as long as:
* you're adding the prefix path *before* creating elements
* AND you're creating the elements via the form object's addElement()
or createElement() methods
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] chmod in Zend_Search_Lucene_Storage_Directory_Filesystem causes problems (ZF-2779)
Yes, I experience this all the time and it's very annoying. The best (albeit hackish) solution I've found is to change the Filesystem-createFile() method to skip throwing the exception when chmod fails. Everything works fine after this. Another solution I've implemented is to only run chmod if permissions are not already 0666. This gets around the issue as well. Tricky1982 wrote: Only file owners can chmod files. Since the apache user is usually a restricted user, with no shell, it's difficult to fire off cron jobs to update indexes out of band. This means that typically another user should do this. But the other user needs to take over ownership of the index files, and in that case, apache can no longer read the indexes and search breaks. Is anyone else having difficulty with this? Is there a workaround? As I am using an ant build to trigger the creation of an index, the index is owned by the user that triggered the build (in my local dev environment myself, and on our dev server this is cruisecontrol). However, apache of course runs as a different user. The only way I can get round this at the moment is running a chown on the index directory after the build takes place to make the owner the apache user. I of course have to reverse this before doing any index maintenance through our ant script... beyond the clumsiness of this is the issue that the index will be unavailable to users during each period of maintenance performed on the search. The only other way round this is to change the user that runs our ant script to that of our apache user... but that seems like quite a hack... Anyone else overcoming/struggling with this issue? -- View this message in context: http://www.nabble.com/chmod-in-Zend_Search_Lucene_Storage_Directory_Filesystem-causes-problems-%28ZF-2779%29-tp16703000p16714873.html Sent from the Zend Framework mailing list archive at Nabble.com.
