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] > >
