A minor point - There's an 'open' section on the Wiki at http://wicket.sourceforge.net/wiki/doku.php?id=open:top that can (currently) be edited by anyone, without needing any registration. It's mentioned on the Wiki front page, although only at the bottom! :-)
/Gwyn On Tue, 08 Feb 2005 22:58:50 +0100, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > We do have a project wiki: http://wicket.sf.net/wiki > > It is only editable by registered sf.net users, there is no need to be a > project member to edit the wiki. You *DO* have to register on the wiki > itself. This process is kind of tricky, since most members have troubles > getting their passwords in their email box. > > Not to everyone: please use the wiki for staging your documentation. We > can put it in the documentation section later when we have a good place > for it. > > Martijn > > > Jonathan Carlson wrote: > > > Thanks Eelco and Jonathan. Your detailed descriptions have been very > > helpful. Too bad you don't have a wicket wicki (I like that!) where > > you could just paste this e-mail into in the meantime. > > > > There really is a learning curve to Wicket so I need to make myself go > > over the examples/userdoc again and again before it really starts > > sinking in. But once that learning curve is scaled, it's a wonderful > > environment. It is almost deceptively easy to get going with Wicket > > (I think :-) > > > > > > ------------------------------------------ > > Jonathan Locke wrote: > > we could use more complete docs on this issue and surely a FAQ entry > > when i can get to it. > > > > in the meantime, it sounds to me like you may still be thinking in terms > > of other frameworks. perhaps tapestry? you need to try to unlearn that > > stuff to some degree. wicket is not a version of tapestry or any other > > framework. its design goals and implementation are quite different. > > > > in general, pages and components in wicket are reused only when you > > implicitly reuse them in your java code. if you create a PageLink, > > you'll (most likely) create a new Page object each time that link is > > clicked. but if a link is an anonymous Link subclass, the page will > > remain unchanged and will be reused implicitly during rendering. spend > > some time staring at the linkomatic and navomatic examples and you'll > > come to understand. basically, if a new page isn't set somehow, the > > original page is re-rendered. > > > > this kind of page rendering reuse typically happens when pages reference > > themselves via self-links or form submits or the like. when this > > occurs, there may be multiple renderings of the same page object cached > > in the client's browser. when pages have self-referential links which > > cause structural modifications to their model, there is the potential > > for stale markup issues. wicket detects this if you tell it when the > > model has changed. there is a good example of this is in the user's > > guide (which is very out of date now) and the library application. when > > you delete a row in the library application, the delete link is > > implemented like this: > > > > listItem.add(listItem.removeLink("remove")); > > > > which looks very simple. but a lot of logic is hidden by this. first, > > removeLink is implemented like this: > > > > public final Link removeLink(final String componentName) > > { > > return new Link(componentName) > > { > > public void linkClicked() > > { > > // Remove listItem and invalidate listView > > listView.getList().remove(index); > > listView.invalidateModel(); > > } > > }; > > } > > > > and the invalidateModel() call results in marking of previous renderings > > of the page as stale. for example, the rendering of the page you can > > get to with the back button in the browser, which will have one more row > > than the current page in the browser. > > > > my advice in general about attempting to do any component > > caching/sharing is that it is probably a good way to get burned if > > you're not careful. we do need a best-practices document on this, but > > i'm too busy working on the core right now to get that done. > > > > anyway, the whole design of wicket is contrary to the idea of trying to > > share components to save memory. a page can re-render itself and that > > is about as much reuse as there is. the basic paradigm is to just > > contruct pages along with all those nested components wholesale. yes, > > this DOES cost something. but what it costs is a commodity item (memory > > and CPU) while what wicket saves (programming effort and time-to-market) > > is relatively precious. if you want to scale wicket, just keep things > > simple, robust, secure, flexible, etc... don't optimize prematurely... > > and buy more $300 emachines servers. > > > > Jonathan Carlson wrote: > > > > > Thanks. I thought I had noticed the opposite behavior (new components > > > being created for each hit) but that must be due to the way I was > > > creating my components. I better look at the examples more closely. > > > > > > If each page is cached in the session, how does it handle different > > > browser windows using the same session and accessing the same page > > > with different data? > > > > > > Sorry for my ignorance on this, but I guess I should understand this > > > before I go any further. If it's in the docs and I just missed it > > > feel free to direct me there. > > > > > > - Jonathan > > > > > > > > > >>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 2005-02-07 > > 2:29:04 PM >>> > > > i'm not sure what you mean by "service objects", but wicket doesn't > > > generally provide for directly putting stuff in the session. it's not > > > necessary because applications, pages and components are all first class > > > objects that are part of the session. so generally, you don't touch the > > > session. instead, you just create a field in your subclass in the usual > > > OO fashion. make sense? this issue comes up a bunch, so i think i'll > > > add a FAQ entry on this issue. > > > > > > jon > > > > > > Jonathan Carlson wrote: > > > > > > > I am wondering what wicket might provide for caching service objects > > > > somewhere in session-scope or application-scope. > > > > > > > > For example, I could just use the standard Servlet APIs for putting > > > > objects into the session, but I wanted to know if Wicket > > > > provided anything more convenient for stuff like that. Eventually, I > > > > will probably use PicoContainer for dependency injection, but my needs > > > > at the moment are pretty basic. > > > > > > > > Thanks, > > > > > > > > Jonathan > > > > > > > > > > ********************************************************************** > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please notify > > the system manager. > > > > www.katun.com > > ********************************************************************** > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Wicket-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
