> 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.
Matthew, I'm terribly sorry if my words made you feel bad. It's just my own point of
view and my own opinion, which may not be shared by others. It's just that I have been
struggling with Quickform for all those years and I am just disappointed at Zend_Form.
That's all. You say the main goal of Zend_Form was to simplify the task of creating
forms. That's Quickforms goal also, and I remember the ZF wasn't supposed to reinvent
the wheel by copying long standing libraries' functionalities.
I don't want to pour any more gas on fire so I'll try to tone down a little bit. And I
want you to know I admire your work. There are things that I don't like in the code but
that's pretty normal. There are lots of code I do like a lot on the other hand. I guess
people (me included) don't feel the need to voice their opinions when they are content
with everything.
BTW: You should try separating all the MVC layers someday by leveraging XSLT (without
EXSLT and calling php functions). This is an eye opener, believe me.
I'll try to address some of the issues as sparsely as possible. But please keep in mind
I'm not trying to persuade you to do any changes to Zend_Form. It's good as it is - and
as you see, it is good and easy for majority of developers (probably because they're
already familiar with similar libraries). What I'm going to do is to advocate my way of
thinking. Showing what's on my mind on that's all to it now.
> There's absolutely nothing preventing you from creating elements called
> "email" or "search". Zend_Form allows this.
That's my major problem - I don't need a second object to hold a single string value. I
already have my own domain model to hold this kind of data. It may be necessary to keep
a copy for the form but I don't want to create a separate object model for this.
> 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.
Yes, but see my other reply regarding semantic validation. Zend_Validate and my model
validation should be outputting they're error messages the same way. And form view
helpers should be able to use them. Precisely in order not to repeat the code and to
keep the amount of code to the minimum.
>> 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.
It's ok, Matthew, I understand. And I don't hold a grudge. I'm not going to point you to
it because it really doesn't matter now. I just mentioned it and I can't really tell why :)
>> 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.
Actually no. I said I would like form helpers to be form data and validation aware. So
the developer doesn't need to do that. Furthermore you don't pull the label and metadata
as these belongs to view layer and shouldn't be stored in the model. So it's just a
static text. But instead of a static text you may provide a static key to
internationalization library in order to pull the whole translation.
> 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.
And this is my main issue with it at the same time.
> 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.
And I'm pedantic at times, on the other hand. I see so much quick and dirty solutions on
my day job I'm fed up with it. When you get the cost, time and quality in the enterprise
the latter is the last one people care about. Jeff Atwood lately said that in open
source the time is the cost, so in theory we could make quality matter a little bit
more. But I digress.
>> 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.
To be completely frank, I will probably not. Unless I will get paid to do it.
Professionally I code no more (I miss that a lot, though), so I don't develop my own
solutions. And when time allows me to code, I spend my last bits of time on the Router.
And when it comes to personal projects, I'm mainly writing Java nowadays. But leisure
wins on more and more occasions :)
> But please be aware that _your_ vision of how forms should be handled are not
> necessarily the same vision _everyone_ shares.
I'm perfectly aware of that. I'm not trying to speak as I'm the only one who is right.
Anyway, the majority always wins and people don't like changes to what they're used to.
--
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
没有评论:
发表评论