On Jan 18, 2008 12:51 PM, Kevin Menard <[EMAIL PROTECTED]> wrote: > On 1/18/08 2:57 PM, in article > [EMAIL PROTECTED], "Howard Lewis > Ship" <[EMAIL PROTECTED]> wrote: > > > On Jan 18, 2008 6:34 AM, Kevin Menard <[EMAIL PROTECTED]> wrote: > >> While I can appreciate that, all of this should be transparent to the > >> developer. Otherwise, we have a whole set of gotchas that just have to be > >> memorized. It's great that there's component documentation, but I > >> shouldn't > >> have to look at it all the time because some components might use > >> Translators and others might use ValueEncoders and there's no clear rule > >> about which is used when. > > > > I've been thinking about that; in many cases, Tapestry can come up > > with a reasonable default. > > I may also create coercions between ValueEncoder and PrimaryKeyEncoder. > > I can agree that this will become less of an issue as more types are handled > out of the box. Of course, there will always be cases where a custom type > will have to be supplied. > > >> > >> It's not a major thing, but it is a gotcha . . . a blemish on the > >> framework. > >> The most intuitive solution should be the default solution. None of the > >> following is intuitive, unfortunately. > > > > I think that's an overreaction. > > I'll concede that I may be overly sensitive to usability issues. But, this > is real user feedback. Everytime I end up getting tripped up by this, I > curse Tapestry. Of course, one could make the argument that it's my own > silly fault, but they all look like ducks to me. > > For what it's worth, I feel the same way when most components use "value" as > the primary binding parameter and others use "object". I really don't want > to have to put that much thought into it, especially when I won't catch the > error until runtime.
That's a good point; I think I use value with field control element components, as there is an implicit relationship to the @value attribute of the HTML <input> element. I don't think _object gets used so often, usually in terms of BeanEditor & friends, where an entire object is passed in. Hopefully those make sense, but I'm open to more careful study on this. I think at this point, I would introduce (from T4) component aliases as the mechanism for renaming existing component parameters. Outside of the internals of T5, I'm striving to stabilize things. I have been guilty of a little last-minute tinkering, mostly moving interfaces to "correct" packages and correcting the misleading names of certain interfaces. > > >> If the issue really is error reporting, perhaps the internal exception > >> could > >> have a discriminator value based on context? That seems like it would > >> address both sides. > > > > Separation of concerns, buddy. The fact that you are jamming two > > similar but ultimately > > unrelated behaviors together and then having to pass extra context to tell > > it > > what to do in a given situation is more problematic to me than having > > the two different interfaces. > > They're unrelated by context, but serve the same core function. It strikes > me as a case of framework leakage. The extra context could be handled > internally by Tapestry or by a component author, shielded from most > developers. This shouldn't be any more problematic for that group, because > as is, the context is already defined by the framework and any component > authors via the declared types. I'm advocating that the declared type could > be a single common interface and that the framework and/or component author > could do the right thing based on context internal to their respective chunk > of code. > > -- > Kevin > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
