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. > > 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. > > 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. > > -- > Kevin > > > On 1/17/08 2:54 PM, in article > [EMAIL PROTECTED], "Howard Lewis > > Ship" <[EMAIL PROTECTED]> wrote: > > > The question is not how similar these are when the operation is a > > success, it's about how to handle failures. > > > > TypeCoercer tends to do too much in terms of coercing objects to > > strings, resulting in hard to understand output and even worse > > exception messages on failure (i.e., user types invalid characters > > into a field). > > > > Translator is tuned to handling user input, and fits into an overall > > (and growing) framework for getting it just right. Parsing errors are > > formatted correctly for presentation to the user. > > > > ValueEncoder is setup for handling things like entities, and is used > > with Loop and Select, and elsewhere. It is much easier to contribute > > new ValueEncoders to the ValueEncoderSource than it is to contribute > > to TypeCoercer (because TypeCoercer itself is integral to the > > injection resolution system). In addition, ValueEncoder now > > automatically works with TypeCoercer unless you give it a more exact > > mapping. > > > > Sometimes its not about the simularities, it's about the differences. > > > > On Jan 17, 2008 11:33 AM, Robert Zeigler <[EMAIL PROTECTED]> wrote: > >> Hm. So, now we have /three/ systems of translating values? > >> 1) TypeCoercer > >> 2) Translator > >> 3) ValueEncoder > >> > >> This has been a source of irritation for me. In fact, I contributed > >> coercers for my app to translate to and from database entities and > >> strings. Works great! Except... I also had to specify/contribute > >> value encoders... and translators... > >> > >> I understand the difference in semantics that you're referring to, but > >> I'm with Kevin that it's really confusing and really annoying to have > >> what amounts to three type conversion systems. > >> > >> Robert > >> > >> > >> On Jan 17, 2008, at 1/1712:46 PM , Howard M. Lewis Ship (JIRA) wrote: > >> > >>> > >>> [ > >>> https://issues.apache.org/jira/browse/TAPESTRY-1929?page=com.atlassian.jira. > >>> plugin.system.issuetabpanels:all-tabpanel > >>> ] > >>> > >>> Howard M. Lewis Ship closed TAPESTRY-1929. > >>> ------------------------------------------ > >>> > >>> Resolution: Won't Fix > >>> > >>> On further reflection, I think these two interfaces really are > >>> different, despite the similarity of the methods defined. > >>> ValueEncoder is about behind-the-scenes values (such as primary keys > >>> of entity objects) whereas Translator is about user presentable > >>> values. The semantics are different, especially in respect to what > >>> happens when a client value can't be converted to a server-side > >>> object. > >>> > >>>> Replace ValueEncoder usage with Translator > >>>> ------------------------------------------ > >>>> > >>>> Key: TAPESTRY-1929 > >>>> URL: https://issues.apache.org/jira/browse/TAPESTRY-1929 > >>>> Project: Tapestry > >>>> Issue Type: Improvement > >>>> Components: Framework > >>>> Affects Versions: 5.0.6 > >>>> Reporter: Kevin Menard > >>>> Assignee: Howard M. Lewis Ship > >>>> Priority: Minor > >>>> > >>>> The Translator and ValueEncode interfaces are very similar in > >>>> definition and usage. Having to know which to use when can be a > >>>> bit of a pain for an end user. > >>>> Per a discussion on the user list, Howard recommended removing > >>>> ValueEncoder and using Translator in its stead. > >>> > >>> -- > >>> This message is automatically generated by JIRA. > >>> - > >>> You can reply to this email to add a comment to the issue online. > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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 Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
