[ 
https://issues.apache.org/jira/browse/TAPESTRY-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566888#action_12566888
 ] 

Howard M. Lewis Ship commented on TAPESTRY-1842:
------------------------------------------------

Tapestry now uses ValueEncoders to convert server-side values to client-side 
strings (including in URLs).  The default ValueEncoder works with the 
TypeCoercer, but contributing in overrides for each individual entity class is 
reasonable, and the ValueEncoderSource service is far less critical path than 
TypeCoercer, meaning you don't have these cruel lifecycle issues to deal with.

> Allow coercions to handle multiple or non-concrete types
> --------------------------------------------------------
>
>                 Key: TAPESTRY-1842
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-1842
>             Project: Tapestry
>          Issue Type: Improvement
>          Components: tapestry-ioc
>    Affects Versions: 5.0.6
>            Reporter: Dan Adams
>            Priority: Critical
>
> I was working on implementing something similar to TAPESTRY-1653 and ran into 
> a problem. In our system, all hibernate entities implement an interface. I 
> wanted to create a coercion that would handle going from String -> entity and 
> from entity -> String. The problem with this was that, with the way coercion 
> currently works, you have to add coercions for every concrete enttiy type 
> rather than having one coercion that knows how to load any entity from the 
> Session by id. This introduces a chicken-and-egg problem where in the 
> coercion depends on the Hibernation Configuration being created already. This 
> causes IoC to kick out because there is a dependency loop. Either I need to 
> find a way around the dependency loop (which I can't see how) and register 
> coercions for each specific entity type at start-up or register one coercion 
> for all entities.
> Obviously this introduces some complications with the coercion logic but it 
> appears to be very much a necessary ability. I'm not opposed to implementing 
> it others can chime in if they have opinions about this.

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

Reply via email to