Thats why I ziped the files and attached them to the bug -
I am not an expert regarding what is going on in Tapestry under the
hood. But at the moment it seems that the simple procedure of passing a
static (thus not dynamic) component parameter to a bean does not work
correctly, when it is done on the jwc.
I will try to run the example on 3 to see if its the same. I would ask
the you look at the files - its a very simple example, and if you can
tell everything *is* ok, well, I guess than it is. From where I sit, it
looks wrong.
In the example files, change in the Test1.page the value of the *first*
'req' parameter to true. All 3 components will become required,
regardless of what the other 'req' parameters say. This looks very wrong
to me...
ציטוט Howard Lewis Ship:
Let's just make sure we're on the same page about beans and components.
Each component will, utlimately, have its own instance of the bean.
The bean's required property is set from the component's required
property, which itself is a parameter.
Each bean is createdon first reference; at which point the
corresponding bean's required property is set from the current value
of the component's required property. After this initialization, there
is no connection between the bean property and the component property.
If we agree on this, and you are sure there is an error, then I can
pull apart some of the code to see what's up. If this scenario, I'm
concerned that the BeanFactory for the component is being shared
between instances ... but that's highly unlikely.
On 7/15/05, Ron Piterman <[EMAIL PROTECTED]> wrote:
Hi,
in a component I have a 'required' parameter, which is passed to a
validator bean to use in a "ValidField" component:
<parameter name="required" default-value="false">
...
<bean...>
<set name="required" value="required">
If i use more than one instance of my component in a page, the bean is
not updated for each instance, thus all are either required or not,
depending on the *first* instance.
Is this a bug, or should bean properties not be minupulated through
parameters? or maybe it is the result of removing the "direction"
attribute from the parameter definition?
Cheers,
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
