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

There is no vendor locking for wicket.. (and all other open source web
frameworks by the way)
what is the locking?

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


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

johan

Reply via email to