[fw-general] zf2 + stored procedure

2013-02-26 Thread hiren.d
is anyone have an idea about how to execute stored procedure with multi
resultset in zf2  ?



Thanks in advance...



--
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/zf2-stored-procedure-tp4659339.html
Sent from the Zend Framework mailing list archive at Nabble.com.

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




[fw-general] Re: What is the relationship between the view, the controller and the action in the controller exactly?

2013-02-26 Thread Yves
Ok, a little bit of an update.  It's displaying and functioning now... sort
of.
In the view, at the very end, I had to execute exit() in order for the form
to show up.  This leads me to believe that I'm messing up the rendering of
the form.

Is there a way to better control the rendering of the form?

Here's my code in its state in case you're curious.

Controller:
http://bin.cakephp.org/view/71127540   

View:
http://bin.cakephp.org/view/1880430008
  

Form:
http://bin.cakephp.org/view/78402641   



--
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/What-is-the-relationship-between-the-view-the-controller-and-the-action-in-the-controller-exactly-tp4659325p4659336.html
Sent from the Zend Framework mailing list archive at Nabble.com.

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




[fw-general] Re: ZfcUser Password Hash Mechanism Change

2013-02-26 Thread whisher
eokorie wrote
> I have successfully managed to implement zfcUser in a project I am working
> on. BUt I do have one question, is there a way I can change the password
> hashing mechanism.  I have read the documentation that came with zFcUser
> and I am aware of the risks involved, but for this purpose, I am trying to
> keep the passwords the same as they are for the time being until I am
> convert all my users to a more secure method.
> 
> The current password system, makes use of a random salt that gets
> encrypted with sha1 and in turn the passwords in encrypted with the salt
> and again with sha1.
> 
> Essentially, the basics of the current encryption system are as follows:
> 
> 1. random salt ($salt) is encrypted $encrypted_salt = sha1($salt)
> 2. Submitted password get encrypted along with sha1($encrypted_salt .
> $givenPassword)
> 
> How can I modify zfcUser to allow me to keep this method of encrypting my
> passwords?
> 
> Many Thanks

Hi,
afaik zfcUser use Bcrypt for manage password
you can peep it in 
ZfcUser\Authentication\Adapter Db
authenticate
$fields = $this->getOptions()->getAuthIdentityFields();
while ( !is_object($userObject) && count($fields) > 0 ) {
$mode = array_shift($fields);
switch ($mode) {
case 'username':
$userObject =
$this->getMapper()->findByUsername($identity);
break;
case 'email':
$userObject =
$this->getMapper()->findByEmail($identity);
break;
}
}
$bcrypt = new Bcrypt();
$bcrypt->setCost($this->getOptions()->getPasswordCost());
if (!$bcrypt->verify($credential,$userObject->getPassword())) {
// Password does not match
$e->setCode(AuthenticationResult::FAILURE_CREDENTIAL_INVALID)
  ->setMessages(array('Supplied credential is invalid.'));
$this->setSatisfied(false);
return false;
}





--
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/ZfcUser-Password-Hash-Mechanism-Change-tp4659332p4659335.html
Sent from the Zend Framework mailing list archive at Nabble.com.

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




[fw-general] Re: What is the relationship between the view, the controller and the action in the controller exactly?

2013-02-26 Thread Yves
I've found something new out.  Basically, if include a Zend_Debug::dump in my
view and then an exit at the end of the file, then the contents of the file
will render fine... up to a point.  Which is weird.  It's as if there is
some buffer that's not getting flushed.

Does this sound familiar?



--
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/What-is-the-relationship-between-the-view-the-controller-and-the-action-in-the-controller-exactly-tp4659325p4659334.html
Sent from the Zend Framework mailing list archive at Nabble.com.

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




Re: [fw-general] Fundamental question: Why isn’t the service manager super global?

2013-02-26 Thread Matthew Weier O'Phinney
On Tue, Feb 26, 2013 at 3:46 AM, roberto blanko  wrote:
> In terms of redundancy, this is just a simple example but should make my
> point clear:
>
> return array(
> 'service_manager' => array(
> 'factories' => array(
> 'Main\Model\StreamRepository' => function($sm) {
> $dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
> return new \Main\Model\StreamRepository($sm, $dbAdapter);
> },
> 'Main\Model\AccountRepository' => function($sm) {
> $dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
> return new \Main\Model\AccountRepository($sm, $dbAdapter);
> },
> 'Main\Model\UserRepository' => function($sm) {
> $dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
> return new \Main\Model\TwitterRepository($sm, $dbAdapter);
> },
> 'Main\Model\ProjectRepository' => function($sm) {
> $dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
> return new \Main\Model\GoogleRepository($sm, $dbAdapter);
> },
> ),
> ),
> );
>
> Each of my repositories (which extends AbstractTableGateway) needs to have
> the DB adapter injected. It would make things faster, if factories could be
> defined based on inherited classes. E.g. in the case above the factories
> for all classes inheriting from Main\Model\AbstractRepository need to have
> the same factory. Or is there a solution for this already? I could use an
> initializer class but this wouldn’t perform very well, would it? Since the
> initializer would be called whether I needed it or not.

There are two approaches you could use here.

First is an initializer. There is actually very little performance
impact from that, and it would reduce the above to four lines (one
line for each class, defined as invokables).

Second is to use an AbstractFactory. The idea behind the
AbstractFactory is when you have many classes that have the same
creational pattern. You might define it like this:

use Zend\ServiceManager\AbstractFactoryInterface;
use Zend\ServiceManager\ServiceLocatorInterface;

class DbAwareFactory implements AbstractFactoryInterface
{
protected $serviceClasses = array(
'Main\Model\AccountRepository',
'Main\Model\GoogleRepository',
'Main\Model\StreamRepository',
'Main\Model\TwitterRepository',
);

public function
canCreateServiceWithName(ServiceLocatorInterface $services, $name,
$requestedName)
{
return in_array($name, $this->serviceClasses);
}

public function createServiceWithName(ServiceLocatorInterface
$services, $name, $requestedName)
{
$dbAdapter = $services->get('Zend\Db\Adapter\Adapter');
return new $name($services, $dbAdapter);
}
}

You would then register it like:

'abstract_factories => array(
'DbAwareFactory',
),

Both initializers and abstract factories were designed with this
problem in mind. While I like initializers, Marco Pivetta points out
that (a) if you're not aware they exist, they may lead to hard to
trace issues when injections you don't expect happen, and (b) if you
do not register an initializer, but thought it was already, again, you
can have some potential hard-to-trace issues. If you feel those might
be problems, the abstract factory is the way to go.

> On Mon, Feb 25, 2013 at 3:08 PM, Matthew Weier O'Phinney
> wrote:
>
>> On Sat, Feb 23, 2013 at 4:31 PM, roberto blanko 
>> wrote:
>> > Matthew, thanks for this elaborate answer. Makes a lot of things clearer
>> > for me.
>> >
>> > So, in that case I stick to injecting everything I need. This really
>> bloats
>> > my module.config.php with a lot of redundant stuff and slows me down
>> quite
>> > a bit, but I see your point.
>>
>>
>> What kind of redundant stuff are you seeing? Depending on what it is,
>> and whether others report similarly, we may be able to come up with
>> some solutions to reduce repetition.
>>
>>
>> > On Tue, Feb 19, 2013 at 5:08 PM, Matthew Weier O'Phinney
>> > wrote:
>> >
>> >> On Tue, Feb 19, 2013 at 3:37 AM, roberto blanko <
>> robertobla...@gmail.com>
>> >> wrote:
>> >> > one problem drives me nuts, since I started working with ZF2 (never
>> >> worked
>> >> > with Version 1):
>> >> >
>> >> > I'm in need of the service manager all the time. E.g. to access my
>> config
>> >> > in config/autoload/local.php via $sm->get('Config'). I need the
>> service
>> >> > manager everywhere. Controllers, models, you name it. And I don’t
>> want to
>> >> > pass it around by hand, which would make everything ugly.
>> >> >
>> >> > Now I’ve started to implement ServiceLocatorAwareInterface in most
>> >> classes.
>> >>
>> >> Don't.
>> >>
>> >> The best option is to define factories for your classes that inject
>> >> the dependencies for you. When you do that, you no longer have hidden

[fw-general] ZfcUser Password Hash Mechanism Change

2013-02-26 Thread eokorie
I have successfully managed to implement zfcUser in a project I am working
on. BUt I do have one question, is there a way I can change the password
hashing mechanism.  I have read the documentation that came with zFcUser and
I am aware of the risks involved, but for this purpose, I am trying to keep
the passwords the same as they are for the time being until I am convert all
my users to a more secure method.

The current password system, makes use of a random salt that gets encrypted
with sha1 and in turn the passwords in encrypted with the salt and again
with sha1.

Essentially, the basics of the current encryption system are as follows:

1. random salt ($salt) is encrypted $encrypted_salt = sha1($salt)
2. Submitted password get encrypted along with sha1($encrypted_salt .
$givenPassword)

How can I modify zfcUser to allow me to keep this method of encrypting my
passwords?

Many Thanks



--
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/ZfcUser-Password-Hash-Mechanism-Change-tp4659332.html
Sent from the Zend Framework mailing list archive at Nabble.com.

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




[fw-general] Getting objectManager / serviceLocator in fieldset

2013-02-26 Thread Webdevilopers
In order to get my object manager inside my fieldset's init() function I
followed the docs:
http://framework.zend.com/manual/2.1/en/modules/zend.form.advanced-use-of-forms.html#the-specific-case-of-initializers

  

At first I found out that I had to change

to

otherwise I got an error:
*setServiceLocator() must be compatible with that of
Zend\ServiceManager\ServiceLocatorAwareInterface::setServiceLocator()*

When calling $this->getServiceLocator() I get an instance of the
FormManager.
Additionally calling $this->getServiceLocator()->getServiceLocator() returns
NULL.

Since I am still new to DI I wonder if I am missing a place to inject?

Testing I switched from

to


Since then I get this error:
*exception 'Zend\Di\Exception\RuntimeException' with message 'Invalid
instantiator of type "NULL" for
"Zend\ServiceManager\ServiceLocatorInterface".'
An abstract factory could not create an instance of
applicationformmyform(alias: Application\Form\MyForm).*
 
Anyway reading some other threads using the ServiceLocator Awareness isn't
recommended. Is using the *FormElementProviderInterface* the alternative?




-
http://www.webdevilopers.net
https://www.facebook.com/webdevilopers
http://www.twitter.com/webdevilopers
--
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/Getting-objectManager-serviceLocator-in-fieldset-tp4659331.html
Sent from the Zend Framework mailing list archive at Nabble.com.

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com




Re: [fw-general] Fundamental question: Why isn’t the service manager super global?

2013-02-26 Thread Marco Pivetta
Initializers don't necessarily perform bad, but add some overhead and are
hard to debug, and also force you to have eventual hard dependencies
configured as soft dependencies (because of setter injection).

An alternative solution (with significant performance drop) is using
`Zend\Di` for that.

You are doing it correctly right now in my opinion, and I don't see that
much redunancy in there, and wouldn't change your current way of doing it

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On 26 February 2013 10:46, roberto blanko  wrote:

> In terms of redundancy, this is just a simple example but should make my
> point clear:
>
> return array(
> 'service_manager' => array(
> 'factories' => array(
> 'Main\Model\StreamRepository' => function($sm) {
> $dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
> return new \Main\Model\StreamRepository($sm, $dbAdapter);
> },
> 'Main\Model\AccountRepository' => function($sm) {
> $dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
> return new \Main\Model\AccountRepository($sm, $dbAdapter);
> },
> 'Main\Model\UserRepository' => function($sm) {
> $dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
> return new \Main\Model\TwitterRepository($sm, $dbAdapter);
> },
> 'Main\Model\ProjectRepository' => function($sm) {
> $dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
> return new \Main\Model\GoogleRepository($sm, $dbAdapter);
> },
> ),
> ),
> );
>
> Each of my repositories (which extends AbstractTableGateway) needs to have
> the DB adapter injected. It would make things faster, if factories could be
> defined based on inherited classes. E.g. in the case above the factories
> for all classes inheriting from Main\Model\AbstractRepository need to have
> the same factory. Or is there a solution for this already? I could use an
> initializer class but this wouldn’t perform very well, would it? Since the
> initializer would be called whether I needed it or not.
>
>
> On Mon, Feb 25, 2013 at 3:08 PM, Matthew Weier O'Phinney
> wrote:
>
> > On Sat, Feb 23, 2013 at 4:31 PM, roberto blanko  >
> > wrote:
> > > Matthew, thanks for this elaborate answer. Makes a lot of things
> clearer
> > > for me.
> > >
> > > So, in that case I stick to injecting everything I need. This really
> > bloats
> > > my module.config.php with a lot of redundant stuff and slows me down
> > quite
> > > a bit, but I see your point.
> >
> >
> > What kind of redundant stuff are you seeing? Depending on what it is,
> > and whether others report similarly, we may be able to come up with
> > some solutions to reduce repetition.
> >
> >
> > > On Tue, Feb 19, 2013 at 5:08 PM, Matthew Weier O'Phinney
> > > wrote:
> > >
> > >> On Tue, Feb 19, 2013 at 3:37 AM, roberto blanko <
> > robertobla...@gmail.com>
> > >> wrote:
> > >> > one problem drives me nuts, since I started working with ZF2 (never
> > >> worked
> > >> > with Version 1):
> > >> >
> > >> > I'm in need of the service manager all the time. E.g. to access my
> > config
> > >> > in config/autoload/local.php via $sm->get('Config'). I need the
> > service
> > >> > manager everywhere. Controllers, models, you name it. And I don’t
> > want to
> > >> > pass it around by hand, which would make everything ugly.
> > >> >
> > >> > Now I’ve started to implement ServiceLocatorAwareInterface in most
> > >> classes.
> > >>
> > >> Don't.
> > >>
> > >> The best option is to define factories for your classes that inject
> > >> the dependencies for you. When you do that, you no longer have hidden
> > >> dependencies, and you have everything you need up front. When you have
> > >> an instance of the object, it's fully configured.
> > >>
> > >> If you need configuration, you're doing it wrong -- that configuration
> > >> should either be injected, or the objects the configuration
> > >> defines/configures should be injected.
> > >>
> > >> As an example, let's consider a common controller. Let's say it makes
> > >> use of a TableGateway, and you have one or more methods in that
> > >> TableGateway that return a paginator instance. You want to be able to
> > >> specify how many results per page the paginator should use. And for
> > >> insert()/update() operations, you want this information tied to a form
> > >> so that the validation is done correctly; however, you want a
> > >> different form based on the operation (new vs. edit). One element of
> > >> the form needs a DB instance in order to validate.
> > >>
> > >> In ZF1, you'd likely do the following:
> > >>
> > >> * Pull the "db" resource from the bootstrap (actually, a DB adapter).
> > >> * Create a TableGateway instance, and inject the DB adapter.
> > >> * Pull configuration from the registry or the bootstrap.
> > >> * Use that configuration to tell the TableGatewa

Re: [fw-general] Fundamental question: Why isn’t the service manager super global?

2013-02-26 Thread roberto blanko
In terms of redundancy, this is just a simple example but should make my
point clear:

return array(
'service_manager' => array(
'factories' => array(
'Main\Model\StreamRepository' => function($sm) {
$dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
return new \Main\Model\StreamRepository($sm, $dbAdapter);
},
'Main\Model\AccountRepository' => function($sm) {
$dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
return new \Main\Model\AccountRepository($sm, $dbAdapter);
},
'Main\Model\UserRepository' => function($sm) {
$dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
return new \Main\Model\TwitterRepository($sm, $dbAdapter);
},
'Main\Model\ProjectRepository' => function($sm) {
$dbAdapter = $sm->get('Zend\Db\Adapter\Adapter');
return new \Main\Model\GoogleRepository($sm, $dbAdapter);
},
),
),
);

Each of my repositories (which extends AbstractTableGateway) needs to have
the DB adapter injected. It would make things faster, if factories could be
defined based on inherited classes. E.g. in the case above the factories
for all classes inheriting from Main\Model\AbstractRepository need to have
the same factory. Or is there a solution for this already? I could use an
initializer class but this wouldn’t perform very well, would it? Since the
initializer would be called whether I needed it or not.


On Mon, Feb 25, 2013 at 3:08 PM, Matthew Weier O'Phinney
wrote:

> On Sat, Feb 23, 2013 at 4:31 PM, roberto blanko 
> wrote:
> > Matthew, thanks for this elaborate answer. Makes a lot of things clearer
> > for me.
> >
> > So, in that case I stick to injecting everything I need. This really
> bloats
> > my module.config.php with a lot of redundant stuff and slows me down
> quite
> > a bit, but I see your point.
>
>
> What kind of redundant stuff are you seeing? Depending on what it is,
> and whether others report similarly, we may be able to come up with
> some solutions to reduce repetition.
>
>
> > On Tue, Feb 19, 2013 at 5:08 PM, Matthew Weier O'Phinney
> > wrote:
> >
> >> On Tue, Feb 19, 2013 at 3:37 AM, roberto blanko <
> robertobla...@gmail.com>
> >> wrote:
> >> > one problem drives me nuts, since I started working with ZF2 (never
> >> worked
> >> > with Version 1):
> >> >
> >> > I'm in need of the service manager all the time. E.g. to access my
> config
> >> > in config/autoload/local.php via $sm->get('Config'). I need the
> service
> >> > manager everywhere. Controllers, models, you name it. And I don’t
> want to
> >> > pass it around by hand, which would make everything ugly.
> >> >
> >> > Now I’ve started to implement ServiceLocatorAwareInterface in most
> >> classes.
> >>
> >> Don't.
> >>
> >> The best option is to define factories for your classes that inject
> >> the dependencies for you. When you do that, you no longer have hidden
> >> dependencies, and you have everything you need up front. When you have
> >> an instance of the object, it's fully configured.
> >>
> >> If you need configuration, you're doing it wrong -- that configuration
> >> should either be injected, or the objects the configuration
> >> defines/configures should be injected.
> >>
> >> As an example, let's consider a common controller. Let's say it makes
> >> use of a TableGateway, and you have one or more methods in that
> >> TableGateway that return a paginator instance. You want to be able to
> >> specify how many results per page the paginator should use. And for
> >> insert()/update() operations, you want this information tied to a form
> >> so that the validation is done correctly; however, you want a
> >> different form based on the operation (new vs. edit). One element of
> >> the form needs a DB instance in order to validate.
> >>
> >> In ZF1, you'd likely do the following:
> >>
> >> * Pull the "db" resource from the bootstrap (actually, a DB adapter).
> >> * Create a TableGateway instance, and inject the DB adapter.
> >> * Pull configuration from the registry or the bootstrap.
> >> * Use that configuration to tell the TableGateway how many items per
> >> page to return for Paginator instances.
> >> * You'd create a different form for each operation, and inject the DB
> >> adapter you pulled.
> >>
> >> This is a fair bit of work. And it really, really doesn't belong in
> >> your controller, any of it.
> >>
> >> Let's look at how to do it in ZF2.
> >>
> >> First, I'd create a factory for the TableGateway.
> >>
> >> 'my-table-gateway' => function ($services) {
> >> $db = $services->get('db');
> >> $config = $services->get('config');
> >> $perPage = isset($config['per_page']) ? $config['per_page'] :
> 10;
> >> $tableGateway = new MyTableGateway($db, $perPage);
> >> return $tableGateway;
> >> }
> >>
> >> Note that in the _factory_ I'm pulling th