You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Robert Zeigler (JIRA)" <de...@tapestry.apache.org> on 2008/06/28 19:53:45 UTC
[jira] Created: (TAPESTRY-2491) Components which use
PrimaryKeyEncoder should be able to look them up from a service
Components which use PrimaryKeyEncoder should be able to look them up from a service
------------------------------------------------------------------------------------
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-2491) Components which use
PrimaryKeyEncoder should be changed to use ValueEncoder, and
PrimaryKeyEncoder should be eliminated.
Posted by "Robert Zeigler (JIRA)" <de...@tapestry.apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-2491) Components which use
PrimaryKeyEncoder should be changed to use ValueEncoder, and
PrimaryKeyEncoder should be eliminated.
Posted by "Kevin Menard (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620977#action_12620977 ]
Kevin Menard commented on TAPESTRY-2491:
----------------------------------------
I had voiced similar concerns in the past. It can just be downright confusing. Just earlier today I was trying to help someone (that's been using the framework for a while) on IRC understand the differences, which are quite subtle.
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-2491) Components which use
PrimaryKeyEncoder should be changed to use ValueEncoder, and
PrimaryKeyEncoder should be eliminated.
Posted by "Robert Zeigler (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler updated TAPESTRY-2491:
-------------------------------------
Summary: Components which use PrimaryKeyEncoder should be changed to use ValueEncoder, and PrimaryKeyEncoder should be eliminated. (was: Components which use PrimaryKeyEncoder should be able to look them up from a service)
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAP5-165) Components which use PrimaryKeyEncoder
should be changed to use ValueEncoder, and PrimaryKeyEncoder should be
eliminated.
Posted by "Robert Zeigler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler updated TAP5-165:
--------------------------------
Affects Version/s: (was: 5.0.15)
5.0.16
> Components which use PrimaryKeyEncoder should be changed to use ValueEncoder, and PrimaryKeyEncoder should be eliminated.
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-165
> URL: https://issues.apache.org/jira/browse/TAP5-165
> Project: Tapestry 5
> Issue Type: Improvement
> Affects Versions: 5.0.16
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-2491) Components which use
PrimaryKeyEncoder should be changed to use ValueEncoder, and
PrimaryKeyEncoder should be eliminated.
Posted by "Robert Zeigler (JIRA)" <de...@tapestry.apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-165) Components which use PrimaryKeyEncoder
should be changed to use ValueEncoder, and PrimaryKeyEncoder should be
eliminated.
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644347#action_12644347 ]
Howard M. Lewis Ship commented on TAP5-165:
-------------------------------------------
About your last example: use the following:
void onActionFromSomeAction(EventContext context) {
resources.triggerContextEvent("SomeComponentEvent",context,null);
}
> Components which use PrimaryKeyEncoder should be changed to use ValueEncoder, and PrimaryKeyEncoder should be eliminated.
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-165
> URL: https://issues.apache.org/jira/browse/TAP5-165
> Project: Tapestry 5
> Issue Type: Improvement
> Affects Versions: 5.0.16
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-2491) Components which use
PrimaryKeyEncoder should be able to look them up from a service
Posted by "Robert Zeigler (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611658#action_12611658 ]
Robert Zeigler commented on TAPESTRY-2491:
------------------------------------------
After thinking about this some more, it occurred to me that the right solution is probably to nix PrimaryKeyEncoder entirely.
Instead, Loop and grid, like many other components, should be using ValueEncoders to do the job. Consider the implementation of the hibernate value encoders: they are effectively PrimaryKeyEncoders. The main difference between the two interfaces is that PrimaryKeyEncoder is slightly more lenient: the "client" value merely has to be serializable, whereas the ValueEncoder must encode to a string. But the key is ultimately going to be stored on the client as a string, so there seems to be no reason why you wouldn't just use ValueEncoder. This would get rid of one redundant interface (PrimaryKeyEncoder) /and/ allow Loop, Grid, etc. to tie into the very nice set of services available for looking up ValueEncoders, so that you can contribute your value encoder(s), and have stuff "just work".
> Components which use PrimaryKeyEncoder should be able to look them up from a service
> ------------------------------------------------------------------------------------
>
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-2491) Components which use
PrimaryKeyEncoder should be changed to use ValueEncoder, and
PrimaryKeyEncoder should be eliminated.
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620805#action_12620805 ]
Howard M. Lewis Ship commented on TAPESTRY-2491:
------------------------------------------------
But in many cases they are "layered". Most of the time a ValueEncoder is just a wrapper around TypeCoercer. Likewise, I think we can automatically generate PKEs from ValueEncoders and do it invisibly.
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-2491) Components which use
PrimaryKeyEncoder should be changed to use ValueEncoder, and
PrimaryKeyEncoder should be eliminated.
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620090#action_12620090 ]
Howard M. Lewis Ship commented on TAPESTRY-2491:
------------------------------------------------
Yes but, the point of PrimaryKeyEncoder is two fold:
1) The primary key will be serialized, so the encoded value doesn't have to be a string (ValueEncoder is full encoding objects into URLs or DOM attributes).
2) PKE includes the ability to ask for a pre-load of multiple keys, which is very important scalability-wise. One database query, not N.
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org