I am a little confused about a few things in 1.1 with form handling
still.
* Why is validation (something that in most MVC frameworks is handled
in the model) now handled in the controller?
Doesn't this move the validation farther away from what it actually is
validating?
* Why is form rendering also now in the controller? The view just
contains
echo $form
where the form should render.
Isn't the form part of the view? It seems to me this new system mixes
both logic and presentation in how forms are rendered and validated.
I feel like I'm missing something important in trying to understand
this because these changes seem very inconsistent with what the rest
of the MVC world is doing. At a time when other frameworks are
advocating skinny controllers and fat models, Symfony is taking things
away from the Model that should logically be handled there like
validation.
Similarly, when other frameworks are moving towards having their
generators build code it's largely CSS driven, whereas the code here
is (by default) tables. This again seems like a step back given the
push for standards driven web design.
I can certainly respect the power of the new methods that are
available, but I wonder why they are preferable given the stated roles
of the Model, View, & Controller and what direct benefits this gives
to designers who are separated from application development teams who
must now learn additional Symfony methods instead of being freed to
just be designers.
I'm not trying to tear down what has obviously had a lot of thought
given the dramatic nature of the change. I'm just trying to understand
how it remains consistent with MVC principles.
Very interesting questions. As I really think the new form framework is the only one (that I know) that fully embraces the MVC pattern, I've just wrote an answer on my blog that try to explain the philosophy behind the design:
Keith wrote: > I am a little confused about a few things in 1.1 with form handling > still.
> * Why is validation (something that in most MVC frameworks is handled > in the model) now handled in the controller?
> Doesn't this move the validation farther away from what it actually is > validating?
> * Why is form rendering also now in the controller? The view just > contains
> echo $form
> where the form should render.
> Isn't the form part of the view? It seems to me this new system mixes > both logic and presentation in how forms are rendered and validated.
> I feel like I'm missing something important in trying to understand > this because these changes seem very inconsistent with what the rest > of the MVC world is doing. At a time when other frameworks are > advocating skinny controllers and fat models, Symfony is taking things > away from the Model that should logically be handled there like > validation.
> Similarly, when other frameworks are moving towards having their > generators build code it's largely CSS driven, whereas the code here > is (by default) tables. This again seems like a step back given the > push for standards driven web design.
> I can certainly respect the power of the new methods that are > available, but I wonder why they are preferable given the stated roles > of the Model, View, & Controller and what direct benefits this gives > to designers who are separated from application development teams who > must now learn additional Symfony methods instead of being freed to > just be designers.
> I'm not trying to tear down what has obviously had a lot of thought > given the dramatic nature of the change. I'm just trying to understand > how it remains consistent with MVC principles.
Thank you for clarifying the new form handling in a great blog post.
The view definitely has more power than I originally thought and I
better understand the new way form widgets are handled on the actual
view rather than just echo $form.
My only remaining question is: how is data validation handled on the
model? Can the validator_schema be instantiated in the model? I see
from the helpful thatsquality.com tutorial series that they can be
instantiated within the configure() method, but that lives in the
controller. From an organizational standpoint, I'd like to keep
everything directly dealing with the model in the model, but am too
unfamiliar with the new system at this point to see how to make that
happen.
I like how everything is decoupled from the framework so that it is re-
usable because it'll really help 3rd party vendors with their plugin
development by opening up the ways in which other kinds of data (XML
as you alluded to) can be handled by Symfony.
- Keith
On Jan 15, 9:24 am, Fabien POTENCIER <fabien.potenc...@symfony-
> Very interesting questions. As I really think the new form framework is
> the only one (that I know) that fully embraces the MVC pattern, I've
> just wrote an answer on my blog that try to explain the philosophy
> behind the design:
> Keith wrote:
> > I am a little confused about a few things in 1.1 with form handling
> > still.
> > * Why is validation (something that in most MVC frameworks is handled
> > in the model) now handled in the controller?
> > Doesn't this move the validation farther away from what it actually is
> > validating?
> > * Why is form rendering also now in the controller? The view just
> > contains
> > echo $form
> > where the form should render.
> > Isn't the form part of the view? It seems to me this new system mixes
> > both logic and presentation in how forms are rendered and validated.
> > I feel like I'm missing something important in trying to understand
> > this because these changes seem very inconsistent with what the rest
> > of the MVC world is doing. At a time when other frameworks are
> > advocating skinny controllers and fat models, Symfony is taking things
> > away from the Model that should logically be handled there like
> > validation.
> > Similarly, when other frameworks are moving towards having their
> > generators build code it's largely CSS driven, whereas the code here
> > is (by default) tables. This again seems like a step back given the
> > push for standards driven web design.
> > I can certainly respect the power of the new methods that are
> > available, but I wonder why they are preferable given the stated roles
> > of the Model, View, & Controller and what direct benefits this gives
> > to designers who are separated from application development teams who
> > must now learn additional Symfony methods instead of being freed to
> > just be designers.
> > I'm not trying to tear down what has obviously had a lot of thought
> > given the dramatic nature of the change. I'm just trying to understand
> > how it remains consistent with MVC principles.
Great questions. I'm the other author of the blog at thatsquality.com,
and even I've been sort of kicking
myself lately for not covering more than just the echo $form in the
template. My intent was to really show
how simply this stuff can be, but I've been regretting it more and
more as of late!
Per your latest question, I'm may be a little confused. The configure
method is not in the controller, it's
in your form class, which is really part of the model. Validation is
coupled with the model through each
model-specific, form class in a few ways:
1) Symfony sets you up with basic validation via the type of your
field when it auto-generates your form class
2) Further configuring of your validation is done in the form class
(Fabien, am I right to essentially be calling
this part of the model?), where validation is handled per each
specific model field.
So, as I see it, no validation should be in your controller, but
rather in the new auto-generated form classes -
where a form class is generated for each table in your schema.
My opinion is based almost entirely from studying the source code, so
Fabien, I'd love to have you clear up
any mis-statements I may have just made.
- Ryan
On Jan 15, 10:58 am, Keith <kmedli...@gmail.com> wrote:
> Thank you for clarifying the new form handling in a great blog post.
> The view definitely has more power than I originally thought and I
> better understand the new way form widgets are handled on the actual
> view rather than just echo $form.
> My only remaining question is: how is data validation handled on the
> model? Can the validator_schema be instantiated in the model? I see
> from the helpful thatsquality.com tutorial series that they can be
> instantiated within the configure() method, but that lives in the
> controller. From an organizational standpoint, I'd like to keep
> everything directly dealing with the model in the model, but am too
> unfamiliar with the new system at this point to see how to make that
> happen.
> I like how everything is decoupled from the framework so that it is re-
> usable because it'll really help 3rd party vendors with their plugin
> development by opening up the ways in which other kinds of data (XML
> as you alluded to) can be handled by Symfony.
> - Keith
> On Jan 15, 9:24 am, Fabien POTENCIER <fabien.potenc...@symfony-
> project.com> wrote:
> > Hi Keith,
> > Very interesting questions. As I really think the new form framework is
> > the only one (that I know) that fully embraces the MVC pattern, I've
> > just wrote an answer on my blog that try to explain the philosophy
> > behind the design:
> > Keith wrote:
> > > I am a little confused about a few things in 1.1 with form handling
> > > still.
> > > * Why is validation (something that in most MVC frameworks is handled
> > > in the model) now handled in the controller?
> > > Doesn't this move the validation farther away from what it actually is
> > > validating?
> > > * Why is form rendering also now in the controller? The view just
> > > contains
> > > echo $form
> > > where the form should render.
> > > Isn't the form part of the view? It seems to me this new system mixes
> > > both logic and presentation in how forms are rendered and validated.
> > > I feel like I'm missing something important in trying to understand
> > > this because these changes seem very inconsistent with what the rest
> > > of the MVC world is doing. At a time when other frameworks are
> > > advocating skinny controllers and fat models, Symfony is taking things
> > > away from the Model that should logically be handled there like
> > > validation.
> > > Similarly, when other frameworks are moving towards having their
> > > generators build code it's largely CSS driven, whereas the code here
> > > is (by default) tables. This again seems like a step back given the
> > > push for standards driven web design.
> > > I can certainly respect the power of the new methods that are
> > > available, but I wonder why they are preferable given the stated roles
> > > of the Model, View, & Controller and what direct benefits this gives
> > > to designers who are separated from application development teams who
> > > must now learn additional Symfony methods instead of being freed to
> > > just be designers.
> > > I'm not trying to tear down what has obviously had a lot of thought
> > > given the dramatic nature of the change. I'm just trying to understand
> > > how it remains consistent with MVC principles.
Now the structure makes more sense to me. Your series is excellent
Ryan and was greatly appreciated by everything I think!
It's such a departure from what I'm used to seeing in Ruby on Rails,
Symfony 1.0, and cakePHP that I wasn't seeing the whole picture I
guess. Very interesting take on the configure as a part of the form.
That mimics, in many ways, the way the old procedural stuff used to
work where you'd set up a configuration area prior to building
anything out in the code.
Thanks for the explanations. As more information comes out and the
documentation gets all shored up I expect things will become that much
more clear. This is a great start though.
Such usage is very bug prone in case one mistypes 'post':
if ($request->isMethod('post'))
It's better to use ->isPostMethod() or ->isMethod(sfRequest::POST) and
let the compiler catch bugs early.
Thanks Ryan for your series on forms, it was a great help since there
is no other documentation for the 1.1 form stuff :)
Everything made sense, as its similar to another MVC pattern I've
used, but one thing I couldn't do was get the form schema decorator
outputting properly.
I had a look through all the render calls as well and couldn't find it
being referenced, so I'm not sure if I should open a issue or not..
Does anyone else suffer from this problem?
Luckily I can just use the compat_10 :on in settings to get around the
forms for now, but I see them as quite powerful, and would like to
include them once it gets stable :)
Cheers,
Simon
On Jan 16, 12:53 am, weaverryan <weaverr...@gmail.com> wrote:
> Great questions. I'm the other author of the blog at thatsquality.com,
> and even I've been sort of kicking
> myself lately for not covering more than just the echo $form in the
> template. My intent was to really show
> how simply this stuff can be, but I've been regretting it more and
> more as of late!
> Per your latest question, I'm may be a little confused. The configure
> method is not in the controller, it's
> in your form class, which is really part of the model. Validation is
> coupled with the model through each
> model-specific, form class in a few ways:
> 1) Symfony sets you up with basic validation via the type of your
> field when it auto-generates your form class
> 2) Further configuring of your validation is done in the form class
> (Fabien, am I right to essentially be calling
> this part of the model?), where validation is handled per each
> specific model field.
> So, as I see it, no validation should be in your controller, but
> rather in the new auto-generated form classes -
> where a form class is generated for each table in your schema.
> My opinion is based almost entirely from studying the source code, so
> Fabien, I'd love to have you clear up
> any mis-statements I may have just made.
> - Ryan
> On Jan 15, 10:58 am, Keith <kmedli...@gmail.com> wrote:
> > Hi Fabien,
> > Thank you for clarifying the new form handling in a great blog post.
> > The view definitely has more power than I originally thought and I
> > better understand the new way form widgets are handled on the actual
> > view rather than just echo $form.
> > My only remaining question is: how is data validation handled on the
> > model? Can the validator_schema be instantiated in the model? I see
> > from the helpful thatsquality.com tutorial series that they can be
> > instantiated within the configure() method, but that lives in the
> > controller. From an organizational standpoint, I'd like to keep
> > everything directly dealing with the model in the model, but am too
> > unfamiliar with the new system at this point to see how to make that
> > happen.
> > I like how everything is decoupled from the framework so that it is re-
> > usable because it'll really help 3rd party vendors with their plugin
> > development by opening up the ways in which other kinds of data (XML
> > as you alluded to) can be handled by Symfony.
> > - Keith
> > On Jan 15, 9:24 am, Fabien POTENCIER <fabien.potenc...@symfony-
> > project.com> wrote:
> > > Hi Keith,
> > > Very interesting questions. As I really think the new form framework is
> > > the only one (that I know) that fully embraces the MVC pattern, I've
> > > just wrote an answer on my blog that try to explain the philosophy
> > > behind the design:
> > > Keith wrote:
> > > > I am a little confused about a few things in 1.1 with form handling
> > > > still.
> > > > * Why is validation (something that in most MVC frameworks is handled
> > > > in the model) now handled in the controller?
> > > > Doesn't this move the validation farther away from what it actually is
> > > > validating?
> > > > * Why is form rendering also now in the controller? The view just
> > > > contains
> > > > echo $form
> > > > where the form should render.
> > > > Isn't the form part of the view? It seems to me this new system mixes
> > > > both logic and presentation in how forms are rendered and validated.
> > > > I feel like I'm missing something important in trying to understand
> > > > this because these changes seem very inconsistent with what the rest
> > > > of the MVC world is doing. At a time when other frameworks are
> > > > advocating skinny controllers and fat models, Symfony is taking things
> > > > away from the Model that should logically be handled there like
> > > > validation.
> > > > Similarly, when other frameworks are moving towards having their
> > > > generators build code it's largely CSS driven, whereas the code here
> > > > is (by default) tables. This again seems like a step back given the
> > > > push for standards driven web design.
> > > > I can certainly respect the power of the new methods that are
> > > > available, but I wonder why they are preferable given the stated roles
> > > > of the Model, View, & Controller and what direct benefits this gives
> > > > to designers who are separated from application development teams who
> > > > must now learn additional Symfony methods instead of being freed to
> > > > just be designers.
> > > > I'm not trying to tear down what has obviously had a lot of thought
> > > > given the dramatic nature of the change. I'm just trying to understand
> > > > how it remains consistent with MVC principles.
rihad wrote: > Such usage is very bug prone in case one mistypes 'post': > if ($request->isMethod('post')) > It's better to use ->isPostMethod() or ->isMethod(sfRequest::POST) and
I agree with you entirely that it's better to use methods that result in compile/runtime errors... however....
The problem with having 'sfRequest::POST' is that technically, it shouldn't be there IMO.
the POST constant should apply to sfWebRequest, and not sfRequest.
isPostMethod() however is fine - but doing so, I guess technically speaking you should ensure it's of type sfWebRequest before calling that.
However, actions in symfony are almost always passed a request of type sfWebRequest - so really, it doesn't matter a great deal... However I see a case where at some point, a CLI request could be made to actions, and constants like GET and POST wouldn't apply.
I would like to say thank you for the brilliant work you have done with regards to the Symfony Framework.
I started using Symfony about one and a half years ago and have nothing but the utmost excitement for the future of the product!
The documentation for getting started is outstanding and I was soon delving into the core of the Symfony system and doing exactly want I needed to do with ease and superior speed.
The system we have built is for a UK lottery company and has millions of records per customer which we used Propel and PostgreSQL to manage.
I installed eaccelerator and to all those whom are concerned about speed and performance – don’t be!!!!
The site has 180 tables, a full affiliate, campaign, mass mailing, customer support system, and banner campaigns.
Have a look and feel free to give me your comments.
Our site is running very fast and I have nothing but respect for the Symfony Team.
I have even rename our South African Company to “Symfony Solutions”; representing what we do best!
Thank you Andrew Symfony Solutions
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date: 1/13/2008 8:23 PM
I would also advise to check if it is worth upgrading for you to switch to propel 1.3 ich can see that your db queries are the ones that take most of processing time (on frontpage 50ms out of 180ms)
On Behalf Of Fabian Lange Sent: Wednesday, January 16, 2008 4:59 PM To: symfony-users@googlegroups.com Subject: [symfony-users] Re: Thank you Symfony Team
Consider removing your development frontend :-)
I would also advise to check if it is worth upgrading for you to switch to propel 1.3 ich can see that your db queries are the ones that take most of processing time (on frontpage 50ms out of 180ms)
Ah and remove the frontend_dev :)
: Fabian
No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date: 1/13/2008 8:23 PM
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date: 1/13/2008 8:23 PM
On Behalf Of Fabian Lange Sent: Wednesday, January 16, 2008 4:59 PM To: symfony-users@googlegroups.com Subject: [symfony-users] Re: Thank you Symfony Team
Consider removing your development frontend :-)
I would also advise to check if it is worth upgrading for you to switch to propel 1.3 ich can see that your db queries are the ones that take most of processing time (on frontpage 50ms out of 180ms)
Ah and remove the frontend_dev :)
: Fabian
No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date: 1/13/2008 8:23 PM
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.2/1223 - Release Date: 1/13/2008 8:23 PM
Does it use any kind of IoC or Dependency Injection framework? I'm thinking along the lines of Spring here.
I'm using type-hinting quite heavily now to improve the robustness and flexibility of my interfaces, but at the moment it's a little clunky. I'd like to be able to replace all my instances of sfGuardUser with a generic 'user' which could be either sfGuardUser or my own user class - doing this at the moment isn't much fun (and all those $anObject->setSomeObjectId(String $id) methods I'd like to change to $anObject->setSomeObject(SomeObject $object))
Is anybody currently using any kind of IOC framework with Symfony?
Will have a look at that tonight, looks promising from a quick read :)
I tried to find info on Garden before, and it looks like the project has not only been closed, but that the code is gone too - I can only find references to it in other articles, no code. This makes me hesitant to use it - it was obviously abandoned for a reason, and an abandoned project is a project that isn't supported. :-/
I also found mentions of Navigator, Solar and Seasar(S2)... all of which I need to investigate. It didn't strike me that any of these had what anybody would call a widescale adoption.
Is anybody out there using DI/IOC with Symfony? In a live project?
On Behalf Of Tristan Rivoallan Sent: 17 January 2008 15:57 To: symfony-users@googlegroups.com Subject: [symfony-users] Re: Symfony 1.1 Questions / IoC / Dependency Injection
On Jan 17, 2008 4:50 PM, Lee Bolding <l...@leesbian.net> wrote:
> I have my own question regarding Symfony 1.1
> Does it use any kind of IoC or Dependency Injection framework? I'm thinking > along the lines of Spring here.
You also should remove development environment for application
backend... :)
Maybe you also could rename backend.php or use a rewrite rule to avoid
access to your admin side just by typing http://www.playukinternet.com/backend.php BTW, is there a pratical reason why you didn't use sfGuardPlugin to
support all your security stuff ?
Jérôme
On 16 jan, 15:58, "Fabian Lange" <Fabian.La...@web.de> wrote:
> I would also advise to check if it is worth upgrading for you to switch to
> propel 1.3 ich can see that your db queries are the ones that take most of
> processing time (on frontpage 50ms out of 180ms)
On Behalf Of Tristan Rivoallan Sent: 17 January 2008 15:57 To: symfony-users@googlegroups.com Subject: [symfony-users] Re: Symfony 1.1 Questions / IoC / Dependency Injection
On Jan 17, 2008 4:50 PM, Lee Bolding <l...@leesbian.net> wrote:
> I have my own question regarding Symfony 1.1
> Does it use any kind of IoC or Dependency Injection framework? I'm thinking > along the lines of Spring here.
|
