Two notes: 1) I've moved the annotations out of tapestry proper, into a tiny additional JAR containing just the annotations. This makes it more palatable to use them outside of the web tier without dragging in an extra MB or so of dependencies.
2) The mechanism by which we go from beans and properties to editors is actually documented (!) and extensible. There's an extensible chain of command, so if you have an external approach to making this decisions (such as an XML file) you still have the hooks to get in and make that happen. See the DataTypeAnalyzer interface On 10/27/07, Christoph Jaeger <[EMAIL PROTECTED]> wrote: > > 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] > > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind
