You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> on 2008/01/17 19:46:34 UTC
[jira] Closed: (TAPESTRY-1929) Replace ValueEncoder usage with
Translator
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Closed: (TAPESTRY-1929) Replace ValueEncoder usage with Translator
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Jan 18, 2008 12:51 PM, Kevin Menard <km...@servprise.com> wrote:
> On 1/18/08 2:57 PM, in article
> ecd0e3310801181157n43a81862qe13a5a73115873d@mail.gmail.com, "Howard Lewis
> Ship" <hl...@gmail.com> wrote:
>
> > On Jan 18, 2008 6:34 AM, Kevin Menard <km...@servprise.com> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Closed: (TAPESTRY-1929) Replace ValueEncoder usage
with Translator
Posted by Kevin Menard <km...@servprise.com>.
On 1/18/08 2:57 PM, in article
ecd0e3310801181157n43a81862qe13a5a73115873d@mail.gmail.com, "Howard Lewis
Ship" <hl...@gmail.com> wrote:
> On Jan 18, 2008 6:34 AM, Kevin Menard <km...@servprise.com> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Closed: (TAPESTRY-1929) Replace ValueEncoder usage with Translator
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Jan 18, 2008 6:34 AM, Kevin Menard <km...@servprise.com> 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
> ecd0e3310801171154w2b6e0a29h4cc2770d4ee366ef@mail.gmail.com, "Howard Lewis
>
> Ship" <hl...@gmail.com> 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 <ro...@scazdl.org> 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: dev-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Closed: (TAPESTRY-1929) Replace ValueEncoder usage
with Translator
Posted by Kevin Menard <km...@servprise.com>.
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.
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.
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.
--
Kevin
On 1/17/08 2:54 PM, in article
ecd0e3310801171154w2b6e0a29h4cc2770d4ee366ef@mail.gmail.com, "Howard Lewis
Ship" <hl...@gmail.com> 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 <ro...@scazdl.org> 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: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Closed: (TAPESTRY-1929) Replace ValueEncoder usage with Translator
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <ro...@scazdl.org> 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Closed: (TAPESTRY-1929) Replace ValueEncoder usage with Translator
Posted by Robert Zeigler <ro...@scazdl.org>.
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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org