When I initially saw Howard's screencast, the first thing that came to my mind was similar to your thoughts: this binds view and model too close together. I don't want to have view-related annotations in my business objects.
Then I thought about how to solve this. Somehow you have to define which properties of your business object you want to expose to the user for editing. Things like the primary key, or a last modified date, which automatically updates on each save, do not belong on the edit page. Also, you might have situations, where there are several edit pages, one for a normal user, who might edit some fields, and one for an administrator, who can change more than the normal user. One possibility of defining this is to create a pure UI object. This object only has the properties used for editing (+ some way to find back to the original business object, primary key would be a good idea). You can have different UI objects for the same business object depending on what you want to edit. You can pack any number of view related information (annotations) into your object, as this is your view. Drawback: now you have to write code to create a UI object from a business object, and to copy back changes from an UI object to the business object, in case the user hits the save button. But this binding can be done with the same techniques already used for binding object to the UI. For instance, fields with the same name in business object and UI object are easy (can be done automatically). Some other bindings may need manual coding. Does this make sense? Christoph Christian Gruber wrote: > Hmm. I've definitely wondered this as well. Unfortunately, something > like this might bind the view and the model too closely together. > You're really then instrumenting your model not with business logic > (per, validate) but with display characteristics which starts to move > away from the point of an MVC architecture. I can see the convenience, > but I wonder if there's a more model-oriented way of describing this > which the view (beaneditform) can interpret. Can't think of a good > approach at the moment, but there should be one. It might amount to the > same thing, but with less display-centric terminology. > > Christian. > > On 27-Oct-07, at 5:16 PM, Christoph Jaeger wrote: > >> Hi, >> >> I like using the BeanEditForm, but I think there should be some >> additional annotations to make it even easier to use. >> >> There is already an annotation called "NonVisual" to mark properties you >> do not want to display on your page. >> >> How about >> >> @Display(type=password) >> >> so you do not have to use >> >> <t:parameter name="password"> >> <t:label for="password"/> >> <t:passwordfield t:id="password" value="person.password"/> >> </t:parameter> >> >> or >> >> @Display(type=multiline) >> >> instead of >> >> <t:parameter name="address"> >> <t:label for="address"/> >> <t:textarea t:id="address" value="person.address"/> >> </t:parameter> >> >> or >> >> @Display(type=text, length=30) >> >> for >> >> <t:parameter name="email"> >> <t:label for="email"/> >> <t:textfield t:id="email" value="person.email" size="30"/> >> </t:parameter> >> >> I think this would increase the chances of using just >> >> <t:beaneditform object="person"/> >> >> in your .tml files. Or is something like this already implemented, and I >> just overlooked it? >> >> Thanks, >> >> Christoph Jäger >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
