[
https://issues.apache.org/jira/browse/TAP5-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159224#comment-15159224
]
Barry Books commented on TAP5-2099:
-----------------------------------
I guess it depends on what you mean by stored. In the case above
rowsperpage = 10;
I'm guessing the 10 is stored as some final Integer in the JVM. That object is
then assigned to the "field" which is not a field at all but the appears to
contain an int. Before this assignment the "field" contained an object that
appears to be an int but was really a Literal binding. If you look the Symbol
binding is really a String provided by SymbolSource but the field in an int so
even the type coercer is involved here.
The binding is not responsible for storing the object but it can. In the
example above the the value is not really the String in
ComponentParameterConstants it's calculated on the fly from the expression
passed to the factory and the SymbolSource. If you look at the provided
LiteralBinding
http://tapestry.apache.org/current/apidocs/src-html/org/apache/tapestry5/internal/bindings/LiteralBinding.html#line.27
it does store the value and the SymbolBindingFactory just gets the symbol value
and returns a new LiteralBinding.
There is quite a bit going on behind the scenes to make it appear that a
component field is just a field and I'm not sure I understand it all either.
The good news is the Binding interface is pretty simple but the documentation
is a little bit too simple. The Binding interface provides two way
communication back to the original object storage so that two way binding can
be implemented. The get method provides an object that may be transformed from
the original storage even calculated on the fly. For example you could create a
random: binding that returns a random number. I created a selector: binding
that created a JQuery selector to the element that is currently being rendered.
The set method allows setting the original storage to a new value. The
documentation also says most are readonly and the AbstractBinding which most
extend throws and exception on set. I think that should say most bindings are
one way. Perhaps some should throw an exception on set but personally I don't
think a binding should cause a field to become readonly just because it's not
interested in observing the fields changes.
Hope that helps
> Update parameters bound to literal: or symbol: from a mixin
> -----------------------------------------------------------
>
> Key: TAP5-2099
> URL: https://issues.apache.org/jira/browse/TAP5-2099
> Project: Tapestry 5
> Issue Type: Improvement
> Affects Versions: 5.3.6, 5.4
> Reporter: Lance
> Labels: patch
> Attachments: TAP52099-1.patch
>
>
> Currently, I cannot update a component component parameter that is
> initialized with a literal: or symbol: binding from a mixin. If I try to
> @BindParameter the param and change it's value, I get a "Binding %s is
> read-only" exception (originating from AbstractBinding).
> I propose that literal and symbol bindings are sourced from a PerThreadValue
> that can be updated by a mixin.
> My original need for this was to create a "SinglePage" mixin for the Grid
> component which would set the rowsPerPage parameter to Integer.MAX_VALUE. I
> can't currently do this because by default, the parameter is a symbol:
> binding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
