Hi all,
Reviewing the form refactoring takes a lot of time. So, I've not
finished yet. But anyway, here is a small summary of the current state
on my side.
Instead of using the new form framework within a Symfony project, which
many of you have done, I've tried to use it in a plain PHP project.
Except small problems/suggestions I've made to Bernhard, I'm quite happy
with the global architecture of the Form and Type classes.
The last part that I'm still reviewing is the Renderer sub-framework.
Right now, I'm not satisfied with it. The templating part of the form
framework should be about two main things: templates and variables.
Variables
---------
This part has been acknowledge by Bernhard, so you can probably skip it
and go to the "Templates" section directly.
Right now, the renderer part is well decoupled from everything else and
the integration is done in the Types via the ThemeRendererInterface
(let's not talk about FormFactoryInterface::createRenderer() for now,
which is the end-user integration point).
First, the interface is misnamed as it is mainly about managing template
variables (the name only makes sense because it extends the
RendererInterface which has a render() method). Moreover, the interface
is only used in Type classes and if you have a closer look, these
classes use much more than just the methods defined in the interface.
So, right now, the Types are coupled with a ThemeRenderer instance, not
ThemeRendererInterface.
So, the first thing I've done is to decouple Types and ThemeRenderer.
The buildRenderer() and buildRendererBottomUp() methods goal is to get
information from the Form instances and populate the template variables.
And by looking at all the core Types, I can confirm that this is the
only goal. Some of the Types need to access the children or the parent
but only to get or set some template variables. This is fine, but as we
pass a ThemeRenderer, people can abuse that. So, instead of
ThemeRendererInterface, I've created a TemplateVariables class (whatever
the name is), which is a data container for variables to pass to the
templates? The implementation is a subset of the current ThemeRenderer
implementation.
Templates
---------
The other thing that bothers me is the fact that we do not leverage the
power of the templating engines we support. I don't mind if Twig and PHP
do not share much code, but I want to use each templating system the
"right" way. And right now, this is not the case for Twig. Calling
methods and variables on objects is not the way to generate HTML and as
a result, it does not play well with automatic escaping. The "good" way
is to use functions and filters as they convert objects, string,
whatever to HTML.
I will work on refactoring this part this evening to see how far I can
go with this idea (should be easy as this is basically the current
approach). If we do that, upgrading from the current form implementation
to the new one will be much easier as the templates will stay mostly the
same.
Fabien
--
Fabien Potencier
Sensio CEO - Symfony lead developer
sensiolabs.com | symfony.com | fabien.potencier.org
Tél: +33 1 40 99 80 80
On 4/7/11 9:22 AM, John Wards wrote:
Hello Folks,
I have been otherwise engaged battling Internet Explorer 8 in my spare
dev time for the last two weeks so I am completely out of the loop as
to where the form component is currently at.
Last week Fabien said he would put his issues on the mailing list, but
we've yet to have this. It would be really good to have an idea of
Fabiens issues with it, especially if they are the same issues I have.
Internally we have issues with the whole "getParent()" thing, when
defining a form, I may not understand the problems this solves but
writing a string that defines your parent feels wrong to me. Its hard
to debug for a start. I think an explanation of this area might help,
so at least I can argue against it with more information if I still
feel it is wrong. It is functional and does its job, but it is a
little bit unclear look at the code what it is done. I feel if you
can't figure it out by looking at the code then something is
wrong...that is just my opinion of course...
I know people have issues with the Type name thing also, I'm not that
bothered it is just a name, however it would be good for people to
debate this openly a bit more.
It would be good if other people using it could list any issues they have too?
From my point of view I think its fine for my use and if it doesn't
get put into 2.0 we will be using the code anyway in our application.
Cheers
John
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
