[fw-general] Problem with autoloading and unit testing Zend_Application
Hello together,
i set up a basic environment for unit testing my Zend_Application.
A basic test looks something like this:
public function testDefaultControllerAndAction() {
$this-dispatch('/');
$this-assertController('index');
$this-assertAction('index');
}
Calling phpunit in command line causes some php fatal errors. All classes
which are loaded with Zend_Application_Module_Autoloader in module bootrap
could not be found.
Are there any solution without setting up all requires manually?
Best regards
Aycko
--
View this message in context:
http://www.nabble.com/Problem-with-autoloading-and-unit-testing-Zend_Application-tp25534200p25534200.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] DataGrid
On Thu, Sep 24, 2009 at 8:38 AM, Cameron themsel...@gmail.com wrote: On Wed, Sep 23, 2009 at 6:49 PM, Matthew Weier O'Phinney matt...@zend.com wrote: -- Cameron themsel...@gmail.com wrote (on Wednesday, 23 September 2009, 09:42 AM +0800): Dojo grids. I've actually just moved a lot of my functionality over to Dojo JsonRestStore so I can do in-grid editing, it's not completed yet, but so far it is coming together really smoothly. I'm planning on doing a blog post on this combination (Zend_Rest_Route + dojox.data.JsonRestStore + dojox.grid.DataGrid) -- the three work together incredibly well, and make CRUD interfaces a breeze. So far I'm finding the same, it's a match made in heaven, except for some reason the grid doesn't seem to be triggering on edits. I can't see any ajax hits in firebug. Anyway, I'm sure it's my fault, I'll work it out! Ok, so I'm dumb, you need to manually call store.save(). Matthew, one thing that your post should cover over is the handling of error conditions - I'm struggling to find any examples of neatly dealing with what happens if your controller decides it's not happy with the data and has to let the store know so it can deal with the situation appropriately. On Tue, Sep 22, 2009 at 9:10 PM, Kyle Spraggs the...@spiffyjr.me wrote: I was curious what everyone is using for DataGrids. I am aware of http:// petala-azul.com/blog/ as well as http://code.google.com/p/ zend-framework-datagrid/ and there is also the possibility of Dojo Grids. Any input would be appreciated. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
[fw-general] Turn PHP errors/warnings/notices into exceptions
I'm trying to do this with set_error_handler(), my will is to trigger Error controller and catch this as application error, since I want to log all errors in one place - Error controller. I tried with setting error handler in bootstrap to function in index.php and that function calls error controller statically, but no success. There must be some easy way to do this. Anyone know? Regards, Saša Stamenković
[fw-general] Turn PHP errors/warnings/notices into exceptions
I'm trying to do this with set_error_handler(), my will is to trigger Error controller and catch this as application error, since I want to log all errors in one place - Error controller. I tried with setting error handler in bootstrap to function in index.php and that function calls error controller statically, but no success. There must be some easy way to do this. Anyone know? Regards, Saša Stamenković -- View this message in context: http://www.nabble.com/Turn-PHP-errors-warnings-notices-into-exceptions-tp25545609p25545609.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Split controller actions into multiple classes
The view displays the model in the UI yes, but the controller also affects the application's presentation, albeit not visually. Repetitive controller logic like a repeating subroutine that is modifying the view, should be factored into action helpers. Repetitive display logic belongs in view helpers as you correctly pointed out. I consider both part of my application's presentation ( but maybe the line is blurred in passive MVC ) Matthew Weier O'Phinney-3 wrote: Umm, not really. Controllers take the request, and determine what view(s) and/or model(s) need to be instantiated. The view is the actual presentation layer. -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25551508.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Split controller actions into multiple classes
I'd agree. The View handles the rendering of output, etc. But the Controller determines the View, constructs responses, and can do a lot to influence the final presentation. The Controller+View make up the presentation layer of the application. Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative From: josh.ribakoff josh.ribak...@gmail.com To: fw-general@lists.zend.com Sent: Thursday, September 24, 2009 11:11:57 AM Subject: Re: [fw-general] Split controller actions into multiple classes The view displays the model in the UI yes, but the controller also affects the application's presentation, albeit not visually. Repetitive controller logic like a repeating subroutine that is modifying the view, should be factored into action helpers. Repetitive display logic belongs in view helpers as you correctly pointed out. I consider both part of my application's presentation ( but maybe the line is blurred in passive MVC ) Matthew Weier O'Phinney-3 wrote: Umm, not really. Controllers take the request, and determine what view(s) and/or model(s) need to be instantiated. The view is the actual presentation layer. -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25551508.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] DataGrid
-- Cameron themsel...@gmail.com wrote (on Thursday, 24 September 2009, 02:53 PM +0800): On Thu, Sep 24, 2009 at 8:38 AM, Cameron themsel...@gmail.com wrote: On Wed, Sep 23, 2009 at 6:49 PM, Matthew Weier O'Phinney matt...@zend.com wrote: -- Cameron themsel...@gmail.com wrote (on Wednesday, 23 September 2009, 09:42 AM +0800): Dojo grids. I've actually just moved a lot of my functionality over to Dojo JsonRestStore so I can do in-grid editing, it's not completed yet, but so far it is coming together really smoothly. I'm planning on doing a blog post on this combination (Zend_Rest_Route + dojox.data.JsonRestStore + dojox.grid.DataGrid) -- the three work together incredibly well, and make CRUD interfaces a breeze. So far I'm finding the same, it's a match made in heaven, except for some reason the grid doesn't seem to be triggering on edits. I can't see any ajax hits in firebug. Anyway, I'm sure it's my fault, I'll work it out! Ok, so I'm dumb, you need to manually call store.save(). I was about to write back and mention that you need to trigger store.save() -- glad you found it. (In my identifier column, I typically add a save button to trigger this.) Matthew, one thing that your post should cover over is the handling of error conditions - I'm struggling to find any examples of neatly dealing with what happens if your controller decides it's not happy with the data and has to let the store know so it can deal with the situation appropriately. When you call store.save(), you can pass onError and onComplete callbacks. In the case of an error, I return an HTTP 400 status with a JSON payload with my error messages, and then popup a dialog indicating what needs to be changed; for success messages, I use a notification system (currently one derived from http://blog.uxdriven.com/2009/09/08/making-your-own-growl-widget-with-dojo/) The place that problems occur is when I add new rows -- Dojo generates a unique hash for the ID, but that means that if I save() a second time, JsonRestStore tries to do a PUT (update) request -- and I have an invalid identifier. I'm still trying to work out that part of the equation. On Tue, Sep 22, 2009 at 9:10 PM, Kyle Spraggs the...@spiffyjr.me wrote: I was curious what everyone is using for DataGrids. I am aware of http:// petala-azul.com/blog/ as well as http://code.google.com/p/ zend-framework-datagrid/ and there is also the possibility of Dojo Grids. Any input would be appreciated. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Turn PHP errors/warnings/notices into exceptions
Hi,
What i did was writing a function that simply throws an exception and
passing that function to set_error_handler, something like this:
error_reporting(E_ALL);
function exceptionThrower($type, $errMsg, $errFile, $errLine) {
throw new Exception($errMsg);
}
set_error_handler('exceptionThrower');
try {
echo $a['b'];
} catch ( Exception $e ) {
echo Sorry: , $e-getMessage();
}
Only trouble with the errorcontroller is that it only catches the
exceptions inside the dispatch loop, so I disabled that and put a try /
catch around the entire bootstrap/dispatch and handle the exceptions
myself, so I can easily implement 401 / 403 / 404 / 500 response codes
based on the type of exception, no matter if it is thrown within the
dispatch loop.
drm / Gerard
Саша Стаменковић wrote:
I'm trying to do this with set_error_handler(), my will is to trigger
Error controller and catch this as application error, since I want to
log all errors in one place - Error controller.
I tried with setting error handler in bootstrap to function in
index.php and that function calls error controller statically, but no
success. There must be some easy way to do this.
Anyone know?
Regards,
Saša Stamenković
Re: [fw-general] Turn PHP errors/warnings/notices into exceptions
Thx, thats ok, but is there any way to trap error in ErrorController, maybe
redirect to /error, but then you need to pass error msg through url...messy
:)
Regards,
Saša Stamenković
On Thu, Sep 24, 2009 at 2:33 PM, drm d...@melp.nl wrote:
Hi,
What i did was writing a function that simply throws an exception and
passing that function to set_error_handler, something like this:
error_reporting(E_ALL);
function exceptionThrower($type, $errMsg, $errFile, $errLine) {
throw new Exception($errMsg);
}
set_error_handler('exceptionThrower');
try {
echo $a['b'];
} catch ( Exception $e ) {
echo Sorry: , $e-getMessage();
}
Only trouble with the errorcontroller is that it only catches the
exceptions inside the dispatch loop, so I disabled that and put a try /
catch around the entire bootstrap/dispatch and handle the exceptions myself,
so I can easily implement 401 / 403 / 404 / 500 response codes based on the
type of exception, no matter if it is thrown within the dispatch loop.
drm / Gerard
Саша Стаменковић wrote:
I'm trying to do this with set_error_handler(), my will is to trigger
Error controller and catch this as application error, since I want to log
all errors in one place - Error controller.
I tried with setting error handler in bootstrap to function in index.php
and that function calls error controller statically, but no success. There
must be some easy way to do this.
Anyone know?
Regards,
Saša Stamenković
RE: [fw-general] Turn PHP errors/warnings/notices into exceptions
What i did was writing a function that simply throws an exception and
passing that function to set_error_handler, something like this:
error_reporting(E_ALL);
function exceptionThrower($type, $errMsg, $errFile, $errLine) {
throw new Exception($errMsg);
}
set_error_handler('exceptionThrower');
You should check out: http://php.net/ErrorException
It is an Exception type tailored to PHP's errors.
Vincent de Lau
vinc...@delau.nl
Re: [fw-general] Directory Folder Structure for admin/back-end
Hey, Thanks for the input, I'm thinking along those lines...just wondering if anyone has been in a similar situation before? -Cobby Diego Potapczuk wrote: Maybe you can do a special route for this. Something like /admin/blog redirect to adminController in blog module, ou adminBlogController, i dont know, but is an idea for you. ::: Diego Potapczuk »» NEAD - Núcleo de Educação a Distância »» SENAI-BA »» Tel: (71) 3287-8343 / (71) 9144-3062 »» http://www.diegoliveira.com.br On Mon, Sep 21, 2009 at 11:39 PM, cobbweb h...@cobbweb.me wrote: Hi all, I'm building a standard CMS with Zend Framework with the typical modules: Pages, News, Blog, Gallery, etc. Each module will have an section in the CMS admin/back-end. Just wondering which way would be the best to layout the structure. Ultimate, I would like front-end modules to be accessed via: www.site.com/gallery/ www.site.com/news/some-news-title/ ...etc and the admin to be: www.site.com/admin/gallery/edit/34 (edit gallery 24) www.site.com/admin/news/edit/327 (edit news article 327) But I would like it if the modules where completely self-contained, which would mean the admin section would contained within the modules folder. Just wondering what people are thinking or a better way I might be able to do this. Cheers, Cobby -- View this message in context: http://www.nabble.com/Directory-Folder-Structure-for-admin-back-end-tp25530546p25530546.html Sent from the Zend Framework mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Directory-Folder-Structure-for-admin-back-end-tp25530546p25570082.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Zend Form Element PluginLoader for Validators
Hello everyone, I want to use non-Zend validators for my elements and use the array options notation to build my form, where i realized that i can't really set the plugin loaders for the validators of each field. However while browsing through the code I saw that every element creates its own plugin loader if none is given, so its very hard to use a global approach. Is there a nice way to use a single plugin loader for all my elements and configure it through the array notation of Zend_Form? greetings, Benjamin
Re: [fw-general] Zend Form Element PluginLoader for Validators
-- Benjamin Eberlei kont...@beberlei.de wrote (on Thursday, 24 September 2009, 04:37 PM +0200): I want to use non-Zend validators for my elements and use the array options notation to build my form, where i realized that i can't really set the plugin loaders for the validators of each field. However while browsing through the code I saw that every element creates its own plugin loader if none is given, so its very hard to use a global approach. Is there a nice way to use a single plugin loader for all my elements and configure it through the array notation of Zend_Form? Not yet, but it's been in my todo list for some time. It's a huge bottleneck currently if you have a large number of elements. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Is there anybody from Zend team ?
You are not angry, you are kind of idiot, kid. Its not our fault you dont understand basics ;) people normally have such problems, most of them passes the problem hardworking way, others give up, and some others like you stays in the same place where they've been 10 years ago with a stupid smile on their faces and whishpers : im a lucifer haha i kill u all, im the smartest human beeing on earth, ahm I told you that 10years aaagghh why nobody listen to me? I kill u!im a dead terrorist! it's generally not a problem of zend, php, asp and technologies in general.You are just another Govnocoder who did nothing to graduate, just kind of bla-bla guy. aoohralex wrote: My critical subject about Zend Framework was deleted. Somebody from Zend deleted my post. My criticism PHP authors and Zend Framework in compare to other frameworks wasn't comfortable for Zend company. You can don't agree with me but delete my subject ? So again: I have started learn ZF because I wanted to learn something new. If we have range 0 – 10. My knowledge ZF is 1 – I can make basic things in ZF – connect to database, queries insert/update/delete, basic zend forms, authorization, use jquery and layout in zend, controllers, views. My knowledge Symfony Framework is 5. My knowledge ASP.NET MVC (not ASP.NET) is 4. Now I can say that ZF is very bad framework or maybe rather it isn't a framework. Everybody knows that authors of PHP are always late and behind – for example PHP is really OO from version v5 (eariel it was only some OO elements in PHP). The same is in Zend Framework – this framework is behind others frameworks. First - Zend_Db is nothing compared to Doctrine ORM. Using Zend_Db I have to create myself models: http://framework.zend.com/docs/quickstart/create-a-model-and-database-table ! In Symfony Framework with Doctrine ORM and in ASP.NET MVC with Linq to SQL I don't need because it is wasting of time – there it is automatic – in Symfony using console and in ASP.NET MVC using Visual Studio. Of course Doctrine and Linq to SQL have got more better things. In Zend Framework almost nothing you can do using console (of course almost nothing compared to Symfony) – in Symfony using console you can generate much more (I don't use in Symfony console to generate modules, controllers or forms but for begginners it is very comfortable). In ASP.NET MVC I don't need use console but Visual Studio but ASP.NET MVC is very young so generated controllers/views etc. don't have so good code as in Symfony. In ASPNET MVC and Symfony Framework I don't need to enable layout like in Zend Framework. The most horrible thing in Zend it was for me Zend_Acl – using that I can't still make that only logged users can have access to action 'add' controller 'books' – in Symfony I can make that using 2 lines of code in module 'books': add: is_secure: on and in ASP.NET one line of code in controller: [Authorize] What is more in Symfony and ASP.NET MVC we have tables in database and everything else related with users, authorization etc. created in these frameworks – in Zend I must myself do that. There is of course more good things in these frameworks – better than in Zend. Documentation – hahah – in Zend documentation is chaotic, is HORRIBLE !! Have you ever seen documentation of Symfony or ASP.NET MVC ? I have never seen worse documentation than in Zend. For me Zend isn't a framework but rather components that we can use in other frameworks – for example Zend Lucene in Symfony: http://www.symfony-project.org/jobeet/1_2/Doctrine/en/17 As I thought – authors of PHP are always late and they are always behind so Zend is always late and behind. For me Symfony and ASP.NET MVC are from XXI age, Zend is from XX age. This was my compare these frameworks. Sry for my English – it isn't my national language. PS. bold text = I am angry because of delete my subject by Zend company. -- View this message in context: http://www.nabble.com/Is-there-anybody-from-Zend-team---tp25455352p25577786.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Announcement: Monthly Bug Hunt Days
Hi, I know the last bug hunt days are finished but since there will be some bug hunt days again next month, I just ask now. My question might be sound stupid but I was always asking myself this question when looking at the issue tracker, When I look at the issue tracker, almost each issue is assigned to someone. How do we know that the assignee is not currently working on this issue when assigned to him/her? Thanks and best regards, Ralf
Re: [fw-general] Announcement: Monthly Bug Hunt Days
Ok, forgot it, found the in progress status. Thanks and best regards, Ralf
Re: [fw-general] DataGrid
Matthew Weier O'Phinney-3 wrote: -- Cameron themsel...@gmail.com wrote (on Wednesday, 23 September 2009, 09:42 AM +0800): Dojo grids. I've actually just moved a lot of my functionality over to Dojo JsonRestStore so I can do in-grid editing, it's not completed yet, but so far it is coming together really smoothly. I'm planning on doing a blog post on this combination (Zend_Rest_Route + dojox.data.JsonRestStore + dojox.grid.DataGrid) -- the three work together incredibly well, and make CRUD interfaces a breeze. On Tue, Sep 22, 2009 at 9:10 PM, Kyle Spraggs the...@spiffyjr.me wrote: I was curious what everyone is using for DataGrids. I am aware of http:// petala-azul.com/blog/ as well as http://code.google.com/p/ zend-framework-datagrid/ and there is also the possibility of Dojo Grids. Any input would be appreciated. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ I don't mean to steal your thunder but that's exactly what I'm using and am in the middle of writing a blog post. :) -- View this message in context: http://www.nabble.com/DataGrid-tp25559736p25578037.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Announcement: Monthly Bug Hunt Days
-- Ralf Eggert r.egg...@travello.de wrote (on Thursday, 24 September 2009, 08:05 PM +0200): I know the last bug hunt days are finished but since there will be some bug hunt days again next month, I just ask now. My question might be sound stupid but I was always asking myself this question when looking at the issue tracker, When I look at the issue tracker, almost each issue is assigned to someone. How do we know that the assignee is not currently working on this issue when assigned to him/her? As you found -- developers may mark the fix as in progress. Just to be on the safe side, though, jump into #zftalk.dev and see if the contributor in question is available, and ask. That's how it worked during the bug hunt last week, and we had no issues with overlap. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Zend Navigation XML config page visibility problem
Andrew Ballard wrote: On Wed, Sep 23, 2009 at 10:54 AM, dennesabing dennes.b.ab...@gmail.com wrote: I have a zend navigation config via xml and i want to hide some pages by setting the visible to false to a page i want to hide. However, the false visible pages are still showing on the html. How i can hide them. My Account admin account admin:account index Profile Information admin account profile admin:account profile false I had to use visible0/visible instead of visiblefalse/visible in the XML configuration. I'm not sure if it is supposed to be that way or not. Andrew @andrew That solves the problem. In the documentation it says bool and defaulted to 'TRUE' but it didn't come to my mind to use the int counterpart as a substitute for bool value. Thanks man. -- View this message in context: http://www.nabble.com/Zend-Navigation-XML-config-page-visibility-problem-tp25531185p25582161.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Handling timeouts in Zend_Ldap queries
How do other folks handle long Zend_Ldap queries. Currently I get the white screen of death, but there has to be a better way. Any thoughts? -Henry
AW: [fw-general] Handling timeouts in Zend_Ldap queries
Hi Henry, a white screen of death most often is caused by scripts exceeding the maximum execution time (or exceeding the memory limit). The ldap-extension will echo some sort of warning/error when the connection itself times out, so you'll get a feedback in these cases. Try raising the memory limit and/or maximum execution time. Best regards Stefan -Ursprüngliche Nachricht- Von: Henry Umansky [mailto:human...@gmail.com] Gesendet: Donnerstag, 24. September 2009 23:14 An: fw-general@lists.zend.com Betreff: [fw-general] Handling timeouts in Zend_Ldap queries How do other folks handle long Zend_Ldap queries. Currently I get the white screen of death, but there has to be a better way. Any thoughts? -Henry
Re: [fw-general] DataGrid
I use (and I'm very happy with it) Jquery Grid: http://www.trirand.com/blog/ I use ZendX_JQuery* for ZF integration and it works like a charm... Kyle Spraggs wrote: I was curious what everyone is using for DataGrids. I am aware of http://petala-azul.com/blog/ as well as http://code.google.com/p/zend-framework-datagrid/ and there is also the possibility of Dojo Grids. Any input would be appreciated. -- Kyle Spraggs (SpiffyJr) http://www.spiffyjr.me -- View this message in context: http://www.nabble.com/DataGrid-tp25559736p25589776.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Split controller actions into multiple classes
Yes, it is thick to me. Sometimes it is useful to make it a goal to have 1 action per controller, when you have a lot of actions per controller I have found it makes you more hesitant to break up actions into helper methods ( the relationship of actions to helper methods for me is not 1:1 so more then 4-5 complex actions and I could easily have 25+ helper methods bloating the controller. When the actions are spread out across controllers it can make it easier to factor, and they can always be re-combined later after some of those helper methods mature and are moved up into more abstract classes Ryan Chan-2 wrote: Hello, On Mon, Sep 21, 2009 at 9:55 PM, Matthew Weier O'Phinney matt...@zend.com wrote: If it is repetitive presentation logic you could sub-class the Zend_Controller_Action or create action helpers if the repeating logic are cross cutting concerns. Keep in mind the saying is fat model thin controller not just thin controller For example, do you think the following code is a thick controller? and difficult to manage? http://howachen.googlepages.com/test.php For me, it is. It would be better to manage if each action is in a separate PHP class file, isn't? -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25600132.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Split controller actions into multiple classes
That's one way of achieving the goal but should not be a means to an end. Ideally you would identify new model objects to be born, for instance is the controller dealing a lot with adding fields to some grid object before pushing it to the view, if so you could sub-class that grid object for that module so the implementation logic resides in a subclass of the grid class instead of the controller instantiating the abstract grid and setting it procedurally. A useful way to think about this is reading the chapter called transaction scripts and page controllers in POEAA, I think those patterns capture the essence of the fat controller smell. Sudheer Satyanarayana wrote: On Friday 18 September 2009 07:10 PM, Ryan Chan wrote: Hello, I have a controller that contains too many line of codes, which made the controller too large. So I want to split each action into eactly one class files. Is it recommended? If not, what are the recommended way to make the controller thin? Consider splitting your code into multiple controllers and perhaps modules. Do you have model classes by the way? -- With warm regards, Sudheer. S Business: http://binaryvibes.co.in, Tech stuff: http://techchorus.net, Personal: http://sudheer.net -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25600601.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Domain Driven Design / Patterns of Enterprise Application Architecture [repost]
Hey everyone, Sorry about the repost (most of you probably havent seen it as I posted it on Nabble, and of course realized that it didnt get sent because I didnt have a subscription to the mailing list (cancelled it because I was reading everything on Nabble). Anyhow, I am reposting the message now that I have re-subscribed to the list, so it will get some exposure beyond Nabble. I have just gone through an article Model Infrastructure - http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html A most excellent insight on Zend Framework and Domain Models (Matthew you are my hero!) The comments in the article brought me to a slide show Zend Framework Workshop, DCP09 - http://www.slideshare.net/weierophinney/zend-framework-workshop-dpc09 An even better, and more up to date insight (Matthew I bow down to your greatness). // on a side note: I love all you guys/gals who have contributed and made Zend Framework what it is today (and what it will be tomorrow) Ok enough rambling, on to nitty gritty. In the first artcle, we are building a model, using a Gateway pattern. The model itself extends Zend_Auth (brilliant, but not necessarily what you are supposed to be doing with light weight models). I poked through the Patterns of Enterprise Architecture / Martin Fowler. In the book, he refers to the gateway pattern being the pattern of choice due to its ease and flexibility. Reading through the comments in the article, I came across the second (and newer/different) ideals by using a DataMapper pattern in replacement to the gateway pattern. I then started reading up on the DataMapper pattern. I like both patterns, both are very functional. However I did get a little confused. The first thing I am a little confused about: My logic is that we have a data source (be it a database table, a web service, a file, etc). Now according to PoEAA, a service is the 'business logic' of the application. However, Matthew places a service between the Controller and the DataMapper. (Makes sense to me). On the other hand I also see services as being the layer between the DataMapper and the DataSource. (For example we have Zend_Service_Amazon. Is that not something we could/would layer between the DataMapper and the DataSource (being Amazon). (Forgive me if I am wrong, I really haven't worked with that 'service' yet, I am just throwing out an example). So if that *is* a service, then by my logic: App_Model_DbTable_User extends Zend_Db_Table_Abstract (in the slideshow) *should* really be App_Service_DbTable_User extends Zend_Db_Table_Abstract because in my logic, the layer between the DataMapper (App_Model_User_DataMapper) and the DataSource (The database table) is a service, and in this case is an extended class of Zend_Db_Table_Abstract In saying that, here is how I envision the structure: |-- /models | |-- User.php (Default_Model_User implements Zend_Acl_Role_Interface) | |-- Article.php (Default_Model_Article implements Zend_Acl_Resource_Interface) | |-- /services | |-- User.php (Default_Service_User) | |-- Article.php (Default_Service_User) | |-- /User | | |-- DataMapper (Default_Service_User_DataMapper) | | |-- DbTable (Default_Service_User_DbTable extends Zend_Db_Table_Abstract) | | | |-- /Article | |-- DataMapper (Default_Service_Article_DataMapper) | |-- DbTable (Default_Service_Article_DbTable extends Zend_Db_Table_Abstract) So in my vision, the /models stays fairly clean, contains basic properties and no business logic at all (however may contain behaviors that manipulate the data/properties themselves). The service contains the business logic (create, login, save, etc) and would have the ability to create new objects (without id's say in the case of the User). The DataMapper handles the actual 'creation' of the User/Article object (as it comes from the database (or other data source)). I am not altogether sure where the best placement of the DataMapper is because it deals with a model it could go in the model directory structure, but it also deals with the data source (which as I stated to me feels like a service), so it could go into the service directory structure. If my thoughts on this are out of line, please correct me. The other thing I was thinking is that I should have a contract (implements) for the DataMapper class which defines the requirements of the data mapper. For example the service will want to call functionality of the data mapper in order to do things. Lets use 'save' as an example: $user = (an instansiated modified Default_Model_User object loaded from the database) $userService-getDataMapper()-save($user); Now within the DataMapper object we have a method called save, which contains the logic to call the Zend_Db_Table_Abstract class (Default_Service_User_DbTable in my case) Now lets say we want to
Re: [fw-general] Domain Driven Design / Patterns of Enterprise Application Architecture [repost]
Don´t be sorry for sending a quality post like this, this is an area that i feel the Zend Framework need a better working to define the best or appropriated way to architect an system build with it. Maybe you could make an simple application to show how all it would work together, especially joins tables and such. ::: Diego Potapczuk On Thu, Sep 24, 2009 at 10:42 PM, Aaron Murray ajmurra...@gmail.com wrote: Hey everyone, Sorry about the repost (most of you probably haven’t seen it as I posted it on Nabble, and of course realized that it didn’t get sent because I didn’t have a subscription to the mailing list (cancelled it because I was reading everything on Nabble). Anyhow, I am reposting the message now that I have re-subscribed to the list, so it will get some exposure beyond Nabble. I have just gone through an article Model Infrastructure - http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html A most excellent insight on Zend Framework and Domain Models (Matthew you are my hero!) The comments in the article brought me to a slide show Zend Framework Workshop, DCP09 - http://www.slideshare.net/weierophinney/zend-framework-workshop-dpc09 An even better, and more up to date insight (Matthew I bow down to your greatness). // on a side note: I love all you guys/gals who have contributed and made Zend Framework what it is today (and what it will be tomorrow) Ok enough rambling, on to nitty gritty. In the first artcle, we are building a model, using a Gateway pattern. The model itself extends Zend_Auth (brilliant, but not necessarily what you are supposed to be doing with light weight models). I poked through the Patterns of Enterprise Architecture / Martin Fowler. In the book, he refers to the gateway pattern being the pattern of choice due to its ease and flexibility. Reading through the comments in the article, I came across the second (and newer/different) ideals by using a DataMapper pattern in replacement to the gateway pattern. I then started reading up on the DataMapper pattern. I like both patterns, both are very functional. However I did get a little confused. The first thing I am a little confused about: My logic is that we have a data source (be it a database table, a web service, a file, etc). Now according to PoEAA, a service is the 'business logic' of the application. However, Matthew places a service between the Controller and the DataMapper. (Makes sense to me). On the other hand I also see services as being the layer between the DataMapper and the DataSource. (For example we have Zend_Service_Amazon. Is that not something we could/would layer between the DataMapper and the DataSource (being Amazon). (Forgive me if I am wrong, I really haven't worked with that 'service' yet, I am just throwing out an example). So if that *is* a service, then by my logic: App_Model_DbTable_User extends Zend_Db_Table_Abstract (in the slideshow) *should* really be App_Service_DbTable_User extends Zend_Db_Table_Abstract because in my logic, the layer between the DataMapper (App_Model_User_DataMapper) and the DataSource (The database table) is a service, and in this case is an extended class of Zend_Db_Table_Abstract In saying that, here is how I envision the structure: |-- /models | |-- User.php (Default_Model_User implements Zend_Acl_Role_Interface) | |-- Article.php (Default_Model_Article implements Zend_Acl_Resource_Interface) | |-- /services | |-- User.php (Default_Service_User) | |-- Article.php (Default_Service_User) | |-- /User | | |-- DataMapper (Default_Service_User_DataMapper) | | |-- DbTable (Default_Service_User_DbTable extends Zend_Db_Table_Abstract) | | | |-- /Article | |-- DataMapper (Default_Service_Article_DataMapper) | |-- DbTable (Default_Service_Article_DbTable extends Zend_Db_Table_Abstract) So in my vision, the /models stays fairly clean, contains basic properties and no business logic at all (however may contain behaviors that manipulate the data/properties themselves). The service contains the business logic (create, login, save, etc) and would have the ability to create new objects (without id's say in the case of the User). The DataMapper handles the actual 'creation' of the User/Article object (as it comes from the database (or other data source)). I am not altogether sure where the best placement of the DataMapper is because it deals with a model it could go in the model directory structure, but it also deals with the data source (which as I stated to me feels like a service), so it could go into the service directory structure. If my thoughts on this are out of line, please correct me. The other thing I was thinking is that I should have a contract (implements) for the DataMapper class which defines the requirements of the data
RE: [fw-general] Domain Driven Design / Patterns of Enterprise Application Architecture [repost]
Oh, I was by no means sorry about the post itself J, I was more or less apologizing for reposting it (to those who have already read it on Nabble). Anyhow, in effect that is kind of what I am striving for is to make a simple application (for learning purposes). However, I am still a little fuzzy on the structure of the whole domain driven design concept. I am reading lots about it, and am more or less using this forum for a little verbal diahrea as I am going through this learning venture. I am of course doing what everyone else is doing (well every newbie around here at least), and building a simple CMS as my starting point. Because my main purpose behind using / learning the Zend Framework is for web based applications in the long run, and some would argue that websites are not the best use of Zend Framework, I have always loved programming in PHP, and am always learning new things with it, I have a hard time working with content management systems that are available today. Every one of them seems quite restrictive in its own way, and reading someone elses code to try to decipher how they developed it really sucks. It is amazing how these relatively complex CMS systems available today (Joomla/Drupal/etc) are even functional considering how non-logical the application was written. I have been working with Zend Framework now since about v1.0 (I got to miss the whole pre-release candidates to version one whew dodged that bullet). I was really cool with how things were going around version 1.5. Then all hell broke loose (for how I thought about development/design) with the introduction of Zend_Tool and Zend_Application. Zend_Tool, in itself was relatively easy to grasp, it was and is still quite simplistic in its default form, I havent gotten into expanding its functionality yet (havent found a need really). So the biggest thing I find helps with learning Zend Framework is to use everything in its default context as much as possible (while learning the component), ie: Rather than extending Zend_Form (creating my own extended class), I start by creating a form in the controller $myForm = new Zend_Form(); $myForm-addElement(blah blah); etc. I do nothing fancy. I pass it to the view, and render it. Then I look at the source (ctrl-u - firefox), and see WHAT just got rendered. Then I add CSS and make it look fancy. Obviously the best method is not to have all that garbage in your controller (or at least that is what I have learned), then I will move that code into a class (or extend the Zend Form class), leaving it completely basic, then I will add the extra goodies (validation, filtering, etc). That is my thought process when it comes to learning Zend Framework itself. I also read a lot of posts here, blogs, tutorials, etc and just keep playing with it. I am still almost completely lost with Zend_Application at this point, I kind of understand the Bootstrap class (as I have used bootstrapping forever), however not quite the way Zend Framework uses it (by default). So now I am trying to wrap my head around Zend_Application as well, but all in time, I am at least picking up some of it. I find the API documentation is a great source as well. Especially when something isnt working quite the way I *THINK* it is supposed to work. I have browsed the source of Modx (www.modxcms.com) which has given me a few ideas here and there. I even tried to install Cahaya (another new CMS built on Zend Framework), but that one crashed and burned for me and I dont really like the directory structures the developer used, so I havent even started looking at the code on that one, it has me afraid already J ) But mostly where I am at right now is getting to the point of developing a solid architecture and layout that I can build on, so I am really trying to understand everything I can about DDD and PoEAA. (I bought PoEAA, and I have the Domain Driven Design Quickly version of Eric Evans book I will most likely be rushing out to buy the full version of his book soon too). I also have to say I picked up Rob Allens book Zend Framework in Action, however I bought that one a little too late. Being a huge fan of Robs tutorials, I recently picked up his book (have been meaning to forever). Unfortunately it was published around version 1.5 and therefore misses most of what I am learning right now (Zend_Application). Kudos to the book though, very well written Rob! I have numerous other projects that I am really interested in kicking off as well, I just decided a simple CMS would give me a fairly generic and well rounded understanding and learning base to kick off some of these other more advanced projects I have in mind. Thanks Aaron From: Diego Potapczuk [mailto:potapc...@gmail.com] Sent: September 24, 2009 8:01 PM To: Aaron Murray Cc: fw-general@lists.zend.com Subject: Re: [fw-general] Domain Driven Design / Patterns of Enterprise Application Architecture
RE: [fw-general] Domain Driven Design / Patterns of Enterprise Application Architecture [repost]
Hey Kyle, There I learned to turn off my HTML formatting (is that better? :) ). Anyhow, thanks for your response. Reading through the examples you laid out, I am gathering due to the actions that _processForm is a protected function of the action controller. When I said in my post that I code stuff in the controller, I do that merely for quick testing of a component, generic, basic setup and development / usage testing. The second part of that is that once I understand (to the best of my abilities) then I refactor the code out of the controller (generally, some things I test inside of models and views as well), and I refactor it to where I feel it best belongs and is best used (which is kind of the main topic of the thread here, where does stuff belong). Some people believe that code belongs in the controller, some people believe that code belongs in the model, some believe it belongs in the view (obviously depending on the context). Me I have started looking at it more along the lines of code is the 'muscle' of the application and belongs 'between' those components. From my perspective, the Action controller is where I put specific calls to functionality through services (so basic straight forward lightweight). The model in my world is simple, handles essentially the state of a data object, with little to no behaviours (unless they are directly related to the state of the object / properties themselves). Most of the processing power would reside in the DataMapper when it comes to models. The view, I have stayed away from all but the basics with the view, but I believe when I get to developing strong views, they will most likely be broken down into reusable components in small manageable bites. Again with the view, very little to no code, and only code that relates directly to the view itself (ie displaying the contents or part of the contents of a model or other object that has been passed to it). I would also look at Zend_View as a service in context, the actual view would be the final rendered output, the Zend_View_whatever would be the service (which I differentiate from the actual view which would be the final outputted product be it an HTML page, a PDF file, an Excel spreadsheet, or whatever format it may be in), Zend_View would be the service (or whatever class you created/extended/etc) to the 'View' just as Zend_Db_Table would be the service layer to the physical database. Now back to what you are saying, I disagree with putting a _processForm function into the action controller (for reasons I stated above). The action controller should merely instansiate the service object (say: Default_Service_MyModel), pass the data to that service and have the service handle the core of the loading of the Default_Form_MyModel and validation of the data. Then once the data is validated, filtered, and whatever else you want to do with it, it gets shipped off from the service layer to the datamapper which turns around and creates the Default_Model_MyModel object, and hands it back to the service layer, which in turn may do other processing such as having the datamapper save the object to the database, or even return the validated object back to the action controller to be shipped off to the view renderer. If the validation fails, it could return some kind of failure / exception back to the action controller to be handled appropriately. Note in what I am saying, the Default_Form_MyModel is an object in itself (which I am gathering you picked up on). The Service merely calls it and utilizes its capabilities to validate the data. This however also means that you can instansiate the Default_Form_MyModel, and send it to the View Rendering 'service' as well (multi use object). In the case of a failure in the controller to datamapper service layer, the service could return the instansiated (and thus populated) form object back to the action controller to be rendered (as populated) in the view. (Hope I made sense with that, its getting late here). So my logic is to keep the Model, View, and Controller as skinny as possible, and insert layers in between each. Here's a best effort ascii diagram of what I am trying to say: View (Screen/Monitor/PDF/etc) | View Renderer (Zend_View) - Service Layer | Action Controller (Zend_Controller_Action) | Model Handler (Default_Service_MyModel) - Service Layer | \ |\ | The Model (Default_Model_MyModel) - a raw instance of the model (created by the DataMapper, handled by the service layer (handler) |/ | / Model DataMapper (Default_Service_MyModel_DataMapper) - DataMapper (builds the model objects, talks to the datasource service, and is controlled by the Model handler/service) | Model DataSource Service (Default_Service_MyModel_DbTable) - The layer between the datamapper and the data source that handles the actual datasource communication API (ie FetchAll()) | Data Source (Database
