RE: component definitions

Hi Christian,

After checking my email I realize that I may be a bit late to the party, but
I had already written the text below, so I guess it would not hurt to send
it :)

> This is in contrast with other component systems I have used,
> among them tiles (BTW, if looked at solely from the
> standpoint of presentation components, the tiles model is
> quite good. What it lacks is behavioral componentization). In
> those systems, component configurations are/can be kept in
> dedicated registries from where they can be referenced by any
> other component/page in the application. This allows reuse of
> component configurations, and possibley more effcient
> cacheing than is done today by tapestry. Of course it is
> conceivable to maintain nested registry namespaces, even down
> to the level of the individual page/component.

What you are saying essentially is that other frameworks have three
"concepts" related to components: 'configured components' that can be used
directly into the template, 'parametrized components' that have to be
configured with argument values to be used, and registries of 'confugured
components'.

I understand where you are coming from, but I think it will be a good idea
to look at what Tapestry offers as well and compare it with your suggestion
to do as described above.

Let's have an objective look at what we have suggested (using a new
component composed of the original one) and what you have been describing.

Here are the possible options and the developer's effort involved:

New Component (Tapestry pre 2.4):
---------------------------------
1 x defining a new component
	5 lines + 'component configuration', 1 line template, 1 line alias

N x using the new component
	1 line in page definition, 1 line in template

New Component (Tapestry 2.4):
-----------------------------
1 x defining a new component
	5 lines + 'component configuration', 1 line template, 1 line alias

N x using the new component
	1 line in template

Suggested solution:
-------------------
1 x defining a 'configured component'
	? lines + 'component configuration'

N x using the 'configured component'
	1 line in template


It is obvious from the above that the current Tapestry version requires
somewhat extra effort since a component definition in the page is necessary.
As pointed out a lot of times in this thread, this is to be resolved in 2.4,
where the 'new component' solution becomes __completely identical__ to the
suggested solution in the variable part of the equation, which is by far the
most prevalent one (and is the base for your complaint).


What about the difference in the 'fixed cost'? Are these 7 lines worth it?
Well, let's have a bit more detailed look at the suggested 'configured
component' solution:

Q: Can some of the parameters of a 'configured component' be 'overriden'
when it is used?
A: Perhaps, it could be implemented this way, I guess.

Q: Can more complex dependencies between the 'configured component'
parameters and the component be defined (e.g. pass one argument, and have
several settings of the component change -- something that pops up often
enough)?
A: Probably not

Q: Does a 'configured component' provide an upgrade and improvement path,
such as adding HTML formatting specific this 'configuration' or perhaps even
adding another component?
A: Definitely not

The answer of all of those questions for the 'new component' option is a
definite 'yes'.


To summarise the way I see things, the proposed 'configured components'
would definitely save some time compared to the current Tapestry release,
but they will be only very slightly better in this respect when using new
components in the next Tapestry release. In addition, they are much less
powerful and extensible than the 'new component' approach. In other words,
you gain little, lose a lot.

Do they still make sense under these circumstances?


Again, I understand that this may look weird initially if you are coming
from a different mindset. I hope my description makes sense.

This is my personal opinion, but I have tried to be objective here. Please
feel free to correct me if you see flaws in the logic.

Finally, there are some things that could be improved in Tapestry to cut
down on those "7 extra lines of code". For example, the template may not be
needed in a situation like that. Whether this makes sense and when it could
be done has to be decided, however.

-mb


-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of
Christian Sell
Sent: Thursday, December 19, 2002 3:35 PM
To: [email protected]
Subject: [Tapestry-developer] component definitions


Hello,

I would like to bring up again the point about component
configurations. As far as I remember there was no final
answer.

In Tapestry component configurations have to be repeated for
every page and component which embeds the component.
Moreover, all components have to be assigned type aliases in
the application file (I am not familiar with the workings of
libraries yet).

This is in contrast with other component systems I have used,
among them tiles (BTW, if looked at solely from the
standpoint of presentation components, the tiles model is
quite good. What it lacks is behavioral componentization). In
those systems, component configurations are/can be kept in
dedicated registries from where they can be referenced by any
other component/page in the application. This allows reuse of
component configurations, and possibley more effcient
cacheing than is done today by tapestry. Of course it is
conceivable to maintain nested registry namespaces, even down
to the level of the individual page/component.

I also dont quite see the need for the type alias definition.
Why not reference components by the complete path to their
location, as is done for java classes? BTW, I also see
WebOGNL doing it this way (e.g. component
id="/path/path/name").

Does anyone else think it would at least theoretically make
sense/be possible to introduce these items into tapestry?

thanks,
Christian Sell


-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now!  Before the Holidays pass you by.
T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/
_______________________________________________
Tapestry-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer



-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now!  Before the Holidays pass you by.
T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/