> I'd love to see your source code... it must be out of this world!!! Nah. Its just more true to test driven development and agility. You know small methods, DRY, KISS bla bla bla.
It's simple as this. Tapestry is service heavy. Why do not have Page.getTemplate() (as option of cause). I asked for it in 2008? Nothing. This whole overcomplicated under-engineered complex with the selectors and caches, template locators bla bla. Why? Start thinking about Page.getTemplate(). Get it right. Then ease implementation details. Why is the dynamic tempalte parser is having a cache? Why? That's not flexible, its not a parser if it also caches. Its a hybrid. Its wrong design by the letter. Its a parser. Nothing more and I know no template parser that caches per default that caches in any way you cant turn off, that caches at all. Thats this feature rich stuff I dislike. Thats what it makes stiff, unfocused and hard to understand. Every service I am touching I end up in hacking. I copy the code and rewrite its behaviour. I do not overwrite I replace. And I test everything to be sure if tapestry sources change I will see the exact spot that breaks now. Thats why I can do it in first place. Just try to simplify tasks around providing easier support for someone implementing Page.getTemplate. It becomes so clear that Tapestry is lacking in this realm. It would have been so easy to do this for me. But no. I have to hack around and search and do. 4hours or more. Reading sources, missing some important stuff. Bla bla. I dont like it it isnt productive. Why cant I load templates from database? Because there is no way to get page.getTemplate() to work easily. It should be one liner. Inject a good abstract service for it give it the string content done. Dont ask about Resource either... 2008 Resource is filebased. Change that give us a resource that is not file based. And what do we get? VirtualResource extending Resource why? Why not put a Virtual Resource up the resource. I mean a resource that is virtual or not but it must not be a file... . It was implemented the other way around. So I have to use unsupported operation exception to guard against using the resource in a way one can only treat a File based resource. If you need to use unsupported operation the design is wrong. Periode. Its like having an inmutable list and having to prevent those modification operation. I know why java.util lives with it. But Resource here is a main concern. And I just stop here. I collect every aspect I dislike about tapestry and want to change and I also collect ideas how to simplify and why. Just for personal use and as a learning experience. Guess what I have more then 20 items. I love the way tapestry is doing the rendering and all. Its good clean simple. But I do not touch the code. Its not straight forward its around two edges. And this does not have to do with services. Its all about doing something certain until it works without the simplification step and the refactoring at the end. If you want we can do a remote programming session (15min perparation, 15min talking). Lets say we both take one big fat class / service implementation of the IOC and refactor (no rewrite, no reimplementation only refactoring). And we see where we both end. And then we compare results using skype asking questions, sharing desktops and such. The way programmers learn best. Then we can check whether my complains are valid or not. If I am right we got tons of things that will improve naturly or if i am wrong it all turns out good enough and no change would be worth the afford. (Might sound like a challenge but its not, its an opportunity). Cheers, Martin (Kersten), Germany 2013/10/18 Lance Java <lance.j...@googlemail.com> > Strange to hear you talk that way of the tapestry implementation. I > personally think it's some of the best code I've seen and I genuinely think > that familiarising myself with the tapestry source code has made me a > better developer. Everything is overridable and there are many seams where > you can intercept and tweak the core implementation. The test coverage is > amazing!! > > Perhaps one of the negatives is that there are many one or two method > services that all work together. It can be difficult to find exactly where > you should be looking / tweaking. But the benefit is that services are > simple to tweak and test. > > I'd love to see your source code... it must be out of this world!!! > > > On 17 October 2013 16:55, Martin Kersten <martin.kersten...@gmail.com > >wrote: > > > Well my english is not good enough :). And it would be a mixed blog > because > > i dislike most of the way its implemented I always ask my self why > tapestry > > is such overly complex and also lacks refactoring (in my opinion) I like > > the tapestry sources its above average but nothing more. And after > reading > > tapestry code I just have the mixed feeling of numbness. Cant help but I > > feel differently for different source styles. Some letft me cristal > clear, > > some warm and relaxed, other kept me alerted and the tapestry style makes > > me numb. Cant help it. Well thats the way it is. My keeps me warm and > > relaxed so its something biased I guess. But some code I write in hurry > > leave my with slightly headaches when I read them later on. Maybe I am > just > > overly sentisive since my near death illness and strange recovery. Well > > dont mind :-). > > > > > > 2013/10/17 Thiago H de Paula Figueiredo <thiag...@gmail.com> > > > > > On Thu, 17 Oct 2013 11:17:26 -0300, Martin Kersten < > > > martin.kersten...@gmail.com> wrote: > > > > > > I collect this stuff I do for blog posts. But I need to find a native > > >> english speaker with a tapestry background first :). > > >> > > > > > > Some of the best blog posts about Tapestry are written by Igor > Drobiazko > > ( > > > http://blog.tapestry5.de, which is German, and Taha Hafeez ( > > > http://tawus.wordpress.com/), which is Indian (guys, please correct me > > if > > > I'm wrong), so I don't see the need of a native English speaker (as > long > > as > > > the person knows Tapestry and writes good English, of course). :) > > > > > > -- > > > Thiago H. de Paula Figueiredo > > > Tapestry, Java and Hibernate consultant and developer > > > http://machina.com.br > > > > > > > ------------------------------**------------------------------**--------- > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org< > > users-unsubscr...@tapestry.apache.org> > > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > > > >
