I see that pushing for a Wicket standard is futile, but I will make one last attempt to answer some of your questions... See comments below...
-----Original Message----- From: Johan Compagner [mailto:[email protected]] Sent: Friday, February 13, 2009 12:17 PM To: [email protected] Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam swing like? are there multiply implementations for swing? Can i choose one from Sun and one from X? or better said are there any desktop UI frameworks that do have multiply implementations (for the same platform??) not that i know of . There could be a reason for that.... Answer: "Swing-like" is referring to the programming model style- not the actual Swing framework (thus the word "like" :o). However, there could very well be other implementations for Swing, but that is another topic altogether. One of the reasons why you don't see multiple implementations of Swing is that it is part of Sun's Java Foundation Classes (JFC)- web frameworks are not ;o) so your managers just want to program against interfaces.. And be able to drop it into any container i dont see the point. That makes testing only more horrible, every container has its own bugs and slightly different behaviors... Answer: The reasoning that "every container has its own bugs and slightly different behaviors" is the very reason why management may want the flexibility to change implementations (the purpose for the standard in the first place). One implementation may not implement some features as well as others. Does anybody here on the list made a application using JPA persistence and the first against hibernate and then when it was finished swapped it for something else? Answer: It is highly plausible that a switch would be made from one JPA implementation to another. I know of companies that have switched from Hiberante to OpenJPA to do just that. Other reasons may include, but are not limited to: better support from one vendor to the next, discounted support through partner programs, light-weight implementation, etc. On Fri, Feb 13, 2009 at 16:59, 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]
