You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martijn Dashorst <da...@apache.org> on 2009/02/11 23:33:14 UTC

Wicket at ApacheCon EU'09 in Amsterdam

We're happy to announce a lot of Wicket involvement at the upcoming
ApacheCon in Amsterdam (23-27 March 2009)

First of all we have 2 training sessions available:
 - Introduction to Wicket by Martijn Dashorst on Mon 23 March
(http://tinyurl.com/aceu09wicket1)
 - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho
on Tue 24 March (http://tinyurl.com/aceu09wicket2)

Both courses are hosted by core members. Martijn has co-authored
Wicket in Action and Timo has been involved with WicketTester and
JDave. There is no better team to get you and your team up to speed
with the finest Java web framework available and start cranking out
fully tested applications.

Martijn will also present Wicket in Action during the normal
conference days. A quick introduction to Wicket's core features in
just one hour. But attending the conference will give you much more:
over 60 sessions covering your favorite Apache projects.

Amsterdam is great, but Wicket meetups in Amsterdam are even better!
We're attempting to schedule a Wicket meetup during the conference at
the conference floor. Details will follow soon.

Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/

See you in Amsterdam!

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Thomas Mäder <th...@devotek-it.ch>.
I guess there are advantages to being a committer ;-) But I maintain, Wicket
is well established on the technical front, but it could use a push on the
corporate side. Of course, I'm now waiting for the inrush of offers to prove
me wrong ;-)

Thomas

On Thu, Feb 12, 2009 at 8:14 PM, Johan Compagner <jc...@gmail.com>wrote:

> Hmmmmm no wicket jobs in switzerland? Damnn
> I am right now waiting for a plane  that will bring me again to basel
> and the bern. I guess i cant stay there much longer then i do now then
> (1.5 week) :(
> The switzerland has to come to holland..... :)
>
>
-- 
Thomas Mäder
Wicket & Eclipse Consulting
www.devotek-it.ch

Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Johan Compagner <jc...@gmail.com>.
Hmmmmm no wicket jobs in switzerland? Damnn
I am right now waiting for a plane  that will bring me again to basel
and the bern. I guess i cant stay there much longer then i do now then
(1.5 week) :(
The switzerland has to come to holland..... :)



On 12/02/2009, Thomas Mäder <th...@devotek-it.ch> wrote:
> I totally agree that the JSR process is horrid. However, Wicket could really
> use some more corporate credibility (which a JSR would provide).
> The problem, I guess is that there are simply no corporate interests behind
> Wicket that would push the agenda. What wicket need is some evangelism, but
> I guess all the core people have real jobs. What we need is less talks
> titled "why wicket is cool" and more "cut your development costs in two with
> Wicket". From experience, I am totally convinced that you can save 50% off
> your development costs if you switch to wicket (from just about any other
> framework), however, I've yet to find a contracting job here in Zürich where
> wicket is asked for (it's JSF, or even Struts).
>
> Thomas
>
> On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner
> <jc...@gmail.com>wrote:
>
>> And then come into the horrible voting/administive stuff? Long Release
>> cycles that are controlled, features that are discussed over and over.
>>
>> Hmm
>>
>> On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
>> > Just out of curiosity... Are there any plans to push a JSR that Wicket
>> > could follow. I think there would be a lot more acceptance of Wicket if
>> > this was to happen :o)
>> >
>> > -----Original Message-----
>> > From: martijn.dashorst@gmail.com [mailto:martijn.dashorst@gmail.com] On
>> > Behalf Of Martijn Dashorst
>> > Sent: Wednesday, February 11, 2009 5:33 PM
>> > To: users@wicket.apache.org
>> > Subject: Wicket at ApacheCon EU'09 in Amsterdam
>> >
>> > We're happy to announce a lot of Wicket involvement at the upcoming
>> > ApacheCon in Amsterdam (23-27 March 2009)
>> >
>> > First of all we have 2 training sessions available:
>> >  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
>> > (http://tinyurl.com/aceu09wicket1)
>> >  - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on
>> > Tue 24 March (http://tinyurl.com/aceu09wicket2)
>> >
>> > Both courses are hosted by core members. Martijn has co-authored Wicket
>> > in Action and Timo has been involved with WicketTester and JDave. There
>> > is no better team to get you and your team up to speed with the finest
>> > Java web framework available and start cranking out fully tested
>> > applications.
>> >
>> > Martijn will also present Wicket in Action during the normal conference
>> > days. A quick introduction to Wicket's core features in just one hour.
>> > But attending the conference will give you much more:
>> > over 60 sessions covering your favorite Apache projects.
>> >
>> > Amsterdam is great, but Wicket meetups in Amsterdam are even better!
>> > We're attempting to schedule a Wicket meetup during the conference at
>> > the conference floor. Details will follow soon.
>> >
>> > Read more about ApacheCon EU 2009 here:
>> > http://www.eu.apachecon.com/c/aceu2009/
>> >
>> > See you in Amsterdam!
>> >
>> > Martijn
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Thomas Mäder
> Wicket & Eclipse Consulting
> www.devotek-it.ch
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Thomas Mäder <th...@devotek-it.ch>.
Unfortunately, those 'idiotic managers' (and I'm not disagreeing with you)
hold the purse strings. The move to Apache was a big step towards acceptance
by the business types. If you try to sell a new technology with a weird name
to your manager, it's not helping that there are "just some guys from the
internet" behind this (let's not argue whether that really matters or not,
it's just about the impression it gives).

Let's just say this: there are at least two angles to selling a particular
technology: the business angle and the technical merits. While the technical
merits of Wicket are evangalized, the business case is less promoted.

Thomas

PS: Just for the record, I'm totally opposed to starting a wicket JSR.

On Fri, Feb 13, 2009 at 10:10 AM, Johan Compagner <jc...@gmail.com>wrote:

> and what would a wicket "standard" give you?
> Except that those idiotic managers then say "its standardized.. now you can
> use it" why is that is a standard for ever? dont think so everything dies.
> But would it run on more platforms?
>
>
-- 
Thomas Mäder
Wicket & Eclipse Consulting
www.devotek-it.ch

Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Dave Schoorl <ma...@cyber-d.com>.
I do think that pushing a JSR for Wicket will have a negative influence 
on the spirit of Wicket and it's community due to the politics involved 
with a JSR. Politics are so not the Wicket way. This is what I mean with 
the "wrong way" and yes, that is mighty subjective.

I also expect there will not be enough support from other parties to 
participate in a JSR (again, highly subjective), because there is 
nothing for them to gain. Which I believe is one of your main arguments: 
there will not be a broader input base. But I think Wicket receives 
enough input since the Wicket developers see what is happening in other 
projects around them and they take that with them.

And without enough support, the JSR will be dropped and I think that in 
the corporate eye, Wicket will turn into 'that project that didn't make 
the JSR', and wide adoption will be even further away.

But again, without a concrete proposal, I have no idea what the 
specification request would describe and what the scope of such a JSR 
would be. Could you elaborate on that? Maybe that clears things up for me.

BTW, I think not that Hibernate has grown as a result of the 
JPA-standard, but that the Java EE standard has grown a a result of the 
emerging of ORM-tools (like Hibernate, Toplink etc.) and other popular 
application stacks, like Spring etc. The quality of Hibernate would have 
increased without the JPA-spec anyway (and ofcourse, there was - and 
there still is - enough opportunity to improve).


Hoover, William wrote:
> I agree that we need to change the views of corporate managers in the
> "right way" by illustrating the cost savings achieved though a reduction
> in development time. At the same time, I don't believe that this will
> change the Wicket community in the "wrong way" (which is a highly
> subjective statement). I'm only presenting the alternative viewpoint. It
> is possible that a standard could potentially inhibit progression due to
> contrasting viewpoints within the community, but it is also equally
> possible that it could lead to a value-added aspect by introducing a
> broader input base to the Wicket community that could speed progression
> (Hibernate/JPA is an example of this). There is always a possibility
> that progress can be slowed as the number of members increase because
> there are more viewpoints to be examined/debated. I think that there is
> a higher probability that the community will grow if such a standard
> were to be adopted.
>
> Just because there is already a specification for a "web framework"
> (JSF) that does not constitute abandoning a standard approach. Look at
> JAX-WS vs JAX-RS. They accomplish many of the same objectives, but they
> both are part of the proposed profile stack
> (http://www.theserverside.com/tt/articles/article.tss?l=JavaEE6Overview)
> . A Wicket implementation could orchestrate a refreshing alternative
> approach to JSF in the same manner that it does today.
>
> When I referred to open-mindedness I was referring to being open-minded
> to the ideas behind the push... I didn't necessary intended to imply
> that anyone would not be open-minded if they did not support a JSR :o)
>
> -----Original Message-----
> From: Dave Schoorl [mailto:maillists@cyber-d.com] 
> Sent: Friday, February 13, 2009 9:21 AM
> To: users@wicket.apache.org
> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
>
> I am not sure what you would like to standardize. Given your JPA
> example, I would guess that you want to push a JSR for a web framework
> or something. But there is already something like that: JSF. Just let
> Wicket be Wicket and instead of changing Wicket (and it's community) in
> the wrong way, let's try to change the views of corporate managers in
> the right way. As Thomas said earlier "What we need is less talks titled
> 'why wicket is cool' and more 'cut your development costs in two with
> Wicket' ".
>
> And I do not think that the lack of support for pushing a JSR has
> anything to do with a lack of open-mindedness...
>
> Hoover, William wrote:
>   
>> I hear the arguments and I completely agree with the notion that 
>> innovation usually happens "elsewhere" and a JSR/JCP would slow that 
>> process down. I just want to objectively view the other side of the 
>> spectrum :o)
>>
>> 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.
>   
>> 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.
>   
>> My hope is that the Wicket community can be as open-minded to this 
>> notion as they are to the open source code they represent :o)
>>
>>   
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by "Hoover, William " <wh...@nemours.org>.
I agree that we need to change the views of corporate managers in the
"right way" by illustrating the cost savings achieved though a reduction
in development time. At the same time, I don't believe that this will
change the Wicket community in the "wrong way" (which is a highly
subjective statement). I'm only presenting the alternative viewpoint. It
is possible that a standard could potentially inhibit progression due to
contrasting viewpoints within the community, but it is also equally
possible that it could lead to a value-added aspect by introducing a
broader input base to the Wicket community that could speed progression
(Hibernate/JPA is an example of this). There is always a possibility
that progress can be slowed as the number of members increase because
there are more viewpoints to be examined/debated. I think that there is
a higher probability that the community will grow if such a standard
were to be adopted.

Just because there is already a specification for a "web framework"
(JSF) that does not constitute abandoning a standard approach. Look at
JAX-WS vs JAX-RS. They accomplish many of the same objectives, but they
both are part of the proposed profile stack
(http://www.theserverside.com/tt/articles/article.tss?l=JavaEE6Overview)
. A Wicket implementation could orchestrate a refreshing alternative
approach to JSF in the same manner that it does today.

When I referred to open-mindedness I was referring to being open-minded
to the ideas behind the push... I didn't necessary intended to imply
that anyone would not be open-minded if they did not support a JSR :o)

-----Original Message-----
From: Dave Schoorl [mailto:maillists@cyber-d.com] 
Sent: Friday, February 13, 2009 9:21 AM
To: users@wicket.apache.org
Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam

I am not sure what you would like to standardize. Given your JPA
example, I would guess that you want to push a JSR for a web framework
or something. But there is already something like that: JSF. Just let
Wicket be Wicket and instead of changing Wicket (and it's community) in
the wrong way, let's try to change the views of corporate managers in
the right way. As Thomas said earlier "What we need is less talks titled
'why wicket is cool' and more 'cut your development costs in two with
Wicket' ".

And I do not think that the lack of support for pushing a JSR has
anything to do with a lack of open-mindedness...

Hoover, William wrote:
> I hear the arguments and I completely agree with the notion that 
> innovation usually happens "elsewhere" and a JSR/JCP would slow that 
> process down. I just want to objectively view the other side of the 
> spectrum :o)
>
> 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.
>
> 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.
>
> My hope is that the Wicket community can be as open-minded to this 
> notion as they are to the open source code they represent :o)
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Dave Schoorl <ma...@cyber-d.com>.
I am not sure what you would like to standardize. Given your JPA 
example, I would guess that you want to push a JSR for a web framework 
or something. But there is already something like that: JSF. Just let 
Wicket be Wicket and instead of changing Wicket (and it's community) in 
the wrong way, let's try to change the views of corporate managers in 
the right way. As Thomas said earlier "What we need is less talks titled 
'why wicket is cool' and more 'cut your development costs in two with 
Wicket' ".

And I do not think that the lack of support for pushing a JSR has 
anything to do with a lack of open-mindedness...

Hoover, William wrote:
> I hear the arguments and I completely agree with the notion that innovation usually happens "elsewhere" and a JSR/JCP would slow that process down. I just want to objectively view the other side of the spectrum :o)
>
> 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.
>
> 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.
>
> My hope is that the Wicket community can be as open-minded to this notion as they are to the open source code they represent :o)
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Jan Kriesten <kr...@mail.footprint.de>.
Hi,

I can't really think of any specification which would make sense to build -
there is just no need for that IMHO.

If managers need something like that - there's JSF. And knowledge is growing
that JSF isn't the ultimate answer. There are other open source projects
embraced by managers as well without being an official standard - else why would
there be so many Struts applications out there?!

Also, Wicket does support a standard, which makes it quite valuable: Portlets!
Does Tapestry do that?

Best regards, --- Jan.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by "Hoover, William " <wh...@nemours.org>.
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:jcompagner@gmail.com] 
Sent: Friday, February 13, 2009 12:17 PM
To: users@wicket.apache.org
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 <wh...@nemours.org>
wrote:

> First of all, thank you for entertaining this idea :o)
>
> See comments below...
>
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Johan Compagner <jc...@gmail.com>.
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....

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


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?

johan


On Fri, Feb 13, 2009 at 16:59, Hoover, William <wh...@nemours.org> wrote:

> First of all, thank you for entertaining this idea :o)
>
> See comments below...
>
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by "Hoover, William " <wh...@nemours.org>.
Rod Johnson (creator of spring) talks about JCP, JEE, and Spring:

http://java.sys-con.com/node/732455

-----Original Message-----
From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com] 
Sent: Friday, February 13, 2009 4:15 PM
To: users@wicket.apache.org
Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam

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
<ta...@googlemail.com> 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
<wh...@nemours.org>wrote:
>
>> First of all, thank you for entertaining this idea :o)
>>
>> See comments below...
>>
>> -----Original Message-----
>> From: Johan Compagner [mailto:jcompagner@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by "Hoover, William " <wh...@nemours.org>.
http://opensource.atlassian.com/confluence/spring/display/JSR168/2008/04
/18/Plans+for+JSR+286+Support 

-----Original Message-----
From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com] 
Sent: Friday, February 13, 2009 4:15 PM
To: users@wicket.apache.org
Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam

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
<ta...@googlemail.com> 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
<wh...@nemours.org>wrote:
>
>> First of all, thank you for entertaining this idea :o)
>>
>> See comments below...
>>
>> -----Original Message-----
>> From: Johan Compagner [mailto:jcompagner@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Igor Vaynberg <ig...@gmail.com>.
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
<ta...@googlemail.com> 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 <wh...@nemours.org>wrote:
>
>> First of all, thank you for entertaining this idea :o)
>>
>> See comments below...
>>
>> -----Original Message-----
>> From: Johan Compagner [mailto:jcompagner@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Wicket and standardization (was: Wicket at ApacheCon EU'09 in Amsterdam)

Posted by Erik van Oosten <e....@grons.nl>.
Please change the subject of this thread.

    Erik.

-- 
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by cpopetz <cp...@gmail.com>.

As the programmer currently maintaining/improving the seam/wicket
integration:

(a) I recently got a change to wicket from Igor in less than a day, upon
request, to support this integration.  I doubt I would have had as much luck
if the behavior of wicket was in a JSR, but in any case, the lack of a JSR
didn't hinder me.

(b) I've coded things to JSR specs before, and found it no easier (and often
less) than reading wicket's source, which is very well commented, and asking
questions.  The ability to target a technology for integration is not about
whether it's "standardized."

(c) I won't comment on the "why" of Seam turning into WebBeans using JSR,
but having been on the WebBeans mailing list for a while, I don't think I
would ever volunteer to shepherd anything through that process.  It was
dreadful, slow, and a lot of compromises were made that IMHO had no
technical merit and were completely politically motivated.

-Clint


whoover wrote:
> 
> 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.forums@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
> <wh...@nemours.org>wrote:
> 
>> First of all, thank you for entertaining this idea :o)
>>
>> See comments below...
>>
>> -----Original Message-----
>> From: Johan Compagner [mailto:jcompagner@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Wicket-at-ApacheCon-EU%2709-in-Amsterdam-tp21965856p22037443.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by "Hoover, William " <wh...@nemours.org>.
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.forums@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
<wh...@nemours.org>wrote:

> First of all, thank you for entertaining this idea :o)
>
> See comments below...
>
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Oleg Taranenko <ta...@googlemail.com>.
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 <wh...@nemours.org>wrote:

> First of all, thank you for entertaining this idea :o)
>
> See comments below...
>
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by "Hoover, William " <wh...@nemours.org>.
First of all, thank you for entertaining this idea :o)

See comments below...

-----Original Message-----
From: Johan Compagner [mailto:jcompagner@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Johan Compagner <jc...@gmail.com>.
>
> 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

Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by francisco treacy <fr...@gmail.com>.
this has nothing to do with being open-minded.

i'm pretty sure that most non-trivial projects out there using jpa
with hibernate implementation can go through a big pain if they ever
decide to "change jpa vendor".
 now that you talk about jpa, this is an example of how backward a
spec can be: jpa 2.0 draft is only now addressing criteria, when we
should be including statically-typed queries and so on (ala linq /
quaere / jaqu).

granted the process might bring some benefit to wicket, but there are
way too many disadvantages, imo. and i don't really see how wicket
could become a sort of standard that gets different implementations.

anyway, i think we've got waaay out of topic =)

francisco

--
http://wickethub.org



On Fri, Feb 13, 2009 at 2:36 PM, Hoover, William <wh...@nemours.org> wrote:
> I hear the arguments and I completely agree with the notion that innovation usually happens "elsewhere" and a JSR/JCP would slow that process down. I just want to objectively view the other side of the spectrum :o)
>
> 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.
>
> 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.
>
> My hope is that the Wicket community can be as open-minded to this notion as they are to the open source code they represent :o)
>
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@gmail.com]
> Sent: Friday, February 13, 2009 4:10 AM
> To: users@wicket.apache.org
> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
>
> and what would a wicket "standard" give you?
> Except that those idiotic managers then say "its standardized.. now you can use it" why is that is a standard for ever? dont think so everything dies.
> But would it run on more platforms?
> Would we have multiply implementations? Because thats most of the time a JCP/JSR does, it doesnt have an implementation, what wicket is, but a description/interfaces what an implementation should do..
>
> johan
>
>
> On Fri, Feb 13, 2009 at 10:00, Martijn Dashorst
> <ma...@gmail.com>wrote:
>
>> Bill Joy from Sun once said: innovation happens elsewhere. I think
>> that the where elsewhere isn't, it is the JCP. Standardization is just
>> antithetical to innovation. Once something is fixed in brick/mortar
>> how can you innovate? Wicket is very comfortably located elsewhere.
>>
>> Martijn
>>
>> On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg
>> <ig...@gmail.com>
>> wrote:
>> > we like the agility that the independence from any sort of a
>> > standard
>> offers us.
>> >
>> > -igor
>> >
>> > On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William
>> > <wh...@nemours.org>
>> wrote:
>> >> Judging by the responses (or the lack thereof), It seems as though
>> >> there
>> isn't enough support from the Wicket community to push for something
>> like this :(
>> >>
>> >> -----Original Message-----
>> >> From: tomlist0408@gmail.com [mailto:tomlist0408@gmail.com] On
>> >> Behalf Of
>> Thomas Mäder
>> >> Sent: Thursday, February 12, 2009 12:57 PM
>> >> To: users@wicket.apache.org
>> >> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
>> >>
>> >> I totally agree that the JSR process is horrid. However, Wicket
>> >> could
>> really use some more corporate credibility (which a JSR would provide).
>> >> The problem, I guess is that there are simply no corporate
>> >> interests
>> behind Wicket that would push the agenda. What wicket need is some
>> evangelism, but I guess all the core people have real jobs. What we
>> need is less talks titled "why wicket is cool" and more "cut your
>> development costs in two with Wicket". From experience, I am totally
>> convinced that you can save 50% off your development costs if you
>> switch to wicket (from just about any other framework), however, I've
>> yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts).
>> >>
>> >> Thomas
>> >>
>> >> On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner
>> >> <jcompagner@gmail.com
>> >wrote:
>> >>
>> >>> And then come into the horrible voting/administive stuff? Long
>> >>> Release cycles that are controlled, features that are discussed over and over.
>> >>>
>> >>> Hmm
>> >>>
>> >>> On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
>> >>> > Just out of curiosity... Are there any plans to push a JSR that
>> >>> > Wicket could follow. I think there would be a lot more
>> >>> > acceptance of Wicket if this was to happen :o)
>> >>> >
>> >>> > -----Original Message-----
>> >>> > From: martijn.dashorst@gmail.com
>> >>> > [mailto:martijn.dashorst@gmail.com]
>> >>> > On Behalf Of Martijn Dashorst
>> >>> > Sent: Wednesday, February 11, 2009 5:33 PM
>> >>> > To: users@wicket.apache.org
>> >>> > Subject: Wicket at ApacheCon EU'09 in Amsterdam
>> >>> >
>> >>> > We're happy to announce a lot of Wicket involvement at the
>> >>> > upcoming ApacheCon in Amsterdam (23-27 March 2009)
>> >>> >
>> >>> > First of all we have 2 training sessions available:
>> >>> >  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
>> >>> > (http://tinyurl.com/aceu09wicket1)
>> >>> >  - Behavior-Driving Your Apache Wicket Application by Timo
>> >>> > Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2)
>> >>> >
>> >>> > Both courses are hosted by core members. Martijn has co-authored
>> >>> > Wicket in Action and Timo has been involved with WicketTester
>> >>> > and JDave. There is no better team to get you and your team up
>> >>> > to speed with the finest Java web framework available and start
>> >>> > cranking out fully tested applications.
>> >>> >
>> >>> > Martijn will also present Wicket in Action during the normal
>> >>> > conference days. A quick introduction to Wicket's core features
>> >>> > in
>> just one hour.
>> >>> > But attending the conference will give you much more:
>> >>> > over 60 sessions covering your favorite Apache projects.
>> >>> >
>> >>> > Amsterdam is great, but Wicket meetups in Amsterdam are even better!
>> >>> > We're attempting to schedule a Wicket meetup during the
>> >>> > conference at the conference floor. Details will follow soon.
>> >>> >
>> >>> > Read more about ApacheCon EU 2009 here:
>> >>> > http://www.eu.apachecon.com/c/aceu2009/
>> >>> >
>> >>> > See you in Amsterdam!
>> >>> >
>> >>> > Martijn
>> >>> >
>> >>> > ----------------------------------------------------------------
>> >>> > ----
>> >>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >
>> >>> >
>> >>> >
>> >>> > ----------------------------------------------------------------
>> >>> > ----
>> >>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >
>> >>> >
>> >>>
>> >>> ------------------------------------------------------------------
>> >>> --- To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Thomas Mäder
>> >> Wicket & Eclipse Consulting
>> >> www.devotek-it.ch
>> >>
>> >>
>> >> -------------------------------------------------------------------
>> >> -- To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > --------------------------------------------------------------------
>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>> Apache Wicket 1.3.5 is released Get it now:
>> http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by "Hoover, William " <wh...@nemours.org>.
I hear the arguments and I completely agree with the notion that innovation usually happens "elsewhere" and a JSR/JCP would slow that process down. I just want to objectively view the other side of the spectrum :o)

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

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.

My hope is that the Wicket community can be as open-minded to this notion as they are to the open source code they represent :o)

-----Original Message-----
From: Johan Compagner [mailto:jcompagner@gmail.com] 
Sent: Friday, February 13, 2009 4:10 AM
To: users@wicket.apache.org
Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam

and what would a wicket "standard" give you?
Except that those idiotic managers then say "its standardized.. now you can use it" why is that is a standard for ever? dont think so everything dies.
But would it run on more platforms?
Would we have multiply implementations? Because thats most of the time a JCP/JSR does, it doesnt have an implementation, what wicket is, but a description/interfaces what an implementation should do..

johan


On Fri, Feb 13, 2009 at 10:00, Martijn Dashorst
<ma...@gmail.com>wrote:

> Bill Joy from Sun once said: innovation happens elsewhere. I think 
> that the where elsewhere isn't, it is the JCP. Standardization is just 
> antithetical to innovation. Once something is fixed in brick/mortar 
> how can you innovate? Wicket is very comfortably located elsewhere.
>
> Martijn
>
> On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg 
> <ig...@gmail.com>
> wrote:
> > we like the agility that the independence from any sort of a 
> > standard
> offers us.
> >
> > -igor
> >
> > On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William 
> > <wh...@nemours.org>
> wrote:
> >> Judging by the responses (or the lack thereof), It seems as though 
> >> there
> isn't enough support from the Wicket community to push for something 
> like this :(
> >>
> >> -----Original Message-----
> >> From: tomlist0408@gmail.com [mailto:tomlist0408@gmail.com] On 
> >> Behalf Of
> Thomas Mäder
> >> Sent: Thursday, February 12, 2009 12:57 PM
> >> To: users@wicket.apache.org
> >> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
> >>
> >> I totally agree that the JSR process is horrid. However, Wicket 
> >> could
> really use some more corporate credibility (which a JSR would provide).
> >> The problem, I guess is that there are simply no corporate 
> >> interests
> behind Wicket that would push the agenda. What wicket need is some 
> evangelism, but I guess all the core people have real jobs. What we 
> need is less talks titled "why wicket is cool" and more "cut your 
> development costs in two with Wicket". From experience, I am totally 
> convinced that you can save 50% off your development costs if you 
> switch to wicket (from just about any other framework), however, I've 
> yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts).
> >>
> >> Thomas
> >>
> >> On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner 
> >> <jcompagner@gmail.com
> >wrote:
> >>
> >>> And then come into the horrible voting/administive stuff? Long 
> >>> Release cycles that are controlled, features that are discussed over and over.
> >>>
> >>> Hmm
> >>>
> >>> On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
> >>> > Just out of curiosity... Are there any plans to push a JSR that 
> >>> > Wicket could follow. I think there would be a lot more 
> >>> > acceptance of Wicket if this was to happen :o)
> >>> >
> >>> > -----Original Message-----
> >>> > From: martijn.dashorst@gmail.com 
> >>> > [mailto:martijn.dashorst@gmail.com]
> >>> > On Behalf Of Martijn Dashorst
> >>> > Sent: Wednesday, February 11, 2009 5:33 PM
> >>> > To: users@wicket.apache.org
> >>> > Subject: Wicket at ApacheCon EU'09 in Amsterdam
> >>> >
> >>> > We're happy to announce a lot of Wicket involvement at the 
> >>> > upcoming ApacheCon in Amsterdam (23-27 March 2009)
> >>> >
> >>> > First of all we have 2 training sessions available:
> >>> >  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
> >>> > (http://tinyurl.com/aceu09wicket1)
> >>> >  - Behavior-Driving Your Apache Wicket Application by Timo 
> >>> > Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2)
> >>> >
> >>> > Both courses are hosted by core members. Martijn has co-authored 
> >>> > Wicket in Action and Timo has been involved with WicketTester 
> >>> > and JDave. There is no better team to get you and your team up 
> >>> > to speed with the finest Java web framework available and start 
> >>> > cranking out fully tested applications.
> >>> >
> >>> > Martijn will also present Wicket in Action during the normal 
> >>> > conference days. A quick introduction to Wicket's core features 
> >>> > in
> just one hour.
> >>> > But attending the conference will give you much more:
> >>> > over 60 sessions covering your favorite Apache projects.
> >>> >
> >>> > Amsterdam is great, but Wicket meetups in Amsterdam are even better!
> >>> > We're attempting to schedule a Wicket meetup during the 
> >>> > conference at the conference floor. Details will follow soon.
> >>> >
> >>> > Read more about ApacheCon EU 2009 here:
> >>> > http://www.eu.apachecon.com/c/aceu2009/
> >>> >
> >>> > See you in Amsterdam!
> >>> >
> >>> > Martijn
> >>> >
> >>> > ----------------------------------------------------------------
> >>> > ----
> >>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> > For additional commands, e-mail: users-help@wicket.apache.org
> >>> >
> >>> >
> >>> >
> >>> > ----------------------------------------------------------------
> >>> > ----
> >>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> > For additional commands, e-mail: users-help@wicket.apache.org
> >>> >
> >>> >
> >>>
> >>> ------------------------------------------------------------------
> >>> --- To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Thomas Mäder
> >> Wicket & Eclipse Consulting
> >> www.devotek-it.ch
> >>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com 
> Apache Wicket 1.3.5 is released Get it now: 
> http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by francisco treacy <fr...@gmail.com>.
totally against pushing wicket as a standard / jsr.

it has already been stated by some of you, but i'd like to highlight
the fact that bureaucracy goes against flexibility.

instead of having wicket to change to please management, why don't we
push to have more managers that think out-of-the-box and choose wicket
for its actual strengths rather than because it wears a jcp badge?

francisco

--
http://wickethub.org



On Fri, Feb 13, 2009 at 10:10 AM, Johan Compagner <jc...@gmail.com> wrote:
> and what would a wicket "standard" give you?
> Except that those idiotic managers then say "its standardized.. now you can
> use it" why is that is a standard for ever? dont think so everything dies.
> But would it run on more platforms?
> Would we have multiply implementations? Because thats most of the time a
> JCP/JSR does, it doesnt have an implementation, what wicket is, but a
> description/interfaces what an implementation should do..
>
> johan
>
>
> On Fri, Feb 13, 2009 at 10:00, Martijn Dashorst
> <ma...@gmail.com>wrote:
>
>> Bill Joy from Sun once said: innovation happens elsewhere. I think
>> that the where elsewhere isn't, it is the JCP. Standardization is just
>> antithetical to innovation. Once something is fixed in brick/mortar
>> how can you innovate? Wicket is very comfortably located elsewhere.
>>
>> Martijn
>>
>> On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg <ig...@gmail.com>
>> wrote:
>> > we like the agility that the independence from any sort of a standard
>> offers us.
>> >
>> > -igor
>> >
>> > On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William <wh...@nemours.org>
>> wrote:
>> >> Judging by the responses (or the lack thereof), It seems as though there
>> isn't enough support from the Wicket community to push for something like
>> this :(
>> >>
>> >> -----Original Message-----
>> >> From: tomlist0408@gmail.com [mailto:tomlist0408@gmail.com] On Behalf Of
>> Thomas Mäder
>> >> Sent: Thursday, February 12, 2009 12:57 PM
>> >> To: users@wicket.apache.org
>> >> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
>> >>
>> >> I totally agree that the JSR process is horrid. However, Wicket could
>> really use some more corporate credibility (which a JSR would provide).
>> >> The problem, I guess is that there are simply no corporate interests
>> behind Wicket that would push the agenda. What wicket need is some
>> evangelism, but I guess all the core people have real jobs. What we need is
>> less talks titled "why wicket is cool" and more "cut your development costs
>> in two with Wicket". From experience, I am totally convinced that you can
>> save 50% off your development costs if you switch to wicket (from just about
>> any other framework), however, I've yet to find a contracting job here in
>> Zürich where wicket is asked for (it's JSF, or even Struts).
>> >>
>> >> Thomas
>> >>
>> >> On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner <jcompagner@gmail.com
>> >wrote:
>> >>
>> >>> And then come into the horrible voting/administive stuff? Long Release
>> >>> cycles that are controlled, features that are discussed over and over.
>> >>>
>> >>> Hmm
>> >>>
>> >>> On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
>> >>> > Just out of curiosity... Are there any plans to push a JSR that
>> >>> > Wicket could follow. I think there would be a lot more acceptance of
>> >>> > Wicket if this was to happen :o)
>> >>> >
>> >>> > -----Original Message-----
>> >>> > From: martijn.dashorst@gmail.com [mailto:martijn.dashorst@gmail.com]
>> >>> > On Behalf Of Martijn Dashorst
>> >>> > Sent: Wednesday, February 11, 2009 5:33 PM
>> >>> > To: users@wicket.apache.org
>> >>> > Subject: Wicket at ApacheCon EU'09 in Amsterdam
>> >>> >
>> >>> > We're happy to announce a lot of Wicket involvement at the upcoming
>> >>> > ApacheCon in Amsterdam (23-27 March 2009)
>> >>> >
>> >>> > First of all we have 2 training sessions available:
>> >>> >  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
>> >>> > (http://tinyurl.com/aceu09wicket1)
>> >>> >  - Behavior-Driving Your Apache Wicket Application by Timo
>> >>> > Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2)
>> >>> >
>> >>> > Both courses are hosted by core members. Martijn has co-authored
>> >>> > Wicket in Action and Timo has been involved with WicketTester and
>> >>> > JDave. There is no better team to get you and your team up to speed
>> >>> > with the finest Java web framework available and start cranking out
>> >>> > fully tested applications.
>> >>> >
>> >>> > Martijn will also present Wicket in Action during the normal
>> >>> > conference days. A quick introduction to Wicket's core features in
>> just one hour.
>> >>> > But attending the conference will give you much more:
>> >>> > over 60 sessions covering your favorite Apache projects.
>> >>> >
>> >>> > Amsterdam is great, but Wicket meetups in Amsterdam are even better!
>> >>> > We're attempting to schedule a Wicket meetup during the conference
>> >>> > at the conference floor. Details will follow soon.
>> >>> >
>> >>> > Read more about ApacheCon EU 2009 here:
>> >>> > http://www.eu.apachecon.com/c/aceu2009/
>> >>> >
>> >>> > See you in Amsterdam!
>> >>> >
>> >>> > Martijn
>> >>> >
>> >>> > --------------------------------------------------------------------
>> >>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >
>> >>> >
>> >>> >
>> >>> > --------------------------------------------------------------------
>> >>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >>> >
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Thomas Mäder
>> >> Wicket & Eclipse Consulting
>> >> www.devotek-it.ch
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>> Apache Wicket 1.3.5 is released
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Johan Compagner <jc...@gmail.com>.
and what would a wicket "standard" give you?
Except that those idiotic managers then say "its standardized.. now you can
use it" why is that is a standard for ever? dont think so everything dies.
But would it run on more platforms?
Would we have multiply implementations? Because thats most of the time a
JCP/JSR does, it doesnt have an implementation, what wicket is, but a
description/interfaces what an implementation should do..

johan


On Fri, Feb 13, 2009 at 10:00, Martijn Dashorst
<ma...@gmail.com>wrote:

> Bill Joy from Sun once said: innovation happens elsewhere. I think
> that the where elsewhere isn't, it is the JCP. Standardization is just
> antithetical to innovation. Once something is fixed in brick/mortar
> how can you innovate? Wicket is very comfortably located elsewhere.
>
> Martijn
>
> On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg <ig...@gmail.com>
> wrote:
> > we like the agility that the independence from any sort of a standard
> offers us.
> >
> > -igor
> >
> > On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William <wh...@nemours.org>
> wrote:
> >> Judging by the responses (or the lack thereof), It seems as though there
> isn't enough support from the Wicket community to push for something like
> this :(
> >>
> >> -----Original Message-----
> >> From: tomlist0408@gmail.com [mailto:tomlist0408@gmail.com] On Behalf Of
> Thomas Mäder
> >> Sent: Thursday, February 12, 2009 12:57 PM
> >> To: users@wicket.apache.org
> >> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
> >>
> >> I totally agree that the JSR process is horrid. However, Wicket could
> really use some more corporate credibility (which a JSR would provide).
> >> The problem, I guess is that there are simply no corporate interests
> behind Wicket that would push the agenda. What wicket need is some
> evangelism, but I guess all the core people have real jobs. What we need is
> less talks titled "why wicket is cool" and more "cut your development costs
> in two with Wicket". From experience, I am totally convinced that you can
> save 50% off your development costs if you switch to wicket (from just about
> any other framework), however, I've yet to find a contracting job here in
> Zürich where wicket is asked for (it's JSF, or even Struts).
> >>
> >> Thomas
> >>
> >> On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner <jcompagner@gmail.com
> >wrote:
> >>
> >>> And then come into the horrible voting/administive stuff? Long Release
> >>> cycles that are controlled, features that are discussed over and over.
> >>>
> >>> Hmm
> >>>
> >>> On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
> >>> > Just out of curiosity... Are there any plans to push a JSR that
> >>> > Wicket could follow. I think there would be a lot more acceptance of
> >>> > Wicket if this was to happen :o)
> >>> >
> >>> > -----Original Message-----
> >>> > From: martijn.dashorst@gmail.com [mailto:martijn.dashorst@gmail.com]
> >>> > On Behalf Of Martijn Dashorst
> >>> > Sent: Wednesday, February 11, 2009 5:33 PM
> >>> > To: users@wicket.apache.org
> >>> > Subject: Wicket at ApacheCon EU'09 in Amsterdam
> >>> >
> >>> > We're happy to announce a lot of Wicket involvement at the upcoming
> >>> > ApacheCon in Amsterdam (23-27 March 2009)
> >>> >
> >>> > First of all we have 2 training sessions available:
> >>> >  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
> >>> > (http://tinyurl.com/aceu09wicket1)
> >>> >  - Behavior-Driving Your Apache Wicket Application by Timo
> >>> > Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2)
> >>> >
> >>> > Both courses are hosted by core members. Martijn has co-authored
> >>> > Wicket in Action and Timo has been involved with WicketTester and
> >>> > JDave. There is no better team to get you and your team up to speed
> >>> > with the finest Java web framework available and start cranking out
> >>> > fully tested applications.
> >>> >
> >>> > Martijn will also present Wicket in Action during the normal
> >>> > conference days. A quick introduction to Wicket's core features in
> just one hour.
> >>> > But attending the conference will give you much more:
> >>> > over 60 sessions covering your favorite Apache projects.
> >>> >
> >>> > Amsterdam is great, but Wicket meetups in Amsterdam are even better!
> >>> > We're attempting to schedule a Wicket meetup during the conference
> >>> > at the conference floor. Details will follow soon.
> >>> >
> >>> > Read more about ApacheCon EU 2009 here:
> >>> > http://www.eu.apachecon.com/c/aceu2009/
> >>> >
> >>> > See you in Amsterdam!
> >>> >
> >>> > Martijn
> >>> >
> >>> > --------------------------------------------------------------------
> >>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> > For additional commands, e-mail: users-help@wicket.apache.org
> >>> >
> >>> >
> >>> >
> >>> > --------------------------------------------------------------------
> >>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> > For additional commands, e-mail: users-help@wicket.apache.org
> >>> >
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Thomas Mäder
> >> Wicket & Eclipse Consulting
> >> www.devotek-it.ch
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Martijn Dashorst <ma...@gmail.com>.
Bill Joy from Sun once said: innovation happens elsewhere. I think
that the where elsewhere isn't, it is the JCP. Standardization is just
antithetical to innovation. Once something is fixed in brick/mortar
how can you innovate? Wicket is very comfortably located elsewhere.

Martijn

On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> we like the agility that the independence from any sort of a standard offers us.
>
> -igor
>
> On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William <wh...@nemours.org> wrote:
>> Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :(
>>
>> -----Original Message-----
>> From: tomlist0408@gmail.com [mailto:tomlist0408@gmail.com] On Behalf Of Thomas Mäder
>> Sent: Thursday, February 12, 2009 12:57 PM
>> To: users@wicket.apache.org
>> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
>>
>> I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide).
>> The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled "why wicket is cool" and more "cut your development costs in two with Wicket". From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts).
>>
>> Thomas
>>
>> On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner <jc...@gmail.com>wrote:
>>
>>> And then come into the horrible voting/administive stuff? Long Release
>>> cycles that are controlled, features that are discussed over and over.
>>>
>>> Hmm
>>>
>>> On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
>>> > Just out of curiosity... Are there any plans to push a JSR that
>>> > Wicket could follow. I think there would be a lot more acceptance of
>>> > Wicket if this was to happen :o)
>>> >
>>> > -----Original Message-----
>>> > From: martijn.dashorst@gmail.com [mailto:martijn.dashorst@gmail.com]
>>> > On Behalf Of Martijn Dashorst
>>> > Sent: Wednesday, February 11, 2009 5:33 PM
>>> > To: users@wicket.apache.org
>>> > Subject: Wicket at ApacheCon EU'09 in Amsterdam
>>> >
>>> > We're happy to announce a lot of Wicket involvement at the upcoming
>>> > ApacheCon in Amsterdam (23-27 March 2009)
>>> >
>>> > First of all we have 2 training sessions available:
>>> >  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
>>> > (http://tinyurl.com/aceu09wicket1)
>>> >  - Behavior-Driving Your Apache Wicket Application by Timo
>>> > Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2)
>>> >
>>> > Both courses are hosted by core members. Martijn has co-authored
>>> > Wicket in Action and Timo has been involved with WicketTester and
>>> > JDave. There is no better team to get you and your team up to speed
>>> > with the finest Java web framework available and start cranking out
>>> > fully tested applications.
>>> >
>>> > Martijn will also present Wicket in Action during the normal
>>> > conference days. A quick introduction to Wicket's core features in just one hour.
>>> > But attending the conference will give you much more:
>>> > over 60 sessions covering your favorite Apache projects.
>>> >
>>> > Amsterdam is great, but Wicket meetups in Amsterdam are even better!
>>> > We're attempting to schedule a Wicket meetup during the conference
>>> > at the conference floor. Details will follow soon.
>>> >
>>> > Read more about ApacheCon EU 2009 here:
>>> > http://www.eu.apachecon.com/c/aceu2009/
>>> >
>>> > See you in Amsterdam!
>>> >
>>> > Martijn
>>> >
>>> > --------------------------------------------------------------------
>>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>> >
>>> > --------------------------------------------------------------------
>>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> --
>> Thomas Mäder
>> Wicket & Eclipse Consulting
>> www.devotek-it.ch
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Igor Vaynberg <ig...@gmail.com>.
we like the agility that the independence from any sort of a standard offers us.

-igor

On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William <wh...@nemours.org> wrote:
> Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :(
>
> -----Original Message-----
> From: tomlist0408@gmail.com [mailto:tomlist0408@gmail.com] On Behalf Of Thomas Mäder
> Sent: Thursday, February 12, 2009 12:57 PM
> To: users@wicket.apache.org
> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
>
> I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide).
> The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled "why wicket is cool" and more "cut your development costs in two with Wicket". From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts).
>
> Thomas
>
> On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner <jc...@gmail.com>wrote:
>
>> And then come into the horrible voting/administive stuff? Long Release
>> cycles that are controlled, features that are discussed over and over.
>>
>> Hmm
>>
>> On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
>> > Just out of curiosity... Are there any plans to push a JSR that
>> > Wicket could follow. I think there would be a lot more acceptance of
>> > Wicket if this was to happen :o)
>> >
>> > -----Original Message-----
>> > From: martijn.dashorst@gmail.com [mailto:martijn.dashorst@gmail.com]
>> > On Behalf Of Martijn Dashorst
>> > Sent: Wednesday, February 11, 2009 5:33 PM
>> > To: users@wicket.apache.org
>> > Subject: Wicket at ApacheCon EU'09 in Amsterdam
>> >
>> > We're happy to announce a lot of Wicket involvement at the upcoming
>> > ApacheCon in Amsterdam (23-27 March 2009)
>> >
>> > First of all we have 2 training sessions available:
>> >  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
>> > (http://tinyurl.com/aceu09wicket1)
>> >  - Behavior-Driving Your Apache Wicket Application by Timo
>> > Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2)
>> >
>> > Both courses are hosted by core members. Martijn has co-authored
>> > Wicket in Action and Timo has been involved with WicketTester and
>> > JDave. There is no better team to get you and your team up to speed
>> > with the finest Java web framework available and start cranking out
>> > fully tested applications.
>> >
>> > Martijn will also present Wicket in Action during the normal
>> > conference days. A quick introduction to Wicket's core features in just one hour.
>> > But attending the conference will give you much more:
>> > over 60 sessions covering your favorite Apache projects.
>> >
>> > Amsterdam is great, but Wicket meetups in Amsterdam are even better!
>> > We're attempting to schedule a Wicket meetup during the conference
>> > at the conference floor. Details will follow soon.
>> >
>> > Read more about ApacheCon EU 2009 here:
>> > http://www.eu.apachecon.com/c/aceu2009/
>> >
>> > See you in Amsterdam!
>> >
>> > Martijn
>> >
>> > --------------------------------------------------------------------
>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>> > --------------------------------------------------------------------
>> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Thomas Mäder
> Wicket & Eclipse Consulting
> www.devotek-it.ch
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by "Hoover, William " <wh...@nemours.org>.
Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :(

-----Original Message-----
From: tomlist0408@gmail.com [mailto:tomlist0408@gmail.com] On Behalf Of Thomas Mäder
Sent: Thursday, February 12, 2009 12:57 PM
To: users@wicket.apache.org
Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam

I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide).
The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled "why wicket is cool" and more "cut your development costs in two with Wicket". From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts).

Thomas

On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner <jc...@gmail.com>wrote:

> And then come into the horrible voting/administive stuff? Long Release 
> cycles that are controlled, features that are discussed over and over.
>
> Hmm
>
> On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
> > Just out of curiosity... Are there any plans to push a JSR that 
> > Wicket could follow. I think there would be a lot more acceptance of 
> > Wicket if this was to happen :o)
> >
> > -----Original Message-----
> > From: martijn.dashorst@gmail.com [mailto:martijn.dashorst@gmail.com] 
> > On Behalf Of Martijn Dashorst
> > Sent: Wednesday, February 11, 2009 5:33 PM
> > To: users@wicket.apache.org
> > Subject: Wicket at ApacheCon EU'09 in Amsterdam
> >
> > We're happy to announce a lot of Wicket involvement at the upcoming 
> > ApacheCon in Amsterdam (23-27 March 2009)
> >
> > First of all we have 2 training sessions available:
> >  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
> > (http://tinyurl.com/aceu09wicket1)
> >  - Behavior-Driving Your Apache Wicket Application by Timo 
> > Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2)
> >
> > Both courses are hosted by core members. Martijn has co-authored 
> > Wicket in Action and Timo has been involved with WicketTester and 
> > JDave. There is no better team to get you and your team up to speed 
> > with the finest Java web framework available and start cranking out 
> > fully tested applications.
> >
> > Martijn will also present Wicket in Action during the normal 
> > conference days. A quick introduction to Wicket's core features in just one hour.
> > But attending the conference will give you much more:
> > over 60 sessions covering your favorite Apache projects.
> >
> > Amsterdam is great, but Wicket meetups in Amsterdam are even better!
> > We're attempting to schedule a Wicket meetup during the conference 
> > at the conference floor. Details will follow soon.
> >
> > Read more about ApacheCon EU 2009 here:
> > http://www.eu.apachecon.com/c/aceu2009/
> >
> > See you in Amsterdam!
> >
> > Martijn
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


--
Thomas Mäder
Wicket & Eclipse Consulting
www.devotek-it.ch


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Thomas Mäder <th...@devotek-it.ch>.
I totally agree that the JSR process is horrid. However, Wicket could really
use some more corporate credibility (which a JSR would provide).
The problem, I guess is that there are simply no corporate interests behind
Wicket that would push the agenda. What wicket need is some evangelism, but
I guess all the core people have real jobs. What we need is less talks
titled "why wicket is cool" and more "cut your development costs in two with
Wicket". From experience, I am totally convinced that you can save 50% off
your development costs if you switch to wicket (from just about any other
framework), however, I've yet to find a contracting job here in Zürich where
wicket is asked for (it's JSF, or even Struts).

Thomas

On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner <jc...@gmail.com>wrote:

> And then come into the horrible voting/administive stuff? Long Release
> cycles that are controlled, features that are discussed over and over.
>
> Hmm
>
> On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
> > Just out of curiosity... Are there any plans to push a JSR that Wicket
> > could follow. I think there would be a lot more acceptance of Wicket if
> > this was to happen :o)
> >
> > -----Original Message-----
> > From: martijn.dashorst@gmail.com [mailto:martijn.dashorst@gmail.com] On
> > Behalf Of Martijn Dashorst
> > Sent: Wednesday, February 11, 2009 5:33 PM
> > To: users@wicket.apache.org
> > Subject: Wicket at ApacheCon EU'09 in Amsterdam
> >
> > We're happy to announce a lot of Wicket involvement at the upcoming
> > ApacheCon in Amsterdam (23-27 March 2009)
> >
> > First of all we have 2 training sessions available:
> >  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
> > (http://tinyurl.com/aceu09wicket1)
> >  - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on
> > Tue 24 March (http://tinyurl.com/aceu09wicket2)
> >
> > Both courses are hosted by core members. Martijn has co-authored Wicket
> > in Action and Timo has been involved with WicketTester and JDave. There
> > is no better team to get you and your team up to speed with the finest
> > Java web framework available and start cranking out fully tested
> > applications.
> >
> > Martijn will also present Wicket in Action during the normal conference
> > days. A quick introduction to Wicket's core features in just one hour.
> > But attending the conference will give you much more:
> > over 60 sessions covering your favorite Apache projects.
> >
> > Amsterdam is great, but Wicket meetups in Amsterdam are even better!
> > We're attempting to schedule a Wicket meetup during the conference at
> > the conference floor. Details will follow soon.
> >
> > Read more about ApacheCon EU 2009 here:
> > http://www.eu.apachecon.com/c/aceu2009/
> >
> > See you in Amsterdam!
> >
> > Martijn
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Thomas Mäder
Wicket & Eclipse Consulting
www.devotek-it.ch

Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Johan Compagner <jc...@gmail.com>.
And then come into the horrible voting/administive stuff? Long Release
cycles that are controlled, features that are discussed over and over.

Hmm

On 12/02/2009, Hoover, William <wh...@nemours.org> wrote:
> Just out of curiosity... Are there any plans to push a JSR that Wicket
> could follow. I think there would be a lot more acceptance of Wicket if
> this was to happen :o)
>
> -----Original Message-----
> From: martijn.dashorst@gmail.com [mailto:martijn.dashorst@gmail.com] On
> Behalf Of Martijn Dashorst
> Sent: Wednesday, February 11, 2009 5:33 PM
> To: users@wicket.apache.org
> Subject: Wicket at ApacheCon EU'09 in Amsterdam
>
> We're happy to announce a lot of Wicket involvement at the upcoming
> ApacheCon in Amsterdam (23-27 March 2009)
>
> First of all we have 2 training sessions available:
>  - Introduction to Wicket by Martijn Dashorst on Mon 23 March
> (http://tinyurl.com/aceu09wicket1)
>  - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on
> Tue 24 March (http://tinyurl.com/aceu09wicket2)
>
> Both courses are hosted by core members. Martijn has co-authored Wicket
> in Action and Timo has been involved with WicketTester and JDave. There
> is no better team to get you and your team up to speed with the finest
> Java web framework available and start cranking out fully tested
> applications.
>
> Martijn will also present Wicket in Action during the normal conference
> days. A quick introduction to Wicket's core features in just one hour.
> But attending the conference will give you much more:
> over 60 sessions covering your favorite Apache projects.
>
> Amsterdam is great, but Wicket meetups in Amsterdam are even better!
> We're attempting to schedule a Wicket meetup during the conference at
> the conference floor. Details will follow soon.
>
> Read more about ApacheCon EU 2009 here:
> http://www.eu.apachecon.com/c/aceu2009/
>
> See you in Amsterdam!
>
> Martijn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket at ApacheCon EU'09 in Amsterdam

Posted by Christopher Armstrong <ca...@fastmail.com.au>.
Hi all

I'm new to this list (and Wicket), and was interested in this  
discussion.

On 12/02/2009, at 11:32 PM, Hoover, William wrote:

> Just out of curiosity... Are there any plans to push a JSR that Wicket
> could follow. I think there would be a lot more acceptance of Wicket  
> if
> this was to happen :o)
> --------

It might be interesting to examine this idea in the context of OSGi.  
OSGi is a standard for componentisation and packaging and component  
lifecycle management that has it roots in embedded devices, and  
incorporates a whole range of further standards related to this type  
of platform. It grew out of efforts that were mostly independent of  
Sun, and has continued to evolve as a standard in a separate  
organisation to the JSR process.

It now has a JSR (277), but the OSGi specifications evolve separately  
of this original JSR. It has multiple implementations (Felix, Equinox,  
Knopflerfish, etc). Its flexibility in its design (extender bundles,  
manifest extensions, whiteboard model, etc assist this) has led to  
many addons that build upon it such as Spring DM, iPOJO, etc. In the  
next version of the specification many of these community ideas will  
be incorporated back into the main specifications. The Core OSGi  
specification doesn't add much to the language, but its Compedium  
specifications, which build upon the Core spec, provide everything  
from configuration management, device resolution, to user  
administration and logging.

Sun were looking at using it in Java 7 in order to modularise the JVM,  
a similar goal to the Apache Harmony project IIRC. They have since  
dropped this goal and have revived JSR 294 for modularisation. OSGi  
continues to move along alone and gain its own popularity without the  
JSR/JCP process. Sun's attitude seems to be to just ignore OSGi (a  
form of NIH syndrome?).

IMHO what this means for Wicket is: unless it provides a small base  
for lots of extra functionality to be built upon, its just going to  
get mired in the politics of the JSR/JCP process and not really  
achieve anything. It will probably end up being shunned as a  
competitor to JSF and left unresolved.

It may be better for Wicket to look at managing its own APIs so there  
is less breakage between versions (note: I've only begun using Wicket  
recently so I'm not trying to suggest this is the case) and that  
versions are clearly delineated in terms of API compatibility between  
them. It could try and elevate the Wicket extensions to be more  
tightly managed within the Wicket project, and seek from time to time  
to incorporate these back in into the Wicket mainline. In this way,  
Wicket becomes "standardised" but still maintains the freedom to  
innovate more quickly. Wicket seems to be tightly modularised enough  
(or able to modularised) that using Wicket as a base to grow new and  
interesting functionality whilst maintaining a stable core seems  
feasible.

Cheers
Chris

---
Christopher Armstrong
carmstrong at fastmail com au.







--------
Christopher Armstrong
carmstrong@fastmail.com.au






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


RE: Wicket at ApacheCon EU'09 in Amsterdam

Posted by "Hoover, William " <wh...@nemours.org>.
Just out of curiosity... Are there any plans to push a JSR that Wicket
could follow. I think there would be a lot more acceptance of Wicket if
this was to happen :o)

-----Original Message-----
From: martijn.dashorst@gmail.com [mailto:martijn.dashorst@gmail.com] On
Behalf Of Martijn Dashorst
Sent: Wednesday, February 11, 2009 5:33 PM
To: users@wicket.apache.org
Subject: Wicket at ApacheCon EU'09 in Amsterdam

We're happy to announce a lot of Wicket involvement at the upcoming
ApacheCon in Amsterdam (23-27 March 2009)

First of all we have 2 training sessions available:
 - Introduction to Wicket by Martijn Dashorst on Mon 23 March
(http://tinyurl.com/aceu09wicket1)
 - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on
Tue 24 March (http://tinyurl.com/aceu09wicket2)

Both courses are hosted by core members. Martijn has co-authored Wicket
in Action and Timo has been involved with WicketTester and JDave. There
is no better team to get you and your team up to speed with the finest
Java web framework available and start cranking out fully tested
applications.

Martijn will also present Wicket in Action during the normal conference
days. A quick introduction to Wicket's core features in just one hour.
But attending the conference will give you much more:
over 60 sessions covering your favorite Apache projects.

Amsterdam is great, but Wicket meetups in Amsterdam are even better!
We're attempting to schedule a Wicket meetup during the conference at
the conference floor. Details will follow soon.

Read more about ApacheCon EU 2009 here:
http://www.eu.apachecon.com/c/aceu2009/

See you in Amsterdam!

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org