One of the core hurdles in Tapestry acceptance is the "steep learning curve" of Tapestry. Or unlearning curve. Whatever.
One of the real design flaws in Tapestry is the fact that there is just so much API. Because you extend base classes, any code you write is immersed in the API you pick up from the base classes. Further, those base classes are often a mix of methods intended for use only by the framework (and occasionally mis-used by Tapestry developers) and "seemed-like-a-good-idea-at-the-time" methods (such as initialize(), and getProperty(), and many more). The tack I've been taking with current and future work is limit the API as much as possible until usecases for more API arrive. Less API means less to learn. To be honest, I'm hamstrung by the need to maintain backwards compatibility. I'd really like to divide things up into API (a limited amount of stuff visible to the user), SPI (service provider interfaces -- stable APIs used when extending Tapestry) and internals (not to be used except by the Tapestry implementation). The design of Tapestry (on top of HiveMind) means that virtually any piece of the system can easily be overridden in a couple of different ways. Further, the design encourages composition over inheritance, because over the last 20 years, I've found composition to be a much more powerful approach to building complex systems. You could quite easily encompass the existing asset service and delegate behavior to it. Rob is right, the service you are designing is not an extension of the asset service, it is a different service with *some* overlap with the existing asset service. You could, in fact, create a new IAsset implementation that included the additional information you need, and passed it to your scalableAsset service. In summary, the way to get things accomplished in an open source project is not to pound on the front door and shout "THIS IS BROKEN". That will not get you any traction. Open source communities are about communication and interaction -- you need to engage the users and developers of Tapestry. In some cases, you will find existing approaches that fit your needs. In others you will guide developers to seeing fixable limitations of the project (be it Tapestry or anything else); That is the natural way. On 10/21/05, Alexandr Kundirenko <[EMAIL PROTECTED]> wrote: > > RP> I am not a member of the tapestry team, but I will respond anyhow. > > RP> FIRST PROBLEM > RP> your posting belongs definetly to the users list and not the dev list. > > Problems are just a sample. > > RP> SECOND PROBLEM > RP> you choose the wrong way to do what you need to do, got alot of problems > RP> and did not stop and think - maybe its the wrong way. > RP> If you want to go to europe from the states, don't choose brazil as your > RP> stop. its a longer and much more expensive way. Try to see what the > RP> travel agancies offer, then decide... > > May be. But I can give you more examples. > > RP> WHAT DID YOU DO WRONG > RP> basically you are right. asset service can not be extended. it should > RP> not. no service should. > RP> instead you should provide your own service - > RP> just create an image service. you can use arbitrary parameters, > RP> construct your own ILink and later interpret it and deliver the results. > RP> Take the asset service as an *example*, not a base class. > > This is main idea of the post. Why I should create new class if I need > to change only few lines of code? I disagree with you. > > RP> The rest is just shouting, so have nice time shouting... > RP> good luck... > > RP> Cheers, > RP> Ron > > RP> PS - I must disagree with your critic : extending tapestry is very easy. > RP> On the early alpha days I used to complain alot about having to learn > RP> hivemind to use tapestry. Now I *know* its a real bless with a briliant > RP> design. It is however not for extending in OO manner, but what one would > RP> rather call "replacing" - many bricks of the wall can be replaced and > RP> thus customize how tapestry works. BUT YOU HAVE TO DO IT RIGHT. > > > > > RP> ????? Alexandr Kundirenko: > >> Hello Tapestry Team, > >> > >> I'm finishing project on T4 and have a lot of problems when I need to > >> extend Tapestry framework. Here is one of my use cases: > >> > >> I want to extend asset service which will dynamically resize images > >> before showing them. > >> I suppose to make ResizableImage component and use it like this: > >> > >> <span jwcid="@ResizableImage" image="ognl:myAsset" width="400" > >> height="300"/> > >> > >> FIRST PROBLEM > >> I can't provide these width/height parameters to my service, > >> because ILink instance in unmodifiable - it has not addParameter(...) > >> method. I can't extend its default impl. because of private members. So I > >> have to copy code from EngineServiceLink and add my methods. Ugly way. > >> > >> SECOND PROBLEM > >> Now I wan't to construct my modifiable > >> ILink instance. I can't extend LinkFactory impl. because of private > >> members. I have to copy code from it and change only *one* line. > >> Terrible. > >> > >> THIRD PROBLEM > >> Ok. Now I can provide parameters to my custom service. But I can't > >> extend AssetService. I can't override it's service() method because of > >> private members. I have to copy/paste again! > >> > >> CONCLUSION > >> We can use contributions, this is great. > >> But we cannot effectively extend existing services. > >> Here are links to other samples: > >> > >> http://issues.apache.org/jira/browse/TAPESTRY-396 > >> http://issues.apache.org/jira/browse/TAPESTRY-621 > >> http://issues.apache.org/jira/browse/TAPESTRY-716 > >> http://issues.apache.org/jira/browse/TAPESTRY-689 > >> http://issues.apache.org/jira/browse/TAPESTRY-442 > >> > >> QUESTION > >> Do you plan to refactor tapestry classes to make them really extendable? > >> Do you plan to do it for 4.0 release? > >> Or explain why you don't want it, please. > >> > >> Thank you > >> > > > RP> --------------------------------------------------------------------- > RP> To unsubscribe, e-mail: > RP> [EMAIL PROTECTED] > RP> For additional commands, e-mail: > RP> [EMAIL PROTECTED] > > > > > -- > aku > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
