Re: DropDownChoiceWithStylingOptions
MartinM wrote: > > Hmm.. mine seems to work fine with some other test cases, is this the > same code you have or is it different: > It's the same, except for "Utils.equalsOrNull" which must be from your unpublished code, and I replaced it with one of my own utility methods. Just try my test case. Adrian -- View this message in context: http://old.nabble.com/DropDownChoiceWithStylingOptions%3CT%3E-tp26642690p27112556.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: DropDownChoiceWithStylingOptions
Hi, thanks for the quick reply.
MartinM wrote:
>
>> There's a small bug - endOptGroup(tmp) for "OptGroup changed" actually
>> closes
>> the optgroup after the current option, not before.
>
> Note: It is supposed to close the previous optgroup. Not the current
> optgroup.
>
Yep, that's why it's a bug. It actually starts a new optgroup and closes it
after one option.
> If there is a bug, can you give me your testcase?
>
Sure, here's the code:
package test;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;
import org.apache.wicket.markup.html.WebPage;
public class TestPage extends WebPage {
private static class Val implements Serializable {
private static final long serialVersionUID = 1L;
private final String text;
private final String group;
public Val(final String text, final String group) {
this.text = text;
this.group = group;
}
public String getText() {
return text;
}
public String getGroup() {
return group;
}
}
private static final IStyledChoiceRenderer R = new
IStyledChoiceRenderer() {
private static final long serialVersionUID = 1L;
@Override
public String getIdValue(final Val object, final int index) {
return String.valueOf(index);
}
@Override
public Object getDisplayValue(final Val object) {
return object.getText();
}
@Override
public String getOptionCssClassName(final Val t) {
return null;
}
@Override
public String getOptGroupLabel(final Val t) {
return t.getGroup();
}
};
public TestPage() {
final List list = new ArrayList();
for (int i = 0; i < 3; ++i) {
for (int j = 0; j < 3; ++j) {
list.add(new Val("text" + j, "group" + i));
}
}
add(new DropDownChoiceWithStylingOptions("test", list, R));
}
}
and the markup:
This is what it generates (I haven't stripped the wicket tags):
Choose One
text0
text1
text2
text0
text1
text2
text0
text1
text2
Adrian
--
View this message in context:
http://old.nabble.com/DropDownChoiceWithStylingOptions%3CT%3E-tp26642690p27112292.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: DropDownChoiceWithStylingOptions
There's a small bug - endOptGroup(tmp) for "OptGroup changed" actually closes
the optgroup after the current option, not before.
I replaced it with buffer.append(""), but I wonder if there can
be some other markup after the previous and whether that matters.
--
View this message in context:
http://old.nabble.com/DropDownChoiceWithStylingOptions%3CT%3E-tp26642690p27111776.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: Directions for Stateless Ajax
Nino.Martinez wrote: > > Why not put these to into wicketstuff minies? > > aditsu wrote: >> Well, I've just implemented a StatelessAutoCompleteTextField that works >> in >> wicket directly :) >> I used a similar technique to my StatlessAjaxLink described at >> http://www.nabble.com/Stateless-AJAX-links-td20031309.html > First, because I hadn't heard of that; second, I need approval from my boss. I expect he'll be ok. Oh and third, I need time to run some more tests. Adrian -- View this message in context: http://www.nabble.com/Directions-for-Stateless-Ajax-tp17518987p20831648.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]
Re: Directions for Stateless Ajax
nate roe wrote: > > I've written a stateless auto-complete TextField by adapting Wicket's own > JavaScript and using a servlet for the back end. I don't like the servlet > and I would like to instead use Wicket to serve the auto-complete > suggestions list, but I'm not sure how. > Well, I've just implemented a StatelessAutoCompleteTextField that works in wicket directly :) I used a similar technique to my StatlessAjaxLink described at http://www.nabble.com/Stateless-AJAX-links-td20031309.html Specifically, I copied AutoCompleteTextField and made some modifications: - replaced the AutoCompleteBehavior with a StatelessAutoCompleteBehavior and stored it in a field - implemented ILinkListener and called the autocomplete behavior's respond method from onLinkClicked StatelessAutoCompleteBehavior extends AutoCompleteBehavior with the following changes: - getStatelessHint returns true - getCallbackUrl returns a url constructed using ILinkListener.INTERFACE - onBind calls getComponent().setOutputMarkupId(true) (just like AbstractDefaultAjaxBehavior) For the record, I'm using wicket 1.4-m3 Adrian -- View this message in context: http://www.nabble.com/Directions-for-Stateless-Ajax-tp17518987p20830784.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]
Re: Generics changes in 1.4-rc1
Johan Compagner wrote: > > Please make issues for this in jira > Since you said issues, I created 3 issues: WICKET-1947, WICKET-1948, WICKET-1949 Adrian -- View this message in context: http://www.nabble.com/Generics-changes-in-1.4-rc1-tp20599173p20615568.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]
Generics changes in 1.4-rc1
Hi, I've been using m3 for a while and just tried switching to rc1. I found several problems: - LabelTree.getNodeTextModel requires IModel and returns IModel. I was overriding it and returning a Model, but I can't do that anymore. Why not just return IModel ? - RatingPanel now requires an IModel for the rating, but I was using IModel. How can I show "rated 3.6 from 7 votes" now? Can it use IModel instead? - BaseTree requires IModel; I was using a Model with a DefaultTreeModel object, but I can't do that anymore (TreeModel is not necessarily Serializable). Why not just require IModel ? Adrian -- View this message in context: http://www.nabble.com/Generics-changes-in-1.4-rc1-tp20599173p20599173.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]
Re: Handling exceptions during render
aditsu wrote: > > Anyway, I want to have the option to catch exceptions from child > components at certain points that I can define. And I think I got a new > idea.. involving replace and RestartResponseException > Well, it seems to work, except I had to call setAuto(true) on the replacement component, to avoid a "Cannot modify component hierarchy after render phase has started (page version cant change then anymore)" exception. I'm not entirely sure what setAuto does, I hope it doesn't break anything in this case. What does that exception mean anyway? Adrian -- View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20336613.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]
Re: Handling exceptions during render
igor.vaynberg wrote: > > i would hate a user to look at a signup form without a signup button > because something inside it caused an error. > > i would also hate to see a user at a checkout page with a missing > $500.00 discount amount shown because there was an error in the > discount label. > Some forms can be submitted by pressing enter, but anyway, there are indeed cases where removing a small component is not a good idea. It's probably better to replace the whole form or the whole checkout list with an error message, or in some cases replace/redirect the whole page (the current behavior). Anyway, I want to have the option to catch exceptions from child components at certain points that I can define. And I think I got a new idea.. involving replace and RestartResponseException Adrian -- View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20336435.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]
Re: Handling exceptions during render
Alex Objelean wrote: > > Can you be more specific? What kind of unexpected runtime exceptions are > you talking about? I don't think I understood you correctly. > It could be anything.. NPE (probably the most popular), IllegalArgumentException and its descendants, ArithmeticException, ClassCastException, IndexOutOfBoundsException etc... or a wrapper for a checked exception. It can happen in the application code or can be thrown from library code. As for the reasons.. again there are lots of possibilities: invalid input, buggy code, invalid data received from 3rd party, unhandled edge case, unavailable resource, high load, etc. > Any runtime exception thrown by the wicket is caused by a programming > error... there is no sense to catch it without fixing the problem in your > code. > That sounds foolish to me, unless you consider any failure to handle any of the situations described above, to be a programming error. And I disagree a LOT more about the second sentence: usually when an application is launched, it already passed some kind of testing which found everything to be working well, and the application works well for a while, then an unexpected exception happens. These exceptions in production are very good friends of Murphy and tend to follow several laws, such as: - Whatever can go wrong will go wrong, and at the worst possible time, in the worst possible way - Every non trivial program has at least one bug - If you perceive that there are four possible ways in which something can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop - If the input editor has been designed to reject all bad input, an ingenious idiot will discover a method to get bad data past it So anyway, when (not if) the unexpected exception is thrown in production code, what would you rather have the users see (whether there are 10, 1000 or 1000 users)? A big "internal error" page? Or a mostly-working page, but with one part missing or showing an error message? Especially if access to that same page is required in order to fix the problem! -- View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20327592.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]
Re: Handling exceptions during render
Well, I'm specifically talking about unexpected runtime exceptions. I don't want those to destroy the whole page. They can kill a component, that's ok, but the rest of the page should work. And yes I want to "make sure that no exceptions are thrown", except that's not so simple when you're dealing with a complex site and lots of pages, components and models. If I missed any exceptions, I want those to be handled gracefully rather than redirecting to an error page. renderAll is ONLY called on the page, all other components go through renderComponentTagBody to call renderNext, and both renderComponentTagBody and renderNext are final :( I tried overriding onComponentTagBody and wrapping the super invocation with try/catch, but then the markup gets broken because it doesn't close tags (i.e. advance in the markup stream?) after the exception is thrown in a child component, and I still get an error page :( renderComponent(MarkupStream) is final too, it seems that all "doors" are closed and locked... Erik van Oosten wrote: > > It won't. I think you have to dig deeper into the request rendering. > > Perhaps that overriding MarkupContainer#renderAll on all your Panels > that have expected exceptions will help. > > But then again, exceptions are intended for controlling the > non-expected. You should not use exceptions for normal page flow. In > other words: just make sure that no exceptions are thrown. > > Regards, > Erik. > > > aditsu wrote: >> Ok, but how would that let me render the rest of the page? > > -- View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20303184.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]
Re: Handling exceptions during render
Thanks, but I can't find any handleRuntimeException method in any class. I'm using wicket 1.4-m3. Also, if the method is private, then how can I possibly override it? Alex Objelean wrote: > > There are more threads about this issue... > > In order to catch all runtime exception, you have to override default > RequestCycle (newRequestCycle method) in your application class and > override RuntimeException e)> method. > > > Alex Objelean > -- View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20302652.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]
Re: Handling exceptions during render
Ok, but how would that let me render the rest of the page?
Alex Objelean wrote:
>
> There are more threads about this issue...
>
> In order to catch all runtime exception, you have to override default
> RequestCycle (newRequestCycle method) in your application class and
> override onRuntimeException method.
>
> Example:
> [CODE]
> @Override
> public RequestCycle newRequestCycle(final Request request, final Response
> response) {
> return new WebRequestCycle(this, (WebRequest) request, (WebResponse)
> response) {
> @Override
> public Page onRuntimeException(final Page page, final
> RuntimeException e) {
> //do something
> return null;
> }
> }
> }
> [/CODE]
>
>
> Alex Objelean
>
--
View this message in context:
http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20302703.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]
Handling exceptions during render
Hi, how can I catch any exception thrown while a component is rendering, and either hide the component or show an error message, but allow the rest of the page to render? Modifying or replacing each such component is not an option, I need a general way to handle exceptions while rendering any unknown component or child component. Such as a getObject method from a model throwing a runtime exception. Adrian -- View this message in context: http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20301737.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]
Re: Stateless AJAX links
Hi, I thought about what you said, and debugged some more. Here's what I found out: Johan Compagner wrote: > > RequestCycle.isRedirect() is right, because that is a call that tells us > must i redirect of i get a page redirect > and with ajax this is always the case. > > Problem is that the BookmarkablePageRequestTarget.getPage(RC) should only > create a page when it is not a redirect > And that also correct. > Actually, neither BehaviorRequestTarget nor AjaxRequestTarget ever check for redirect. As long as the target is not changed to something else, the redirect setting is ignored. AFAICT, the redirect-for-ajax thing is there so that *if* the *final* request target is something other than AjaxRequestTarget, it will cause a redirect. E.g. if in my handler method I set the response page to a bookmarkable page, then it should do a redirect indeed (that is, a javascript redirect, not an http 302). The problem is that my initial target is BookmarkableListenerInterfaceRequestTarget, before changing to AjaxRequestTarget, and wicket doesn't expect that. It sees a non-ajax target for an ajax request, so it just blindly says "this is a redirect", when actually I'm not gonna do that. So I think isRedirect should NOT check for ajax unless it's at the RESPOND step. In the PROCESS_EVENTS step it should only check for the redirect flag. That would probably solve my problem and at the same time it would start to make sense. What do you think? Adrian -- View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20193967.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]
Re: Stateless AJAX links
John Patterson wrote: > > > aditsu wrote: >> >> Anyway, everything is working now, but I wanted some answers to those >> questions. >> > > I am very interested in what you have achieved here. Is there any chance > you could summarise what you had to do to get stateless AJAX links to > work? Perhaps just a post to this topic or even a wiki page? > My first post in this thread pretty much describes what I did. You can find it at http://www.nabble.com/Stateless-AJAX-links-td20031309.html Feel free to ask for details where it's not clear. Adrian -- View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20189364.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]
Re: Stateless AJAX links
Johan Compagner wrote: > > what doesnt work? > it will throw a page expire now and that works. > It should work now just as normal links. > *My page* doesn't work in that situation, since wicket thinks it's expired. >> It's an ajax request that makes changes to the current page (without >> going >> to another page). What does that have to do with redirecting? > > redirect is only relevant if you redirect to a page > If it is a "normal" ajax request that just renders some components then > redirect boolean is used at all. > Then you just have an AjaxRequestTarget that does its work. > Have you read my previous messages? BookmarkablePageRequestTarget.getPage(RequestCycle) checks for isRedirect before calling newPage. isRedirect ALWAYS returns true for ajax requests (WHY???) I had to override a method to workaround this problem. > So you are just rendering a few components then the rendering/response > phase > shouldnt touch the redirect at all see above > you just have a AjaxRequestTarget > No, the original request target is never an AjaxRequestTarget. Normally it's a BehaviorRequestTarget but I'm using a BookmarkableListenerInterfaceRequestTarget instead. Only after the initial processing (which in my case has the problems I mentioned above), the target is changed to an AjaxRequestTarget. > see above, AjaxRequestTarget should then handle the response and that one > doesnt look at the redirect > and the redirect boolean is only relevant for the Response not the > request. > See above, the target is not an AjaxRequestTarget yet, it is BookmarkableListenerInterfaceRequestTarget. And it looks at isRedirect(), which doesn't even look at the redirect boolean because it checks for isAjax first and returns true. Again, why does isRedirect() always return true for ajax requests? > then just use statefull pages > I dont get why you have partial updated pages, that are constantly created > as the original again because > you want stateless pages. > Dont you want to keep that partial updated page in memory? > I guess you dont have any callbacks in the things you update? that is just > text/images? > The initial pages are stateless because this way I can cache them and serve up to 6000 requests per second or more, instead of 0.5 to 25 requests per second. In over 95% of the cases, users won't click on the ajax link. No wicket code will be executed. For the few cases when they do click, only one page will be created per session (I had to trick wicket to put it in the session, that was one of the other problems I mentioned). The component I am adding through the ajax request is a stateful form. I wanted to make it stateless, but there doesn't seem to be any reasonable way to do that, because it includes a captcha field. Anyway, everything is working now, but I wanted some answers to those questions. Regards, Adrian -- View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20184803.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]
Re: Session ID
aepelde wrote:
>
> I'have implemented a custom MySession session object and create an
> instance when my application's newSession method is called. Something
> simple like this:
>
> public Session newSession(Request request, Response response) {
> MySession session = new MySession(request);
> }
>
> Now I need to get this session's ID, but I don't know how to do it. Any
> idea?
>
>
You could call session.getId(). That will return null if there's not actual
web session associated; if you want to force using a web session, call
session.bind() first.
Adrian
--
View this message in context:
http://www.nabble.com/Session-ID-tp20175225p20175821.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]
Re: Stateless AJAX links
aditsu wrote: > > Furthermore, BookmarkableListenerInterfaceRequestTarget.processEvents > simply assumes that the page is not null after calling > getPage(requestCycle) > Oops, correction. This has changed between 1.4-m2 and m3, now it checks and throws a PageExpiredException. Either way, it won't work. Adrian -- View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20175686.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]
Re: Stateless AJAX links
Thanks. but some of the things don't really make sense: Johan Compagner wrote: > >> - Why does wicket always do redirect for ajax requests? > > Because how else would you render the resulting page? > It's an ajax request that makes changes to the current page (without going to another page). What does that have to do with redirecting? > Do you really want to replace the complete dom with a new page without the > browser doing a normal get? > Then the url thats in the browser wouldnt point at all anymore to the > right > page (if a user would do refresh in a browser) > No, I just replace part of the dom of the current page. If the user refreshes the page, he/she will see the original page again (like it was before the changes). >> - Why does BookmarkablePageRequestTarget.getPage(RequestCycle) only call >> newPage if isRedirect is false? And why is it final? > > see eriks reply, again the redirect is done through the browser as a > second > request > else the url in the browser doesnt point to the right page. > Well, then how can it possibly know what to redirect to, if it has no page? Furthermore, BookmarkableListenerInterfaceRequestTarget.processEvents simply assumes that the page is not null after calling getPage(requestCycle) > if you click an ajax link and you want to show a different page then yes a > redirect to that page has to happen > else we have to replace the complete document with the new page, dont know > if we really support that and if that will go fine in all the browsers. > Yeah, *if* I want to show a different page. (By the way, a 302 redirect won't help in that case, but I see that it automatically uses another way for ajax requests). However I *don't* want to show a different page. >> - Is there any better way to do what I am trying to do? > > yes why have ajax links that could be just normal links if you want to > have > a stateless page. > That could work, but I'd rather not render and send the whole updated page to the browser, when most of it doesn't change. How would that be better? Adrian -- View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20175375.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]
Re: Stateless AJAX links
Bump I still have several questions that haven't been answered: - What is the meaning of redirect (in the context of RequestCycle)? - Why does wicket always do redirect for ajax requests? - Why does BookmarkablePageRequestTarget.getPage(RequestCycle) only call newPage if isRedirect is false? And why is it final? - When I respond to the ajax request, adding a stateful component (therefore making the page stateful), why is the page not stored in the session automatically? - Are there any problems with the hacks I used? Do they break anything? - Is there any better way to do what I am trying to do? Thanks Adrian aditsu wrote: > > Hi, I managed to hack wicket (1.4-m3) to do a kind of stateless ajax link. > I extended AbstractLink and implemented ILinkListener, and added a custom > stateless AjaxEventBehavior that creates a callback url using the > ILinkListener interface (in order to get a > BookmarkableListenerInterfaceRequestTarget). > In onLinkClicked, I create an AjaxRequestTarget and then call an abstract > handler. > > This is already a nasty hack, however it doesn't work yet by itself. > BookmarkableListenerInterfaceRequestTarget.processEvents calls > getPage(requestCycle) if it can't find a page, and that method creates a > new page... but only if !requestCycle.isRedirect(). And isRedirect returns > true for ajax requests. > getPage is also final (why?) so I had to override processEvents to make it > work. > What does isRedirect mean anyway? And why is it true for all ajax > requests? > > After hacking that, the stateless ajax link worked, however when I tried > to add a stateful form to the page through it, it didn't work because the > page wasn't stored in the session. I had to use yet another hack - I > called getRequestCycle().urlFor(getPage()) because that seems to touch the > page in the session. > > So everything seems to work now, however I don't like having to use these > hacks, and I wonder if I broke anything by using them (especially the page > creation on redirect). Is there any better way to do ajax stateless links? > Is wicket going to support that anytime soon? > > Thanks > Adrian > -- View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20166433.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]
Re: Problem with a stateless form
I filed WICKET-1897 about this problem -- View this message in context: http://www.nabble.com/Problem-with-a-stateless-form-tp20127191p20166277.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]
Problem with a stateless form
Hi, I made a small application to reproduce the problem. You can download it from http://aditsu.net/wickettest.zip Dependencies: jetty 6, wicket 1.4-m3, slf4j, log4j Steps to reproduce: 1. Run the test.Start class 2. Open http://localhost:8080 in a browser 3. Open http://localhost:8080/page2 in a new tab 4. Go to the first tab and click submit Result: WicketRuntimeException: unable to find component with path form on stateless page [Page class = test.Page2, id = 0, version = 0] It looks like the 2 pages are created with the same id in 2 different pagemaps, but when I submit the form, it goes to the second pagemap and finds the second page (with no form on it). Bug? -- View this message in context: http://www.nabble.com/Problem-with-a-stateless-form-tp20127191p20127191.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]
Re: Stateless AJAX links
igor.vaynberg wrote: > > can you set a breakpoint and see where response.redirect is being called > from for ajax processing? i can see it would be called if you added the > page > itself to the ajaxrequesttarget. > Actually, redirect seems to be false, but WebRequestCycle.isRedirect first checks for isAjax. It also has a comment "If it's an ajax request we always redirect." I can try to debug it later to confirm, if needed. igor.vaynberg wrote: > > as far as supporting stateless ajax goes, i am not sure if or when we are > going to support it. we are not going to look into it until we start > working > on 1.5 (a month or two). the focus of wicket has never been stateless > pages. > I understand; I was thinking that wicket already supports stateless pages, and they can help improve the performance a lot, and from my experiment I found that it's not really hard to make stateless ajax work. Anyway, it's not bad if wicket will support that in a few months. Until then, I wonder if my way of doing it is good. Adrian -- View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20082568.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]
Re: RequestCycle.urlFor modifies a page's parameters?
igor.vaynberg wrote: > > i dont think this is normal. please file a jira issue. > Filed WICKET-1881 Thanks Adrian -- View this message in context: http://www.nabble.com/RequestCycle.urlFor-modifies-a-page%27s-parameters--tp20031013p20077002.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]
Re: DHTML DnD best practice?
Look at wicketstuff-jquery, especially DnDSortableBehavior. It's not perfect, but at least it can give you some ideas. -- View this message in context: http://www.nabble.com/DHTML-DnD-best-practice--tp20010633p20031872.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]
Stateless AJAX links
Hi, I managed to hack wicket (1.4-m3) to do a kind of stateless ajax link. I extended AbstractLink and implemented ILinkListener, and added a custom stateless AjaxEventBehavior that creates a callback url using the ILinkListener interface (in order to get a BookmarkableListenerInterfaceRequestTarget). In onLinkClicked, I create an AjaxRequestTarget and then call an abstract handler. This is already a nasty hack, however it doesn't work yet by itself. BookmarkableListenerInterfaceRequestTarget.processEvents calls getPage(requestCycle) if it can't find a page, and that method creates a new page... but only if !requestCycle.isRedirect(). And isRedirect returns true for ajax requests. getPage is also final (why?) so I had to override processEvents to make it work. What does isRedirect mean anyway? And why is it true for all ajax requests? After hacking that, the stateless ajax link worked, however when I tried to add a stateful form to the page through it, it didn't work because the page wasn't stored in the session. I had to use yet another hack - I called getRequestCycle().urlFor(getPage()) because that seems to touch the page in the session. So everything seems to work now, however I don't like having to use these hacks, and I wonder if I broke anything by using them (especially the page creation on redirect). Is there any better way to do ajax stateless links? Is wicket going to support that anytime soon? Thanks Adrian -- View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20031309.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]
RequestCycle.urlFor modifies a page's parameters?
Hi, I'm using wicket 1.4-m3
I was debugging a problem and I found that RequestCycle.urlFor(Component,
RequestListenerInterface, ValueMap) can sometimes modify the parameters of
an existing page.
Here's the relevant code:
if (listener != IRedirectListener.INTERFACE && component.isStateless() &&
page.isBookmarkable() && page.getStatelessHint())
{
PageParameters pageParameters = page.getPageParameters();
if (pageParameters == null)
{
pageParameters = new PageParameters();
}
if (params != null)
{
Iterator> it =
params.entrySet().iterator();
while (it.hasNext())
{
final Map.Entry entry =
it.next();
final String key = entry.getKey();
final String value =
entry.getValue().toString();
// Do not encode values here. It is the
encoder's job
// to do the endoding. This leads to
double encoding
// - Doug Donohoe
// @see
https://issues.apache.org/jira/browse/WICKET-1627
pageParameters.add(key, value);
}
}
Is this normal?
--
View this message in context:
http://www.nabble.com/RequestCycle.urlFor-modifies-a-page%27s-parameters--tp20031013p20031013.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]
