RE: Recommended way to clean up a component?

Good points all. Thanks for clearing that up.
 
To sum up: Pages are easier to work with because the have convenience
methods to improve their usability. To implement the same sorts of
convenience methods in Components would incur a performance penalty.
 
I think it would be useful to have a subclass of BaseComponent (like the one
you mention that adds itself automatically as a PageDetachListener) as part
of the Tapestry distribution. The hardest thing about it is coming up with a
good name for it. I call my class "CachingComponent" but I'm not too happy
with that...

 -----Original Message-----
From: Mind Bridge [mailto:[email protected]]
Sent: Monday, November 11, 2002 6:17 PM
To: [email protected]
Subject: RE: [Tapestry-developer] Recommended way to clean up a component?



Hi Phil, 


Please note that _everything_ that you can do in a component, you can do in
a page as well. After all, page extends component. For example, you _can_
use the listener approach within a page if you want to. 


The differences occur mostly because the page provides some additional tools
to make things easy. (e.g. the detach() and initialize() methods) Some of
these tools can be provided efficiently within the page, but would be
inefficient to provide within the components. For others there is no point,
since you can always do getPage().getBlah(), and it makes no sense to load
the component interface unnecessarily. 


Basically, if I understand correctly, Howard's goal was to create a
framework that can be very efficient if necessary. For that reason he has
abstained from building in inefficiencies as much as possible, but has made
the framework very extensible to compensate for that if necessary. 


For example, it is trivial for the developer to create a subclass of
BaseComponent that registers itself as a PageDetachListener automatically
and invokes the overridable methods detach() and initialize(). That class
can then be used instead of BaseComponent in his application. This achieves
precisely what you ask for, but it does not require all components to
register themselves as a listener (in the same way BaseComponent extends
AbstractComponent to add the capability of using a template; the most
performance critical components are based on AbstractComponent, however). 


Taken together, these two things probably discourage component development.
Maybe there is a connection between this and dearth of Tapestry component
contribs? 


Not at all. At our company we have a long list of "standard" components that
we have developed and use. Some of them are simple, others comprise of tens
of other components and depend on thousands of lines of code. Obviously they
have been significantly extended and improved over time, but the way to use
them has remained exactly the same -- a few lines to insert them and bind to
them. The code that uses them has not changed at all. This is, I think, a
most powerful testament of the Tapestry approach. 


Most of our components cannot be contributed to the public -- they depend
heavily on the our in-house technology. Others can, and we have started
doing that. 


The problem of the relative lack of publicly contributed components is not
in Tapestry's techology. It is in the relatively clumsy current mechanism to
contribute the components, which indirectly discourages people from sharing.
As you have probably noticed, this problem is being addressed :-). 


Sorry, I did not mean to turn this into advocacy (I know that is not
needed), but could not help myself at one point :-). I do think it is a good
idea to look for ways to improve the framework and make it more
user-friendly, but I do not think we should lose perspective. I hope what
I've written makes sense, and would give rise to further suggestions. 


Best regards, 


-mb 



 Phil Surette <[email protected]> wrote: 


No problem (about not agreeing). I don't quite agree with you either wrt the
impact on performance, but I think we're splitting hairs there. As for
initialize... can't find the method you're referring to, maybe it's
something I should be using ;)
 
I do think it's a serious problem with Tapestry that Pages and Components
are so different. As I recall from when I joined this list, someone gave up
on Tapestry for just that reason. Anyone used to the AWT, for instance, will
expect the root component (the IPage in Tapestry) to be like  other
components. 
 
As it is, you have to learn to do a number of the same things twice: the
Page way, and the Component way. This also makes it more painful to extract
components from Pages. Taken together, these two things probably discourage
component development. Maybe there is a connection between this and dearth
of Tapestry component contribs?

 




  _____  

Do you Yahoo!?
U2 on  <http://rd.yahoo.com/launch/mailsig/*http://launch.yahoo.com/u2>
LAUNCH - Exclusive medley & videos from Greatest Hits CD