You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Anton Mezerny <an...@gmail.com> on 2010/11/07 19:29:15 UTC
Some questions about Tapestry components source code
Hi all,
I've spent some time diving into the tapestry's sources (particulary
BeanEditor and all code which is linked to it).
I use Tapestry 5.2.2.
I found some interesting things, that I can't explain:
1)in PropertyEditor.java there is some code, but it is not used anywhere (I
did't find any usages). Am I missing something?
@Inject
@Core
private BeanBlockSource defaultBeanBlockSource;
BeanBlockSource defaultBeanBlockSource()
{
return defaultBeanBlockSource;
}
2)Why form component doesn't have informal parameters support? There is no
according annotation above the class definition (hovewer it works well with
informal parameters, except IDE errors)
3)There is one inconvenience in the loop component - it has a parameter called
'value' which clashes with different html elements attributes of the same
name,
for example I can't write this simple construction because I can't specify
a value attribute of 'option' tag, so I need to nest option tag inside loop
component:
<option t:type="loop" source="myList"
value="myValue">${myValue.label}</option>
Even if I specify current value of the loop like t:value="myValue" and
client value as just value="myValue.id", then client value (value="myValue.id")
is not rendered. Of course, it does not matter much, but creates some
inconvenience.
As I understand, it's now impossible to change name of the current loop
value parameter, due to backward compatibility reason, but maybe it is
possible to define it deprecated and provide also new parameter named, for
example
'currentValue' or 'var' with the same functionality.
Thanks a lot. It's just my thoughts about how to make great framework even
better.
Anton
Re: Some questions about Tapestry components source code
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 08 Nov 2010 10:19:09 -0200, Anton Mezerny
<an...@gmail.com> wrote:
> Didn't understand how it works. Does Tapestry make assignment from
> defaultBeanBlockSource to beanBlockSource field (which is annotated with
> @Parameter) if it is empty?
Tapestry will invoke the defaultBeanBlockSource() and use the return value
as the initial one for the beanBlockSource parameter if it wasn't bound or
null was passed to it.
> There is no any usages of defaultBeanBlockSource
> or getDefaultBeanBlockSource in component code. This implicit logic is
> very unusual for me.
Tapestry and Tapestry-IoC have a lot of implicit logic, also known as
convention over configuration.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Some questions about Tapestry components source code
Posted by Anton Mezerny <an...@gmail.com>.
>
> This is an example of providing a default value for a component parameter.
> One way is using the value attribute of @Parameter. Another one is to write
> a method named default<parameter name>. In this particular case, it's a
> default value for the beanBlockSource parameter.
>
Didn't understand how it works. Does Tapestry make assignment from
defaultBeanBlockSource to beanBlockSource field (which is annotated with
@Parameter) if it is empty? There is no any usages of defaultBeanBlockSource
or getDefaultBeanBlockSource in component code. This implicit logic is very
unusual for me.
Also I have some question about debugging in Tapestry - as usual all fields
in components and pages are null, but there are some conduits, that
corresponds to ordinary fields. Can I use this conduits to get actual values
of my fields? In IDEA I can't find in conduit anything, that corresponds to
my actual fields. Is there any ability to use normal debug in Tapestry,
maybe some configuration parameter?
2010/11/7 Thiago H. de Paula Figueiredo <th...@gmail.com>
> On Sun, 07 Nov 2010 16:29:15 -0200, Anton Mezerny <an...@gmail.com>
> wrote:
>
> Hi all,
>>
>
> Hi!
>
>
> I've spent some time diving into the tapestry's sources (particulary
>> BeanEditor and all code which is linked to it).
>>
>
> I learned a lot from reading Tapestry sources. They're very well written
> and architected, use a lot of design patterns and some parts are just
> awesome. :)
>
>
> I found some interesting things, that I can't explain:
>> 1)in PropertyEditor.java there is some code, but it is not used anywhere
>> (I
>> did't find any usages). Am I missing something?
>> @Inject
>> @Core
>> private BeanBlockSource defaultBeanBlockSource;
>>
>>
>> BeanBlockSource defaultBeanBlockSource()
>> {
>> return defaultBeanBlockSource;
>> }
>>
>
> Good question! I didn't get this the same time I saw it. :P
> This is an example of providing a default value for a component parameter.
> One way is using the value attribute of @Parameter. Another one is to write
> a method named default<parameter name>. In this particular case, it's a
> default value for the beanBlockSource parameter.
>
>
> 2)Why form component doesn't have informal parameters support? There is no
>> according annotation above the class definition (hovewer it works well with
>> informal parameters, except IDE errors)
>>
>
> I think there's a JIRA asking for Form to support informal parameters. If
> there isn't, please post one.
>
>
> 3)There is one inconvenience in the loop component - it has a parameter
>> called 'value' which clashes with different html elements attributes of the
>> same
>> name, for example I can't write this simple construction because I can't
>> specify a value attribute of 'option' tag, so I need to nest option tag
>> inside loop component:
>>
>> <option t:type="loop" source="myList"
>> value="myValue">${myValue.label}</option>
>>
>
> I agree this is inconvenient, but renaming the parameter would break
> backward compatibility pretty hard.
> I love invisible instrumentation and I use it almost all the time, but you
> can also use the other syntax:
>
> <t:loop t:type="loop" source="myList" t:value="myValue">
> <option value="${myValue.value}">${myValue.label}</option>
> </t:loop>
>
>
> As I understand, it's now impossible to change name of the current loop
>> value parameter, due to backward compatibility reason, but maybe it is
>> possible to define it deprecated and provide also new parameter named, for
>> example 'currentValue' or 'var' with the same functionality.
>>
>
> This wouldn't work, as informal parameters are attributes whose name don't
> match a parameter name. We would need to remove the value parameter. Another
> option is to create another component.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Some questions about Tapestry components source code
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Sun, 07 Nov 2010 16:29:15 -0200, Anton Mezerny
<an...@gmail.com> wrote:
> Hi all,
Hi!
> I've spent some time diving into the tapestry's sources (particulary
> BeanEditor and all code which is linked to it).
I learned a lot from reading Tapestry sources. They're very well written
and architected, use a lot of design patterns and some parts are just
awesome. :)
> I found some interesting things, that I can't explain:
> 1)in PropertyEditor.java there is some code, but it is not used anywhere
> (I
> did't find any usages). Am I missing something?
> @Inject
> @Core
> private BeanBlockSource defaultBeanBlockSource;
>
>
> BeanBlockSource defaultBeanBlockSource()
> {
> return defaultBeanBlockSource;
> }
Good question! I didn't get this the same time I saw it. :P
This is an example of providing a default value for a component parameter.
One way is using the value attribute of @Parameter. Another one is to
write a method named default<parameter name>. In this particular case,
it's a default value for the beanBlockSource parameter.
> 2)Why form component doesn't have informal parameters support? There is
> no according annotation above the class definition (hovewer it works
> well with informal parameters, except IDE errors)
I think there's a JIRA asking for Form to support informal parameters. If
there isn't, please post one.
> 3)There is one inconvenience in the loop component - it has a parameter
> called 'value' which clashes with different html elements attributes of
> the same
> name, for example I can't write this simple construction because I
> can't specify a value attribute of 'option' tag, so I need to nest
> option tag inside loop component:
>
> <option t:type="loop" source="myList"
> value="myValue">${myValue.label}</option>
I agree this is inconvenient, but renaming the parameter would break
backward compatibility pretty hard.
I love invisible instrumentation and I use it almost all the time, but you
can also use the other syntax:
<t:loop t:type="loop" source="myList" t:value="myValue">
<option value="${myValue.value}">${myValue.label}</option>
</t:loop>
> As I understand, it's now impossible to change name of the current loop
> value parameter, due to backward compatibility reason, but maybe it is
> possible to define it deprecated and provide also new parameter named,
> for example 'currentValue' or 'var' with the same functionality.
This wouldn't work, as informal parameters are attributes whose name don't
match a parameter name. We would need to remove the value parameter.
Another option is to create another component.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org