Couldn't agree more with Inge I have worked with tapestry-Guice & tapestry-Spring IOC and I think one of the merits of Tapestry IOC is how easily you can integrate it with any IOC.
Any web framework needs some build-in IOC, It may be a couple of Java classes but it is there. In Tapestry, we have a better one and which can do things other full blown IOC's can't do. So in nutshell, we have an IOC which eases integration of other IOC's with tapestry web framework and which can also work on its own. So it is the best of both worlds. :) One last point. Tapestry web framework needs an IOC for its own implementation and using Guice or Spring would mean depending on one and providing integration for other which in turn would again raise questions like "Merits of Guice", "Merits of Spring". regards Taha On 21-May-2013, at 3:31 PM, Inge Solvoll <inge.tapes...@gmail.com> wrote: > I love Tapestry IOC. When used in a very basic way, it's almost > indistinguishable from Guice. Actually it's less intrusive since you don't > need annotations for injection. > > Tapestry is very powerful when you do more advanced stuff, and I just love > that the power's there even though I don't use it that much. > > "Why doesn't everyone use X if it's so great?" > "Why don't you use the standard?" > > These questions wrongly assume that standards are always a good thing, and > that standards are of high quality. And that the companies funding these > standards are acting in your best interest, not in their own :) > > > On Thu, May 16, 2013 at 7:01 PM, Lenny Primak <lpri...@hope.nyc.ny.us>wrote: > >> I don't think neither I nor hantsy have any realistic action items that >> will possibly be implemented, >> simply because the maintainers have too much stake in the status quo. >> There is nothing wrong with that. It is legitimate to protect your >> investment, >> especially if you making a living off of it. I would do the same thing. >> There were legitimate reasons at the time to make decisions that were made, >> at least most of them. >> >> But, the landscape changed. Now there are better, simpler, more popular >> choices >> in IOC than Tapestry-IOC, and I would prefer a world without Tapestry-IOC. >> I can attest that there is some NIH thing going on in Tapestry-world as >> well. >> There are words like "code dumping" or "not enough tests" or something else >> that is used as an excuse to re-implement something that's already working >> in a different way, but this never applies to code that goes into Tapestry >> every day. >> >> I admit, my biggest pet peeve is code duplication. I would take 50% >> functionality >> from someone else other than develop 100% on my own, even if it isn't >> exactly >> 100% exact way I would do it. I find a way to work with a other people's >> products, >> not trying to re-create the whole stack. >> >> Standards? The excuse that standards stifle innovation is so "Microsoft" >> Standards in no way stifle innovation. Where would we be without >> standardized electricity? TCP/IP? etc. >> >> Backward compatibility? Also, this is used a lot as an excuse. >> Perhaps the templates are backward-compatible, at best. >> IOC code has never been compatible from one version to the next. >> I even had to change code from 5.3.1 to 5.3.2 >> >> >> Why do I like tapestry? Well let's discuss the features. >> >> - Template language. Can be read in DreamWeaver and other tools, can be >> handed off to designers and then taken back. >> This is #1 feature of Tapestry for me. No other framework comes close to >> this level of consistency >> Con: HTML5 isn't really XML-compliant, so as tools go more HTML5 they >> will lose their XML compliant features and >> TML editing with those tools will start failing over time. >> >> - Zones / JavaScript integration >> Love the fact that I don't have to touch JavaScript for most tasks. >> >> - Component Model. I do like the component model. Perhaps not internally >> (due to IOC) >> but the way its structured, i.e. pages/components/mixins. >> >> Neutral: >> - live class reloading. Glassfish redeploy is very fast, so I don't even >> use live class reloading >> - Hibernate / JPA integration. I use EJB/CDI layers to do this processing >> >> Negative: >> - Tapestry-IOC >> At the very least, dynamic configuration should be factored out and >> disconnected from the IOC part. Then perhaps replaced with an >> off-the-shelf tool. >> >> On May 16, 2013, at 1:45 AM, Dmitry Gusev wrote: >> >>> I'm not getting what are you trying to say. Is it "lets replace >>> tapestry-ioc with some other ioc"? >>> Or "lets implement proper CDI support"? >>> >>>> If you are implying that this is all so important, why isn't every >>> project on the planet using Tapestry-IOC? >>> >>>> I would be very happy using the Web Framework without Tapestry-IOC, >> using >>> just plain beans for configuration, >>> or even using CDI events to gather configuration. >>> >>> I understand this is a rhetorical statements, but isn't every Tapestry5 >>> application on the planet uses tapestry-ioc? >>> >>> How would you use tapestry5 the web framework without its ioc? >>> >>> I mean what do you like in tapestry5 the web framework if its not ioc? >>> >>> I doubt you like its template language, because its not something unique. >>> What then? Component model? Just curious. >>> >>> I know I'm advanced tapestry5 user because I use it since 2005 everyday >>> non-stop and since version 3. >>> I understand its concepts well and I may be just forgot how hard was it >> to >>> learn tapestry-ioc... >>> this seems very easy to me now (at least those parts that are used in >>> tapestry5 the web framework) and I can't imagine whats that hard to learn >>> in it. >>> Maybe if you still remember it and describe this here somewhere - then we >>> may improve documentation? >>> >>> On Thu, May 16, 2013 at 6:23 AM, hantsy <han...@yahoo.com.cn> wrote: >>> >>>> >>>>> As I said in another thread, you're suggesting replacing Tapestry-IoC >>>>> with CDI. If that was done, people would still learn one IoC framework >>>>> in order to learn Tapestry. CDI has a broader reach (in termos of >>>>> concepts and features) than T-IoC. Not much people use CDI now (I may >>>>> be wrong, of course). Given all that, I don't think replacing >>>>> Tapestry-IoC with CDI in Tapestry would turn Tapestry much easier to >>>>> learn, if at all. And you'd need to rewrite a lot of Tapestry code, >>>>> which would need to get bigger. I don't think that's worth the effort >>>>> at all. >>>>> >>>> >>>> As far as I know, CDI which is part of Java EE 6 is widely used in >>>> enterprise applications, I have used it in a large enterprise >>>> applications(the development cycle is over 20 months). You should keep >>>> a eye open to other communities, such as JBoss.org(in my view, it is the >>>> most active community in these years), and glassfish...and the Apache >>>> OpenEJB/OpenWebBeans related communities. >>>> >>>> I am a Tapestry4.0 user, but after 4.0, I gave up Tapestry. But I >>>> subscribed this maillist to keep up with what is new in the newest >>>> Tapestry. Of course, I rarely posted new topic in this maillist and >>>> replied others. >>>> >>>> For the new Tapestry5, I have read the code Tap5-hotelbooking which is >>>> the sample motioned in the Tapestry 5 homepage. >>>> >>>> But I was disappeared, too many artifacts are invented by Tapestry(like >>>> Tapestry4 before), such as IOC, it is stopper for me to adopt it. >>>> >>>> Tapestry should embrace the existed and mature specs, such JSR330, Bean >>>> Validation, Managed Bean, etc, Spring has supported them in 3.0 >> natively. >>>> >>>> CDI provides more than JSR 330(only provides DI), for example, CDI >>>> events, Tapestry can provides bridges to CDI Events, CDI conversation, >>>> which can be implemented to group Tapestry pages to process a wizard >>>> like task easily, eg. shopping cart. >>>> >>>> As I know, there are fewer people using Tapestry after 4.0, at least in >>>> the circle of my friends, it is the truth. >>>> >>>> Tapestry developers should open minds and work together with other >>>> technologies/framework, not invent everything themselves. Thus Tapestry >>>> will be back to the view of more Java developers. >>>> >>>> >>>> Regards >>>> >>>> Hantsy >>>> -- >>>> Fulltime Java EE Freelancer from China >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>> >>> >>> -- >>> Dmitry Gusev >>> >>> AnjLab Team >>> http://anjlab.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
