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. >> 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]
