Zend Framework and Doctrine

I am learning Zend Framework and Doctrine.

I am wondering what is the best practice to connect forms to models and vice versa. I don't know where I should put my code.

I have seen in Zendcast video tutorials where author creates methods like mapFormToRecord and mapRecordToForm in form class. Well I guess it is very handy when form is sophisticated and uses many records. Is it a good practice? I somehow believe that form-class should not need to know about data-records.

And sometimes we might have model which is used in many forms. So It would be handy to have few functions in that model which would help to prepare data for forms. For example to give an array of id=>name pairs so that it might be used in Zend_Form_Element_Select.

However I would like to have a consistency. So I don't want to put this code nor in model nor in form because in various situations I act differently. What if controller will contain all the code responsible for mapping form to models? This will result in code duplication if one form will be used more than in one controller. Moreover controller gets bloated if form is not from the simple ones. So I think that controller should only invoke the mapper function - not more.

Or maybe there is a consistent pattern in those data conversions between forms and models? I think that there is. At least in my simple cases. So maybe a separate general-purpose class could be a solution? Where should I put such class and how should I name it?

Another question: Zend_Form has validators and filter. Doctrine has validators and filters too. Which do we use and when?

What is your way of dealing the connections between forms and models?

(Sorry if it was hard for you to read my text. I don't have enough knowledge of English language to express myself freely)

Implement multiple inheritance using the property and method missing magic methods, create a mixin that extracts form structure from the property documentation ((new ReflectionClass(get_class($this->mixedin)))->getProperties()->each(function ($p) { echo $p->getDocComment() }); (not valid code)), make the flagged (protected and _ prefixed) properties available through __get()-magic, have automated form in-filler in the mixin.

EXPERT REUSABLE SOLUTION

I'm assuming this is a poorly copy/pasted troll, from the newline at the start.

>>3
I wrote all of >>2 for nothing? Awww ;_;

I hate enterprise PHP more than anything. PHP Frameworks are bullshit.

Think about the problem you're trying to solve right now. You want to "connect your form to your model"? No, what you really want to do is write to your database. Do you really think that once you figure out the way to maneuver your classes and $html->br()s out from within the Zend Framework best practices that you will have saved yourself time or effort, compared to simply writing the form yourself? $pdo->prepare(). filter_var(). There, there's your sanitization.

But maybe you do think it will save you time (development time; clearly not render time, since with the inclusion of these large libraries you can forget about efficiency). Are you planning on generating forms with thousands of fields? Still, it would be faster for you to write some sort of database introspection yourself -- which brings me to another problem. ORM. I won't insult your intelligence by assuming you don't know about the object-relational impedance mismatch, but listen. Try to write an ORM-based solution yourself, and discover what everyone else does: that mismatch is not going to go away. No matter how the system has been designed, somehow, and sooner than you think, it will fail you.

I know, OP. I know you want to tuck the database code away nice and safe. But do you know how easy it is to write a singleton database connection class? And please, don't overlook the utility of the humble include! I know you want to treat your $posts and $transactions like objects, because in your mind, they are objects, not a collection of fields. But did you know that PDO::FETCH_OBJ does largely the same thing? And if you really wanted to, you could exploit the malleability of PHP objects by giving them anonymous functions as soon as they're fetched! $result->method = function() { echo "It's wonderful!"; } And yes, the idea of  $db->save($posts[0]); is quite pleasant, but face it OP, it's a pipe dream. You will find yourself a month into the project with no choice but to code over the wall, and all the while Doctrine will be struggling to balance the menagerie of abstraction is has collected for itself, trampling all over your latency and disrespecting your users' page load times, just so that it could treat the database as "an object" and not as your database.

Just like Zend wants to treat your form as "an object" and not as a form. Solve your problem, not the elaborate distractions outside of your problem. Write your own forms, and enjoy the benefit of faster, cleaner PHP that does exactly what you want it to.

>>5
If PHP did anonymous functions like that it wouldn't annoy me as much as it does. Instead, what that guy wrote is a syntax error and you have to use create_function instead.

>>5
PHP is not an enterprise language, so it's to be expected that PHP enterprise frameworks fail.

>>6
http://php.net/manual/en/functions.anonymous.php

$greet = function($name)
{
    printf("Hello %s\r\n", $name);
};

$greet('World');
$greet('PHP');

There is a syntax error though: he forgot the semicolon at the end of the statement. Also, echo probably won't work inline like that, but that's not the point.

>>8
available since PHP 5.3.0.
So basically, not available at all.

>>9
5.3 has been available for nearly a year.

>>10
Which means it's still at least half a decade away from being supported widely enough by the target audience of PHP developers to be usable.

It's available enough. However, lambdas doesn't work with objects like >>5 wants it to because methods and properties have different namespaces:

% php -r '$o=new stdClass; $o->m = function () { echo "A"; }; $o->m();'          

Fatal error: Call to undefined method stdClass::m() in Command line code on line 1
% php -r '$o=new stdClass; $o->m = function () { echo "A"; }; $o->{"m"}();'      

Fatal error: Call to undefined method stdClass::m() in Command line code on line 1
% php -r '$o=new stdClass; $o->m = function () { echo "A"; }; ($o->m)();'        

Parse error: syntax error, unexpected '(' in Command line code on line 1
% php -r '$o=new stdClass; $o->m = function () { echo "A\n"; }; $f = $o->m; $f();'
A
%

>>12
$o->m(); -> Error
$f = $o->m; $f(); -> Works
Oh my god, this is the most awful thing ever. I hate PHP so much.

>>13
I know PHP exactly well enough to wonder whether there's a buggy version where $o->m;(); works as intended in the first example.

>>12
$ php -r '$o=new stdClass; $o->m = function () { echo "A"; }; call_user_func($o->m);'
A

php -r ';_;'

% php -r ';_;'

Notice: Use of undefined constant _ - assumed '_' in Command line code on line 1

>>17
Your interpreter is fucked up.

>>5

Yes I think that I save time and a lot of it.

For example when I use doctrine I don't even need to write models in most cases. I just describe my database structure in .yml file and doctrine generates models and SQL for me. More than that it can generate models from already existing database. How long will it take to write a category model for your menu system? Minutes if you use doctrine! People behind doctrine have had much more practice than I have in this subject so they already considered most cases which I face to and they made solutions which I can take and use.

And not only time is what I save. Some other great things are:

My application is easy to understand for followers developers. Because my framework's documentation usually cover architecture and main principles of my app.

Code I write is easy to reuse, or I use code which is reusable. Because I use libraries where I can. Describing forms as objects allows to use the same object over many applications. HTML forms are hardly ever reusable. And if you write in HTML you are already repeating stuff you did hundreds of times before. HTML was meant to be used by computers not by programmers. That means CPU should generate HTML code not a programmer. Programmers always seek for a ways to write as less code as possible. Here even generation of PHP code comes in mind (greatly used by symfony php framework and doctrine).

Code I write is easy to test. I can test my forms isolated before I put them it into application. I can test my models.

Application structure is ok for teams. It is easy for one to work on forms for other on models and for third to connect separate parts of application.


We also gain some overhead. But overhead exists in every software product. In most cases it is not the reason why application performs slowly. Bad app architecture, imperfect algorithms in application is the cause. Increasing power of CPU's can easily cope with increasing overhead however it will never be able to cope with bad algorithms.

If we build a website for high loads we will have to use caching system anyways. And if our code was decoupled into objects we are able to write a greater caching system.

We are able to have great applications only because we have better and better tools for them. Those tools is overhead for CPU, but we couldn't have our applications without them.

So lets just use best tools available which save our time  and take a less care about cpu business. We are programmers after-all, not calculators.

>>11
and who does not allow you to use any latest version of open-source free software? Unless you are writing a mass-usage system. However php5.3 is already in it's stable! Hosting companies aren't updating very fast however you can't write your application in a day either so no need to worry about portability of today. There are already many companies who support php5.3 and others will have to shift in nearest days.

>>19
That was painful to read.

>>20
ye, sorry. I've started to write in English just recently so it isn't easy to read it.

>>19
I'm not even going to begin tearing that wall of bullshit down, but you're a shitty programmer, using a shitty language, and obviously have not spent enough time with other languages to realize that it's shit.

I can definitely write a typical web application in a day. Most webshits are remarkably simple, and once you've done one of them, if you did it smartly, you can reuse a huge amount of code in the next. It's far easier for me to copy most of the existing basic HTML templates from another project, so I don't repeat anything "hundreds of times"; in fact, I don't write much HTML at all. And I certainly don't need a CPU to "generate" it for me.

If you want to save your time, get a better language that doesn't waste it, like PHP does.

>>22
please mention a few features in other programming languages which makes it easier to build a web app faster than in php

>>23
I don't know if you've ever used Sinatra, but I think thats easier than php

>>24
no I have not used Sinatra, however I believe it is not a separate programming language and is ruby based. If you want to compare Sinatra with PHP you will need to compare it with PHP and a list of libraries available for PHP, including major php-orm, templating and other libraries.

>>25
Well it's a DSL, but it mostly covers the control part. If you need a DB, you still need to use ActiveRecord or some other library, and ditto for templating. Still, you gotta love the simplicity of the 'hello world' program
  require 'rubygems'
  require 'sinatra'
  get '/' do
    'Hello world!'
  end

>>26
"hello-world" application can't be used to compare programming languages and your example certainly is not the simplest one in 'hello-world' contest.

>>27
hello-world" application can't be used to compare programming languages
well of course not
your example certainly is not the simplest one in 'hello-world' contest.
I didn't even mean to imply it was the simplest.

Actually I am not a big fan of php myself. I like python more than php. Ruby is nice too. However I do not agree that PHP is time wasting language by it self. And PHP has few great advantages in web-development over other languages.

>>29
ones which you are conveniently not specifying

>>28
But you implied that I gotta love the simplicity of your hello-world example.

>>31
Are you saying it isn't simple?

>>31
There was no implication there, he very clearly stated it.

>>32
As simple as any other hello-world application. There is nothing to get in love to.

>>30
there was no advantages mentioned in this post for other languages as well even though I asked to mention some features in my post at >>23

What about PHP advantages, I see such:

When you buy a PHP application you are sure that you won't face a problems to maintain and host it.

PHP is popular so it is easy to find specialists and it is easy to find a job if you are one.

So I think that PHP fits perfectly if you want to quickly start a new web site.

>>32
By the way I actually dislike your example of hello-world app with Sinatra. What I like is when code is self-explanatory: when I can get a basic understanding of what is happening even if I am not familiar with the language or the library.

It is more important for code to be easily read than written.

When I read your example I don't see any function calls and the line <with '/' do> says nothing to me.

In most other hello-world examples I can understand what is going on even without comments.

So as a hello-world example Sinatra is very bad. I hope it is much better when you have more knowledge of it.

>>35
By the way I actually dislike your example of hello-world app with Sinatra. What I like is when code is self-explanatory:
Huh? What's there to understand. If you get a GET request, for '/', you return 'hello world'. Perfectly understandable, if you understand HTTP anyway.

>>36
I am not saying that it is something much or hard to understand, I just say that it is not self-explanatory, so it fails as a good hello-world example.

I would prefer a hello-world example more similar to something like this:

    if REQUEST.PATH is '/'
       write 'Hello World';

In your example I do not see where does '/' come from and what does "do" does with string "Hello World".

>>37
I just say that it is not self-explanatory
So, what you are saying is that you don't understand HTTP
if REQUEST.PATH is '/'
[code]       write 'Hello World';
But then you are always assuming that it is a GET request, Sinatra provides functions for most of the HTTP requests (e.g. PUT, POST, DELETE). I don't think it makes much sense to have a "write" function do that job either, unless you were to attach it to a response object of some kind, but that's just my opinion.
what does "do" does with string "Hello World".
Well that's because you don't actually know ruby ;)
do...end is ruby syntax for "blocks" and "Hello World" is returned by the block as its the last thing in it.

>>38
>But then you are always assuming that it is a GET request
I do not assume that request must be GET. I don't care what type of request it was. If I would care I would write something like this:
if REQUEST.METHOD is 'get' and REQUEST.PATH is '/'

>Well that's because you don't actually know ruby ;)
You got be here :)

>>39
I don't care what type of request it was
Now I know I'm being trolled

>>38
I think you need to step back for a moment and realize you're talking to a person who thinks that PHP is a good language for web development.
This conversation can serve no purpose: you won't convince him, because he's a brain-damaged moron too ignorant to have the context required to even grasp the arguments made, and it won't elucidate anything for anyone else, because the arguments would be so basic as to be irrelevant.

I'm all for taking probable trolls seriously for the benefit of the greater community, but in this particular instance you are fighting a pointless battle you cannot win.

>>40
After I walked through Sinatra's read-me I see that it strictly separates methods in it's router. And at least README didn't document a possibility to write code which ignores request-method but is fixed to request-path. That is quite a nice practice as it forces to fallow http definition and use request-methods by their purpose. Most of web applications written in PHP do not fallow this principle and make same response no matter what request-method was.

>>42
How does it handle attempting to GET a POST resource, or similar?

I get the idea that it just throws a 404 if everything doesn't match, which isn't correct, as cases where the method is unsupported but the path matches up should be handled with a 405.

(And what about HEAD requests? How does it handle those, if you have to explicitly state the request method for everything?)

>>43
HEAD requests are handled automagically. Since all they are is a GET, without returning the resource.

I get the idea that it just throws a 404 if everything doesn't match, which isn't correct, as cases where the method is unsupported but the path matches up should be handled with a 405.
Good point. I think that if you are coding in a REST style, then you should have written methods for the resource anyway. While inelegant, you could always just write it out, it's only n+1 lines, where n is the number of things you disallow.

#the error handler
error 405 {"Resource Not Allowed"}
# for the resource
get resource {405}

>>45
whoops, my bad. That should be
error(405) {"Resource Not Allowed"}
get(resource){405}