[Catalyst] Putting more in the View

[Ian Docherty]

Wade.Stuart at fallon.com wrote:

>
>
>  
>
>>In the 'traditional' manner, the /user/save/33 Controller would take the
>>request->params and validate them. If valid the relevent user record
>>would be updated and that would be the end of it. If invalid however we
>>need to display an error message and re-populate the form with the
>>additions or modifications made by the user so they can correct them. In
>>other words sticky-forms.
>>
>>This is where I have my first problem. I can't now pass the user object
>>back to the Template, I need to pass the request->params to the
>>template. I can either try to build up a CDBI::User object from the
>>request->params and pass that to the Template (which does not work since
>>CDBI cannot create a new object without writing it to the database. I
>>understand that DBIC can do this but I have not yet gone down this
>>route.). Or I can refrain from passing in a CDBI::User object to the
>>Template in the first place but instead pass in all the parts of the
>>user object separately to the stash.
>>    
>>
>
>Are you using the FillInForm plugin? This provides sticky form
>functionality.  It also ties well with DFV.
>
>I do not understand were you are struggling with the user object being
>passed anywhere.  Because the form has invalid data, the user object has
>not been modified and the form is shown again for the end user to correct.
>Why even try to pass the user object around?
>  
>
I looked at the FillInForm module but felt that the idea of parsing the 
HTML output (presumably after TT has created it) was too flaky so I 
would be interested in knowing peoples opinions. I felt it might work 
for simple cases but not more complex ones (such as forms updated with 
AJAX).

You are right that if the form has invalid data I *dont* have to pass in 
a user object. However the same form is used in two way.s
1. To show the initial User data, which could be populated directly from 
the User object.
2. To show the invalid input data, with suitable error messages. I can't 
now display data directly from the User object but have to populate it 
from the previous request-params.

The template is different in the two cases. In the first case it is 
assuming a complex object together with methods is passed. In the second 
case it is at best a complex data structure.

I accept your point that FillInForm would do this but still aim to be 
convinced. On this point, I am not clear how FillInForm should work. If 
for example I have a loop (for example displaying a number of User 
contact telephone numbers for example) then this loop is populated 
initially from a User-has-many relationship. The TT loop is controlled 
the first time round from a User method. On subsequent form submission 
(using sticky-forms) there is no User method, so how does TT get it's 
loop count?

>>I hope you are following this. Sorry for the long post but I am getting
>>to the important bit now...
>>
>>These are the relevent bits of code.
>>
>>1. Decompose a User object into separate stash variables.
>>2. Put the stash variables into the form (this is done with TT).
>>3. Do simple validation when the form is submitted, e.g. ensure that
>>mandatory fields are filled in.
>>4. Do simple manipulation of data, e.g. remove leading and trailing
>>whitespace, convert checkboxes into true/false values, date formats etc.
>>5. Do database validation. e.g. is this username already taken
>>6. Compose a User object from the input data from (4) if the validation
>>succeeds.
>>7. If validation fails, take the raw request->params (prior to (4)) and
>>re-populate the form.
>>
>>    
>>
>
>1: why do this at all stash and TT both handle complex vars?
>
>
>DFV && FillInForm.
>
>  
>
>>In my previous experience, and in many of the examples I have seen,
>>steps 1,3,4,6 and 7 (and often 5 as well) takes place in the
>>    
>>
>controller....
>  
>
>>My reasoning is that 1,2,3,4 and 7 rightfully belong in the View not the
>>Controller. 5 and 6 should be in the Controller/Model.
>>    
>>
>
>1: does not need to be done.
>  
>
Agree if using DFV

>2: this is already in your V, as TT [% %] blocks.
>  
>
I agree, my point too.

>3: this is either C or M.  Validation has little to nothing to do with the
>view.
>  
>
Agree to some extent but then why do people do Javascript validation 
(which is indisputably in the View)?

>4,5,6: C and/or M this has nothing to do with view.
>  
>
The MVC model breaks a two-way dependency between the View and the 
Controller and recommends that the Controller should not have knowledge 
of the View. This is exemplified by the Controller just sending the User 
object directly to the View which does with it as it needs. The 
Controller cares not how the data is processed or modified.

The View on the other hand needs to know how the Controller requires its 
data. For example, if on validating a date string to ensure it is valid, 
it should convert it into the system internal date format (whatever that 
is). Similarly it should not just pass a checkboxes value of 'on' or 
undefined to the controller but to a boolean true or false.

So, if the view was changed to use some other method that (for example) 
used a radio button, or a drop-down, instead of a checkbox then only the 
view would change (to process the input) and the controller would remain 
unchanged.

I argue then that 4 *does* belong in the View and not the controller.

>7: C and V,  or nothing if you are using DFV and FillInForm.
>  
>
I concede this point but still have my doubts about FillInForm in more 
complex cases.

>  
>
>>To this end I have developed my Catalyst application along these lines.
>>
>>I have a Myapp::V::User->objectDecompose method that takes the User
>>object passed to it from the URI /user/edit/33 code and puts the bits
>>that the view needs into the Template. (Step 1)
>>
>>I have MyApp::V::User->validate which takes the request->params and
>>validates them (Step 3 and 4) and, on the assumption that the validation
>>might fail, also implements the sticky-form (Step 7).
>>    
>>
>
>this is silly,  what does validation against business rules or database
>rules have to do with view.
>  
>
I agree with retrospect that checking mandatory fields is a business 
rule but still insist that some data transforms belong in the View.

>  
>
>>This leaves my controller fairly clean and easier to implement with all
>>the messy validation and data transfer taking place in the View where in
>>my opinion is should be.
>>
>>I welcome any comments on this approach.
>>    
>>
>
>
>
>_______________________________________________
>Catalyst mailing list
>Catalyst at lists.rawmode.org
>http://lists.rawmode.org/mailman/listinfo/catalyst
>
>
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060215/98bf6ad8/attachment.htm