[
https://issues.apache.org/jira/browse/TAPESTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620123#action_12620123
]
Robert Zeigler commented on TAPESTRY-2491:
------------------------------------------
*shrug*
Pre-loading from PKE is nice... I don't see, however, why it couldn't be
incorporated directly into ValueEncoder.
My real gripe is that there are simply too many "type conversion" systems in T5.
We have:
Translators
ValueEncoders
PrimaryKeyEncoders
TypeCoercers
That's four different systems. Granted, each does something /slightly/
different:
Translator -> handles text input /by the user/, to be converted to some
non-text type.
ValueEncoders -> handle storing a string representation of an object into a
url for "pretty" urls
PrimaryKeyEncoders -> specifically store the primary key of an object into a
form, and retrieve the value again, allowing for preloading of multiple keys.
TypeCoercers -> convert to and from parameter types within the framework.
But there's so much overlap between them... I like t5... but this, to me, is a
glaring wart of over-complexity.
In any event, if the 4 systems are all here to stay, then my original
description of the issue (allowing for configurable pk encoders, just like
value encoders, so module developers can make them work "like magic" as we do
with value encoders) is still valid.
> Components which use PrimaryKeyEncoder should be changed to use ValueEncoder,
> and PrimaryKeyEncoder should be eliminated.
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-2491
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2491
> Project: Tapestry
> Issue Type: Improvement
> Affects Versions: 5.0.14
> Environment: any
> Reporter: Robert Zeigler
> Priority: Minor
>
> While working on an application, I noticed that my objects were being
> serialized "weird" into a form by the loop component. I realized that I
> hadn't provided the primary key encoder, and once I did things worked as
> expected. That got me to thinking that it would be nice if the Loop
> component, and other components that rely on PrimaryKeyEncoders, could check
> to see if there is an encoder available for the value-type, if none is
> explicitly bound by the user. That way, module-authors could provide
> PrimaryKeyEncoders that makes things work "like magic".
> For example, tapestry-hibernate could contribute PrimaryKeyEncoders for each
> entity type so that the objects are automatically, and properly, encoded into
> forms.
--
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]
