[
https://issues.apache.org/jira/browse/TAPESTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621000#action_12621000
]
Robert Zeigler commented on TAPESTRY-2491:
------------------------------------------
The evidence of the overcomplexity is that the framework, itself, trips up on
it, especially in regards to layering.
Take the following rather trivial example:
public class SomeComponent {
@Parameter
private Object[] parameters;
@Component(parameters="context=inherit:context")
private ActionLink someAction;
@Inject
private ComponentResources resources;
void onActionFromSomeAction(Object[] parameters) {
resources.triggerEvent("SomeComponentEvent",parameters,null);
}
}
Is there a problem with that code? Try writing an event handler for
SomeComponentEvent which takes a hibernate entity, and then try passing in a
hibernate entity to SomeComponent.
You'll wind up with an exception: no coercion found from string to type xxx
(where xxx is the type of your hibernate entity).
What happens is that someAction uses ValueEncoder to encode the hibernate
entity to string.
But because onAction takes the parameters as an object array, they aren't
decoded.
Then the event handling code will find the SomeComponentEventHandler, and try
to convert the parameters to match the method signature of the handler.
But the event handling code uses TypeCoercer directly, rather than
ValueEncoders.
So you've got a parameter that is encoded with ValueEncoder, but decoded with
TypeCoercer.
And this is what I mean about overly complex.
I can file a separate jira for the specific instance described above, but the
bigger issue is having 4 type conversion systems in the first place.
This isn't the first place where this same issue (value encoded by one type
coercion system are decoded by another one elsewhere) has come up, because I
reported exactly this issue with the form component back in Feb. in
TAPESTRY-2177.
If T5 is going to be competitive against frameworks built in dynamic languages,
it absolutely has to handle type coercion so seamlessly that the user /never/
has to think about it. Right now, there's way too much thinking involved,
starting with having 4 ways of converting types.
> 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]
