Re: component x not found on page y
I've been seeing similar exceptions, but haven't investigated in depth. They've only been hitting the administrative pages on my site, which makes me think that it's due to a combination of tabbed browsing and expired pages. Forgive my vagueness... I haven't looked closely at wicket's internals. My theory... 1. User loads page A in a tab with form "foo" on it. Page has id 1 in the pagemap. 2. Time passes, session/pagemap expires. 3. User loads page B in another tab. It also gets id 1. 4. User returns to tab A and submits form "foo". Wicket complains because there is no component "foo" in page B. I tried enabling multi-tab support to see if that would help, but it didn't work with my mounted URLs. I've read that using HybridUrlEncoding (?) could resolve that problem, but the problem hasn't been wide-spread enough to justify the risk. Hope this helps, Alex On Aug 4, 2008, at 2:25 PM, Jeremy Levy wrote: We have been struggling with an issue for several months now, any help would be appreciated. In our logs I see variations of the same error on the following error which results in a 500 for the user: 2008-08-04 13:21:24,006 ERROR Wap [RequestCycle] : component updateSection:theForm not found on page com.mdate.wap.messagecenter.TypeChatPage[id = 7], listener interface = [RequestListenerInterface name=IFormSubmitListener, method=public abstract void org .apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()] org.apache.wicket.WicketRuntimeException: component updateSection:theForm not found on page com.mdate.wap.messagecenter.TypeChatPage[id = 7], listener interface = [RequestListenerInterface name=IFormSubmitListener, method=public abstract void org .apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()] at org .apache .wicket .request .AbstractRequestCycleProcessor .resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java: 416) [snip] We are unable to repeat the issue and the pages render correctly when we test them. There is no AJAX in use on this site, and I can't identify any specific pattern. The error happens on unauthenticated pages as well as authenticated pages. We are using Wicket 1.3.4. The components that are referenced in the error messages don't exist on pages the messages reference. J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Direclty using parent's compoundpropertymodel not possible ?
I think we're talking about two different things: I was talking about trying to access the model of a parent component, it sounds like you're talking about trying to access the model of a superclass. In the case I'm talking about, you can't access the inherited model in your constructor because your object hasn't been added to the parent component yet (it will be added after the constructor runs). Therefore you need to wait until onBeforeRender to do initialization that depends on inspecting the inherited model. Hope that helps, Alex On Jul 31, 2008, at 5:39 PM, Daniel Freitas wrote: I think I might be missing something here. I assume you don't create your components in the parent's constructor right? Or you call a different super constructor perhaps? Because java executes the parent constructor before calling a subclass constructor and for what I've seen so far in the examples, the components are usually created and added in the constructor, so you would have created your components and models before getting to the subclass initialization. 2008/7/31 ZedroS <[EMAIL PROTECTED]> hi Sorry for the delay, holidays went in the way ;) Alex Jacoby-2 wrote: More than once I've tried accessing my inherited model from within a constructor, forgetting that since the component hasn't been added yet it can't access its inherited model there. That's not your problem, right? Alex hum, Alex, thanks a lot !! It's something I hadn't figured out by myself and most probably stuck my head against more than once without even realizing it ! Thanks a lot (and shame on me) ! It would be nice for it to be included in the Working with Wicket models wiki page for people like me... I'll definitely makes more tries of it, since I'm not sure I properly get how compound property models are shared among inheritors. And the day I'm sure of it, I'll update the wiki page if noone has done it before me. ++ zedros -- View this message in context: http://www.nabble.com/Direclty-using-parent%27s-compoundpropertymodel-not-possible---tp18356056p18763687.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Direclty using parent's compoundpropertymodel not possible ?
More than once I've tried accessing my inherited model from within a constructor, forgetting that since the component hasn't been added yet it can't access its inherited model there. That's not your problem, right? Alex On Jul 11, 2008, at 3:17 AM, Joseph P. wrote: I did already. My issue is more about model sharing with sub components and especially how to access it easily in a sub component (like for example in a panel whose representation depends on the data in the model attached to some form way above in the hierarchy). Thanks nonetheless for your help ++ zedros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wicketstuff examples internal error
Some of the repeater examples are returning "Internal server error". http://www.wicketstuff.org/wicket13/repeater/ I've got them locally too, but I figured someone might want to take a look. Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setRenderBodyOnly(true) - something more powerful?
Have you tried the tag? On Jun 11, 2008, at 9:29 AM, Martin Makundi wrote: Hi! I have had to tweak some markup. I have complex tables so my markup is as follows: I would very much like to hide the excess and tags completely from the markup seen by the browser. However, if I set setRenderBodyOnly(true) for the specific components, the tags will be visible as "" and "". Only the attributes are not rendered. Is there some way to hide completely the markup of the excess elements? Hurts validation. I cannot just set visibility to false because the elements are nested and I want the content to be visible :) ** Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can't get round this problem
I imagine it can be done, but I don't know how. You might want to explain more about what you're trying to do. -Original Message- From: Mathias P.W Nilsson [mailto:[EMAIL PROTECTED] Sent: Sun 6/8/2008 6:08 PM To: users@wicket.apache.org Subject: RE: Can't get round this problem The hidden fields are set after ajax submit and then I set the action on the form. I must MD5 some fields before submitting. Why can't this be done in wicket? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can't get round this problem
Sounds like you're submitting the info to another website (not back to your wicket app), in which case you should just use a plain HTML form (without associated wicket form components): wicket won't change the input field names then. Alex -Original Message- From: Mathias P.W Nilsson [mailto:[EMAIL PROTECTED] Sent: Sun 6/8/2008 5:31 PM To: users@wicket.apache.org Subject: Can't get round this problem I have a page that has 2 fragment. One for normal ordering and one for credit card ordering. When sending the input type hidden names they must have the exact name but wicket changes it orderPanel:Merchant_id must be Merchant_id. How can I remove the orderPanel that adds to the markup. I have tried to extend the hidden field and override the protected void onComponentTag(ComponentTag tag) but this just makes it work even worse. Why must wicket change the name of the input tag? Is there a way around this. I must be able to specify my own name. I was hoping that just new HiddenField( "Merchant_id", new Model( "" ) ); would do the trick but wicket changes that name. -- View this message in context: http://www.nabble.com/Can%27t-get-round-this-problem-tp17723379p17723379.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. I haven't tried migrating to 1.4 yet (waiting for the dust to settle), so I don't have any first-hand experience. The last java posse podcast discussed the wicket generics problem at length (though without any direct knowledge of the issues). They recommended a book for designing generified APIs, but the title escapes me. Here's the podcast link: http://media.libsyn.com/media/dickwall/JavaPosse189.mp3 I don't mean to imply that the core devs haven't already mastered all there is to master about generics, but everyone seems to agree that they can be tricky little beasts. I don't mind waiting longer for 1.4 if that's what it takes. Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Private Homepage Redirection
+1
I did something similar but not nearly so elegant. This would have
been nice to have.
On May 7, 2008, at 3:22 AM, Johan Compagner wrote:
add this to the api...
Because this is the second question about this in a very short time..
johna
On Wed, May 7, 2008 at 7:47 AM, Martijn Dashorst <[EMAIL PROTECTED]
>
wrote:
Perhaps this one helps?
public class RedirectToExternalException extends
AbstractRestartResponseException
{
private static final long serialVersionUID = 1L;
public RedirectToExternalException(String url)
{
RequestCycle rc = RequestCycle.get();
if (rc == null)
{
throw new IllegalStateException(
"This exception can only be
thrown from within request processing cycle");
}
else
{
Response r = rc.getResponse();
if (!(r instanceof WebResponse))
{
throw new IllegalStateException(
"This exception can
only be thrown when wicket is processing an
http request");
}
// abort any further response processing
rc.setRequestTarget(new
RedirectRequestTarget(url));
}
}
}
On 5/7/08, TH Lim <[EMAIL PROTECTED]> wrote:
RestartResponseException worked but it doesn't accept external
URL. As
a
result, I have to put the redirection in the dummy Page's HTML
header.
Someone in the forum mentioned using WebApplication.getHomePage() to
get
around but that too requires you to put up a dummy Page to
redirect to
the
external site as mentioned in previous paragraph.
Thanks for the replies. Now I have a choice to make after becoming
more
knowledgeable on this issue.
Eelco Hillenius wrote:
I tried both AbortException and RestartResponseException. They
didn't
work.
AbortException basically causes Wicket to show a blank page
instead
of
redirecting to the external site while RestartResponseException
caused
stack
overflow error. The exceptions were thrown in
onUnauthorizedInstantiation(...) method.
You should use the RestartResponseException, not AbortException
directly. The stack overflow error is something you can fix
yourself;
make sure you redirect to a page that won't cause these redirects
to
be triggered again.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Private-Homepage-Redirection-tp17079231p17093829.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AjaxEditableLabel - cancel broken on Safari
Hitting the escape key doesn't work to cancel an edit in AjaxEditableLabel with Safari 3.1.1 (and wicket 1.3.3 - nice symmetry in the versions :)). http://www.wicketstuff.org/wicket13/ajax/editable-label Works on Firefox. Is there any other way to cancel an edit? Can a cancel button be added to it by changing the editor component? Would people recommend using scriptaculous or dojo instead? I'd prefer to keep my extra dependencies to a minimum if possible. I added a JIRA entry: https://issues.apache.org/jira/browse/WICKET-1581 Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Wicket 1.3.3] Possible wicket:enclosure regression.
Thanks. Is this the right place to download 1.3.4? http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.3-SNAPSHOT/ Cheers, Alex On Apr 30, 2008, at 4:45 PM, Igor Vaynberg wrote: also fixed for 1.3.4... -igor On Wed, Apr 30, 2008 at 1:37 PM, Alex Jacoby <[EMAIL PROTECTED]> wrote: Forget it, I found it in JIRA - says it's fixed for 1.4. Now I just need to find where to download it :) https://issues.apache.org/jira/browse/WICKET-1536 Alex On Apr 30, 2008, at 4:32 PM, Alex Jacoby wrote: I just upgraded to 1.3.3 today and I'm having enclosure problems too -- it seems like their state isn't updated after the page is constructed. Is this fixed in trunk? Searched the list but haven't found anything yet. Thanks, Alex Fabio Fioretti wrote: Hi All, I'm experiencing a possible regression for wicket:enclosure in Wicket 1.3.3 (maybe related to the couple of patches that involved enclosures for 1.3.3). It thought of a regression because the following code works just fine in 1.3.1, even if I haven't tested it in 1.3.2. Basically, I have a RadioGroup with a couple of options. When the user selects the second option, a text field and link (wrapped in an enclosure) should appear next to the option. If she/he selects the first option, they should disappear again. Their visibility management is based on the enclosure. [snip] -- View this message in context: http://www.nabble.com/-Wicket-1.3.3--Possible-wicket%3Aenclosure-regression.-tp16480916p16991013.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Wicket 1.3.3] Possible wicket:enclosure regression.
Forget it, I found it in JIRA - says it's fixed for 1.4. Now I just need to find where to download it :) https://issues.apache.org/jira/browse/WICKET-1536 Alex On Apr 30, 2008, at 4:32 PM, Alex Jacoby wrote: I just upgraded to 1.3.3 today and I'm having enclosure problems too -- it seems like their state isn't updated after the page is constructed. Is this fixed in trunk? Searched the list but haven't found anything yet. Thanks, Alex Fabio Fioretti wrote: Hi All, I'm experiencing a possible regression for wicket:enclosure in Wicket 1.3.3 (maybe related to the couple of patches that involved enclosures for 1.3.3). It thought of a regression because the following code works just fine in 1.3.1, even if I haven't tested it in 1.3.2. Basically, I have a RadioGroup with a couple of options. When the user selects the second option, a text field and link (wrapped in an enclosure) should appear next to the option. If she/he selects the first option, they should disappear again. Their visibility management is based on the enclosure. [snip] -- View this message in context: http://www.nabble.com/-Wicket-1.3.3--Possible-wicket%3Aenclosure-regression.-tp16480916p16991013.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Wicket 1.3.3] Possible wicket:enclosure regression.
I just upgraded to 1.3.3 today and I'm having enclosure problems too -- it seems like their state isn't updated after the page is constructed. Is this fixed in trunk? Searched the list but haven't found anything yet. Thanks, Alex Fabio Fioretti wrote: > > Hi All, > > I'm experiencing a possible regression for wicket:enclosure in Wicket > 1.3.3 (maybe related to the couple of patches that involved enclosures > for 1.3.3). It thought of a regression because the following code > works just fine in 1.3.1, even if I haven't tested it in 1.3.2. > > Basically, I have a RadioGroup with a couple of options. When the user > selects the second option, a text field and link (wrapped in an > enclosure) should appear next to the option. If she/he selects the > first option, they should disappear again. Their visibility management > is based on the enclosure. > [snip] > -- View this message in context: http://www.nabble.com/-Wicket-1.3.3--Possible-wicket%3Aenclosure-regression.-tp16480916p16991013.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problems uploading files w/ Safari 3.1.1
I don't think this is a wicket issue, but curious if any else is noticing problems uploading files to tomcat-hosted apps with the latest version of Safari (3.1.1). The first upload attempt hangs, but if you cancel and try again, it works. Each subsequent upload does the same thing: hang, cancel, work. It only manifests when redirecting through apache to tomcat. If I connect directly to tomcat it's not a problem. I've seen it on wicket and non-wicket code. I saw these discussions but haven't tried their proposed solutions yet: http://www.webmasterworld.com/macintosh_webmaster/3300569.htm http://blog.airbladesoftware.com/2007/8/17/note-to-self-prevent-uploads-hanging-in-safari Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can only locate or create session in the context of a request cycle.
Right after I got onto my bike to ride home I realized the same thing
you did: it sounds like there's no need for the request cycle -- just
look for the token upon session creation (and maybe again if there's a
subsequent request for a not-yet-validated session).
But then there's the logout issue... If you do need to worry about
the user logging out in the other app too, it might be simplest to
just use a cookie to represent the fact that the user's logged in, and
check it (in the requestCycle) on each request. Assuming your two
apps are in the same domain, it works. There's some complication in
trying to make the cookie secure enough to avoid forgery, but it's
doable.
You mentioned the possibility of just invalidating the wicket session
from the other app -- if you can do that, go for it -- it sounds
simpler. In my case the other apps aren't java based, so that wasn't
an attractive option.
Good luck,
Alex
That is what I meant, but I wasn't sure if the token you were
referring to was in a cookie or in the URL. Since it's in the URL,
it
does complicate stuff.
Here's my proposal: use the custom request cycle to grab the initial
token and store that auth info in the request cycle. Then when you
create a new wicket session, check if the request cycle has a valid
auth token -- if so, you validate the session, save the auth token
there if necessary, and never worry about the request cycle (or URL
token) again.
Do i need to retain this in the RequestCycle at the first place ? I
mean i
can just fetch the token from the request object itself..in my
CustomSession constructor as follows :
public MyCustomSession(Request request)
{
super(request);
String authToken = request.getParameter("authToken");
if (authenticate(authToken) == "success")
{
setAuthToken(authToken);
}
}
I am not sure as to when exactly is the Session is created, but
given it
does before the request processing starts, in that case it is fair
enough
to have this logic in the Session constructor instead of
onBeginRequest(),
what do you think ?
You don't need to worry about people logging out from outside your
app, right?
Well we do, havent thought about it much, but the way i see it is
to have
invoke the InvalidateSessionPage (from this other interface/app),
in which
1) i invalid the wicket session
2) Have javascript to delete the cookie (jSessionId) from the
browser,
though i feel this wouldn't really be necessory if the first step is
performed..What do you think ?
What do you think? better approach, where the external app isnt
tightly
coupled with my app (where it needs to invoke the
InvalidateSessionPage)..
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can only locate or create session in the context of a request cycle.
Farhan, I figure we should take this back on-list. Messages in
chronological order, with my last response at the bottom.
> > On Apr 16, 2008, at 5:06 PM, [EMAIL PROTECTED] wrote:
> > Alex,
> >
> > Wasn't sure how frequent are u in the forum, so thought to mail you
> directly the reply...As below..
> >
> > Subclassing RequestCycle would give me control on begin/end of the
> request, i wouldnt still have access to the Wicket Session (as the
Wicket
> Session isnt created at that time)
> >
> > A plain servlet filter also gives me control in the beginning of
the
> request (if not at the end), except for the fact that i have am
playing with
> HttpRequest,HttpResponse, where as wicket RequestCycle gives me an
> abstracted view of these classes, other than that i am just
wondering what
> is the real benefit of extending WebRequestCycle..I can still do
all the
> authentication stuff (check for authtoken/cookie etc) in a normal
filter
> too..isnt it?..unless am missing some benefits which extending
RequestCycle
> would provide
> >
> > Farhan.
On Wed, Apr 16, 2008 at 2:20 PM, Alex Jacoby <[EMAIL PROTECTED]>
wrote:
> Farhan,
>
> Good call emailing me - I only check the forum when I get to work
in the
> morning.
>
> Why use the (wicket) session for auth info at all? You can use a
custom
> request cycle just like you use a custom session. That way the
fact that
> the session doesn't exist at request time is irrelevant.
>
> Then in your pages you can use RequestCycle.get() instead of
Session.get()
> to extract auth info.
>
> My custom AuthenticatedWebSession's auth methods all delegate to
my custom
> request cycle methods.
>
> Does that make sense?
>
> I'm not sure if this will help in your case, but it sounds like
it might.
>
> Alex
On Apr 16, 2008, at 5:42 PM, Farhan Sarwar wrote:
I kind of get you but to be sure, so u suggesting to store the auth
data within the request cycle itself and access it using
((MyCustomRequestCycle)RequestCycle.get()).getAuthToken (offcourse
once i have set the same attributes onBeginRequest) as below..
public class MyCustomRequestCycle extends WebRequestCycle
{
String authToken;
String cookieName;
public String getAuthToken()
{
return authToken;
}
public void setAuthToken(String authToken)
{
this.authToken = authToken;
}
public String getCookieName()
{
return cookieName;
}
public void setCookieName(String cookieName)
{
this.cookieName = cookieName;
}
public VCertRetailRequestCycle(WebApplication application, Request
request,
Response response)
{
super(application, (WebRequest) request, response);
}
protected void onBeginRequest()
{
// getToken from the url passed as a query string
setAuthToken(request.getParameter("authToken"));
}
protected void onEndRequest()
{
authToken = null;
cookieName = null;
}
}
Please comment if i am correctly understanding the approach u are
suggesting
Now if that is the correct understanding, its just helping me
maintain the values submitted with each request, available to all
the pages in that particular request cycle...but i would want to
maintain that information across the whole session, so that i dont
have to append the authToken (passed to me in the url at the first
place by the authentication framework) in every url i have in my
wicket app (in the form links, forms etcs)...
I understand that WebRequestCycle.onBeginRequest is acting like a
filter for me in a "wicket way" where before i allow the request
cycle to further continue i can redirect the un-authentication users
onBeginRequest to LoginPage or something...
Thanks in advance and Regards,
Farhan.
That is what I meant, but I wasn't sure if the token you were
referring to was in a cookie or in the URL. Since it's in the URL, it
does complicate stuff.
Here's my proposal: use the custom request cycle to grab the initial
token and store that auth info in the request cycle. Then when you
create a new wicket session, check if the request cycle has a valid
auth token -- if so, you validate the session, save the auth token
there if necessary, and never worry about the request cycle (or URL
token) again.
You don't need to worry about people logging out from outside your
app, right?
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can only locate or create session in the context of a request cycle.
Would subclassing your wicket RequestCycle work? That's where I'm doing similar authentication stuff right now and it seems to be working well. It seems like Session is harder to integrate with external apps since actions can happen that it's unaware of. If you use RequestCycle you can check cookies, tokens, etc, on each request, which is really where you want to do it since you have no idea if the user did something (like logout) in the external app. Alex On Apr 15, 2008, at 1:22 PM, mfs wrote: Yeah i need to..i.e. the very authentication token so that for subsequent request i cant avoid the authentication call.. Well i can opt for HttpSession but then i will be using the same wherever in my pages i need it (there are a couple of scenarios where i need to pass the info back), and hence compromising the abstraction wicket provides.. Johan Compagner wrote: if there is no session do you already want to store something? On Tue, Apr 15, 2008 at 3:10 AM, mfs <[EMAIL PROTECTED]> wrote: Guys, Please comment.. I have a non-wicket AuthenticationFilter which is intercepting all request to my wicket-app and checking if the request is coming in from a valid user. Basically in the url am passed over an authenticationToken (by another application where the user has signed in already). Now in my AuthenticationFilter i check if that is a valid token and if yes i want to set some attribute (isAuthenticated etc) in wicket-session, . The problem is that the wicket session has yet not been created (because this is the first request to the wicket app, intercepted by the filter), and hence i get this error "you can only locate or create sessions in the context of a request cycle", when i try do a Session.get(). I am already using WicketSessionFilter which would expose my wicket session to my non-wicket filter. The problem is just for the first request, where a wicket session yet doesnt exist. I am thinking of using HttpSession directly in my filter and store all the session data there, but before i do so, i thought to check if anyone has a better work around, ideally i would want to avoid using it. Thanks in advance Farhan -- View this message in context: http://www.nabble.com/Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16693084p16693084.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Re%3A-Can-only-locate-or-create-session-in-the-context-of-a-request-cycle.-tp16696797p16703394.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance question
I was just looking into this yesterday. If you use eclipse, the Test and Performance Tools Platform looks good: http://www.eclipse.org/tptp/ Unfortunately I couldn't get it to cooperate with my version of MyEclipse :( Alex On Apr 14, 2008, at 6:39 PM, Ritz123 wrote: Havent used a profiler in a while - is there any opensource one which can work with tomcat? igor.vaynberg wrote: profile it and see where the time goes, or paste some code from those pages -igor On Mon, Apr 14, 2008 at 2:57 PM, Ritz123 <[EMAIL PROTECTED]> wrote: Hi, I have created first couple of pages of my wicket application but have some performance concerns. The pages (even the refresh alone takes 6-7 secs on Dual Core 2.2GHz Pentium with 4GB of RAM). DB is located on the remote host, but has caching at the application server - so thats not adding to the latency for the refresh. Here is the requestlogger information for the home page refresh couple of times Can someone point me to the direction on going about finding out what is taking this long other than (and may be simpler than) running a profiler on the application - atleast initially. My application is running in deployment mode and is running in tomcat. = ! before getting top nav menuitems 1208209856242 ! after getting top nav menuitems 1208209860972 time taken 4730 2008-04-14 14:51:07,677 (http-0.0.0.0-8080-Processor12) [ RequestLogger.jav a:320:INFO ] time=11567,event=BookmarkablePage[com.neobits.web.pages.Index],resp onse = BookmarkablePage [com.neobits.web.pages.Index],sessionid=729B1C0D58665D15518 044E5C8A63088.jvm1,sessionsize=1177,sessionstart=Mon Apr 14 14:38:51 PDT 2008,re quests =4,totaltime=28472,activerequests=3,maxmem=532M,total=266M,used=56M ! before getting top nav menuitems 1208209878458 ! after getting top nav menuitems 1208209878696 time taken 238 2008-04-14 14:51:25,266 (http-0.0.0.0-8080-Processor4) [ RequestLogger.java :320:INFO ] time=6888,event=BookmarkablePage[com.neobits.web.pages.Index],respon se = BookmarkablePage [com.neobits.web.pages.Index],sessionid=729B1C0D58665D1551804 4E5C8A63088.jvm1,sessionsize=1177,sessionstart=Mon Apr 14 14:38:51 PDT 2008,requ ests =5,totaltime=35360,activerequests=3,maxmem=532M,total=266M,used=55M ! before getting top nav menuitems 1208209893292 ! after getting top nav menuitems 1208209893526 time taken 234 2008-04-14 14:51:40,514 (http-0.0.0.0-8080-Processor6) [ RequestLogger.java :320:INFO ] time=7309,event=BookmarkablePage[com.neobits.web.pages.Index],respon se = BookmarkablePage [com.neobits.web.pages.Index],sessionid=729B1C0D58665D1551804 4E5C8A63088.jvm1,sessionsize=1177,sessionstart=Mon Apr 14 14:38:51 PDT 2008,requ ests =6,totaltime=42669,activerequests=4,maxmem=532M,total=266M,used=46M -- View this message in context: http://www.nabble.com/Performance-question-tp16690935p16690935.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Performance-question-tp16690935p16691538.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make a Ajax button have a confirm dialog
http://cwiki.apache.org/WICKET/getting-user-confirmation.html
On Apr 1, 2008, at 9:54 PM, Pinger wrote:
I will look. However, if you could post a code example, you would be
my hero.
:)
freak182 wrote:
You need to extend AbstractBehavior of course and add some
javascript to
do the trick...you can use javascript already available or you can
customise to yuorself..im using jquery..you can google it :)
Pinger wrote:
That would be sweet.. how do I do that? Sorry I saw one example
for that
for the button but I could not get that could not get it working
for the
ajax button. If I can get this to work, I was going to see if the
developers want it for the release; I think it is a very common
behavior
that many people would use.
freak182 wrote:
You could add a behavior... e.g a confirmbehavior for your needs :)
Pinger wrote:
That is all well and good, but it does not
"Do Stuff"
now after i hit ok
djo.mos wrote:
Hi,
Pinger wrote:
I want to get a Yes/No confirm dialog, so I only "Do Stuff" if
they
say yes..
What kind of confirmation ? Javascript ? Html ?
for the first, you could use this
ajaxButton.add(new SimpleAttributeModifier("onclick", "return
confirm('Delete ?');"));
Cheers
--
View this message in context:
http://www.nabble.com/Make-a-Ajax-button-have-a-confirm-dialog-tp16425091p16435564.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 1.4 with only generics and stop support for 1.3
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Release 1.4 with only generics and stop support for 1.3
Just curious what experiences people had with serialization and generics, never having played there myself... On Mar 17, 2008, at 4:13 AM, Martijn Dashorst wrote: This thread is the accompanying discussion thread for the ongoing vote on the same subject. Please use this discussion thread for voicing your opinion or asking questions. This makes counting the votes much easier. The discussion on our development list makes it clear that a lot of folks are anxious for generified models. Most users if not all wish us to release a quick release which is 1.3 + generics. The consequence is that the core team will stop to support 1.3, and that everybody that wishes updates will have to migrate to 1.4, and upgrade to Java 5. Why should we keep supporting 1.3 and JDK 1.4? Why only a generified release, and not a full release with more Java5 conversions? Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
+1 for generics On Mar 17, 2008, at 8:33 AM, Ryan McKinley wrote: yes, generics! It would make the model business so much more clear. ryan Enrique Rodriguez wrote: On Sun, Mar 16, 2008 at 9:32 PM, Ned Collyer <[EMAIL PROTECTED]> wrote: FWIW +1 to java5 and 1.3. Generics == joy, especially with the model stuff wicket uses :) Same here; would like to see generics. Enrique - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why does SqlTimestampConverter only use the time portion of the timestamp?
I can't answer your question about why, but I can suggest using a DateTextField from wicket-datetime for more control over the formatting. Unfortunately, it requires adding two jars (wicket- datetime and jodatime). Alex On Mar 13, 2008, at 2:08 PM, Markus Strickler wrote: Hi- is there any reason why SqlTimestampConverter.convertToString() only returns a time? Or is this a bug? Thanks, -kusako - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-datetime
Odd... Just tested again and it's working now. Pretty sure I wasn't hallucinating before but if no one else notices the problem I'll chalk it up to gremlins in my computer. I was using Safari 3 on leopard, btw. Alex On Mar 11, 2008, at 4:00 PM, Nino Saturnino Martinez Vazquez Wael wrote: There was sometrouble with safari 2, but wicket got patched and that fixed it. Alex Jacoby wrote: Side note: the demo doesn't seem to be working in Safari (3.0.4). Clicking the calendar icon doesn't do anything. I don't see any JS errors in the console. Anyone else seen this? Alex On Mar 6, 2008, at 1:20 AM, Igor Vaynberg wrote: it seems to be working just fine here http://wicketstuff.org/wicket13/dates/ -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AjaxFormSubmitBehavior not working in Safari
I created a JIRA issue for this a couple weeks back... https://issues.apache.org/jira/browse/WICKET-1362 ...but it hasn't been touched yet. Anyone else seen this problem? Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-datetime
Side note: the demo doesn't seem to be working in Safari (3.0.4). Clicking the calendar icon doesn't do anything. I don't see any JS errors in the console. Anyone else seen this? Alex On Mar 6, 2008, at 1:20 AM, Igor Vaynberg wrote: it seems to be working just fine here http://wicketstuff.org/wicket13/dates/ -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Guide for html designers
Thanks for all the advice -- guess I'll see how it goes, possibly post something to the wiki if it seems to be useful. Alex On Mar 6, 2008, at 4:58 AM, Nino Saturnino Martinez Vazquez Wael wrote: Yeah thats the usual way.. But still if you panalize a lot, tweaking for them could become a little hard. But I guess if you spend a little hour with them they should not have those trouble.. Johan Compagner wrote: most of the time at least as far as i know you work the other way around. First the webdeveloper then the programmer And maybe after that the webdeveloper only tweaks. But he can do that just fine he just should leave the wicket tags alone johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Guide for html designers
Heh, slight misunderstanding -- I *am* the programmer, and my site is just about done, and I'm going to be passing it on to the web folk (HTML, CSS, graphics people who don't program) to prettify it asap. I know that it will involve me teaching them some of the basics of wicket, but I was wondering if there were resources out there for helping in this type of situation... a "Wicket for non-programmers" type guide. I've written a few pages so far... Thanks again for the suggestions, Alex On Mar 5, 2008, at 4:54 PM, Ned Collyer wrote: A web designer being a graphics or a HTML guy (or a combination thereof)? Seriously tho, design your site, give the output to the programmer to "wicket up". I don't see how wicket will work for you if you don't understand the basic bits of java. If you do, the tutorials and examples on the website http://wicket.apache.org/examples.html then that should be an easy enough stepping stone to forage deeper. Things you are probably interested in are panels, borders, includes and fragments. http://wicketstuff.org/wicket13/compref/ But I think you will find it tough with zero java knowledge. It may work well if you are working with a programmer :), but solo - good luck! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Guide for html designers
I searched the wiki and the list archives, but I haven't found any sort of wicket reference appropriate for a web designer who doesn't speak Java. The list of xhtml tags in the wiki is the closest, but it's definitely written more for the programmers. Am I missing something? If not, I'll contribute the guide I write to the wiki. Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Forget it... it wouldn't help much. http://en.wikipedia.org/wiki/Csrf: Using POST instead of GET does not offer protection, as JavaScript can be used to forge POST requests with ease. On Mar 4, 2008, at 9:29 AM, Alex Jacoby wrote: Just a thought from a security newbie... does/can wicket require POST for form submissions? Would that prevent the issue of embedding the evil param values in the src of an image? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Just a thought from a security newbie... does/can wicket require POST for form submissions? Would that prevent the issue of embedding the evil param values in the src of an image? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: need to sanitize uploaded file names before saving?
Thanks! That was the first thing I did, before I saw Files.filename(). I figured the latter would save me unnecessary object creation, though admittedly the java.io.File solution is probably more robust (I haven't looked at the source for File yet to compare the two). On Feb 20, 2008, at 5:36 PM, Peter Ertl wrote: Why not simply use new java.io.File(client_file_name).getName() ? > Returns the name of the file or directory denoted by this abstract pathname. > This is just the last name in the pathname's name sequence. > If the pathname's name sequence is empty, then the empty string is returned. Am 20.02.2008 um 22:03 schrieb Alex Jacoby: Good points -- I was munging the filename a bit, but basically leaving it unchanged so that it would be simpler to debug. I'm still curious about the directory traversal thing... I've tried using tamper data to change the filename, but I get a MalformedStreamException each time I try [1]. Side note: I think spaces are allowed in filenames in unix file systems. Just quoted or escaped. (Regardless, your point is still taken.) Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: need to sanitize uploaded file names before saving?
I'm now running it through Files.filename() followed by a replaceAll for non-word, non-dot chars. It seems to work OK. Have I overlooked anything? (They can still put a bad extension on the file, but since they're restricted to the data directory of my choosing I'm OK with that.) Thanks, Alex On Feb 20, 2008, at 4:03 PM, Alex Jacoby wrote: Good points -- I was munging the filename a bit, but basically leaving it unchanged so that it would be simpler to debug. I'm still curious about the directory traversal thing... I've tried using tamper data to change the filename, but I get a MalformedStreamException each time I try [1]. Side note: I think spaces are allowed in filenames in unix file systems. Just quoted or escaped. (Regardless, your point is still taken.) Alex [1] org.apache.wicket.util.upload.MultipartFormInputStream $MalformedStreamException: Stream ended unexpectedly at org .apache .wicket .util .upload .MultipartFormInputStream.readBodyData(MultipartFormInputStream.java: 568) On Feb 20, 2008, at 3:24 PM, Abdul Habra wrote: When I save uploaded files, I never use the client's name of the file. That could cause problems, and could be a security risk. For example, a windows client may have a file name which contains spaces, however on a unix system this will not be a valid file name. Another example if u r running on a windows server, somebody may upload a file named dir.bat and put in it whatever commands they like, then ... I leave it to your imagination :) Alex Jacoby <[EMAIL PROTECTED]> wrote: I'm saving uploaded files to a directory on the local file system. I was just wondering: would it be possible for someone to give their uploaded file a name like "../../secretdir/passwd" so that they could theoretically clobber another file (if permissions weren't somehow blocking it)? If so, is this something that wicket does or could check for? The javadocs for FileItem.getName say that while most browsers provide only a basename (no path), Opera does include a full path, so it would seem that a malicious user could do some directory traversal trickery... It's not hard to check for "../" or a leading "/" (or just "/" ANYWHERE I suppose), but I'd skip it if it weren't necessary. Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: need to sanitize uploaded file names before saving?
Good points -- I was munging the filename a bit, but basically leaving it unchanged so that it would be simpler to debug. I'm still curious about the directory traversal thing... I've tried using tamper data to change the filename, but I get a MalformedStreamException each time I try [1]. Side note: I think spaces are allowed in filenames in unix file systems. Just quoted or escaped. (Regardless, your point is still taken.) Alex [1] org.apache.wicket.util.upload.MultipartFormInputStream $MalformedStreamException: Stream ended unexpectedly at org .apache .wicket .util .upload .MultipartFormInputStream.readBodyData(MultipartFormInputStream.java: 568) On Feb 20, 2008, at 3:24 PM, Abdul Habra wrote: When I save uploaded files, I never use the client's name of the file. That could cause problems, and could be a security risk. For example, a windows client may have a file name which contains spaces, however on a unix system this will not be a valid file name. Another example if u r running on a windows server, somebody may upload a file named dir.bat and put in it whatever commands they like, then ... I leave it to your imagination :) Alex Jacoby <[EMAIL PROTECTED]> wrote: I'm saving uploaded files to a directory on the local file system. I was just wondering: would it be possible for someone to give their uploaded file a name like "../../secretdir/passwd" so that they could theoretically clobber another file (if permissions weren't somehow blocking it)? If so, is this something that wicket does or could check for? The javadocs for FileItem.getName say that while most browsers provide only a basename (no path), Opera does include a full path, so it would seem that a malicious user could do some directory traversal trickery... It's not hard to check for "../" or a leading "/" (or just "/" ANYWHERE I suppose), but I'd skip it if it weren't necessary. Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
need to sanitize uploaded file names before saving?
I'm saving uploaded files to a directory on the local file system. I was just wondering: would it be possible for someone to give their uploaded file a name like "../../secretdir/passwd" so that they could theoretically clobber another file (if permissions weren't somehow blocking it)? If so, is this something that wicket does or could check for? The javadocs for FileItem.getName say that while most browsers provide only a basename (no path), Opera does include a full path, so it would seem that a malicious user could do some directory traversal trickery... It's not hard to check for "../" or a leading "/" (or just "/" ANYWHERE I suppose), but I'd skip it if it weren't necessary. Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception redirecting to source page
Just wondering if this sort of thing is documented anywhere... Thanks, Alex On Feb 18, 2008, at 1:02 PM, Igor Vaynberg wrote: good. there are some internals that do not count on a runtime exception being thrown because of user code...for example throwing it out of something like validator will abort entire form processing, and might leave that particular form component in an inconsistent state. but throwing it out of onclick/onsubmit handlers shouldnt pose much problem as most wicket processing has already happened. -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j and commons.digester on tomcat
Well, solved it at last. Finally looked in my output directory and saw that it was totally empty. That was the real problem -- no class files -- but the lack of tomcat logging (or selective logging to system.out) hid that well. Clean build didn't help. Replacing eclipse config files with older versions from CVS didn't help. Trashing my ~/.eclipse didn't help. Still no class files were generated by eclipse. Changing the output directory and then changing it back finally resolved it. Did I say "arg"? Alex On Jan 31, 2008, at 4:06 PM, Alex Jacoby wrote: Eclipse crashed, and afterwards I seem to be unable to deploy my wicket app on tomcat. During deployment the digester component complains about not being able to find its logger, and my application "SummerProgram" fails to start. The other deployed apps (non-wicket) seem ok. I've spent the past hour searching google and the mailing list archives. It seems to come up with tomcat occasionally, but the only suggestions have been to make sure that the log4j jar isn't in the tomcat shared/lib or common/lib directory, and in my case it's not. Any ideas? Arg, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
log4j and commons.digester on tomcat
Eclipse crashed, and afterwards I seem to be unable to deploy my wicket app on tomcat. During deployment the digester component complains about not being able to find its logger, and my application "SummerProgram" fails to start. The other deployed apps (non-wicket) seem ok. I've spent the past hour searching google and the mailing list archives. It seems to come up with tomcat occasionally, but the only suggestions have been to make sure that the log4j jar isn't in the tomcat shared/lib or common/lib directory, and in my case it's not. Any ideas? Arg, Alex The relevant tomcat log: INFO: Starting service Catalina Jan 31, 2008 3:58:09 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.25 Jan 31, 2008 3:58:09 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled log4j:WARN No appenders could be found for logger (org.apache.commons.digester.Digester.sax). log4j:WARN Please initialize the log4j system properly. Jan 31, 2008 3:58:10 PM org.apache.catalina.core.StandardContext start SEVERE: Error filterStart Jan 31, 2008 3:58:10 PM org.apache.catalina.core.StandardContext start SEVERE: Context [/SummerProgram] startup failed due to previous errors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using SubmitLink button without a form
Solved: Just using a normal Link with its onClick instead. No need
for onSubmit.
Still, should the SubmitLink be fixed or have its javadocs updated, or
am I missing something?
Thanks,
Alex
On Jan 16, 2008, at 10:22 AM, Alex Jacoby wrote:
I would like to use a SubmitLink button without a form, but it looks
like the code for form-less SubmitLink only handles the case when
it's attached to an anchor tag, and not when it's attached to a
button input.
From SubmitLink.java:
// Here it properly sets the href tag in the case of an anchor, and
calls getTriggerJavaScript for other cases...
protected void onComponentTag(ComponentTag tag)
{
// [snip]
if (tag.getName().equalsIgnoreCase("a"))
{
tag.put("href", "#");
}
tag.put("onclick", getTriggerJavaScript());
}
}
// ... but getTriggerJavaScript returns null if there's no form
protected final String getTriggerJavaScript()
{
if (getForm() != null)
{
// [Does a lot of stuff]
}
else
{
return null;
}
}
I'm not sure what the javascript should be, but it should be
possible, right?
Thanks,
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
using SubmitLink button without a form
I would like to use a SubmitLink button without a form, but it looks
like the code for form-less SubmitLink only handles the case when it's
attached to an anchor tag, and not when it's attached to a button input.
From SubmitLink.java:
// Here it properly sets the href tag in the case of an anchor, and
calls getTriggerJavaScript for other cases...
protected void onComponentTag(ComponentTag tag)
{
// [snip]
if (tag.getName().equalsIgnoreCase("a"))
{
tag.put("href", "#");
}
tag.put("onclick", getTriggerJavaScript());
}
}
// ... but getTriggerJavaScript returns null if there's no form
protected final String getTriggerJavaScript()
{
if (getForm() != null)
{
// [Does a lot of stuff]
}
else
{
return null;
}
}
I'm not sure what the javascript should be, but it should be possible,
right?
Thanks,
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 12, 2008, at 2:56 PM, Dmitry Kandalov wrote: On Saturday 12 January 2008 23:25:43 Igor Vaynberg wrote: sure, and all you need to know is that you subclass requestcycle.onbeginrequest() and add your own code there and it is called at the beginning of the request. why do you need to know the sequence of calls that leads to onbeginrequest() being called? I don't. I can image someone may want to be sure that this method is called before anything else he overrides, or to know that he can't get requested page at this step, but probably it's a very rare case. I've hit exactly this type of issue -- you try to override one of the public methods, and it turns out that the object isn't fully initialized yet, so you can't do what you'd hoped to. I agree there's value to the black-box model, data encapsulation, and all that -- I don't want to know all the gory details of your implementation. However, for public methods which are designed to be overridden when necessary, it would be extremely helpful to have more documentation provided about the state of the object when that method is called. It's a matter of balance -- overall I think the documentation is pretty good, but there are places where it's weaker than it should be. Yes, I can set breakpoints and step through the code, but that shouldn't be the default response to questions about missing documentation. Following that argument you could say that NO javadocs are ever necessary :) Thanks for all the great work, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
when to cache pre-redirect urls
I'm integrating a wicket app w/ an external login framework. When a user who isn't logged in tries to access a restricted page, wicket redirects them to the sign-in page, which is a RedirectPage for the external login page. That page sets a cookie when people log in, and can redirect users back to any URL I specify. My problem is grabbing that URL -- I'd like to do it in the constructor of my WebRequestCycle, but I can't tell which page requests are real user requests, and which ones are wicket-created redirects to the login page. They both create a new WebRequestCycle, in both cases isRedirect() returns false, and in both cases request.getPage() returns null. I used to cache the URL in the session.getRoles method (it doesn't get called for the redirect), but it seems like there's got to be a better place (the request cycle for instance). Any ideas? Any ideas are appreciated, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: external login pages
It would be nice if it were easier to get the full URL for a page
like discussed here http://issues.apache.org/jira/browse/WICKET-609
Whoops - I see this is already fixed in the 1.3 release. The javadocs
just haven't been updated yet:
http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/protocol/http/RequestUtils.html
Alex
On Jan 4, 2008, at 10:54 AM, Alex Jacoby wrote:
Thanks for the advice. What you suggested is exactly what I've been
working on. I think I got it for now, but it's not pretty. Wicket-
auth-roles takes care of figuring out that the user isn't authorized
for a particular page "behind the scenes", so by the time my code
knows that the user is being redirected to the login page, the
original request is lost. My workaround is to save the original
request URL in the session in the AuthenticatedWebSession#getRoles
method on every request, even when it's not needed. That method
always seems to get called.
It would be nice if it were easier to get the full URL for a page
like discussed here http://issues.apache.org/jira/browse/WICKET-609
Thanks for the help,
Alex
On Jan 4, 2008, at 3:52 AM, Jeremy Thomerson wrote:
It's really late here and I'm not at a computer, so this is
somewhat pseudo-code, but try this:
// place where you caught that they weren't
// authenticated (before page construction)
String url =
getRequest
().getServletResponse().getUrlOrSomethingICantRememberRightNow();
throw new RestartResponseAtInterceptPageException(new
RedirectPage("/perl-stuff/signin.pl?dest=" + url));
Of course, you could encrypt the destination or something if it was
critical, but typically that shouldn't be a problem.
Hope this helps.
Jeremy Thomerson
-- sent from a wireless device
-Original Message-
From: "Erik van Oosten" <[EMAIL PROTECTED]>
To: users@wicket.apache.org
Sent: 1/4/08 2:23 AM
Subject: Re: external login pages
Hi Alex,
Normally you can throw a special exception, the
RestartResponseAtInterceptPageException. Unfortunately I do not think
this will work when the intercept page is external to Wicket.
So the only thing you can do, is put the original URL in a
parameter to
the perl page, and let the perl page use that as second redirect.
Makes
sense?
Regards,
Erik.
Alex Jacoby wrote:
I am building a new wicket app that has to use an existing login
page. The legacy login page is written in perl and sets a login
cookie before redirecting the user back to a specified URL.
I'm hoping to keep things simple and use role-based authorization
for
pages. In my authenticated app the login page is set to a
RedirectPage which redirects to the external login page. My problem
is that I can't figure out how to grab the original URL that sent me
to the login page, so that I can pass that URL to the external login
page, and thereby be sent to my original destination after login.
(Currently I just send them back to the home page, which is
annoying.)
Has anyone tried this before? I've got a feeling there's a better
way
I could be doing this -- my current version using
AuthenticatedWebApp
is very kludgy.
Thanks for any ideas,
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: external login pages
Thanks for the advice. What you suggested is exactly what I've been
working on. I think I got it for now, but it's not pretty. Wicket-
auth-roles takes care of figuring out that the user isn't authorized
for a particular page "behind the scenes", so by the time my code
knows that the user is being redirected to the login page, the
original request is lost. My workaround is to save the original
request URL in the session in the AuthenticatedWebSession#getRoles
method on every request, even when it's not needed. That method
always seems to get called.
It would be nice if it were easier to get the full URL for a page like
discussed here http://issues.apache.org/jira/browse/WICKET-609
Thanks for the help,
Alex
On Jan 4, 2008, at 3:52 AM, Jeremy Thomerson wrote:
It's really late here and I'm not at a computer, so this is somewhat
pseudo-code, but try this:
// place where you caught that they weren't
// authenticated (before page construction)
String url =
getRequest
().getServletResponse().getUrlOrSomethingICantRememberRightNow();
throw new RestartResponseAtInterceptPageException(new RedirectPage("/
perl-stuff/signin.pl?dest=" + url));
Of course, you could encrypt the destination or something if it was
critical, but typically that shouldn't be a problem.
Hope this helps.
Jeremy Thomerson
-- sent from a wireless device
-Original Message-
From: "Erik van Oosten" <[EMAIL PROTECTED]>
To: users@wicket.apache.org
Sent: 1/4/08 2:23 AM
Subject: Re: external login pages
Hi Alex,
Normally you can throw a special exception, the
RestartResponseAtInterceptPageException. Unfortunately I do not think
this will work when the intercept page is external to Wicket.
So the only thing you can do, is put the original URL in a parameter
to
the perl page, and let the perl page use that as second redirect.
Makes
sense?
Regards,
Erik.
Alex Jacoby wrote:
I am building a new wicket app that has to use an existing login
page. The legacy login page is written in perl and sets a login
cookie before redirecting the user back to a specified URL.
I'm hoping to keep things simple and use role-based authorization for
pages. In my authenticated app the login page is set to a
RedirectPage which redirects to the external login page. My problem
is that I can't figure out how to grab the original URL that sent me
to the login page, so that I can pass that URL to the external login
page, and thereby be sent to my original destination after login.
(Currently I just send them back to the home page, which is
annoying.)
Has anyone tried this before? I've got a feeling there's a better
way
I could be doing this -- my current version using AuthenticatedWebApp
is very kludgy.
Thanks for any ideas,
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
external login pages
I am building a new wicket app that has to use an existing login page. The legacy login page is written in perl and sets a login cookie before redirecting the user back to a specified URL. I'm hoping to keep things simple and use role-based authorization for pages. In my authenticated app the login page is set to a RedirectPage which redirects to the external login page. My problem is that I can't figure out how to grab the original URL that sent me to the login page, so that I can pass that URL to the external login page, and thereby be sent to my original destination after login. (Currently I just send them back to the home page, which is annoying.) Has anyone tried this before? I've got a feeling there's a better way I could be doing this -- my current version using AuthenticatedWebApp is very kludgy. Thanks for any ideas, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dynamic url
I'm new to wicket too, but my guess is that if you tried the URL in a new browser entirely (or if you quit and re-opened your browser), the URL wouldn't work any more. New tabs still have all the cookies that the old tabs have, which works out nicely in many cases. They're extensions of the current session, not new sessions. Hope I understood your problem correctly, Alex On Dec 17, 2007, at 4:10 AM, tbt wrote: Hi I'm a newbie to wicket and I'm using a WebSession to log users into my application. When navigating through the pages wicket generates a dynamic url such as http://192.222.7.66:8080/oem?wicket:interface=wicket-1:0:: But if you copy this url and paste it in a seperate tab the inner page is displayed. As a result users can view data without giving the username and password. How can I stop this. Thanks -- View this message in context: http://www.nabble.com/dynamic-url-tp14370171p14370171.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
