Re: [fw-general] Zend_Db Transactions - How to get a initiate transaction ?

2008-04-15 Thread Maresa

Perhaps what you can do is to have a class member variable like
isTransactionStarted and 2 other methods called beginTransaction() and
commit() like this:

private function beginTransaction() {
   if ($this->isTransactionStarted === false) {
  $this->objDb->beginTransaction();
  $this->isTransactionStarted = true;
   }
}

private function commit() {
if ($this->isTransactionStarted) {
  $this->objDb->commit();
  $this->isTransactionStarted = false;
   }
}

Then, instead of calling $this->objDb->beginTransaction(), you call
$this->beginTransaction() which now should never begin transaction twice.

Oh yeah ... you may want to do method rollback() as well on your class.

Hope it works for you ...

MSN


Juan Felipe Alavarez Saldarriaga wrote:
> 
> Hey :)
> 
> Is there a way to use a initiate transaction ? I mean, I got this:
> 
> class MyUsersClass
> {
> protected $objDb = null;
> 
> public function __construct()
> {
> $this->objDb = Zend_Registry::get( 'objDb' );
> }
> 
> public function save( Array $arrData )
> {
>   $this->objDb->beginTransaction();
>   
>   try 
>   {
> // Try to insert the user groups.
> foreach ( $arrUserGroups AS $intGroupIndex => $intGroupId )
> {
> $arrUserGroupsData = array( "user_id" => $lastInsertId,
> "group_id" => $intGroupId );
> 
> self::saveUserGroups( $arrUserGroupsData  );
> }
> 
>   $this->objDb->commit();
> }
> catch ( Exception $objException )
> {
> $this->objDb->rollBack();
> }
> }
> 
> public function saveUserGroups( Array $arrArguments )
> {
> if ( false !== empty( $arrArguments ) )
> {
> throw new Exception( "Data to save user groups can't be
> empty." );
> }
> 
> if ( false !== empty( $arrArguments["user_id"] ) )
> {
> throw new Exception( "User id can't be empty." );
> }
> 
> if ( false !== empty( $arrArguments["group_id"] ) )
> {
> throw new Exception( "Group id can't be empty." );
> }
> 
>   $this->objDb->beginTransaction();
> 
> try
> {
> // Insert data.
> $this->objDb->insert( $this->strUserGroupsTable, $arrArguments
> );
> 
>   $this->objDb->commit();
> }
> catch ( Exception $objException )
> {
>   $this->objDb->rollBack();
> 
> throw new Exception( "Can't save user groups -
> ({$objException->getMessage()})" );
> }
> }
> }
> 
> So I'm saving some user data into the save method, that method have a
> transaction started, then I call the saveUserGroups method on the same
> class and it have another 
> transaction started, is possible to, I don't know, get the transaction
> started in the save method ? cause I got a fatal error that another
> transaction is started.
> 
> Thx.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Zend_Db-Transactions---How-to-get-a-initiate-transaction---tp15960812p16717517.html
Sent from the Zend Framework mailing list archive at Nabble.com.



Re: [fw-general] chmod in Zend_Search_Lucene_Storage_Directory_Filesystem causes problems (ZF-2779)

2008-04-15 Thread Carl.Vondrick

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.



Re: [fw-general] custom form validator

2008-04-15 Thread Matthew Weier O'Phinney
-- 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] Is anyone processing Zend_Form forms manually in the views?

2008-04-15 Thread Matthew Weier O'Phinney
-- 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');
>  
> 
> 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:

form as $item): 
// iteration occurs over elements, sub forms, and display groups ?>



// or


some content
form->foo ?>


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:



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  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) 
> >> 
> >>   - form->getElement('username')->render();
> >> ?>
> > 
> > In your view script (used with the ViewScript decorator, as recomended
> > above), you could do exactly that, only easier:
> > 
> > form->username ?>
> > 
> >> 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

2008-04-15 Thread chinaski

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?

2008-04-15 Thread asadkn

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');
 

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  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) 
>> 
>>   - form->getElement('username')->render();
>> ?>
> 
> In your view script (used with the ViewScript decorator, as recomended
> above), you could do exactly that, only easier:
> 
> form->username ?>
> 
>> 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] Zend_Config_Ini - keys as an array

2008-04-15 Thread Robert Castley
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] Zend_Config_Ini - keys as an array

2008-04-15 Thread Vincent
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

2008-04-15 Thread Matthew Weier O'Phinney
-- 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:




Init
Authenticate
Access
Wrapper




> // 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] interaction between controller plugin and front controller or view

2008-04-15 Thread Denis Fohl
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

2008-04-15 Thread Vincent
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


[fw-general] Zend_Config_Ini - keys as an array

2008-04-15 Thread Paul Simon
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] Changing view path in bootstrap

2008-04-15 Thread Matthew Weier O'Phinney
-- 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:



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
> > supp

RE: [fw-general] interaction between controller plugin and front controller or view

2008-04-15 Thread Holger Lampe
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] interaction between controller plugin and front controller or view

2008-04-15 Thread Holger Lampe
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



[fw-general] interaction between controller plugin and front controller or view

2008-04-15 Thread Denis Fohl

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

2008-04-15 Thread Serkan Kibritoglu
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/
> >>>
> >>>
> >>

[fw-general] Zend_Form_Element_Select and null values

2008-04-15 Thread Łukasz Bandzarewicz

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:

 Please select region
 Region1
 ..etc


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.



[fw-general] chmod in Zend_Search_Lucene_Storage_Directory_Filesystem causes problems (ZF-2779)

2008-04-15 Thread Tristan Celder
"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] Overrinding Zend_Db_Adapter_Oracle::_connect() method

2008-04-15 Thread Mauricio Cuenca

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.