Rod Johnson (creator of spring) talks about JCP, JEE, and Spring: http://java.sys-con.com/node/732455
-----Original Message----- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, February 13, 2009 4:15 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam how will having wicket as a standard help this? look at spring, it is no jsr but a lot of projects integrate with it, and it in return integrates with other projects. anyways, there is already a start of wicket seam support by the seam folks. http://in.relation.to/Bloggers/SeamlessWicket -igor On Fri, Feb 13, 2009 at 1:05 PM, Oleg Taranenko <taranenko.for...@googlemail.com> wrote: > Hmm... > > some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and > Wicket. Was it successful? May be this is an example, why wicket > should to be treated as a standard? > > Oleg > > On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William <whoo...@nemours.org>wrote: > >> First of all, thank you for entertaining this idea :o) >> >> See comments below... >> >> -----Original Message----- >> From: Johan Compagner [mailto:jcompag...@gmail.com] >> Sent: Friday, February 13, 2009 9:38 AM >> To: users@wicket.apache.org >> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam >> >> > >> > From a developers point-of-view standardization can often be a >> > thorn in our side, but for management it can offer a >> > vendor-independent/implementation-independent solution. >> > Maintaining/upgrading infrastructure is difficult, expensive and >> > time consuming. From the point-of-view of management a standard can >> > often minimize the risk of vender lock-in. >> >> >> >> But the examples you gave me have multiply implementations. But >> wicket doesnt have multiply implementations, what would that mean? >> That we have IComponent, IRequestCycle, ISession and IApplication and >> so on? >> And that IBM would make its own implementation of all the components >> including the base? And JBoss and X and Y? >> >> Answer: They do not have multiple implementations now, but they could >> potentially have them in the future. It would mean that other >> communities could follow a standard and mangement could be satisfied >> that Wicket has the backing of a recognized standard. >> >> There is no vendor locking for wicket.. (and all other open source >> web frameworks by the way) what is the locking? >> >> Answer: I agree that other frameworks that have a standard have been >> disastrous as far as portability between implementations (such as the >> loosly organized JSF specification), but the locking I'm referring to >> is in realation to the vendor (Wicket in this case) from a business >> standpoint. I for one do not have an issue with being tightly coupled >> to Wicket, but I can see why managment may have an issue with it. A >> question we need to ask ourselves from a management standpoit is if >> for whatever reason we had to migrate from Wicket to another >> framework, what revenue impact would that have on our organization in >> doing so? If we chose a standards base solution would this minimize >> the risk due to multiple vendor offerings? >> >> And wicket runs pretty much on all simple servlet containers.. Some >> bugs in some not counting... >> So give me a concreet example what a standardized wicket would look >> like. >> What vendor-independent/implementation-independent solutions there >> would be then.. >> >> Answer: This is a preliminary concept, but the Swing-like >> architecture for the web could be a starting point? >> >> >> > >> > Another thing to consider is that a broader multi-community >> > involvement could also bread innovation. There may be other >> > innovators >> >> > from other communities that may have valuable input that could >> > improve >> >> > Wicket in ways that may have not been previously considered. IMHO, >> > the >> >> > biggest argument for JSR/JCP is that there is often a broader >> involvement in the process. >> > Hibernate, for instance, was in a similar position a few years back >> > when they introduced a new persistence concept. They have since >> > become >> >> > heavily involved in the JPA specification process. When I first >> > worked >> >> > with Hibernate, like many, I was very impressed (similar to the >> > first time I worked with Wicket :o), but looking back at how >> > Hiberante initially did things to how they do them now there are >> > some huge improvements due to the JPA specification. >> > >> > >> look hibernate is an implementation of a persistence.. And they >> adapted (and where involved) into the specifications yes Ok now >> translate that to wicket.. >> What is wicket an implementation of? a webframework? ahh.. tapestry >> is also a webframework and struts is also a webframework They all >> implement the standard webframework spec.. which is the servlet >> spec.. >> So >> >> JPA Spec == Servlet Spec >> Hibernate == Wicket >> TopLink == Tapestry >> >> So wicket is already in the JSR/JCP ! we are an >> enhancement/implementation of the servlet spec :) ok ok. Maybe you >> say.. sevlet spec implementation == servlet .jar and tomcat ;) not >> the thing you would build on top of that again But then if you have >> wicket,tapestry and struts (and x and y) and then you want to define >> a Web Framework spec that all of them can adapt to what would that >> then be? What would that then gain? Would that mean that tapestry >> components/pages could run inside wicket? >> It is just not as easy to do as with a persistence spec. Which is >> pretty easy because so many things kind of already work the same way >> before they where under the same spec.. >> web frameworks differ quite a bit >> >> Answer: Ironically, the same argument that Wicket follows the Servlet >> specification is the same one I used in some of the dicusssions with >> my colleagues ;o) I think there is a lot to gain in standardizing a >> Swing-like architecture such as Wicket. The answer to your question >> is the same reason why Wicket prides itself as a truly decoupled >> solution that facilitates a true MVC2 model. As stated previously, it >> would also gain more corporate acceptance. I think that web framework >> only differs from other tiers because noone has come to the table >> with a more viable solution than JSP/JSF in the past. Wicket could >> really set the precidence here. I understand the reluctance to >> standardize Wicket. None of us want to lose anything that Wicket is offering to the community. >> I'm just suggesting a means to broaden Wickets impact in the greater >> java community :o) >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
