Hi Frank, Sorry for the late reply. We are currently migrating our main application from Wicket 1.3 to 1.4 and contextually upgrading ext-wicket. This might eventually be the right occasion to update the project, though we are still targetting Ext 2.2.
With regard to behaviors and components, we felt it was useful to keep them separate in spite of a small overhead, as it is always easy to merge them but much more complicated to extract a behavior from a component. Anyway, ext-wicket was born to help up support Ext-JS components we found interesting for our applications, and not to provide a clean and complete mapping of Ext features into Wicket. Therefore, its architecture is far from perfect! Is your integration effort moving forward? Kind regards, Fabio On Wed, Sep 29, 2010 at 4:43 PM, Frank van Lankvelt <f.vanlankv...@onehippo.com> wrote: > hi Fabio, > > good to hear it is in active use and development! There might be more users > than you think; perhaps you can get them to voice their enthousiasm. Might > help to find the time to publish the changes? > > Concerning your example, some behaviors are definitively offered best as > actual wicket behaviors. Tooltips, data stores, other services you need > from the client. But I still wonder whether that justifies the overhead, > considering the large number of components. Are there other motivations > like, I could imagine, needing to subclass the FormComponent to be able to > participate in form processing? > > thanks, Frank --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
