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
