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 LAUNCH - Exclusive medley & videos from Greatest Hits CD
