Re: [fw-general] Re: Form from 2 entities and extra inputs
FWIW I advice against using form and input filter annotations in doctrine entities. While it may be handy for rapid and simple prototyping, it has been stated many many times that doctrine entities are dumb value objects, and they should not be concerned with anything other than themselves. This is a strong design nuance that is often not given the importance it deserves. Using annotations inside entities to build forms and input filters is actually obfuscating business logic, inside something that should not be aware of any logic whatsoever in the first place. Furthermore, you'll find that such annotations are limited in flexibility (e.g. objects needing concrete dependencies in their options like doctrine's ObjectSelect). The only annotations I consistently use are the doctrine mappings for DDL, which is the only thing entities *could* be concerned with, but even that is arguable and may end up being inconvenient in some cases. TL;DR: write separate classes for all your forms/fieldsets/filters. Leave the annotations for DDL mappings only.
[fw-general] Zend\Di\Di configuration array?
Is there any better Zend\Di\Di configuration array in the wild? The one on the docs page is wrong: the hierarchy is completely incorrect, and it's missing a number of keys. Is there a better example somewhere else? Something that displays all possible configuration options? --- Philip g...@gpcentre.net http://www.gpcentre.net/
Re: [fw-general] Zend\Di\Di configuration array?
Please report the problems on the bug tracker. https://github.com/zendframework/zf2-documentation/issues Thanks! Kind regards, Frank Am 10.01.2014, 20:07 Uhr, schrieb Philip G guice...@gmail.com: Is there any better Zend\Di\Di configuration array in the wild? The one on the docs page is wrong: the hierarchy is completely incorrect, and it's missing a number of keys. Is there a better example somewhere else? Something that displays all possible configuration options? --- Philip g...@gpcentre.net http://www.gpcentre.net/ -- List: fw-general@lists.zend.com Info: http://framework.zend.com/archives Unsubscribe: fw-general-unsubscr...@lists.zend.com
Re: [fw-general] Zend\Di\Di configuration array?
I find this one more up to date: http://zf2.readthedocs.org/en/latest/modules/zend.di.introduction.html Don't know if this is the one you looked at though? On 10 Jan 2014 19:08, Philip G guice...@gmail.com wrote: Is there any better Zend\Di\Di configuration array in the wild? The one on the docs page is wrong: the hierarchy is completely incorrect, and it's missing a number of keys. Is there a better example somewhere else? Something that displays all possible configuration options? --- Philip g...@gpcentre.net http://www.gpcentre.net/
Re: [fw-general] Zend\Di\Di configuration array?
It is the lest docs; however, it's not changed (I was looking at the official published docs): http://zf2.readthedocs.org/en/latest/modules/zend.di.configuration.html I found that the Configuration file looks more like: 'definition' = [ 'class' = [ 'Class Name' = [ 'method Name' = [ 'paramName1' = [options], ] ], ], ], But I'm not even scratching the surface. There's also 'instantiator', and 'supertypes' under the class name part. The 'instance' counterpart is completely different: the CODE looks things such as alias and preferences and under some unknown key, parameters, injections and shared --- Philip g...@gpcentre.net http://www.gpcentre.net/ On Fri, Jan 10, 2014 at 11:19 AM, Daniel Latter dan.lat...@gmail.comwrote: I find this one more up to date: http://zf2.readthedocs.org/en/latest/modules/zend.di.introduction.html Don't know if this is the one you looked at though? On 10 Jan 2014 19:08, Philip G guice...@gmail.com wrote: Is there any better Zend\Di\Di configuration array in the wild? The one on the docs page is wrong: the hierarchy is completely incorrect, and it's missing a number of keys. Is there a better example somewhere else? Something that displays all possible configuration options? --- Philip g...@gpcentre.net http://www.gpcentre.net/
Re: [fw-general] Zend\Di\Di configuration array?
That's the thing, I don't know what's correct. And I'm already spending more time than I should be trying to decipher Zend\Di to determine if it fully suits my needs. --- Philip g...@gpcentre.net http://www.gpcentre.net/ On Fri, Jan 10, 2014 at 11:14 AM, Frank Brückner d...@froschdesignstudio.dewrote: Please report the problems on the bug tracker. https://github.com/zendframework/zf2-documentation/issues Thanks! Kind regards, Frank Am 10.01.2014, 20:07 Uhr, schrieb Philip G guice...@gmail.com: Is there any better Zend\Di\Di configuration array in the wild? The one on the docs page is wrong: the hierarchy is completely incorrect, and it's missing a number of keys. Is there a better example somewhere else? Something that displays all possible configuration options? --- Philip g...@gpcentre.net http://www.gpcentre.net/ -- List: fw-general@lists.zend.com Info: http://framework.zend.com/archives Unsubscribe: fw-general-unsubscr...@lists.zend.com
Re: [fw-general] Zend\Di\Di configuration array?
Just raided my favourites: https://github.com/rwilson04/zf2-dependency-injection https://github.com/ralphschindler/Zend_DI-Examples http://ocramius.github.io/blog/zend-framework-2-controllers-and-dependency-injection-with-zend-di/ On 10 Jan 2014 19:31, Philip G g...@gpcentre.net wrote: That's the thing, I don't know what's correct. And I'm already spending more time than I should be trying to decipher Zend\Di to determine if it fully suits my needs. --- Philip g...@gpcentre.net http://www.gpcentre.net/ On Fri, Jan 10, 2014 at 11:14 AM, Frank Brückner d...@froschdesignstudio.dewrote: Please report the problems on the bug tracker. https://github.com/zendframework/zf2-documentation/issues Thanks! Kind regards, Frank Am 10.01.2014, 20:07 Uhr, schrieb Philip G guice...@gmail.com: Is there any better Zend\Di\Di configuration array in the wild? The one on the docs page is wrong: the hierarchy is completely incorrect, and it's missing a number of keys. Is there a better example somewhere else? Something that displays all possible configuration options? --- Philip g...@gpcentre.net http://www.gpcentre.net/ -- List: fw-general@lists.zend.com Info: http://framework.zend.com/archives Unsubscribe: fw-general-unsubscr...@lists.zend.com
Re: [fw-general] Zend\Di\Di configuration array?
On Fri, Jan 10, 2014 at 1:31 PM, Philip G g...@gpcentre.net wrote: That's the thing, I don't know what's correct. And I'm already spending more time than I should be trying to decipher Zend\Di to determine if it fully suits my needs. Obligatory question: do you specifically need Zend\Di, or more generally an Inversion of Control (IoC) container? I ask, as we're generally no longer pushing usage of the Zend\Di component, in favor of using Zend\ServiceManager as an IoC container. While the Di component attempts to guess how wiring should occur, you typically end up having to do a lot to correct errors in wiring, as well as jump through many hoops if you want to do anything custom, such as provide specific implementation types to use in specific cases, or provide scalar configuration for instances. Additionally, unless you've cached the wiring discovered by the reflection scanner, it tends to perform really, really poorly. The ServiceManager is far easier to configure, and much more performant (though, as with just about any generalized component, could be even better). If you are looking for an IoC container to manage DI for your various services/instances, I'd recommend Zend\ServiceManager instead of Zend\Di. On Fri, Jan 10, 2014 at 11:14 AM, Frank Brückner d...@froschdesignstudio.dewrote: Please report the problems on the bug tracker. https://github.com/zendframework/zf2-documentation/issues Thanks! Kind regards, Frank Am 10.01.2014, 20:07 Uhr, schrieb Philip G guice...@gmail.com: Is there any better Zend\Di\Di configuration array in the wild? The one on the docs page is wrong: the hierarchy is completely incorrect, and it's missing a number of keys. Is there a better example somewhere else? Something that displays all possible configuration options? --- Philip g...@gpcentre.net http://www.gpcentre.net/ -- List: fw-general@lists.zend.com Info: http://framework.zend.com/archives Unsubscribe: fw-general-unsubscr...@lists.zend.com -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: fw-general@lists.zend.com Info: http://framework.zend.com/archives Unsubscribe: fw-general-unsubscr...@lists.zend.com
[fw-general] Re: Zend\Di\Di configuration array?
Excuse, that I interfere. I think that part of the DI functionality could be used as an alternative to shared event manager. -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/Zend-Di-Di-configuration-array-tp4661430p4661437.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] Zend\Di\Di configuration array?
On Fri, Jan 10, 2014 at 12:41 PM, Matthew Weier O'Phinney matt...@zend.comwrote: The ServiceManager is far easier to configure, and much more performant (though, as with just about any generalized component, could be even better). If you are looking for an IoC container to manage DI for your various services/instances, I'd recommend Zend\ServiceManager instead of Zend\Di. I was looking into that, but ran into a configuration snafu when I hit the DB component: I couldn't figure out a way to Lazy load PDO (requires a DSN) when the DSN is stored within the same file as the SM configuration. And SM Configuration doesn't have a built-in config pass. All that stuff is injected via Zend MVC, which I'm not using. DI doesn't really solve this either, but using a Proxy class could work ... maybe. My application is very simple: a single php tracking script. Reads in visits, deciphers their cookies, and makes a call to a DB or Web Service back end depending on parameters from their cookie. The basic requirements are: - Speed - Parsing and managing incoming and outgoing cookies. - Ability to set content-type headers to either json or gif. - Log to directly to DB or Web Services (or neither), depending on cookie parameters. zend-http resolves a number of these: it gives me PhpEnv.\Request and Response, as well as Http\Client for WS. My plan for DB was PDO directly (using pdo_cassandra). Now, I want this to be easily swappable for testability, and that's where I ran into the trouble. Naturally, you'd think DI and a DiC; however, DiC is notorious for not being speedy, unless configured (thus my config question). In addition, it's not a lazy loader, something I was toying with the idea of Proxy class for. ServiceManager would resolve the swapability of RequestInterface and ResponseInterface. But, I fell when it came to configuring for lazy loading. PDO requires a DSN, which is stored within the same config as SM values. And, I can't load PDO until I know this request is to be logged to the DB. WS is slightly less tricky: it's not as overhead dependent, and can be instantiated with no impact, and URL set at a later time. --- Philip g...@gpcentre.net http://www.gpcentre.net/
[fw-general] BjyAuthorize RuleProvider from Doctrine (help requested)
I've been entangling myself in code, while trying to implement a RuleProvider to work with BjyAuthorize ZF2 module. I need a bit of help. I put my code here for reference https://github.com/dennis-fedco/BjyRuleProvider . I am looking for help in some specific areas. Some problems I am currently experiencing: * FedcoUser/src/FedcoUser/Entity/ControllerGuardRule class - should it implement any Providers, like BjyAuthorize\Provider\Rule\ProviderInterface interface, or not? I ask because it seems that I have FedcoUser/src/FedcoUser/Provider/Rule/ObjectRepositoryProvider that already implements Rule\ProviderInterface. All in all, where, and how should I retrieve my rules? * My Doctrine mappings for ControllerGuardRule are out of whack https://gist.github.com/dennis-fedco/51d994f05a1255396f64 , but I have another post on that topic elsewhere (in doctrine forum). My goal basically is have an application that uses BjyAuthorize and loads Rules from the Database via Doctrine. Can a good soul take a peek at my code perhaps and help me untangle myself? Thanks, Dennis -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/BjyAuthorize-RuleProvider-from-Doctrine-help-requested-tp4661439.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] ServiceManager, an object with __constructor parameters.
As pointed out earlier by our lord and savior Matthew O'Phinney, Zend\Di is
becoming less desired component in favor of ServiceManager.
Works for me. I agree SM is much easier to use, except in one instance. So
I turn to the community to help me resolve this one instance:
How do I get a ServiceManager object with __constructor() parameters?
My dilemma: I'm building a super-small application with very limited
requirements that is dependent on PDO.
However, PDO requires constructor parameters. How do I create a PDO loader
that can 1) be cached by PHP5.5 opcode 2) doesn't require a bunch of other
classes and 3) can be loaded only at the time I need to make a PDO call.
(speed of application is #1 requirement)
$sm-get('PDO'); doesn't work since I can't pass in construction parameters.
$sm-get('Db'); won't work either, since construction parameters exist
within the same file the closure would be included:
```
app.config.php = [
'sm' = array(
factories = array(
'Db' = function ($sm) {
(PS: Are these cached now? I recall some caching issues
with embedded closures)
// $sm-get('Config'); is invalid; not using
Zend\Application that would inject this.
//return new PDO(); // No way to get construct parameters
below...
},
)
),
//
db = [
dsn =
'cassandra:host=127.0.0.1;port=9160,host=127.0.0.2;port=9162;version=3.0.0;dbname=test',
username = null,
password = null,
],
];
```
For Di, I could pass in the parameters: $di-get('PDO', $cfg['db']);
This isn't possible for SM. This little functionality would make a world of
difference.
---
Philip
g...@gpcentre.net
http://www.gpcentre.net/
Re: [fw-general] ServiceManager, an object with __constructor parameters.
i think the AbstractPluginManager had a seconds argument that is passed to
the constructor.
On Jan 10, 2014 7:57 PM, Philip G guice...@gmail.com wrote:
As pointed out earlier by our lord and savior Matthew O'Phinney, Zend\Di is
becoming less desired component in favor of ServiceManager.
Works for me. I agree SM is much easier to use, except in one instance. So
I turn to the community to help me resolve this one instance:
How do I get a ServiceManager object with __constructor() parameters?
My dilemma: I'm building a super-small application with very limited
requirements that is dependent on PDO.
However, PDO requires constructor parameters. How do I create a PDO loader
that can 1) be cached by PHP5.5 opcode 2) doesn't require a bunch of other
classes and 3) can be loaded only at the time I need to make a PDO call.
(speed of application is #1 requirement)
$sm-get('PDO'); doesn't work since I can't pass in construction
parameters.
$sm-get('Db'); won't work either, since construction parameters exist
within the same file the closure would be included:
```
app.config.php = [
'sm' = array(
factories = array(
'Db' = function ($sm) {
(PS: Are these cached now? I recall some caching issues
with embedded closures)
// $sm-get('Config'); is invalid; not using
Zend\Application that would inject this.
//return new PDO(); // No way to get construct parameters
below...
},
)
),
//
db = [
dsn =
'cassandra:host=127.0.0.1;port=9160,host=127.0.0.2;port=9162;version=3.0.0;dbname=test',
username = null,
password = null,
],
];
```
For Di, I could pass in the parameters: $di-get('PDO', $cfg['db']);
This isn't possible for SM. This little functionality would make a world of
difference.
---
Philip
g...@gpcentre.net
http://www.gpcentre.net/
Re: [fw-general] ServiceManager, an object with __constructor parameters.
another trick ala functional programming is returning a closure insidebof a
closure:
array(
'factories' = array(
'db' = function ($sm) {
return function ($constructorArgs) {
return new Db($constructorArgs);
};
},
)
)
you would then use this as
$db = $this-getServiceLocator()-get('db');
$db('someparam');
or
$db-__invoke('someparam');
since its a bit hacky. i am not sure how others would approve it.
On Jan 10, 2014 7:57 PM, Philip G guice...@gmail.com wrote:
As pointed out earlier by our lord and savior Matthew O'Phinney, Zend\Di is
becoming less desired component in favor of ServiceManager.
Works for me. I agree SM is much easier to use, except in one instance. So
I turn to the community to help me resolve this one instance:
How do I get a ServiceManager object with __constructor() parameters?
My dilemma: I'm building a super-small application with very limited
requirements that is dependent on PDO.
However, PDO requires constructor parameters. How do I create a PDO loader
that can 1) be cached by PHP5.5 opcode 2) doesn't require a bunch of other
classes and 3) can be loaded only at the time I need to make a PDO call.
(speed of application is #1 requirement)
$sm-get('PDO'); doesn't work since I can't pass in construction
parameters.
$sm-get('Db'); won't work either, since construction parameters exist
within the same file the closure would be included:
```
app.config.php = [
'sm' = array(
factories = array(
'Db' = function ($sm) {
(PS: Are these cached now? I recall some caching issues
with embedded closures)
// $sm-get('Config'); is invalid; not using
Zend\Application that would inject this.
//return new PDO(); // No way to get construct parameters
below...
},
)
),
//
db = [
dsn =
'cassandra:host=127.0.0.1;port=9160,host=127.0.0.2;port=9162;version=3.0.0;dbname=test',
username = null,
password = null,
],
];
```
For Di, I could pass in the parameters: $di-get('PDO', $cfg['db']);
This isn't possible for SM. This little functionality would make a world of
difference.
---
Philip
g...@gpcentre.net
http://www.gpcentre.net/
[fw-general] Re: Form from 2 entities and extra inputs
Thanks for your reaply and advice, I really appreciate it; I had a bad feeling about them, although I somehow like them at the beginning. I've also read that annotations are speed killer, is that true btw? Based on that I've decided to remove annotations and provide that info inside forms and fieldsets instead. I was just wondering how should I organize my forms/fieldsets for actions add and edit? Those two actions need a different input filter, that's why I created two fieldset with filters, one per each action, and I'm calling them from Form based on a parameter that is passed into the form from controller (so this way I only have 1 form). Should I rather have 1 form and 1 fieldset/filter per action? According to your words I guess I should remove filters from fieldsets (this way I could also use only 1 fieldset, since inputs are the same). Would I then add filters to form inside form rather than from fieldset? You didn't mention form Elements, so I was wondering when we would use those? -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/Form-from-2-entities-and-extra-inputs-tp4661395p4661443.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
