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 <[email protected]> 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 <[email protected]>wrote: > >> First of all, thank you for entertaining this idea :o) >> >> See comments below... >> >> -----Original Message----- >> From: Johan Compagner [mailto:[email protected]] >> Sent: Friday, February 13, 2009 9:38 AM >> To: [email protected] >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
