For forms that won't hit the size limit of a cookie (4k), you can save the form variables off to flash-scoped copies for re-display. See this post for an example. A reader, opensas, wrote a helpful comment that referenced a technique that obviates the need for flash variables.
Model
A central theme in the Play! Framework is to use your domain objects throughout your application. The domain objects extend Generic Model which makes them persistable. The domain objects will contain business logic, possibly referencing other Models. The domain objects can also be used on the front-end to transport form variables.
This includes server-side validation logic. In the following Controller method, a Model "Tutorial" is retrieved from the database if an id is present.
Basic GET Form Controller Handling Blank and Filled |
When the form is submitted, the method saveTutorial() is invoked. Play! creates a Tutorial object which is filled with form variables. Two validation() calls are made. If the form is not valid, some lists are gathered and passed along to a render() call.
Controller Method Supporting Form POST |
The @showTutorial in the render call is a reference to a template rather than the method. There is a file showTutorial.html that will be called from saveTutorial().
Here is the re-worked view code. Note that the flash.tutorial_title_tx has been replaced with tutorial.tutorial_title_tx.
View Code |
The URLs
As mentioned in opensas' comment in the post about flash variables, there is an inconsistency in the URLs. saveTutorial(). Upon a validation error, the /savetutorial URL is displayed in the browser instead of the /showtutorial which occurs on a successful submission. The flash variable version invokes the "right" controller so the URLs are consistent.
But given that I don't have to re-define each Model as a set of flash variables, I think this is the better approach. Many thanks to opensas.
No comments:
Post a Comment