Re: [fw-mvc] Pattern / example?

Thanks

My codes are now almost equal to Benjamin Eberlei 's showed in
> http://www.whitewashing.de/blog/articles/42
,as a result.

But there is a tiny problem .All the elements must be classified
to Zend_Form_Element_(*).
Zend_Form_Element_(*) is classfied as view logic to perform
specifically in HTML form elements. Not meta model.

In case, a Model has a element *paragraph*.
class Model {
protected $_paragraph;
}
What type of Zend_Form_Element_(*) should I use ?
For instance requirement,
- textarea to edit it
- plain text to view it normally or edit preview
- hiddenfield to handle a state form
Should I change the class according to the rendering situation?

In reality, I selected Zend_Form_Element_Textarea and
changed decorators per situation.
Thinking naturally, I think it must be Zend_Element_String so called
tentatively.
And a Model does have many instances of Zend_Element_(*) what
be classfied to meta model.
It enables us to render contents in a semantic process.

However, I am satisfied with Zend_Form implementation.
Pay it no mind. What I just said is no more than a tentative assumption.

thanks

--
Tomoaki Kosugi
id:noopable

2009/6/4 Abraham Block <atblock@gmail.com>:
> I think a better approach would be what Benjamin Eberlei wrote about a while
> ago: http://www.whitewashing.de/blog/articles/42
> where basically the Zend_Form just stores the meta data of the form and the
> form is actually handled by a viewhelper.
> All this academic stuff does come at the price of complexity though...in the
> end of the day, we would like to just get our job done, and Zend_Form gives
> a good compromise for doing that.
>
> On Wed, Jun 3, 2009 at 8:46 PM, Tomoaki Kosugi <kipspro@gmail.com> wrote:
>>
>> Hi
>>
>> This approach is just like Zend_Form with validators, model-data, and
>> decorators.
>>
>> $form->addDecorator($decorator);
>> $form->render();
>>
>> This approach is very very usuful for making a semantic view dynamically,
>> getting an advantage over the MVC designed with separate templating .
>>  This ease concerns about making a widget or a sectionally view design.
>> And for keeping view scripts simply.
>>
>> I think that It would be nice if Zend_Form_(*) be remade to
>> general-purpose classes.vary depending on the intended use.
>> Like a Zend_Element or Zend_Decorator.
>>
>> I tried to design a model with an architecture just like Zend_Form .
>> First,I was stuck in a collision Zend_Form_Decorator_Abstract::setElement.
>> It allows only Zend_Form_Element or other classes.
>> Because Zend_Form is designed only to render form-elements.
>> Thus, I made a model what is based upon Zend_Form.It has a delegation
>> to Zend_Db_Table.
>> Besides, Zend_Form_Element is designed to represent a form element.
>> I made custom elements to match semantic model's elements.
>>
>> thanks
>>
>> --
>> Tomoaki Kosugi
>> id:noopable
>>
>> 2009/6/4 Ed Lazor <edlazor@internetarchitects.biz>:
>> > Anyone happen to have their models designed to "render" themselves?
>> > For example:
>> >
>> > $model->display();
>> >
>> > or
>> >
>> > $model->draw();
>> >
>> > This is more of a general OOP question, but I'd like to apply it as
>> > much to ZF as possible since that's where I'll be implementing it.  I
>> > read how you're supposed to design your objects and assign them the
>> > responsibilities to manage themselves.  The article (mentioned in my
>> > last thread) gave the example of having the model draw itself.  It
>> > sounds neat, so I'd like to try it and I'm wondering how to approach
>> > it.  I'm guessing the model would generate the data, send it to an
>> > adapter of some sort, the adapter would apply a template (or
>> > whatever), results would return to the model, which then returns the
>> > results to the originating code.  Is that correct?  Anyone know / have
>> > examples?
>> >
>> > Thanks,
>> >
>> > Ed
>> >
>> >
>>
>
>
>