Thanks, guys.
On Mon, Sep 1, 2008 at 17:06, David Zülke <[EMAIL PROTECTED]> wrote:
> Am 01.09.2008 um 15:26 schrieb George Pop:
>
>> Hi.
>
> Hey George,
>
>
>> I am new to Agavi. Bear with me if I enquire about the obvious.
>
> Fantastic! Welcome!
>
>
>> I was wondering whether the usual separation of views into "Input",
>> "Success", "Error" etc. is just a convention, or if there's a functional
>> purpose to it. I mean, is it a serious offense to mix some of these views
>> into one, especially when there's very little code in either of them?
>>
>> Case in point, the sample application that comes with Agavi has three
>> views for the Login action: Input, Error, and Success. Now, the Error view
>> is only there to set an error on the validation manager, after which it
>> renders the template for the Input view. Here's the meat of it:
>>
>> if(($error = $this->getAttribute('error')) !== null) {
>> $this->container->getValidationManager()->setError($error,
>> $this->context->getTranslationManager()->_('Wrong ' . ucfirst($error),
>> 'default.errors.Login'));
>> }
>>
>> What if I simply add this code to the Input view, and have the action
>> return "Input" instead of "Error" when the wrong credentials have been
>> entered? Am I headed for trouble?
>
> You should definitely keep the separate views. Note that you can use the
> command line "agavi" script to generate them, so there's no manual labor
> involved (except maybe adding them to version control).
>
> If you have it all in one view, the execute() methods get extremely
> cluttered. The example above has a manual error setting. Usually, the
> validation rules define the error messages, and those are automatically set
> into the validation manager. The Form Population Filter then outputs the
> page again with the messages inserted and the fields highlighted.
> In such a case, your error checking code needs to look different again, and
> it just becomes cumbersome.
>
> And you'll often have sth like EditProduct actions, where in the Input view,
> you grab data from the database, and pass it to the FPF so it inserts them
> into the form for you. But on Error, you don't want that to happen. And on
> Success, you want to redirect back to the ViewProduct action.
>
> Also, you cannot cache things if everything is in one view. Usually, you'd
> set up caching for an action based on several rules, and then say "only
> cache stuff if the Success view is run". On error, no cache would be created
> (otherwise, I could quickly fill your hard drive with junk data!)
>
> In general, if you keep things tidy, it will save you trouble later. Think
> of web services that also need different outputs depending on the situation
> etc. Having it all in one view would mean severe ugliness after some time.
>
> Hope that helps,
>
> David
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.agavi.org/mailman/listinfo/users
>
>
_______________________________________________
users mailing list
[email protected]
http://lists.agavi.org/mailman/listinfo/users
