That is a good point... That is the very reason why they are now trying to push WebBeans as part of the standard profile ;o)
-----Original Message----- From: Oleg Taranenko [mailto:taranenko.for...@googlemail.com] Sent: Friday, February 13, 2009 4:05 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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
