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