Here is how I managed to do ajax refresh:
final Component
newDummyAjaxUpdateComponentFromMarkup =
TakpPanelWithDynamicMarkup.newDummyAjaxUpdateComponentFromMarkup(freshMarkup,
markupId, false);
if (newDummyAjaxUpdateComponentFromMarkup != null) {
target.addComponent(newDummyAjaxUpdateComponentFromMarkup);
}
public static Component newDummyAjaxUpdateComponentFromMarkup(String
freshMarkup, String markupId, boolean required) {
XmlPullParser xmlPullParser = new XmlPullParser();
try {
xmlPullParser.parse(freshMarkup);
} catch (Exception e) {
throw new RuntimeException(e);
}
XmlTag xmlTag = findStartTag(xmlPullParser, markupId);
if (xmlTag != null) {
final StringBuilder stringBuilder = new StringBuilder();
final int startEndPosition;
{
final String tagAsString = xmlTag.toString();
stringBuilder.append(tagAsString);
startEndPosition = xmlTag.getPos() + tagAsString.length();
}
{
try {
xmlTag = (XmlTag) xmlPullParser.nextTag();
} catch (Exception e) {
if (required) {
throw new RuntimeException(e);
}
// else
Utils.errorLog(TakpPanelWithDynamicMarkup.class, e);
}
stringBuilder.append(xmlPullParser.getInput(startEndPosition,
xmlTag.getPos())); // Value inside
stringBuilder.append(xmlTag.toString());
}
return new TakpPanelWithDynamicMarkup(markupId) {
private transient IResourceStream markupResourceStream;
@Override
public IResourceStream getMarkupResourceStream(MarkupContainer
container, Class<?> containerClass) {
if (markupResourceStream == null) {
final StringBufferResourceStream stream = new
StringBufferResourceStream();
stream.append("<wicket:panel>");
stream.append(stringBuilder);
stream.append("</wicket:panel>");
markupResourceStream = new MarkupResourceStream(stream);
}
return markupResourceStream;
}
};
} else if (required) {
throw new IllegalStateException("Component with markup id " +
markupId + " not found from markup stream " + freshMarkup);
}
return null;
}
It could be streamlined ofcourse.. with duality it could be native
part of wicket ;)
**
Martin
2012/2/25 Per <p...@hamburg.de>:
> Hi Martin,
>
> some of the things we did was (as mentioned by others) to generate HTML,
> this saved a lot of memory. But also to look really hard at the component
> tree and decide if everything was needed *all the time*. For instance, we
> had plenty of AJAX links that were rarely used (5 per row or so). We decided
> to make them load on demand only ("click for admin actions"). This saved
> some 500 bytes per row. Also, some optimisations like replacing
> setVisible(false) by an empty component saved us some space. Some component
> use more memory than others, and can be replaced. Etc. It's really crucial
> to use a profiler to see where all the bytes go. I wrote a blogpost over
> here:
> http://www.small-improvements.com/blog/technical/tuning-wicket-session-size
> a few months ago. You may even want to create your own eviction-policy that
> collects certain pages more aggressively than others (if applicable). Many
> options.
>
> But yeah, it's tough, it's one of the things I found most challenging about
> Wicket. I'd love to hear how you end solving with the problem, maybe there's
> something else to be learned!
>
> Good luck!
> Per
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Performance-optimization-tp4412659p4419111.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
