[
https://issues.apache.org/jira/browse/TAPESTRY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Howard M. Lewis Ship closed TAPESTRY-1623.
------------------------------------------
Resolution: Won't Fix
Assignee: Howard M. Lewis Ship
I'm "morally" opposed to this, as it won't be type safe and each component that
uses this will either have to include casts or its own usage of the TypeCoercer.
Perhaps we could come up with a better informal, cross-page, cross-component
communication channel. I just find Block parameters to be clumsy. Every time
we move further away from JavaBeans properties, we introduce yet another
difference between render time and form submit time and that's going to bite us
and our users.
> Access to block parameters
> --------------------------
>
> Key: TAPESTRY-1623
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1623
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Dan Adams
> Assignee: Howard M. Lewis Ship
>
> One of the features I used in T4 which made it very powerful was the ability
> to pass informal parameters to a Block and then get them from within the
> block. BeanEditForm demonstrates making a context available to blocks via an
> environmental interface but this seems like too much overhead for less
> formally defined situations. Perhaps it could look something like this:
> <t:delegate to="block:myblock" foo="bar" />
> <t:block id="myblock">
> ${context.parameters.bar}
> </t:block>
> in the class:
> @Environment
> private BlockContext context;
> the interface:
> public interface BlockContext {
> Map<String, Object> getParameters();
> }
> This would also required being able to do more OGNL-like expressions.
--
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]
