Well complaining is always easy... You have to remember this project, as many other open source projects, is largely made by people on their free time. So, if you feel documentation is deficient why not try to volunteer and help make it better. My experience is that this is a very friendly and helpful community where people will try to help you if you ask things nicely and in proper terms. Another thing. As software developer you should get used to use software with deficient and no documentation at all... Even more if you have the (excellent) source code at hand and lots of examples illustrating how things work.
It also took me sometime to get used to the "Wicket way" to develop WEB applications. But at the end you will see it is worth the extra effort! Regards, Ernesto On Wed, Oct 7, 2009 at 9:23 AM, Robin Sander <[email protected]> wrote: > > I didn't suggest improvements but second a question anotherone asked in > this thread. > And as a user I usually don't write re-usable components (in the sense > re-usable by other people), > so this is not my focus. > > And regarding the excellent wiki page: that's one thing I don't like about > wicket. Documentation is > not were in belongs, in the code or at least checked in with the code. I > always have to figure > it out by myself if some wiki page is up-to-date or not. > I really never had such a hard time understanding a framework! (but to > repeat myself, I'm not used > to think in components when it comes to web design, so that's probably just > me) > Take for example Spring or Hibernate: the latest reference always comes > with the distribution and > the code is documented very well. (and maybe better aligns to my thinking) > > > > On Oct 6, 2009, at 18:54, Igor Vaynberg wrote: > > so maybe, in the future, you can take the time to understand why the >> things are what they are first and then suggest improvements :) >> >> there is an excellent page about models on our wiki. have a look, >> maybe it will make things clear. >> >> -igor >> >> On Tue, Oct 6, 2009 at 9:48 AM, Robin Sander <[email protected]> >> wrote: >> >>> >>> In this case one would have to use a Wrapper-Class which implements a >>> special interface Wicket >>> reacts on. Something like >>> >>> class personeditor extends panel { >>> >>> public personeditor(string id, person p) { >>> super(id, new DetachableWrapper(p)); // let DetachableWrapper >>> implement ModelWrapper >>> } >>> >>> And then Component.getDefaultModelObject() reacts on ModelWrapper >>> interface >>> (like on IModel now) >>> >>> Object getDefaultModelObject() { >>> if (model instanceof ModelWrapper) { >>> return ((ModelWrapper)model).getObject(); >>> } else { >>> return model' >>> } >>> >>> But then personeditor would hard code the detachable stuff so for >>> re-usable >>> components this solution >>> would be worse than the current one. >>> >>> I must admit that I don't get the whole detachable stuff in Wicket. I'm >>> used >>> to think in horizontal tiers >>> where one tier does all the caching "automagically" (e.g. 2nd level cache >>> in >>> JPA/Hibernate) and the >>> other tiers don't know about that fact. In addition, I'm so used to think >>> in >>> the request/response pattern >>> that the Wicket component model is really hard to get for me (never did >>> any >>> Swing...) >>> >>> >>> >>> On Oct 6, 2009, at 17:09, Igor Vaynberg wrote: >>> >>> so if i have >>>> >>>> class personeditor extends panel { >>>> public personeditor(string id, person p) {..} } >>>> >>>> instead of >>>> >>>> class personeditor extends panel { >>>> public personeditor(string id, imodel<person> p) {..} } >>>> >>>> how do i implement the lazy loading behavior if the person has to be >>>> loaded from the database? >>>> >>>> -igor >>>> >>>> On Tue, Oct 6, 2009 at 12:36 AM, Robin Sander <[email protected]> >>>> wrote: >>>> >>>>> >>>>> Ok, I overlooked that IModel extends IDetachable but besides the >>>>> detach() >>>>> method >>>>> - which would be a special model behaviour in my opinion - IModel does >>>>> have >>>>> two >>>>> methods only: >>>>> >>>>> T getObject(); >>>>> void setObject(final T object); >>>>> >>>>> Where's the benefit of using >>>>> new Component<MyBean>("xy", new Model<MyBean>(myBean)) >>>>> and then access the actual model (object) by using >>>>> getObject()/setObject() >>>>> instead of >>>>> new Component<MyBean>("xy", myBean) >>>>> and then having a field >>>>> T model; >>>>> which could be directly accessed? (or even wrapped if you want to >>>>> implement >>>>> additional >>>>> stuff) >>>>> >>>>> A user may add still addional behaviour by implementing special >>>>> interfaces >>>>> like Detachable >>>>> or something. This approach looks more natural for me but I'm asking >>>>> more >>>>> out of curiosity... >>>>> >>>>> >>>>> On Oct 5, 2009, at 18:32, Jeremy Thomerson wrote: >>>>> >>>>> On Mon, Oct 5, 2009 at 7:44 AM, Robin Sander <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Another question because someone mentioned it in this thread and I >>>>>>> asked >>>>>>> this question myself: >>>>>>> why do we need an empty interface for Model? Why can't a mere String >>>>>>> or >>>>>>> any >>>>>>> serializable POJO be >>>>>>> used as a model? (than this discussion about the name would end >>>>>>> also...) >>>>>>> >>>>>>> >>>>>> I'm not sure I understand what you're saying. IModel is currently the >>>>>> interface and is not an empty interface. And an instance of IModel is >>>>>> a >>>>>> data proxy / location service - not the actual data itself - which is >>>>>> whay >>>>>> any POJO can not be a model. The POJO is the model object. >>>>>> >>>>>> -- >>>>>> Jeremy Thomerson >>>>>> http://www.wickettraining.com >>>>>> >>>>> >>>>> >>>>> >>> >>> >
