RE: css resources location
Hmm... Open the resulting war file and check that the path is correct. At the project im working on the CSS file is outside the WEB-INF/classes folder and with the aproach i mentioned it works. war structure is like this: project.war - css - WEB-INF - ... Hope it helps. On Thu, 2010-03-25 at 18:23 -0300, Matias Pansa wrote: Thanks for the quick response , i try this way and it's not working . The href is correct but the css file it's not loaded , even try using the same lines included in the wicket example app for netbeans using StyleSheetReference (...) and nothing. In the example app the style.css file is in the same folder with the java and html files , the example works ok. By now i just forget the images , just trying to make de css file work , href=resources/com.com.myapp.HomePage/My.css but the page is not showin the css atributes. Subject: Re: css resources location From: corneliu.petre...@theredpoint.ro To: users@wicket.apache.org Date: Thu, 25 Mar 2010 19:25:03 +0200 You've probably got the path wrong. Try: String contextPath = ((WebRequest)getRequest()).getHttpServletRequest().getContextPath(); construct path like this String path = contextPath + relative_css_path; CSSPackageResource.getHeaderContribution(path); On Thu, 2010-03-25 at 14:08 -0300, Matias Pansa wrote: Hi , i'm new to wicket . I been searching in the list archive for css resource problems but i can't found a solution . My app is developed under netbeans and there's no way to make de css ( file or html embedded ) to work with wicket . I try almost every way that i found on the archive of this list , but nothing work. When i preview the html in the browser everything is ok , css ,images etc , but when i deploy to tomcat only css is rendered ok , images are not showed. here is what i've used : 1 - css embedded in the html file , css is ok but images are no showed , i try almost every path ( background-image : url( ) ... ) posible to the images , same as the html and java files , web folder , web-inf , image folder , resources ,etc. I check that resource images are in the war file. 2- wicket:head tag with headercontributor.forcss(...) , css and images not working at all in every folder of the app. I try almost every solution found on the mail list , nothing works to show the images , so now i'm lost , the most basic solution was put all the css code in the html file and nothing. here is the tree of the app in netbeans : Shirosecurity - -web pages -meta-inf -web-inf -configuration files -server resources -sourcepackages -com.myapp.wicket --- java and html files -test packages -libraries i would apreciate any help on this. _ Mirá tus emails ¡cuando te llegan! Hotmail actualiza tu bandeja de entrada automáticamente. Ver más http://www.descubrewindowslive.com/hotmail/actualizacion-guardado.asp _ Mirá tus emails ¡cuando te llegan! Hotmail actualiza tu bandeja de entrada automáticamente. Ver más http://www.descubrewindowslive.com/hotmail/actualizacion-guardado.asp - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax refresh problem with WebMarkupContainer and CSS class in DeploymentMode
Because it is urgent, I tried some changes without success.
It seems to be the AjaxFallBackLink in the dataview, wich causes the table
not to be shown when the page shows up.
Is there any other possibility to show a modal window without an AjaxLink?
Here is some code of the dataview with the link ...
dataView = new DataViewWebConfig(sorting, dp) {
private static final long serialVersionUID = 1L;
/*
* (non-Javadoc)
* @see
org.apache.wicket.markup.repeater.data.DataViewBase#onDetach()
*/
@Override
protected void onDetach() {
super.onDetach();
}
/*
* (non-Javadoc)
* @see
org.apache.wicket.markup.repeater.RefreshingView#populateItem(org.apache.wicket.markup.repeater.Item)
*/
@Override
protected void populateItem(final ItemWebConfig item) {
WebConfig con = (WebConfig)
item.getModelObject();
AjaxLinkWebConfig detailLink = new
AjaxLinkWebConfig(detailLink) {
private static final long
serialVersionUID = 1L;
@Override
public void onClick(AjaxRequestTarget
target) {
WebConfig item = (WebConfig)
getParent()
.getDefaultModelObject();
LOGGER.debug(show details +
item.getKey() + ...);
modalNewConfig.setTitle(Configuration Parameter - Details);
modalNewConfig.setContent(new
NewConfigPanel(modalNewConfig.getContentId(),
item, true,
feedback,modalNewConfig));
modalNewConfig.show(target);
target.appendJavascript(document.getElementById('inKey').focus());
}
};
item.add(detailLink);
detailLink.add(new Label(key,con.getKey()));
...
Thanks in advance, Peter
--
View this message in context:
http://old.nabble.com/Ajax-refresh-problem-with-WebMarkupContainer-and-CSS-class-in-DeploymentMode-tp27998174p28039133.html
Sent from the Wicket - User 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
Re: Caching components
We have a lot of Repeating views, which containing a lot of components, which also contains repeatingviews. To know would should be rendered, we load some hopefully small (listsizes, objectbyId, ...) datas from DB in the constructor and/or in onBeforeRender and in isVisible. You are right, this is not a recommented way. Most of the time is database-loading and wicket has no performance-problem for us. We profile our application and never found wicket-components as hotspots. One reason for loading some data in contstructur or onBeforeRender is to prevent creating huge hierarchies. This is faster than override isVisible(), since isVisible would called more than one times. For our usecase the responsetime is much faster with HTML-Caching, because the Database-calls are minimized. We save the time for creating componentshierarchies (all three categories) with loading data. Martin Jeremy Thomerson schrieb: On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs sachs.mar...@gmail.com mailto:sachs.mar...@gmail.com wrote: hi, we need caching of components, since the construction of huge hierarchies is not cheap. The rendering ist fast. We cache the rendered HTML of a hole component via a beheaviour and write them on the next requests into a Label (unescaped). So instead of creating the complete hierarchie on every request, we create a much smaller one. But you must check, that the cachable components are stateless. Also we have JQuery for client-effects in this components, this would also be cached. The performance is much better with that: approx. 10-50 times better: 100ms with cache (the response time is not much depending on count of users) vs 1500 ms without cache depending how many parallel user A 15x gain is a big statement to make. Can you please break this 1500ms down into at least the following categories: 1 - time in IModel#getObject() and all child calls of this (IOW, loading data) 2 - time in constructor of components (without loading data in the constructor - hopefully you're not doing this) 3 - time in rendering of components That would be a much better number to give other users. I have NEVER seen where creating / rendering components could take 1400ms - unless you're doing something wrong like database calls in your component constructors. So, I suspect that most of that 1400ms (I would guess at least 1250ms) is in your model loading. The only time I've seen (or seen proof of) the component hierarchy actually be the slow part of a Wicket page is if you were displaying a repeating view of some sort with thousands of rows and each row had a bunch of components in it - leading to tens of thousands of components being built in the hierarchy. -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: DatePicker and visibility of the parent component
We had the same problem. It probably can be solved in a better way (but
that would require a RFE and changes to Wicket), but we used a quick and
easy solution (tm).
Instead of actually setting isVisible() on the Date Picker, we just hide
it using CSS. I don't know if this is applicable in your use case with
wicket:enclosure.
@Override
public void onRendered(Component component) {
if (!isReadOnly()) {
super.onRendered(component);
} else {
Response response = component.getResponse();
response.write(\ndiv style=\display:none;\);
super.onRendered(component);
response.write(\n/div);
}
}
});
We're using isReadOnly() (non-standard Wicket method) to determine if
DatePicker should be visible or not. You probably could be using
setVisible() isVisible() using overrides and some tweaks.
Hi,
I have date picker added to a date field.
DateTextField field = new DateTextField(field, -MM-dd);
field1.add(new DatePicker());
If the section the date picker is in is visible there is no problem. If
the
section is not visible using wicket:enclosure, I get an error:
http://localhost:8080/resources/org.apache.wicket.extensions.yui.YuiLib/calendar/calendar.jsUncaught
TypeError: Cannot read property 'id' of null
Re: Inject Dao ( with JPA impl) into Wicket without Spring ?
We have put all lookup in the wicket application class. Thus all pages do: getApplication().getWhatEverService(). I belive this make unit testing a bit easier since you mock the application the same way every time. /Per On Tue, Mar 23, 2010 at 6:05 PM, smallufo small...@gmail.com wrote: 2010/3/24 smallufo small...@gmail.com Thank you , I tried it , and it can successfully inject EntityManagerFactory into a WebPage , But it seems unable to inject EntityManager , is it because of some thread-safe limitation here ? Sorry , I meant wicket-contrib-javaee here. 2010/3/23 Major Péter majorpe...@sch.bme.hu I think yes, Wicket is already depending on cglib, so you could create something like this: http://fisheye6.atlassian.com/browse/wicket/branches/wicket-1.4.x/wicket-spring/src/main/java/org/apache/wicket/spring/SpringBeanLocator.java?r=HEAD or for non-spring code check out the wicketstuff javaee-inject project. Best Regards, Peter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxSubmitLink not calling the onsubmit event handler
Did you get a resolution to this issue? I have the same problem.
currently i am using this techniques to do the my stuff.But it
breaks when the user press return key.
// save this so we can call it later
var wicketOnClick = ajaxSubmitLink.onclick;
ajaxSubmitLink.onclick = function() {
// do your stuff
return wicketOnClick();
};
Is this expected behavior I wonder, or a bug?
SubmitLink will call the form's onsubmit='???' handler,
AjaxSubmitLink does not.
AFAIK AjaxSubmitLink doesn't fire the submit event. Is serializes the form
data and then makes a post call. I guess this
can't be fixed easily because wicket is using *inline event registration
model*.
On 4 January 2010 23:05, Anantha Kumaran ananthakuma...@gmail.com wrote:
hi pieter
my problem is that the AjaxSubmitLink is not behaving like the SubmitLink
which calls the onsubmit before submitting
the form.currently i am using the mousedown(can't use onclick) of the
AjaxSubmitLink to do the validation stuffs but it breaks when the user
submit the form by pressing the return.
On Mon, Jan 4, 2010 at 12:03 AM, Pieter Degraeuwe
pieter.degrae...@systemworks.be wrote:
If you want to do some additional stuff, you can do it in the form a a
Behaviour.. I did use such behaviour to ask a javascript confirm. If
user
does not confirm, the form is not submitted.
new AttributeModifier(onclick, true, new ModelString(if
(!confirm(' +
msg + ')) { /* do some additional stuff if not confirmed*/return;} else
{
/*do some stuff beform submitting the form*/})) {
@Override
protected String newValue(String currentValue, String
replacementValue) {
return replacementValue + currentValue;
}
};
On Mon, Jan 4, 2010 at 5:30 AM, Anantha Kumaran
ananthakuma...@gmail.com
wrote:
is there any way to do this on the client side.I want to do some
client
side
stuff before submitting the form.
On Sun, Jan 3, 2010 at 9:36 AM, Mathias Nilsson
wicket.program...@gmail.com
wrote:
form.add ( new AjaxSubmitLink(){
protected void onSubmit(AjaxRequestTarget target, Form form){
// Add feedback and do ajax stuff.
}
protected void onError(AjaxRequestTarget target, Form form){
// Add FeedbackPanel here
target.add( feedback );
}});
--
View this message in context:
http://old.nabble.com/AjaxSubmitLink-not-calling-the-onsubmit-event-handler-tp2718p27002962.html
Sent from the Wicket - User 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
--
Pieter Degraeuwe
Systemworks bvba
Belgiëlaan 61
9070 Destelbergen
GSM: +32 (0)485/68.60.85
Email: pieter.degrae...@systemworks.be
visit us at http://www.systemworks.be
--
Richard Nichols :: http://www.visural.com/ ::
http://www.richardnichols.net/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Anantha Kumaran(http://ananthakumaran.github.com)
Re: RE: RE: RE: Regarding TreeTable Horizontal Scrollbar
Hi, I am new to the Wicket and am trying out the TreeTable example. I am facing a more fundmental issue. I am unable to give a fixed width to the middle columns. I can only specify the Unit as Proportional which is dividing the columns proportionally within the available space. Because of this I don't even see where horizontal scrollbar can be used with the table. The total width of the table seems to remain same no matter how many coloumns I add. Is there a way to change this behaviour so that I can specify fixed widths to all the columns? regards, Kamesh Leo Erlandsson wrote: Hi, Still a CSS issue, not a Wicket one ;) I used Google to search for css table locked column scroll First result was a good StackOverflow-question: http://stackoverflow.com/questions/296020/how-can-i-lock-the-first-row-and-first-column-of-a-table-when-scrolling-possibly Try the Horizontal Scrollbar in the example mentioned in the Accepted StackOverflow answer: http://www.cubido.at/Portals/7/docs/Blog/Karin/HTML%20and%20Javascript/ResizeColumns/Table.htm Source here: http://www.cubido.at/Portals/7/docs/Blog/Karin/HTML%20and%20Javascript/ResizeColumns.zip Seems to be what you're looking for. Thanks to have your valuable reply effort you made to answer my query. But let me to explain you again my problem statement because this solution won't help me to fix the issue I have. I need a CSS style at TreeTable markup level so that the Horizontal Scrollbar would be a part of TreeTable component. Here is my problem statement: In my application, there are two scenarios: 1) I need an entire table to be scrollable horizontally 2) Horizontal scrolling on entire table except the tree node column. Now I tried with changing both TreeTable markup CSS attribute but couldn't get success. I am using wicket 1.4.5 version. Actually the problem statement is, in my application, I need a TreeTable where first column should contain the data in a tree structure rest others column will be the simple one. So, I used TreeTable wicket-extension component to get the requirement fulfill but the problem arises when table has many number of columns then the table should be horizontally scrollable. And as per my analysis, this existing treetable component doesn't provide this feature. Could you please let me know that whether it's possible to customize component for above mentioned requirement? And if yes, then guide me to do this otherwise please let me know what would be the other approach. - --- Leo Erlandsson, M. Sc. -- View this message in context: http://old.nabble.com/Regarding-TreeTable-Horizontal-Scrollbar-tp27901312p28039590.html Sent from the Wicket - User 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
Re: Caching components
Hi Martin, One reason for loading some data in contstructur or onBeforeRender is to prevent creating huge hierarchies. This is faster than override isVisible(), since isVisible would called more than one times. why are you loading data in the component at all? There is this nice 'LoadableDetachableModel' which could/should wrap that... Best regards, --- Jan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Re: RE: RE: RE: Regarding TreeTable Horizontal Scrollbar
Take a look at http://www.wicketframework.org/wicket-extensions/apidocs/wicket/extensions/markup/html/tree/table/ColumnLocation.html Specifying fixed size column should be no harder than adding them as LEFT or RIGHT columns instead of MIDDLE Column. MIDDLE column cannot have a fixed width. You should, however, be aware of a JavaScript i TreeTable that does resizing, see method init() in TreeTable: // Attach the javascript that resizes the header according to the body // This is necessary to support fixed position header. The header does // not // scroll together with body. The body contains vertical scrollbar. The // header width must be same as body content width, so that the columns // are properly aligned. Maybe you need to remove this, or at least modify the behavior... Or, you could always do as I did in my example - specify the width of the treetable greater than the size of the enclosing div (see earlier examples). Hi, I am new to the Wicket and am trying out the TreeTable example. I am facing a more fundmental issue. I am unable to give a fixed width to the middle columns. I can only specify the Unit as Proportional which is dividing the columns proportionally within the available space. Because of this I don't even see where horizontal scrollbar can be used with the table. The total width of the table seems to remain same no matter how many coloumns I add. Is there a way to change this behaviour so that I can specify fixed widths to all the columns? regards, Kamesh
Re: Caching components
Yes we use LoadableDetachableModel. But we also do some times getModel().getObject() deeper in hierarchy inside the construction, to e.g. set the visibility of a panel or to create just the right panel, instead of creating e.g. ten panels and implement isVisible(). Martin Jan Kriesten schrieb: Hi Martin, One reason for loading some data in contstructur or onBeforeRender is to prevent creating huge hierarchies. This is faster than override isVisible(), since isVisible would called more than one times. why are you loading data in the component at all? There is this nice 'LoadableDetachableModel' which could/should wrap that... Best regards, --- Jan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Caching components
I'd wrap the getModel().getObject() in accessor methods to hide the fact that you do that. getContract() is so much more legible than getModel().getObject() Martijn On Fri, Mar 26, 2010 at 10:59 AM, Martin Sachs sachs.mar...@gmail.com wrote: Yes we use LoadableDetachableModel. But we also do some times getModel().getObject() deeper in hierarchy inside the construction, to e.g. set the visibility of a panel or to create just the right panel, instead of creating e.g. ten panels and implement isVisible(). Martin Jan Kriesten schrieb: Hi Martin, One reason for loading some data in contstructur or onBeforeRender is to prevent creating huge hierarchies. This is faster than override isVisible(), since isVisible would called more than one times. why are you loading data in the component at all? There is this nice 'LoadableDetachableModel' which could/should wrap that... Best regards, --- Jan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket JavaScript Library Integration - A Common Base
Uwe Schäfer schrieb: Hi Cemal, I was thinking that it could possibly be sensible to have another project where we abstract out the mechanisms wiQuery provides for resources and JavaScript statements. to keep that topic alive: do you agree that providing a unified way for component authors to contribute standard libs to the page, as well as coordinating these dependencies on the page level is a primary goal of creating this lib? cu uwe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
testing JS in WicketTester
Good morning, Is there any way to test JavaScript code in WicketTester? I know of Selenium-based solutions, but I think that's too much heavyweight. Plus, I'd really like to unit test my rendering JS behavior. In a similar way than with YUI test, but for my homegrown JS. A recommandation, anyone? Thanks in advance, Pierre -- Les deux règles universelles du bide : 1) on n'explique pas un bide 2) dans le futur, un bide sera toujours un bide.
AjaxFormComponentUpdatingBehavior
Hello,
thanx for wicket!!! it is a joy working with this great framework!
I would need some help with an Ajax enabled table. It would be very great if
some one could give me a hint on this.
I have a DateTextField with a DatePicker, once the content is changed i want
the tabelcontent (rows) to be updated.
I added a AjaxFormComponentUpdatingBehavior(onchange) to my textfield.
...
travelstartDateTextField.add(new AjaxFormComponentUpdatingBehavior(onchange) {
@Override
protected void onUpdate(AjaxRequestTarget target) {
if (target != null) {
target.addComponent(StartPageForm.this.availableCategoriesContainer);
}
}
});
...
the availableCategoriesContainer contains the AjaxFallbackDefaultDataTable. A
SortableDataProvider feeds the data to the table. The method getting the rows
for the tabel is sometimes slow...
The table contains an action panel to select one of the rows...
now: everything work just fine normaly... but...
sometimes I get this strange error:
WicketMessage: org.apache.wicket.WicketRuntimeException: component
inputForm:availableCategoriesContainer:table:rows:1:cells:4:cell:select not
found on page de.rbag.web.reservation.pages.StartPage[id = 23], listener
interface = [RequestListenerInterface name=ILinkListener, method=public
abstract void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
I gues it has something to do with the fact that the ajax hasn't finished yet...
what would be a good way to avoid, that users click on the select-button on a
table-row before the ajax request is finished?
it would be very great to here from you, since i am almost finished with my app
but this keeps me from enrolling... :-(
Thanx a lot in advance
Cheers Björn
___
WEB.DE DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
http://produkte.web.de/go/02/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Wicket on GAE with Facebook Connect - doesnt work after deploying / HTTP 500 error
Hi everyone,
I'm trying to run a simple Wicket Application with Facebook Connect on
Google App Engine.
So far it runs local, but when I deploy to Google Facebook Connect wont
work.
I cant find any examples for using wicket with gae and facebook on the
web. Is anyone here who successfully made it?
Here is the output from ajax debug window:
---
INFO: Using XMLHttpRequest transport
INFO:
INFO:
Initiating Ajax GET request on
?wicket:interface=wicket-9:36:fbconnectpanel::IActivePageBehaviorListener:0:wicket:ignoreIfNotActive=truerandom=0.6834228196057528
INFO: Invoking pre-call handler(s)...
ERROR: Received Ajax response with code: 500
ERROR: 500 error had text:
htmlhead
meta http-equiv=content-type content=text/html;charset=utf-8
title500 Server Error/title
/head
body text=#00 bgcolor=#ff
h1Error: Server Error/h1
h2The server encountered an error and could not complete your request.pIf
the problem persists, please A
HREF=http://code.google.com/appengine/community.html;report/A your problem
and mention this error message and the query that caused it./h2
h2/h2
/body/html
INFO: Invoking post-call handler(s)...
INFO: Invoking failure handler(s)...
---
FacebookConnectPanel.java - took the most from
http://cwiki.apache.org/WICKET/adding-facebook-connect.html
---
package polizeiwache.sites.auth.facebookconnect;
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.wicket.Page;
import org.apache.wicket.ajax.AbstractDefaultAjaxBehavior;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.behavior.SimpleAttributeModifier;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.panel.Panel;
import org.apache.wicket.protocol.http.WebResponse;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;
import
org.springframework.security.authentication.UsernamePasswordAuthenticationToken;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.authority.GrantedAuthorityImpl;
import org.springframework.security.core.context.SecurityContext;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.core.context.SecurityContextImpl;
import pojos.FacebookUser;
//import com.facebook.api.FacebookException;
//import com.facebook.api.FacebookJsonRestClient;
//import com.facebook.api.FacebookWebappHelper;
//import com.facebook.api.ProfileField;
import com.google.code.facebookapi.FacebookException;
import com.google.code.facebookapi.FacebookJsonRestClient;
import com.google.code.facebookapi.FacebookWebappHelper;
import com.google.code.facebookapi.ProfileField;
//import
com.google.appengine.repackaged.org.apache.commons.logging.impl.LogFactoryImpl;
/**
* @see http://cwiki.apache.org/WICKET/adding-facebook-connect.html
* @author christoph
*
*/
@SuppressWarnings(deprecation)
public class FacebookConnectPanel extends Panel
{
/**
*
*/
private static final long serialVersionUID = -5912681574741410118L;
//private static final
com.google.appengine.repackaged.org.apache.commons.logging.Log log =
LogFactoryImpl.getLog(FacebookConnectPanel.class);
private WebMarkupContainer fbloginDiv;
private Label fblogin;
/**
*
* @param id
*/
public FacebookConnectPanel(String id) {
super(id);
}
/**
* This method will the panel
*/
public void createPanel() {
fbloginDiv = new WebMarkupContainer(fbloginDiv);
fbloginDiv.setOutputMarkupId(true).setMarkupId(fbloginDiv);
fblogin = new Label(fblogin, fb:login-button
onlogin='callWicket();'/fb:login-button);
fblogin.setEscapeModelStrings(false);
fblogin.setOutputMarkupId(true);
if (isAuthenticated())
{
fbloginDiv.add(new SimpleAttributeModifier(style,
display:none;));
}
fbloginDiv.add(fblogin);
addOrReplace(fbloginDiv);
/**
* This will only be called after they're logged in via facebook
*/
final AbstractDefaultAjaxBehavior behave = new
AbstractDefaultAjaxBehavior()
{
/**
*
*/
private static final long serialVersionUID =
-486358491644699655L;
protected void respond(final AjaxRequestTarget target)
{
// deal with facebook
try {
handleFacebookCallback(target.getPage());
} catch
Re: Wicket and Reverse Proxy
H... No responses. Maybe I can attack this little by little. When an AJAX response is sent back to the browser, is there a way to stop Wicket from sending the script elements? These script elements are already there on the initial page load so I don't see why it needs to send these again on the AJAX response. On Mon, Feb 22, 2010 at 11:59 AM, T Ames tamesw...@gmail.com wrote: A while ago I sent a message ( at bottom) and received no responses. In that message I had thought that AJAX was not working, but I was mistaken. In the Ajax Debug screen, Wicket is responding back with a stream. Here is one of the issues that I found. I get this error. ERROR: Wicket.Ajax.Call.failure: Error while parsing response: 'src' is null or not an object The Juniper system adds strange things in the resource path. Example. This is a snippet of the source view on initial load for wicket javascript: script type=text/javascript src=../resources/org.apache.wicket.markup.html.WicketEventReference/,DanaInfo=159.116.216.35,Port=38080,CT=js+wicket-event.js/script script type=text/javascript src=../resources/org.apache.wicket.ajax.WicketAjaxReference/,DanaInfo=159.116.216.35,Port=38080,CT=js+wicket-ajax.js/script script type=text/javascript src=../resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/,DanaInfo=159.116.216.35,Port=38080,CT=js+wicket-ajax-debug.js/script script type=text/javascript id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/ wicketAjaxDebugEnable=true; /*--]]*//script When the ajax stream is returned from the ajax call, the added stuff is not there: script type=text/javascript src=resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js/script script type=text/javascript src=resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script script type=text/javascript id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/ wicketAjaxDebugEnable=true; /*--]^]^*//script so I am assuming this is why I am getting the Wicket Ajax Error. I am not understanding what Juniper is trying to do. I was hoping maybe someone may be able to shed some light on this. Another strange thing I noticed was when debugging the web page in Eclipse, my class level variables were always set at the initial value even though I would change the value within the ajax code. If I run the application normally without using Juniper, the class level values change as you would expect. It is strange but is seems like each time I am returned to the java code I am getting the the initial page object. Nabble link to original messsage - http://old.nabble.com/Reverse-Proxy-and-AJAX-td24094730.html#a24094730 June 18, 2009 My company is going to start using a *Juniper* Reverse Proxy server for VPN access. We have a large mix of different web technologies in use. Wicket is one of them. What this product does is URL rewriting to make things work. I am having a problem with Wicket AJAX functions working properly. Below is an example of the way the URLs look where AJAX does work and where it does not. .
How to integrate wicket and velocity?
Can anyone tell me where I find a good documentation about this integration? Thanks!
Re: How to integrate wicket and velocity?
See wicket-examples project: http://www.wicket-library.com/wicket-examples/velocity/ Regards, Peter 2010-03-26 14:00 keltezéssel, Gustavo Henrique írta: Can anyone tell me where I find a good documentation about this integration? Thanks! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket JavaScript Library Integration - A Common Base
Uwe! I was thinking in terms of a simple core, of well defined and limited scope. It would provide a clear and well trodden way for people to integrate their favourite JavaScript libraries with Wicket in a consistent and effective, tried and tested way. As you say, there are always going to be potential complications whenever a single web page depends on more than one version of the same JavaScript libraries, or sometimes even when some libraries clash with other, (seemingly) unrelated ones. What I was proposing was not as a solution to incompatibilities between such multiple dependencies. On the other hand, once we had the common base (that seems to have already attracted some interest and even potential development support here), an extension, optional for people who want/need it, could try to manage the versions and other causes of conflict you talk of, if I understand you correctly. I am a believer in keeping the core as simple and light as possible whilst still open (and designed for) potential enhancement with extended functionality. Regards - Cemal jWeekend OO Java Technologies, Wicket Consulting, Development, Training http://jWeekend.com 2010/3/26 Uwe Schäfer schae...@thomas-daily.de: Uwe Schäfer schrieb: Hi Cemal, I was thinking that it could possibly be sensible to have another project where we abstract out the mechanisms wiQuery provides for resources and JavaScript statements. to keep that topic alive: do you agree that providing a unified way for component authors to contribute standard libs to the page, as well as coordinating these dependencies on the page level is a primary goal of creating this lib? cu uwe - 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
Re: Wicket on GAE with Facebook Connect - doesnt work after deploying / HTTP 500 error
you are aware of this?
http://www.danwalmsley.com/2009/04/08/apache-wicket-on-google-app-engine-for-java/
2010/3/26 christoph glass mail.kaffeeser...@googlemail.com
Hi everyone,
I'm trying to run a simple Wicket Application with Facebook Connect on
Google App Engine.
So far it runs local, but when I deploy to Google Facebook Connect wont
work.
I cant find any examples for using wicket with gae and facebook on the
web. Is anyone here who successfully made it?
Here is the output from ajax debug window:
---
INFO: Using XMLHttpRequest transport
INFO:
INFO:
Initiating Ajax GET request on
?wicket:interface=wicket-9:36:fbconnectpanel::IActivePageBehaviorListener:0:wicket:ignoreIfNotActive=truerandom=0.6834228196057528
INFO: Invoking pre-call handler(s)...
ERROR: Received Ajax response with code: 500
ERROR: 500 error had text:
htmlhead
meta http-equiv=content-type content=text/html;charset=utf-8
title500 Server Error/title
/head
body text=#00 bgcolor=#ff
h1Error: Server Error/h1
h2The server encountered an error and could not complete your
request.pIf the problem persists, please A HREF=
http://code.google.com/appengine/community.html;report/A your problem
and mention this error message and the query that caused it./h2
h2/h2
/body/html
INFO: Invoking post-call handler(s)...
INFO: Invoking failure handler(s)...
---
FacebookConnectPanel.java - took the most from
http://cwiki.apache.org/WICKET/adding-facebook-connect.html
---
package polizeiwache.sites.auth.facebookconnect;
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.wicket.Page;
import org.apache.wicket.ajax.AbstractDefaultAjaxBehavior;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.behavior.SimpleAttributeModifier;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.panel.Panel;
import org.apache.wicket.protocol.http.WebResponse;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;
import
org.springframework.security.authentication.UsernamePasswordAuthenticationToken;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.authority.GrantedAuthorityImpl;
import org.springframework.security.core.context.SecurityContext;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.core.context.SecurityContextImpl;
import pojos.FacebookUser;
//import com.facebook.api.FacebookException;
//import com.facebook.api.FacebookJsonRestClient;
//import com.facebook.api.FacebookWebappHelper;
//import com.facebook.api.ProfileField;
import com.google.code.facebookapi.FacebookException;
import com.google.code.facebookapi.FacebookJsonRestClient;
import com.google.code.facebookapi.FacebookWebappHelper;
import com.google.code.facebookapi.ProfileField;
//import
com.google.appengine.repackaged.org.apache.commons.logging.impl.LogFactoryImpl;
/**
* @see http://cwiki.apache.org/WICKET/adding-facebook-connect.html
* @author christoph
*
*/
@SuppressWarnings(deprecation)
public class FacebookConnectPanel extends Panel
{
/**
*
*/
private static final long serialVersionUID = -5912681574741410118L;
//private static final
com.google.appengine.repackaged.org.apache.commons.logging.Log log =
LogFactoryImpl.getLog(FacebookConnectPanel.class);
private WebMarkupContainer fbloginDiv;
private Label fblogin;
/**
*
* @param id
*/
public FacebookConnectPanel(String id) {
super(id);
}
/**
* This method will the panel
*/
public void createPanel() {
fbloginDiv = new WebMarkupContainer(fbloginDiv);
fbloginDiv.setOutputMarkupId(true).setMarkupId(fbloginDiv);
fblogin = new Label(fblogin, fb:login-button
onlogin='callWicket();'/fb:login-button);
fblogin.setEscapeModelStrings(false);
fblogin.setOutputMarkupId(true);
if (isAuthenticated())
{
fbloginDiv.add(new SimpleAttributeModifier(style,
display:none;));
}
fbloginDiv.add(fblogin);
addOrReplace(fbloginDiv);
/**
* This will only be called after they're logged in via facebook
*/
final AbstractDefaultAjaxBehavior behave = new
AbstractDefaultAjaxBehavior()
{
/**
*
*/
private static final long serialVersionUID =
-486358491644699655L;
protected void respond(final AjaxRequestTarget
target)
RE: Wicket JavaScript Library Integration - A Common Base
This sounds exactly like the thing I'm looking for. A small and simple framework for HeaderContribution. Stefan -Ursprüngliche Nachricht- Von: ce...@jweekend.com [mailto:ce...@jweekend.com] Im Auftrag von Cemal Bayramoglu Gesendet: Freitag, 26. März 2010 14:26 An: users Betreff: Re: Wicket JavaScript Library Integration - A Common Base Uwe! I was thinking in terms of a simple core, of well defined and limited scope. It would provide a clear and well trodden way for people to integrate their favourite JavaScript libraries with Wicket in a consistent and effective, tried and tested way. As you say, there are always going to be potential complications whenever a single web page depends on more than one version of the same JavaScript libraries, or sometimes even when some libraries clash with other, (seemingly) unrelated ones. What I was proposing was not as a solution to incompatibilities between such multiple dependencies. On the other hand, once we had the common base (that seems to have already attracted some interest and even potential development support here), an extension, optional for people who want/need it, could try to manage the versions and other causes of conflict you talk of, if I understand you correctly. I am a believer in keeping the core as simple and light as possible whilst still open (and designed for) potential enhancement with extended functionality. Regards - Cemal jWeekend OO Java Technologies, Wicket Consulting, Development, Training http://jWeekend.com 2010/3/26 Uwe Schäfer schae...@thomas-daily.de: Uwe Schäfer schrieb: Hi Cemal, I was thinking that it could possibly be sensible to have another project where we abstract out the mechanisms wiQuery provides for resources and JavaScript statements. to keep that topic alive: do you agree that providing a unified way for component authors to contribute standard libs to the page, as well as coordinating these dependencies on the page level is a primary goal of creating this lib? cu uwe - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket JavaScript Library Integration - A Common Base
Stefan, ... and encapsulating JavaScript statements; the two main concerns I'd imagine anyone making an integration between Wicket and a JavaScript library has. Regards - Cemal jWeekend OO Java Technologies, Wicket Consulting, Development, Training http://jWeekend.com On 26 March 2010 13:37, Stefan Lindner lind...@visionet.de wrote: This sounds exactly like the thing I'm looking for. A small and simple framework for HeaderContribution. Stefan -Ursprüngliche Nachricht- Von: ce...@jweekend.com [mailto:ce...@jweekend.com] Im Auftrag von Cemal Bayramoglu Gesendet: Freitag, 26. März 2010 14:26 An: users Betreff: Re: Wicket JavaScript Library Integration - A Common Base Uwe! I was thinking in terms of a simple core, of well defined and limited scope. It would provide a clear and well trodden way for people to integrate their favourite JavaScript libraries with Wicket in a consistent and effective, tried and tested way. As you say, there are always going to be potential complications whenever a single web page depends on more than one version of the same JavaScript libraries, or sometimes even when some libraries clash with other, (seemingly) unrelated ones. What I was proposing was not as a solution to incompatibilities between such multiple dependencies. On the other hand, once we had the common base (that seems to have already attracted some interest and even potential development support here), an extension, optional for people who want/need it, could try to manage the versions and other causes of conflict you talk of, if I understand you correctly. I am a believer in keeping the core as simple and light as possible whilst still open (and designed for) potential enhancement with extended functionality. Regards - Cemal jWeekend OO Java Technologies, Wicket Consulting, Development, Training http://jWeekend.com 2010/3/26 Uwe Schäfer schae...@thomas-daily.de: Uwe Schäfer schrieb: Hi Cemal, I was thinking that it could possibly be sensible to have another project where we abstract out the mechanisms wiQuery provides for resources and JavaScript statements. to keep that topic alive: do you agree that providing a unified way for component authors to contribute standard libs to the page, as well as coordinating these dependencies on the page level is a primary goal of creating this lib? cu uwe - 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 - 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
Re: Caching components
the recommended way to handle this would be to cache the data not the generated html -igor On Fri, Mar 26, 2010 at 1:11 AM, Martin Sachs sachs.mar...@gmail.com wrote: We have a lot of Repeating views, which containing a lot of components, which also contains repeatingviews. To know would should be rendered, we load some hopefully small (listsizes, objectbyId, ...) datas from DB in the constructor and/or in onBeforeRender and in isVisible. You are right, this is not a recommented way. Most of the time is database-loading and wicket has no performance-problem for us. We profile our application and never found wicket-components as hotspots. One reason for loading some data in contstructur or onBeforeRender is to prevent creating huge hierarchies. This is faster than override isVisible(), since isVisible would called more than one times. For our usecase the responsetime is much faster with HTML-Caching, because the Database-calls are minimized. We save the time for creating componentshierarchies (all three categories) with loading data. Martin Jeremy Thomerson schrieb: On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs sachs.mar...@gmail.com mailto:sachs.mar...@gmail.com wrote: hi, we need caching of components, since the construction of huge hierarchies is not cheap. The rendering ist fast. We cache the rendered HTML of a hole component via a beheaviour and write them on the next requests into a Label (unescaped). So instead of creating the complete hierarchie on every request, we create a much smaller one. But you must check, that the cachable components are stateless. Also we have JQuery for client-effects in this components, this would also be cached. The performance is much better with that: approx. 10-50 times better: 100ms with cache (the response time is not much depending on count of users) vs 1500 ms without cache depending how many parallel user A 15x gain is a big statement to make. Can you please break this 1500ms down into at least the following categories: 1 - time in IModel#getObject() and all child calls of this (IOW, loading data) 2 - time in constructor of components (without loading data in the constructor - hopefully you're not doing this) 3 - time in rendering of components That would be a much better number to give other users. I have NEVER seen where creating / rendering components could take 1400ms - unless you're doing something wrong like database calls in your component constructors. So, I suspect that most of that 1400ms (I would guess at least 1250ms) is in your model loading. The only time I've seen (or seen proof of) the component hierarchy actually be the slow part of a Wicket page is if you were displaying a repeating view of some sort with thousands of rows and each row had a bunch of components in it - leading to tens of thousands of components being built in the hierarchy. -- Jeremy Thomerson http://www.wickettraining.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
Re: Wicket and Reverse Proxy
because wicket doesnt track what has been sent or not, it simply renders what you tell it to. the filtering of duplicates happens on the client side where js knows whats is there and what is not. -igor On Fri, Mar 26, 2010 at 5:53 AM, T Ames tamesw...@gmail.com wrote: H... No responses. Maybe I can attack this little by little. When an AJAX response is sent back to the browser, is there a way to stop Wicket from sending the script elements? These script elements are already there on the initial page load so I don't see why it needs to send these again on the AJAX response. On Mon, Feb 22, 2010 at 11:59 AM, T Ames tamesw...@gmail.com wrote: A while ago I sent a message ( at bottom) and received no responses. In that message I had thought that AJAX was not working, but I was mistaken. In the Ajax Debug screen, Wicket is responding back with a stream. Here is one of the issues that I found. I get this error. ERROR: Wicket.Ajax.Call.failure: Error while parsing response: 'src' is null or not an object The Juniper system adds strange things in the resource path. Example. This is a snippet of the source view on initial load for wicket javascript: script type=text/javascript src=../resources/org.apache.wicket.markup.html.WicketEventReference/,DanaInfo=159.116.216.35,Port=38080,CT=js+wicket-event.js/script script type=text/javascript src=../resources/org.apache.wicket.ajax.WicketAjaxReference/,DanaInfo=159.116.216.35,Port=38080,CT=js+wicket-ajax.js/script script type=text/javascript src=../resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/,DanaInfo=159.116.216.35,Port=38080,CT=js+wicket-ajax-debug.js/script script type=text/javascript id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/ wicketAjaxDebugEnable=true; /*--]]*//script When the ajax stream is returned from the ajax call, the added stuff is not there: script type=text/javascript src=resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js/script script type=text/javascript src=resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script script type=text/javascript id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/ wicketAjaxDebugEnable=true; /*--]^]^*//script so I am assuming this is why I am getting the Wicket Ajax Error. I am not understanding what Juniper is trying to do. I was hoping maybe someone may be able to shed some light on this. Another strange thing I noticed was when debugging the web page in Eclipse, my class level variables were always set at the initial value even though I would change the value within the ajax code. If I run the application normally without using Juniper, the class level values change as you would expect. It is strange but is seems like each time I am returned to the java code I am getting the the initial page object. Nabble link to original messsage - http://old.nabble.com/Reverse-Proxy-and-AJAX-td24094730.html#a24094730 June 18, 2009 My company is going to start using a *Juniper* Reverse Proxy server for VPN access. We have a large mix of different web technologies in use. Wicket is one of them. What this product does is URL rewriting to make things work. I am having a problem with Wicket AJAX functions working properly. Below is an example of the way the URLs look where AJAX does work and where it does not. . - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket on GAE with Facebook Connect - doesnt work after deploying / HTTP 500 error
You solved it :)
I configured my project some days ago with the instructions from your
link. Now I checked everything carefully again, and noticed that I
forgott the following line in WicketApplication.java
---
super.init();
---
Now it seems to work.
Thank you very much!
Best regards
Christoph
On Fri, 2010-03-26 at 14:32 +0100, Martin Funk wrote:
you are aware of this?
http://www.danwalmsley.com/2009/04/08/apache-wicket-on-google-app-engine-for-java/
2010/3/26 christoph glass mail.kaffeeser...@googlemail.com
Hi everyone,
I'm trying to run a simple Wicket Application with Facebook Connect on
Google App Engine.
So far it runs local, but when I deploy to Google Facebook Connect wont
work.
I cant find any examples for using wicket with gae and facebook on the
web. Is anyone here who successfully made it?
Here is the output from ajax debug window:
---
INFO: Using XMLHttpRequest transport
INFO:
INFO:
Initiating Ajax GET request on
?wicket:interface=wicket-9:36:fbconnectpanel::IActivePageBehaviorListener:0:wicket:ignoreIfNotActive=truerandom=0.6834228196057528
INFO: Invoking pre-call handler(s)...
ERROR: Received Ajax response with code: 500
ERROR: 500 error had text:
htmlhead
meta http-equiv=content-type content=text/html;charset=utf-8
title500 Server Error/title
/head
body text=#00 bgcolor=#ff
h1Error: Server Error/h1
h2The server encountered an error and could not complete your
request.pIf the problem persists, please A HREF=
http://code.google.com/appengine/community.html;report/A your problem
and mention this error message and the query that caused it./h2
h2/h2
/body/html
INFO: Invoking post-call handler(s)...
INFO: Invoking failure handler(s)...
---
FacebookConnectPanel.java - took the most from
http://cwiki.apache.org/WICKET/adding-facebook-connect.html
---
package polizeiwache.sites.auth.facebookconnect;
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.wicket.Page;
import org.apache.wicket.ajax.AbstractDefaultAjaxBehavior;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.behavior.SimpleAttributeModifier;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.panel.Panel;
import org.apache.wicket.protocol.http.WebResponse;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;
import
org.springframework.security.authentication.UsernamePasswordAuthenticationToken;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.authority.GrantedAuthorityImpl;
import org.springframework.security.core.context.SecurityContext;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.core.context.SecurityContextImpl;
import pojos.FacebookUser;
//import com.facebook.api.FacebookException;
//import com.facebook.api.FacebookJsonRestClient;
//import com.facebook.api.FacebookWebappHelper;
//import com.facebook.api.ProfileField;
import com.google.code.facebookapi.FacebookException;
import com.google.code.facebookapi.FacebookJsonRestClient;
import com.google.code.facebookapi.FacebookWebappHelper;
import com.google.code.facebookapi.ProfileField;
//import
com.google.appengine.repackaged.org.apache.commons.logging.impl.LogFactoryImpl;
/**
* @see http://cwiki.apache.org/WICKET/adding-facebook-connect.html
* @author christoph
*
*/
@SuppressWarnings(deprecation)
public class FacebookConnectPanel extends Panel
{
/**
*
*/
private static final long serialVersionUID = -5912681574741410118L;
//private static final
com.google.appengine.repackaged.org.apache.commons.logging.Log log =
LogFactoryImpl.getLog(FacebookConnectPanel.class);
private WebMarkupContainer fbloginDiv;
private Label fblogin;
/**
*
* @param id
*/
public FacebookConnectPanel(String id) {
super(id);
}
/**
* This method will the panel
*/
public void createPanel() {
fbloginDiv = new WebMarkupContainer(fbloginDiv);
fbloginDiv.setOutputMarkupId(true).setMarkupId(fbloginDiv);
fblogin = new Label(fblogin, fb:login-button
onlogin='callWicket();'/fb:login-button);
fblogin.setEscapeModelStrings(false);
fblogin.setOutputMarkupId(true);
if (isAuthenticated())
{
fbloginDiv.add(new SimpleAttributeModifier(style,
display:none;));
}
Re: Label update after change of radiochoice by ajax not working
I've added a jira-issue (https://issues.apache.org/jira/browse/WICKET-2806) for this. Cheers Per - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
PageExpiredException - getting this when the session hasn't timeout
Hi, we're getting this exception in production sometimes, and today I experienced it first hand. We have a session of 60 mins set in the web.xml - however I got this after just 5 mins: org.apache.wicket.protocol.http.PageExpiredException: Cannot find the rendered page in session [pagemap=null,componentPath=1,versionNumber=0] at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:197) at hub.app.wicket.app.HubRequestCycleProcessor.resolve(HubRequestCycleProcessor.java:137) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1301) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1419) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:456) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:289) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141) at com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29) at com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) I honestly don't know where this is coming from. What can cause this? cookie not being passed? apache proxy balancer not working? Has anyone experienced this? PS HubRequestCycleProcessor is just calling WebRequestCycleProcessor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't timeout
oh and I doubled check that all the classes implement Serializable Wayne Pope-2 wrote: Hi, we're getting this exception in production sometimes, and today I experienced it first hand. We have a session of 60 mins set in the web.xml - however I got this after just 5 mins: org.apache.wicket.protocol.http.PageExpiredException: Cannot find the rendered page in session [pagemap=null,componentPath=1,versionNumber=0] at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:197) at hub.app.wicket.app.HubRequestCycleProcessor.resolve(HubRequestCycleProcessor.java:137) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1301) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1419) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:456) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:289) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141) at com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29) at com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) I honestly don't know where this is coming from. What can cause this? cookie not being passed? apache proxy balancer not working? Has anyone experienced this? PS HubRequestCycleProcessor is just calling WebRequestCycleProcessor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/PageExpiredException---getting-this-when-the-session-hasn%27t-timeout-tp28043403p28043436.html Sent from the Wicket - User 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
Re: Support for back button and new windows?
Also on this subject -- if I want to prevent users from submitting wizard (multi-page form) again via back button after they've submitted it once (or in other conditions), what would be the best way to approach this problem? And similarly -- if I want to prevent users from using back button at all (e.g. show them the last 'normally' generated page if they submit anything from the 'old' page), what would be the best way to achieve this? Sergey Olefir wrote: Hi, I'm looking for a good source of information on Wicket's support for browser's back button and also on what happens when user opens a new tab/window. I feel this is something I need to understand well before we can deploy our first Wicket application in production. -- View this message in context: http://old.nabble.com/Support-for-back-button-and-new-windows--tp28028525p28043507.html Sent from the Wicket - User 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
Re: Wicket and Reverse Proxy
Makes sense, but I need to override this behavior. Is there a way to stop Wicket from sending the script elements at the time of the AJAX response? On Fri, Mar 26, 2010 at 9:52 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: because wicket doesnt track what has been sent or not, it simply renders what you tell it to. the filtering of duplicates happens on the client side where js knows whats is there and what is not. -igor On Fri, Mar 26, 2010 at 5:53 AM, T Ames tamesw...@gmail.com wrote: H... No responses. Maybe I can attack this little by little. When an AJAX response is sent back to the browser, is there a way to stop Wicket from sending the script elements? These script elements are already there on the initial page load so I don't see why it needs to send these again on the AJAX response. On Mon, Feb 22, 2010 at 11:59 AM, T Ames tamesw...@gmail.com wrote: A while ago I sent a message ( at bottom) and received no responses. In that message I had thought that AJAX was not working, but I was mistaken. In the Ajax Debug screen, Wicket is responding back with a stream. Here is one of the issues that I found. I get this error. ERROR: Wicket.Ajax.Call.failure: Error while parsing response: 'src' is null or not an object The Juniper system adds strange things in the resource path. Example. This is a snippet of the source view on initial load for wicket javascript: script type=text/javascript src=../resources/org.apache.wicket.markup.html.WicketEventReference/,DanaInfo=159.116.216.35,Port=38080,CT=js+wicket-event.js/script script type=text/javascript src=../resources/org.apache.wicket.ajax.WicketAjaxReference/,DanaInfo=159.116.216.35,Port=38080,CT=js+wicket-ajax.js/script script type=text/javascript src=../resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/,DanaInfo=159.116.216.35,Port=38080,CT=js+wicket-ajax-debug.js/script script type=text/javascript id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/ wicketAjaxDebugEnable=true; /*--]]*//script When the ajax stream is returned from the ajax call, the added stuff is not there: script type=text/javascript src=resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js/script script type=text/javascript src=resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script script type=text/javascript id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/ wicketAjaxDebugEnable=true; /*--]^]^*//script so I am assuming this is why I am getting the Wicket Ajax Error. I am not understanding what Juniper is trying to do. I was hoping maybe someone may be able to shed some light on this. Another strange thing I noticed was when debugging the web page in Eclipse, my class level variables were always set at the initial value even though I would change the value within the ajax code. If I run the application normally without using Juniper, the class level values change as you would expect. It is strange but is seems like each time I am returned to the java code I am getting the the initial page object. Nabble link to original messsage - http://old.nabble.com/Reverse-Proxy-and-AJAX-td24094730.html#a24094730 June 18, 2009 My company is going to start using a *Juniper* Reverse Proxy server for VPN access. We have a large mix of different web technologies in use. Wicket is one of them. What this product does is URL rewriting to make things work. I am having a problem with Wicket AJAX functions working properly. Below is an example of the way the URLs look where AJAX does work and where it does not. . - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageExpiredException - getting this when the session hasn't timeout
One more bit of info - it was a ajax request that caused this. Any ideas? On Fri, Mar 26, 2010 at 3:42 PM, Wayne Pope waynemailingli...@gmail.com wrote: oh and I doubled check that all the classes implement Serializable Wayne Pope-2 wrote: Hi, we're getting this exception in production sometimes, and today I experienced it first hand. We have a session of 60 mins set in the web.xml - however I got this after just 5 mins: org.apache.wicket.protocol.http.PageExpiredException: Cannot find the rendered page in session [pagemap=null,componentPath=1,versionNumber=0] at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:197) at hub.app.wicket.app.HubRequestCycleProcessor.resolve(HubRequestCycleProcessor.java:137) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1301) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1419) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:456) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:289) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141) at com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29) at com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) I honestly don't know where this is coming from. What can cause this? cookie not being passed? apache proxy balancer not working? Has anyone experienced this? PS HubRequestCycleProcessor is just calling WebRequestCycleProcessor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/PageExpiredException---getting-this-when-the-session-hasn%27t-timeout-tp28043403p28043436.html Sent from the Wicket - User 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
ListView and Serialization
Hi,
I have a question concerning the serialization of subcomponents of ListView.
If I understand correctly, then the components that are added to a ListView in
the populateItem method should be stateless, since they are removed in the
onPopulate method each time the list view is rendered (as long as reuseItems
is set to false).
Nevertheless, the subcomponents are saved in the ListView and so they are
serialized/stored in the session after the page with the ListView has been
rendered.
This seems unnecessary to me. Why do we have to store components that are
discarded before the next rendering phase anyway?
So I created a subclass of ListView with the following method overridden:
@Override
protected void onDetach() {
super.onDetach();
if ( !getReuseItems() ) {
removeAll();
}
}
This removes the subcomponents before the page is stored in the session and
should save some memory in most cases.
Is there a reason why this is not done in ListView itself? Has nobody thought
about it yet or could there be any problems with this approach?
Cheers,
Michael
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Wicket and JEE6
Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark
Re: Wicket and JEE6
Weld has wicket support built-in I believe. On Fri, Mar 26, 2010 at 12:52 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark
RE: Wicket and JEE6
Weld claims support, I don't know about built-in. When I use @Inject in a Wicket WebPage subclass the objects are null. Like I mentioned below, I added weld-wicket.jar and subclassed the WeldApplication and the injected objects in the Wicket WebPage subclass are still null. This was from following this example: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/viewlayers.html If you track down the example code it seems that the examples from JBoss are using older versions of Wicket and Weld/Seam so I don't know if something has broken in either project, wicket or weld. Injection worked like a charm in a JSF2 controller class so I don't know what going wrong or what supporting jar is missing. Any additional help is greatly appreciated! -Mark -Original Message- From: James Carman [mailto:jcar...@carmanconsulting.com] Sent: Friday, March 26, 2010 10:52 AM To: users@wicket.apache.org Subject: Re: Wicket and JEE6 Weld has wicket support built-in I believe. On Fri, Mar 26, 2010 at 12:52 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
I started a JSR-299 integration project a while back, but at the time there was no portable way (across vendors) to get to the stuff you needed to inject into your components. I believe that's been fixed in the latest API, but I haven't had a chance to dig in and verify that and then use it. My guess is that there's really not that much to it (my code was pretty small). On Fri, Mar 26, 2010 at 1:35 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Weld claims support, I don't know about built-in. When I use @Inject in a Wicket WebPage subclass the objects are null. Like I mentioned below, I added weld-wicket.jar and subclassed the WeldApplication and the injected objects in the Wicket WebPage subclass are still null. This was from following this example: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/viewlayers.html If you track down the example code it seems that the examples from JBoss are using older versions of Wicket and Weld/Seam so I don't know if something has broken in either project, wicket or weld. Injection worked like a charm in a JSF2 controller class so I don't know what going wrong or what supporting jar is missing. Any additional help is greatly appreciated! -Mark -Original Message- From: James Carman [mailto:jcar...@carmanconsulting.com] Sent: Friday, March 26, 2010 10:52 AM To: users@wicket.apache.org Subject: Re: Wicket and JEE6 Weld has wicket support built-in I believe. On Fri, Mar 26, 2010 at 12:52 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ListView and Serialization
Hi Michael,
there's no requirement for components inside ListView to be stateless -
I wonder were you got that from.
You can have Links, Buttons or anything else in there so removing all on
detach is a recipe for disaster for the next incoming request.
Sven
Michael Gottschalk wrote:
Hi,
I have a question concerning the serialization of subcomponents of ListView.
If I understand correctly, then the components that are added to a ListView in
the populateItem method should be stateless, since they are removed in the
onPopulate method each time the list view is rendered (as long as reuseItems
is set to false).
Nevertheless, the subcomponents are saved in the ListView and so they are
serialized/stored in the session after the page with the ListView has been
rendered.
This seems unnecessary to me. Why do we have to store components that are
discarded before the next rendering phase anyway?
So I created a subclass of ListView with the following method overridden:
@Override
protected void onDetach() {
super.onDetach();
if ( !getReuseItems() ) {
removeAll();
}
}
This removes the subcomponents before the page is stored in the session and
should save some memory in most cases.
Is there a reason why this is not done in ListView itself? Has nobody thought
about it yet or could there be any problems with this approach?
Cheers,
Michael
-
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
Starting web application thorws Invalid configuration type: 'null' for the configuration parameter
Hi, I am getting a really weird error in my web.xml file. So I have what is copied below. I am getting an error message saying I have to be in either development or deployment mode. (I tried switching putting deployment in and it didn't work). I don't understand where my mistake was in configuring my wicket app. I am trying to make a spring app with hibernate. The error seams to switch between missing a filter for the opensessioninview (which is defined and I have all the right jars in my classpath) and my configuration being null. Has anyone seen this problem before? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 context-param param-nameconfiguration/param-name param-valuedeployment/param-value /context-param .. filter filter-nameopensessioninview/filter-name filter-class org.springframework.orm.hibernate3.support.OpenSessionInViewFilter /filter-class /filter filter-mapping filter-nameopensessioninview/filter-name url-pattern/*/url-pattern /filter-mapping . Thank you, -- Eric Reagan
RE: quickstart POM has wrong artifactId for jetty maven plugin
FWIW, this is happening because version/ is omitted in generated pom.xml
plugin/ tag. To fix:
change
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
/plugin
to
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version${jetty.version}/version
/plugin
TahitianGabriel wrote:
Had the same behavior when lauching maven in command line (OK within
eclipse). Just add the jetty plugin with the version you want in your
pom.xml :
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version6.1.4/version
/plugin
-
Nikita Tovstoles
vside.com
--
View this message in context:
http://old.nabble.com/quickstart-POM-has-wrong-artifactId-for-jetty-maven-plugin-tp27555192p28047057.html
Sent from the Wicket - User 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
Wicket form data isn't received
I've been working on an existing wicket application and am banging my head against the desk :) I'm trying to have two different pages that handle the sign on for the authenticated web session. One which is using ntlm with jcifs works fine. However, I can't get any other forms to work. I see from looking closely at the log file that the data is posted - however it almost looks like it's redirected. I did see that it was 'unable to find cookie' - but i wouldn't think that is the problem. I've looked through the web.xml and the page we have that extends the AuthenticatedWebApplication. I'm not sure if that is the issue, or if it something else. I wonder if the form is being redirected as it is not authenticated ending up in a catch 22. Is a way to have unauthenticated pages when using the AuthenticatedWebApplication? Or am I stuck in a vicious circle :) I've included the html and java, based on the article at http://www.developer.com/java/web/article.php/3673576/Wicket-The-First-Steps.htm 26 Mar 2010 13:42:13,430: (request cycle) url: /nrg/app/test 26 Mar 2010 13:42:13,603: Add userId to [MarkupContainer [Component id = loginForm]] 26 Mar 2010 13:42:13,605: Add loginForm to [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:13,649: Begin render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:13,657: Load markup: cacheKey=com.sam.auth.TestLoginen_UShtml 26 Mar 2010 13:42:13,694: Loading markup from file:/home/HOMEDIRS/montgomeryb/tomcat/webapps/nrg/WEB-INF/classes/com/sam/auth/TestLogin.html 26 Mar 2010 13:42:13,756: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = GET, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = null, contentLength = -1, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:13,771: time=328,event=BookmarkablePage[com.sam.auth.TestLogin()],response=BookmarkablePage[com.sam.auth.TestLogin()],sessionid=535C7A65C8E2F12DE0EEA8EF26830D80,sessionsize=326,sessionstart=Fri Mar 26 13:42:13 EDT 2010,requests=2,totaltime=328,activerequests=0,maxmem=891M,total=525M,used=245M 26 Mar 2010 13:42:13,771: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = GET, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = null, contentLength = -1, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:18,771: (request cycle) url: /nrg/app/test 26 Mar 2010 13:42:18,772: Getting page [path = 0:loginForm, versionNumber = 0] 26 Mar 2010 13:42:18,774: registered listener interface [RequestListenerInterface name=INewBrowserWindowListener, method=public abstract void org.apache.wicket.markup.html.INewBrowserWindowListener.onNewBrowserWindow()] 26 Mar 2010 13:42:18,790: Unable to find Cookie with name=loginForm.userId and request URI=/nrg/app/test You entered User id null 26 Mar 2010 13:42:18,793: Begin render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:18,799: Rendering raw markup 26 Mar 2010 13:42:18,807: End render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:18,809: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = POST, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = application/x-www-form-urlencoded, contentLength = 0, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:18,813: time=38,event=Interface[target:TestLogin$LoginForm(loginForm), page: com.sam.auth.TestLogin(0), interface: IFormSubmitListener.onFormSubmitted],response=Interface[target:TestLogin$LoginForm(loginForm), page: com.sam.auth.TestLogin(0), interface: IFormSubmitListener.onFormSubmitted],sessionid=535C7A65C8E2F12DE0EEA8EF26830D80,sessionsize=2602,sessionstart=Fri Mar 26 13:42:13 EDT 2010,requests=3,totaltime=366,activerequests=0,maxmem=891M,total=525M,used=253M 26 Mar 2010 13:42:18,815: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = POST, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = application/x-www-form-urlencoded, contentLength = 0, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:18,816: Redirecting to ?wicket:interface=:0 html titleHello World/title body form wicket:id=loginForm User Name input type=text wicket:id=userId/br/ input type=submit value=Login/ /form /body /html package com.sam.auth; import org.apache.wicket.markup.html.WebPage; import org.apache.wicket.markup.html.form.Form; import
RE: Wicket and JEE6
Warning: Long Response with sample code to illustrate issue.
I ran the following code in Glassfish v3 with the following jars:
portlet-api_2.0_spec-1.0.jar (someone is relying on this??)
slf4j-api-1.4.2.jar
slf4j-jdk14-1.4.2.jar
wicket-1.4.7.jar
Be sure to add an empty beans.xml to the WEB-INF folder.
After starting up Glassfish, type the following in the browser
(WicketTest is the name of my project, yours may vary):
localhost:8080/WicketTest/
The output it: No Util Class
localhost:8080/WicketTest/jsf.faces
The output is: Hello World!
Code follows
web.xml:
?xml version=1.0 encoding=UTF-8?
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; id=WebApp_ID
version=2.5
display-nameWicketTest/display-name
servlet
servlet-nameFaces Servlet/servlet-name
servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern/faces/*/url-pattern
url-pattern*.faces/url-pattern
/servlet-mapping
filter
filter-namewicket example/filter-name
filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class
init-param
param-nameapplicationClassName/param-name
param-valuecom.example.wicket.ExampleApplication/param-value
/init-param
/filter
filter-mapping
filter-namewicket example/filter-name
url-pattern/*/url-pattern
/filter-mapping
/web-app
EntityUtil.java:
package com.example.wicket;
public class EntityUtil {
public String getEntity() {
return Hello World!;
}
}
ExampleApplication.java:
package com.example.wicket;
import org.apache.wicket.Page;
import org.apache.wicket.protocol.http.WebApplication;
public class ExampleApplication extends WebApplication {
@Override
public Class? extends Page getHomePage() {
return HomePage.class;
}
}
HomePage.java:
package com.example.wicket;
import javax.inject.Inject;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.model.Model;
public class HomePage extends WebPage {
@Inject private EntityUtil util;
public HomePage() {
super();
add(new Label(hello, new ModelString(this.getHello(;
}
private String getHello() { return (null != util) ? util.getEntity()
: No Util Class; }
}
HomePage.html:
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html xmlns:wicket=http://wicket.apache.org;
head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1
titleInsert wicket title here/title
/head
body
span wicket:id=helloYo!/span
/body
/html
jsf.xhtml (in context root):
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
h:head
titleInsert jsf title here/title
/h:head
h:body
span#{controller.hello}/span
/h:body
/html
Controller.java:
package com.example.wicket;
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;
import javax.inject.Named;
@Named @RequestScoped
public class Controller {
@Inject private EntityUtil util;
public String getHello() { return (null != util) ? util.getEntity()
: No Util Class; }
}
-Original Message-
From: James Carman [mailto:jcar...@carmanconsulting.com]
Sent: Friday, March 26, 2010 11:36 AM
To: users@wicket.apache.org
Subject: Re: Wicket and JEE6
I started a JSR-299 integration project a while back, but at the time
there
was no portable way (across vendors) to get to the stuff you needed to
inject into your components. I believe that's been fixed in the latest
API,
but I haven't had a chance to dig in and verify that and then use it.
My
guess is that there's really not that much to it (my code was pretty
small).
On Fri, Mar 26, 2010 at 1:35 PM, Ericksen, Mark W (IS)
mark.erick...@ngc.com wrote:
Weld claims support, I don't know about built-in.
When I use @Inject in a Wicket WebPage subclass the objects are null.
Like I mentioned below, I added weld-wicket.jar and subclassed the
WeldApplication and the injected objects in the Wicket WebPage
subclass
are still null.
This was from following this example:
http://docs.jboss.org/weld/reference/1.0.0/en-US/html/viewlayers.html
If you track down the example code it seems that the examples from
JBoss
are using older versions of Wicket and Weld/Seam so I don't know if
something has broken in either project, wicket or weld.
Injection worked like a charm in a JSF2 controller class so I don't
know
what going wrong
Re: Caching components
But why in repeating views are the components duplicated for each row? Wicket should re-use the components - one instance for each row could do all the rendering. Not one instance for each row which is a waste. Caching is a different concept as it also preserves the data which is not wanted in repeaters unless one wants to cache the whole collection. Bernard On Fri, 26 Mar 2010 06:50:24 -0700, you wrote: the recommended way to handle this would be to cache the data not the generated html -igor On Fri, Mar 26, 2010 at 1:11 AM, Martin Sachs sachs.mar...@gmail.com wrote: We have a lot of Repeating views, which containing a lot of components, which also contains repeatingviews. To know would should be rendered, we load some hopefully small (listsizes, objectbyId, ...) datas from DB in the constructor and/or in onBeforeRender and in isVisible. You are right, this is not a recommented way. Most of the time is database-loading and wicket has no performance-problem for us. We profile our application and never found wicket-components as hotspots. One reason for loading some data in contstructur or onBeforeRender is to prevent creating huge hierarchies. This is faster than override isVisible(), since isVisible would called more than one times. For our usecase the responsetime is much faster with HTML-Caching, because the Database-calls are minimized. We save the time for creating componentshierarchies (all three categories) with loading data. Martin Jeremy Thomerson schrieb: On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs sachs.mar...@gmail.com mailto:sachs.mar...@gmail.com wrote: hi, we need caching of components, since the construction of huge hierarchies is not cheap. The rendering ist fast. We cache the rendered HTML of a hole component via a beheaviour and write them on the next requests into a Label (unescaped). So instead of creating the complete hierarchie on every request, we create a much smaller one. But you must check, that the cachable components are stateless. Also we have JQuery for client-effects in this components, this would also be cached. The performance is much better with that: approx. 10-50 times better: 100ms with cache (the response time is not much depending on count of users) vs 1500 ms without cache depending how many parallel user A 15x gain is a big statement to make. Can you please break this 1500ms down into at least the following categories: 1 - time in IModel#getObject() and all child calls of this (IOW, loading data) 2 - time in constructor of components (without loading data in the constructor - hopefully you're not doing this) 3 - time in rendering of components That would be a much better number to give other users. I have NEVER seen where creating / rendering components could take 1400ms - unless you're doing something wrong like database calls in your component constructors. So, I suspect that most of that 1400ms (I would guess at least 1250ms) is in your model loading. The only time I've seen (or seen proof of) the component hierarchy actually be the slow part of a Wicket page is if you were displaying a repeating view of some sort with thousands of rows and each row had a bunch of components in it - leading to tens of thousands of components being built in the hierarchy. -- Jeremy Thomerson http://www.wickettraining.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket and JEE6
Mark, Try taking a look at the addComponentInstantiationListener method on the Application class. It takes one parameter of type IComponentInstantiationListener and that interface has one method which is onInstantiation(Component component). Every time a component gets instantiated it will be handed to this listener so maybe you can write your own dependency injection code there. I would think that is what the WeldApplication is doing under the covers but since it isn't working for you then you may have more luck just writing it yourself. The other trick is to making this work is obtaining a reference to your weld context. I use Spring so I'm not familiar with what it takes with Weld. I hope this helps. Thanks, Josh -Original Message- From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com] Sent: Friday, March 26, 2010 11:52 AM To: users@wicket.apache.org Subject: Wicket and JEE6 Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket form data isn't received
Bryan, Have you put a breakpoint in your onSubmit method of the form to see if it is getting to that point? If it isn't then make sure you don't have a validator failing and no feedback panel. I've made that mistake before. Thanks, Josh -Original Message- From: Bryan Montgomery [mailto:mo...@english.net] Sent: Friday, March 26, 2010 3:33 PM To: users@wicket.apache.org Subject: Wicket form data isn't received I've been working on an existing wicket application and am banging my head against the desk :) I'm trying to have two different pages that handle the sign on for the authenticated web session. One which is using ntlm with jcifs works fine. However, I can't get any other forms to work. I see from looking closely at the log file that the data is posted - however it almost looks like it's redirected. I did see that it was 'unable to find cookie' - but i wouldn't think that is the problem. I've looked through the web.xml and the page we have that extends the AuthenticatedWebApplication. I'm not sure if that is the issue, or if it something else. I wonder if the form is being redirected as it is not authenticated ending up in a catch 22. Is a way to have unauthenticated pages when using the AuthenticatedWebApplication? Or am I stuck in a vicious circle :) I've included the html and java, based on the article at http://www.developer.com/java/web/article.php/3673576/Wicket-The-First-Steps .htm 26 Mar 2010 13:42:13,430: (request cycle) url: /nrg/app/test 26 Mar 2010 13:42:13,603: Add userId to [MarkupContainer [Component id = loginForm]] 26 Mar 2010 13:42:13,605: Add loginForm to [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:13,649: Begin render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:13,657: Load markup: cacheKey=com.sam.auth.TestLoginen_UShtml 26 Mar 2010 13:42:13,694: Loading markup from file:/home/HOMEDIRS/montgomeryb/tomcat/webapps/nrg/WEB-INF/classes/com/sam/a uth/TestLogin.html 26 Mar 2010 13:42:13,756: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = GET, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = null, contentLength = -1, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:13,771: time=328,event=BookmarkablePage[com.sam.auth.TestLogin()],response=Bookmarka blePage[com.sam.auth.TestLogin()],sessionid=535C7A65C8E2F12DE0EEA8EF26830D80 ,sessionsize=326,sessionstart=Fri Mar 26 13:42:13 EDT 2010,requests=2,totaltime=328,activerequests=0,maxmem=891M,total=525M,used=2 45M 26 Mar 2010 13:42:13,771: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = GET, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = null, contentLength = -1, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:18,771: (request cycle) url: /nrg/app/test 26 Mar 2010 13:42:18,772: Getting page [path = 0:loginForm, versionNumber = 0] 26 Mar 2010 13:42:18,774: registered listener interface [RequestListenerInterface name=INewBrowserWindowListener, method=public abstract void org.apache.wicket.markup.html.INewBrowserWindowListener.onNewBrowserWindow() ] 26 Mar 2010 13:42:18,790: Unable to find Cookie with name=loginForm.userId and request URI=/nrg/app/test You entered User id null 26 Mar 2010 13:42:18,793: Begin render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:18,799: Rendering raw markup 26 Mar 2010 13:42:18,807: End render [Page class = com.sam.auth.TestLogin, id = 0, version = 0] 26 Mar 2010 13:42:18,809: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = POST, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = application/x-www-form-urlencoded, contentLength = 0, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated = null] 26 Mar 2010 13:42:18,813: time=38,event=Interface[target:TestLogin$LoginForm(loginForm), page: com.sam.auth.TestLogin(0), interface: IFormSubmitListener.onFormSubmitted],response=Interface[target:TestLogin$Log inForm(loginForm), page: com.sam.auth.TestLogin(0), interface: IFormSubmitListener.onFormSubmitted],sessionid=535C7A65C8E2F12DE0EEA8EF26830 D80,sessionsize=2602,sessionstart=Fri Mar 26 13:42:13 EDT 2010,requests=3,totaltime=366,activerequests=0,maxmem=891M,total=525M,used=2 53M 26 Mar 2010 13:42:18,815: ending request for page [Page class = com.sam.auth.TestLogin, id = 0, version = 0], request [method = POST, protocol = HTTP/1.1, requestURL = http://poe3b:8800/nrg/app/test, contentType = application/x-www-form-urlencoded, contentLength = 0, contextPath = /nrg, pathInfo = null, requestURI = /nrg/app/test, servletPath = /app/test, pathTranslated =
Re: ListView and Serialization
Hi Sven,
you wrote:
there's no requirement for components inside ListView to be stateless -
I wonder were you got that from.
I got that from the ListView class comment and from studying the code.
The comment says:
By default, setReuseItems is false, which has the effect that ListView
replaces all child components by new instances. The idea behind this is that
you always render the fresh data, and as people usually use ListViews for
displaying read-only lists [...].
You can have Links, Buttons or anything else in there so removing all on
detach is a recipe for disaster for the next incoming request.
I don't think so, because removeAll is already called in ListView.
In onPopulate, which is called in onBeforeRender by AbstractRepeater, the
following can be found:
if (getReuseItems()) {
[...]
} else {
// Automatically rebuild all ListItems before rendering the
// list view
removeAll();
}
... then the components are recreated using populateItem.
In my opinion, the only difference in my proposal is to call removeAll
earlier: not in onBeforeRender of the next request cycle, but in onDetach of
the current request cycle.
Cheers,
Michael
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: ListView and Serialization
Hi Michael,
the only difference in my proposal is to call removeAll earlier:
not in onBeforeRender of the next request cycle, but in onDetach of
the current request cycle.
it makes a huge difference:
If you call removeAll in onDetach, the next request to a component
inside the ListView will no longer find its receiver:
populateItem(ListItem item) {
item.add(new Link(link) {
onClick() {
// how should this link be clicked when all components are already
removed??
}
});
}
Sven
Michael Gottschalk wrote:
Hi Sven,
you wrote:
there's no requirement for components inside ListView to be stateless -
I wonder were you got that from.
I got that from the ListView class comment and from studying the code.
The comment says:
By default, setReuseItems is false, which has the effect that ListView
replaces all child components by new instances. The idea behind this is that
you always render the fresh data, and as people usually use ListViews for
displaying read-only lists [...].
You can have Links, Buttons or anything else in there so removing all on
detach is a recipe for disaster for the next incoming request.
I don't think so, because removeAll is already called in ListView.
In onPopulate, which is called in onBeforeRender by AbstractRepeater, the
following can be found:
if (getReuseItems()) {
[...]
} else {
// Automatically rebuild all ListItems before rendering the
// list view
removeAll();
}
... then the components are recreated using populateItem.
In my opinion, the only difference in my proposal is to call removeAll
earlier: not in onBeforeRender of the next request cycle, but in onDetach of
the current request cycle.
Cheers,
Michael
-
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
Feedback border when using in a repeating view
I am using a feedback border panel for some components (i.e. email) in a repeating view (in this case a dataview). I am using a Email validator for this component and when an error occurs it creates a red border and backround around this component. Well it is supposed to but it isn't. I do this feedback border panel on components outside a repeating view and it works fine. Should I be doing something different? I tried setting the reuse strategy but it didn't work. Any suggestions? Thanks - Doug
RE: Wicket and JEE6
Thanks Josh. With your idea in mind I dug deeper into what Weld's support for Wicket is/was. In the Weld download is a jar called weld-wicket.jar that has a WeldApplication class for doing what you suggest. However following the instruction for using their integration code only got me an error when including their jar in my project. java.lang.NoSuchMethodError: org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service Registry; So I included the weld-wicket code in my simple project to see what was going on. Their integration solution provides a new RequestCycle class called WeldRequestCycle. In this class they attempt to preserve a long running conversation through weld/wicket trickery. There's a line of code in a few places that causes a runtime exception that stops the request cycle. ConversationContext conversationContext = Container.instance().services().get(ContextLifecycle.class).getConversat ionContext(); These are Weld classes, but stepping through the debugger shows it goes go back through the Wicket filter. Therefore I don't know who is at fault here. Maybe something in Wicket changed that is causing Weld to croak or Weld in Glassfish is the culprit. Either way I really don't care about long running conversation support at this point so I removed the class and any dependency on it in my modified version of the weld-wicket code base. With that exception out of the way and changing my application to subclass from WeldApplication, I have simple injection working with Weld. Yippee! I'll cross my fingers there are no other side effects. Problem is now what? I guess I can post this with the Seam/Weld team and hope someone updates the Weld-Wicket integration. Or I can hope someone from the Wicket team will take a look and see if it's something in the latest version of Wicket that caused this to break and could do a patch. Anyone? :) -Mark -Original Message- From: Josh Chappelle [mailto:jchappe...@4redi.com] Sent: Friday, March 26, 2010 2:59 PM To: users@wicket.apache.org Subject: RE: Wicket and JEE6 Mark, Try taking a look at the addComponentInstantiationListener method on the Application class. It takes one parameter of type IComponentInstantiationListener and that interface has one method which is onInstantiation(Component component). Every time a component gets instantiated it will be handed to this listener so maybe you can write your own dependency injection code there. I would think that is what the WeldApplication is doing under the covers but since it isn't working for you then you may have more luck just writing it yourself. The other trick is to making this work is obtaining a reference to your weld context. I use Spring so I'm not familiar with what it takes with Weld. I hope this helps. Thanks, Josh -Original Message- From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com] Sent: Friday, March 26, 2010 11:52 AM To: users@wicket.apache.org Subject: Wicket and JEE6 Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - 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
FeedbackPanel's ListView paths missing in WicketTester 1.3.7
I¹m trying to drop in 1.3.7 to correct a number of AutoComplete-related problems, and finding a new problem: Whereas a FeedbackPanel used to contain paths like this: feedback:feedbackul:messages:0:message feedback:feedbackul:messages:1:message And one could assertLabel on these, now the only path is: feedback:feedbackul:messages Which appears to contain the whole ListView. The individual paths underneath are no longer reachable/assertable. They DO, however, render to the content on the page. So my questions are: is this intentional and if so, what is the reasoning behind it... And what¹s the new/right/best way to do these assertions? (Weirdly assertErrorMessages and assertInfoMessages both fail in this case (it¹s a warn, not an info or error), which is probably the reason the test was doing an assertLabel in the first place.) Suggestions?
Re: ListView and Serialization
Hi Sven,
Am Freitag, 26. März 2010 schrieb Sven Meier:
the only difference in my proposal is to call removeAll earlier:
not in onBeforeRender of the next request cycle, but in onDetach of
the current request cycle.
it makes a huge difference:
If you call removeAll in onDetach, the next request to a component
inside the ListView will no longer find its receiver:
populateItem(ListItem item) {
item.add(new Link(link) {
onClick() {
// how should this link be clicked when all components are already
removed??
}
});
}
Yes, you are right, thank you!
I did not think of the possibility that something could happen before
onBeforeRender is called.
However, for my use case, this is not a problem, since I only use stateless
components in many of my list views anyway.
I would then create a StatelessListView with my optimization and only use it
if I know that I have only stateless child components.
Cheers,
Michael
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Caching components
repeaters support this, see listview.setreuseitems() and refreshingview.setreuseitemstrategy() -igor On Fri, Mar 26, 2010 at 1:50 PM, b...@actrix.gen.nz wrote: But why in repeating views are the components duplicated for each row? Wicket should re-use the components - one instance for each row could do all the rendering. Not one instance for each row which is a waste. Caching is a different concept as it also preserves the data which is not wanted in repeaters unless one wants to cache the whole collection. Bernard On Fri, 26 Mar 2010 06:50:24 -0700, you wrote: the recommended way to handle this would be to cache the data not the generated html -igor On Fri, Mar 26, 2010 at 1:11 AM, Martin Sachs sachs.mar...@gmail.com wrote: We have a lot of Repeating views, which containing a lot of components, which also contains repeatingviews. To know would should be rendered, we load some hopefully small (listsizes, objectbyId, ...) datas from DB in the constructor and/or in onBeforeRender and in isVisible. You are right, this is not a recommented way. Most of the time is database-loading and wicket has no performance-problem for us. We profile our application and never found wicket-components as hotspots. One reason for loading some data in contstructur or onBeforeRender is to prevent creating huge hierarchies. This is faster than override isVisible(), since isVisible would called more than one times. For our usecase the responsetime is much faster with HTML-Caching, because the Database-calls are minimized. We save the time for creating componentshierarchies (all three categories) with loading data. Martin Jeremy Thomerson schrieb: On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs sachs.mar...@gmail.com mailto:sachs.mar...@gmail.com wrote: hi, we need caching of components, since the construction of huge hierarchies is not cheap. The rendering ist fast. We cache the rendered HTML of a hole component via a beheaviour and write them on the next requests into a Label (unescaped). So instead of creating the complete hierarchie on every request, we create a much smaller one. But you must check, that the cachable components are stateless. Also we have JQuery for client-effects in this components, this would also be cached. The performance is much better with that: approx. 10-50 times better: 100ms with cache (the response time is not much depending on count of users) vs 1500 ms without cache depending how many parallel user A 15x gain is a big statement to make. Can you please break this 1500ms down into at least the following categories: 1 - time in IModel#getObject() and all child calls of this (IOW, loading data) 2 - time in constructor of components (without loading data in the constructor - hopefully you're not doing this) 3 - time in rendering of components That would be a much better number to give other users. I have NEVER seen where creating / rendering components could take 1400ms - unless you're doing something wrong like database calls in your component constructors. So, I suspect that most of that 1400ms (I would guess at least 1250ms) is in your model loading. The only time I've seen (or seen proof of) the component hierarchy actually be the slow part of a Wicket page is if you were displaying a repeating view of some sort with thousands of rows and each row had a bunch of components in it - leading to tens of thousands of components being built in the hierarchy. -- Jeremy Thomerson http://www.wickettraining.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 - 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
Re: Caching components
Igor, I don't understand the optimal use of the different repeaters list views in different scenarios well enough yet, so I would be greateful if someone could provide a link for more documentation. As far as I understand, though, refreshingview.setreuseitemstrategy() is about re-using items - it is all about models. I am thinking about re-using the rendering component for ALL items in the collection. That would not require any strategy. And I would want this to work with database driven collections, so far I have used DataProvider with LDMs. What needs to be done to get re-used components in this scenario? Bernard On Fri, 26 Mar 2010 16:41:11 -0700, you wrote: repeaters support this, see listview.setreuseitems() and refreshingview.setreuseitemstrategy() -igor On Fri, Mar 26, 2010 at 1:50 PM, b...@actrix.gen.nz wrote: But why in repeating views are the components duplicated for each row? Wicket should re-use the components - one instance for each row could do all the rendering. Not one instance for each row which is a waste. Caching is a different concept as it also preserves the data which is not wanted in repeaters unless one wants to cache the whole collection. Bernard On Fri, 26 Mar 2010 06:50:24 -0700, you wrote: the recommended way to handle this would be to cache the data not the generated html -igor On Fri, Mar 26, 2010 at 1:11 AM, Martin Sachs sachs.mar...@gmail.com wrote: We have a lot of Repeating views, which containing a lot of components, which also contains repeatingviews. To know would should be rendered, we load some hopefully small (listsizes, objectbyId, ...) datas from DB in the constructor and/or in onBeforeRender and in isVisible. You are right, this is not a recommented way. Most of the time is database-loading and wicket has no performance-problem for us. We profile our application and never found wicket-components as hotspots. One reason for loading some data in contstructur or onBeforeRender is to prevent creating huge hierarchies. This is faster than override isVisible(), since isVisible would called more than one times. For our usecase the responsetime is much faster with HTML-Caching, because the Database-calls are minimized. We save the time for creating componentshierarchies (all three categories) with loading data. Martin Jeremy Thomerson schrieb: On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs sachs.mar...@gmail.com mailto:sachs.mar...@gmail.com wrote: hi, we need caching of components, since the construction of huge hierarchies is not cheap. The rendering ist fast. We cache the rendered HTML of a hole component via a beheaviour and write them on the next requests into a Label (unescaped). So instead of creating the complete hierarchie on every request, we create a much smaller one. But you must check, that the cachable components are stateless. Also we have JQuery for client-effects in this components, this would also be cached. The performance is much better with that: approx. 10-50 times better: 100ms with cache (the response time is not much depending on count of users) vs 1500 ms without cache depending how many parallel user A 15x gain is a big statement to make. Can you please break this 1500ms down into at least the following categories: 1 - time in IModel#getObject() and all child calls of this (IOW, loading data) 2 - time in constructor of components (without loading data in the constructor - hopefully you're not doing this) 3 - time in rendering of components That would be a much better number to give other users. I have NEVER seen where creating / rendering components could take 1400ms - unless you're doing something wrong like database calls in your component constructors. So, I suspect that most of that 1400ms (I would guess at least 1250ms) is in your model loading. The only time I've seen (or seen proof of) the component hierarchy actually be the slow part of a Wicket page is if you were displaying a repeating view of some sort with thousands of rows and each row had a bunch of components in it - leading to tens of thousands of components being built in the hierarchy. -- Jeremy Thomerson http://www.wickettraining.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail:
Wicket page test 1.3 is now available
Dear all, Wicket page test 1.3 is now available. It is a library allowing you to unit test your Wicket pages easily, supporting AJAX and Javascript without changes to your pages. New features implemented in this version: * Provide a generic starter page to launch another page whose constructor needs some arguments. * Provide a page navigator to inspect the arguments passed to the response page. * Easier way to open a page. Get it from maven as described in http://wicketpagetest.sourceforge.net/ -- Author of books for learning CXF, Axis2, Wicket, JSF (http://www.agileskills2.org) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
I've got a working example with Weld. Check out: http://svn.carmanconsulting.com/public/wicket-candi/trunk There's a weld-example subdirectory in there. Currently, I don't have the conversation stuff working, but the injections appear to be working. Unfortunately, the implementation doesn't work with OWB. :( I'll see what's causing it and see if we can get them both working. Good luck. On Fri, Mar 26, 2010 at 6:35 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Thanks Josh. With your idea in mind I dug deeper into what Weld's support for Wicket is/was. In the Weld download is a jar called weld-wicket.jar that has a WeldApplication class for doing what you suggest. However following the instruction for using their integration code only got me an error when including their jar in my project. java.lang.NoSuchMethodError: org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service Registry; So I included the weld-wicket code in my simple project to see what was going on. Their integration solution provides a new RequestCycle class called WeldRequestCycle. In this class they attempt to preserve a long running conversation through weld/wicket trickery. There's a line of code in a few places that causes a runtime exception that stops the request cycle. ConversationContext conversationContext = Container.instance().services().get(ContextLifecycle.class).getConversat ionContext(); These are Weld classes, but stepping through the debugger shows it goes go back through the Wicket filter. Therefore I don't know who is at fault here. Maybe something in Wicket changed that is causing Weld to croak or Weld in Glassfish is the culprit. Either way I really don't care about long running conversation support at this point so I removed the class and any dependency on it in my modified version of the weld-wicket code base. With that exception out of the way and changing my application to subclass from WeldApplication, I have simple injection working with Weld. Yippee! I'll cross my fingers there are no other side effects. Problem is now what? I guess I can post this with the Seam/Weld team and hope someone updates the Weld-Wicket integration. Or I can hope someone from the Wicket team will take a look and see if it's something in the latest version of Wicket that caused this to break and could do a patch. Anyone? :) -Mark -Original Message- From: Josh Chappelle [mailto:jchappe...@4redi.com] Sent: Friday, March 26, 2010 2:59 PM To: users@wicket.apache.org Subject: RE: Wicket and JEE6 Mark, Try taking a look at the addComponentInstantiationListener method on the Application class. It takes one parameter of type IComponentInstantiationListener and that interface has one method which is onInstantiation(Component component). Every time a component gets instantiated it will be handed to this listener so maybe you can write your own dependency injection code there. I would think that is what the WeldApplication is doing under the covers but since it isn't working for you then you may have more luck just writing it yourself. The other trick is to making this work is obtaining a reference to your weld context. I use Spring so I'm not familiar with what it takes with Weld. I hope this helps. Thanks, Josh -Original Message- From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com] Sent: Friday, March 26, 2010 11:52 AM To: users@wicket.apache.org Subject: Wicket and JEE6 Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands,
Re: Caching components
set the reuse strategy to one that reuses components. we ship one, look for implementations of the interface -igor On Fri, Mar 26, 2010 at 5:57 PM, b...@actrix.gen.nz wrote: Igor, I don't understand the optimal use of the different repeaters list views in different scenarios well enough yet, so I would be greateful if someone could provide a link for more documentation. As far as I understand, though, refreshingview.setreuseitemstrategy() is about re-using items - it is all about models. I am thinking about re-using the rendering component for ALL items in the collection. That would not require any strategy. And I would want this to work with database driven collections, so far I have used DataProvider with LDMs. What needs to be done to get re-used components in this scenario? Bernard On Fri, 26 Mar 2010 16:41:11 -0700, you wrote: repeaters support this, see listview.setreuseitems() and refreshingview.setreuseitemstrategy() -igor On Fri, Mar 26, 2010 at 1:50 PM, b...@actrix.gen.nz wrote: But why in repeating views are the components duplicated for each row? Wicket should re-use the components - one instance for each row could do all the rendering. Not one instance for each row which is a waste. Caching is a different concept as it also preserves the data which is not wanted in repeaters unless one wants to cache the whole collection. Bernard On Fri, 26 Mar 2010 06:50:24 -0700, you wrote: the recommended way to handle this would be to cache the data not the generated html -igor On Fri, Mar 26, 2010 at 1:11 AM, Martin Sachs sachs.mar...@gmail.com wrote: We have a lot of Repeating views, which containing a lot of components, which also contains repeatingviews. To know would should be rendered, we load some hopefully small (listsizes, objectbyId, ...) datas from DB in the constructor and/or in onBeforeRender and in isVisible. You are right, this is not a recommented way. Most of the time is database-loading and wicket has no performance-problem for us. We profile our application and never found wicket-components as hotspots. One reason for loading some data in contstructur or onBeforeRender is to prevent creating huge hierarchies. This is faster than override isVisible(), since isVisible would called more than one times. For our usecase the responsetime is much faster with HTML-Caching, because the Database-calls are minimized. We save the time for creating componentshierarchies (all three categories) with loading data. Martin Jeremy Thomerson schrieb: On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs sachs.mar...@gmail.com mailto:sachs.mar...@gmail.com wrote: hi, we need caching of components, since the construction of huge hierarchies is not cheap. The rendering ist fast. We cache the rendered HTML of a hole component via a beheaviour and write them on the next requests into a Label (unescaped). So instead of creating the complete hierarchie on every request, we create a much smaller one. But you must check, that the cachable components are stateless. Also we have JQuery for client-effects in this components, this would also be cached. The performance is much better with that: approx. 10-50 times better: 100ms with cache (the response time is not much depending on count of users) vs 1500 ms without cache depending how many parallel user A 15x gain is a big statement to make. Can you please break this 1500ms down into at least the following categories: 1 - time in IModel#getObject() and all child calls of this (IOW, loading data) 2 - time in constructor of components (without loading data in the constructor - hopefully you're not doing this) 3 - time in rendering of components That would be a much better number to give other users. I have NEVER seen where creating / rendering components could take 1400ms - unless you're doing something wrong like database calls in your component constructors. So, I suspect that most of that 1400ms (I would guess at least 1250ms) is in your model loading. The only time I've seen (or seen proof of) the component hierarchy actually be the slow part of a Wicket page is if you were displaying a repeating view of some sort with thousands of rows and each row had a bunch of components in it - leading to tens of thousands of components being built in the hierarchy. -- Jeremy Thomerson http://www.wickettraining.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 - To unsubscribe, e-mail:
