Same view for create/edit?

0 views
Skip to first unread message

Sean Chambers

unread,
Nov 3, 2009, 10:08:27 AM11/3/09
to Spark View Engine Dev
I have a partial view that has a number of input fields on it like so:

<input type="text" id="something" name="something" value="$
{User.something}" />

The value is populated if I am editing a user, the only problem is
this doesn't work when creating a new item because a null reference
exception is thrown.

Is there a way to initialize User or something like that so I that
when adding a new user the value attributes are just blank? Maybe
there's just something extremely simple here I'm missing.

Thanks

Sean

Adam Schroder

unread,
Nov 3, 2009, 4:44:57 PM11/3/09
to spar...@googlegroups.com
Just pass an empty model to your view so that the values will be blank.

Morten Maxild

unread,
Nov 4, 2009, 6:47:04 AM11/4/09
to spar...@googlegroups.com
What I often do is create a dedicated DTO type that represents the form submitted data. This simple message object when newed up using the default ctor represents a new user, and can safely be rendered with the 'User/Edit.spark' template.

Of course this introduces a new layer of DTO/Message types, but it does simplify working with input from submitted form params, url params and query params that are all string based. Many value objects in your domain is not string friendly (dates, money, ints etc...) because how does a 'new' field get rendered. And you are not going to make every value object in your domain nullable.

HTH
Morten

Adam Schroder

unread,
Nov 4, 2009, 7:11:56 PM11/4/09
to spar...@googlegroups.com
@Morten do you make that DTO object just strings?

Morten Maxild

unread,
Nov 5, 2009, 10:40:23 AM11/5/09
to spar...@googlegroups.com

All properties on the model send to the view (and later deserialized on submit by the controller action invoker and friends) has to render as expected on an edit form for a new such resource

 

Yes this most often means string properties

 

Of course since my custom model binder (a deviate of the DefaultModelBinder) can handle lots of simple types (and custom types with type-converters) it is a step back, since I have to build infrastructure to map the DTO to ‘strongly typed’ command objects and the like

 

/Morten

 

 


Reply all
Reply to author
Forward
0 new messages