(on Thursday, 14 August 2008, 09:50 PM +0200):
> Now, to the second problem. I, personally, don't like the design of
> Zend_Form as well as Quickform's because I don't like the libraries that
> model html elements (text, textarea, select, etc). This is relevant to
> form generators ONLY which I don't like to use. And I don't see why the
> whole form has to be designed that way only to support automatic form
> visualization.
>
> When you think about it in detail, is it really relevant for your model
> from what type of html control the data comes from? Is it relevant if
> search query comes from textarea, text input or a hidden field? It's
> still a string representing a text and it comes through GET or POST
> parameters. And it could as well come from an e-mail/IM provided URL, PDF
> form, XForm, AJAX, etc. Basically you should be able to validate the data
> without the form object.
>
> Furthermore, when you model your form data as html elements you create
> two additional problems - your view layer information leaks to the model
> (html text labels, form data visual representation, etc) and you restrict
> yourself to html forms. And now try to separate the view and controller
> layers by using two-step view and xslt. You're basically screwed.
Actually, Michał, this is an unfair and inaccurate criticism. If you
look at the design, we have _elements_, period. While the default,
shipped concrete elements all model _HTML_ elements, they don't have to
-- this was done as they'll be familiar to web developers.
There's absolutely nothing preventing you from creating elements called
"email" or "search". Zend_Form allows this. This is also in fact why
decorators are available -- so that you can choose the final
representation to suit your given application needs. Model an element
however you want, filter and validate and render it however you want --
that is the design.
As for being able to validate the data without the form object, this is
possible -- you can use other strategies, such as creating your own
validation chain with Zend_Validate, or using Zend_Filter_Input.
The main advantage Zend_Form provides is that it simplifies your final
view scripts or presentation layer, and helps reduce the amount of code
necessary to present the form and form elements, and also prevents
synchronization issues (for example, if you add or remove fields from
your input filter, you don't have to worry that you forgot to do
similarly in your presentation layer). It is a swiss-army knife for
performing input filtering and presentation of data selection.
> I have provided my thoughts on a form proposal like a year ago (which as
> it seems were ignored).
I reviewed all form proposals that were in the wiki when formulating the
final proposal. I do not recall seeing one that you had created. I also
do not recall you commenting on the final proposal; I apologize if I
overlooked any thoughts you had, but I also had plenty of other input
from the community, as well as my review of other form solutions in
other languages and frameworks.
> To reiterate - php form libraries should work on GET/POST data not on
> html elements. Validators and validation should be form independent
> (as they validate data and can validate more than just forms). Form
> generators should be able to use form data and validators or just
> validation feedback. If you don't like generators, you should be able
> to use html form view helpers which too should be able to use the same
> form and validation data.
The problem with this approach is that you end up having to create much,
much more logic in your presentation layer -- repetitious logic like
pulling the value, escaping it, pulling the label, escaping it, pulling
metadata... you get the point.
I completely agree -- Zend_Form is not a "pure" implementation -- it
mixes some responsibilities. However, this is done for convenience and
to promote rapid application development. There are plenty of options
already in ZF to allow you to create more pure implementations such as
you describe -- Zend_Filter, Zend_Validate, Zend_Filter_Input, the
Zend_View helpers, etc, can be combined in various ways to achieve these
goals. These were not the goals of Zend_Form, however. The main goal of
Zend_Form was to simplify the task of creating forms that could provide
input filtering and render themselves.
I'm all for purity of design... as long as it doesn't impede or
complicate development. I'm a pragmatist. Zend_Form is a pragmatic
solution.
> Now, when it comes to this design, Solar Form is not far from hitting the bullseye:
>
> http://solarphp.org/manual:form_processing:overview
>
> It's not the first time Paul M. Jones is doing something great. Just look
> at hist PEAR Text_Wiki. And Zend_View also is based on his ideas. Hats
> off to you Paul.
Solar_Form was one of the libraries I evaluated when developing the
Zend_Form proposal, btw. I agree with you -- Paul's implementation is
quite good, and it was one of the approaches I liked best.
> But unfortunately Solar still mixes view layer and models - by using
> labels and types. Yes, types. All GET/POST incoming form data is
> represented as strings - and this should be filtered/validated at a model
> level.
>
> I have been planning to create a Zend Framework compatible form library
> but I don't have much time on my hands. And I have lost my imperative
> when Zend_Form got created ;)
I'd be happy to see what you develop, if you ever do. But please be
aware that _your_ vision of how forms should be handled are not
necessarily the same vision _everyone_ shares. This is why we have a
proposal process, and why Zend_Form is the way it is now. This is not to
say that alternate implementations won't be considered sometime in the
future, however.
> Adam Jensen wrote:
>> On Thu, Aug 14, 2008 at 12:24 PM, Michał Minicki <martel@post.pl> wrote:
>>> Let me chime in for a sec. There are two kinds of validation -
>>> general/formatting/visual and semantic validation. These two actually belong
>>> to different objects. Where do they belong? The short answer is to form and
>>> model respectively.
>>
>> Very interesting point; I think I've been running up against this
>> distinction myself lately.
>>
>> Let me add another wrinkle: we primarily use the validators in form
>> objects for checking the acceptability of user input, correct?
>> However, form objects only really handle the first kind of validation;
>> as you said later on, only the model knows how to do the semantic
>> validation.
>>
>> If that's the case, how do we validate user input semantically?
>> Semantic validation errors needs to be communicated to the user just
>> as surely as formatting validation errors do, and it'd be nice to
>> handle them all in one place (ideally Zend_Form, since its
>> error-reporting mechanisms are so easy to use).
>>
>> I suppose the Zend_Form subclass could just duplicate all the semantic
>> validation rules that are already in the model, but I think we all
>> know how difficult that would make our lives later on :)
>>
>> Thanks!
>> Adam
>
>
> --
> Michał Minicki aka Martel Valgoerad | martel@aie.pl | http://aie.pl/martel.asc
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> "Idleness is not doing nothing. Idleness is being free to do anything." --
> Floyd Dell
>
--
Matthew Weier O'Phinney
Software Architect | matthew@zend.com
Zend Framework | http://framework.zend.com/
没有评论:
发表评论