Re: Wicket6 setResponsePage() stackoverflow error.

[Milind]

some part of web.xml as:


 
  
MyPortlet

  org.apache.wicket.portlet.PortletFilter


  applicationClassName
  
test.portlet.myportlet.WicketApplication
  

  
  
  
  
MyPortlet
/MyPortlet/*
REQUEST
FORWARD
INCLUDE
  



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket6-setResponsePage-stackoverflow-error-tp4668538p4668541.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What is the proper way to start a secondary process in Wicket 6

[Ernesto Reinaldo Barreiro]

@Martin,

Many thanks! I will try to have a look today at the PR and see if I find
the time to write the blogs article during this week.

Thanks again!

On Mon, Nov 24, 2014 at 5:46 PM, Martin Grigorov 
wrote:

> Hi Ernesto,
>
> See https://github.com/reiern70/antilia-bits/pull/1
> I've moved the code that exports the Application thread local to
> TasksRunnable. This way it is possible to export the Session too.
>
> The code looks good (after removing all annoying whitespaces :-) ). Now it
> needs some explanation (i.e. blog article) ;-)
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sun, Nov 23, 2014 at 8:13 AM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > Warren,
> >
> > ThreadContext.detach(); seems to be more proper than...
> > ThreadContext.setApplication(null); I will update demo.
> >
> > On Sat, Nov 22, 2014 at 10:58 PM, Warren Bell 
> > wrote:
> >
> > > Ernesto,
> > >
> > > That’s kind of what I ended up doing except with a different
> > > ThreadPoolExecutor implementation.
> > >
> > > ExecutorService executorService = new ScheduledThreadPoolExecutor(20)
> > > {
> > > @Override
> > > protected void beforeExecute(Thread t, Runnable r) {
> > > ThreadContext.setApplication(MyApplication.this);
> > > }
> > >
> > > @Override
> > > protected void afterExecute(Runnable r, Throwable t) {
> > > ThreadContext.detach();
> > > }
> > > };
> > >
> > > No particular reason why I picked ScheduledThreadPoolExecutor other
> than
> > > it looked a little easier to use. I need to look more into the
> different
> > > types of Thread pools and such.
> > >
> > > I used:
> > >
> > > ThreadContext.detach();
> > >
> > > instead of:
> > >
> > > ThreadContext.setApplication(null);
> > >
> > > Warren Bell
> > >
> > >
> > > On Nov 22, 2014, at 11:18 AM, Ernesto Reinaldo Barreiro <
> > > reier...@gmail.com> wrote:
> > >
> > > > pushed a new version including injecting a Guice managed service
> class
> > > >
> > > > On Sat, Nov 22, 2014 at 8:08 PM, Ernesto Reinaldo Barreiro <
> > > > reier...@gmail.com> wrote:
> > > >
> > > >> Warren,
> > > >>
> > > >> Something like:
> > > >>
> > > >> ExecutorService executorService =  new ThreadPoolExecutor(10, 10,
> > > >>0L, TimeUnit.MILLISECONDS,
> > > >>new LinkedBlockingQueue()) {
> > > >>   @Override
> > > >>   protected void beforeExecute(final Thread t, final
> Runnable
> > > r) {
> > > >>   ThreadContext.setApplication(BgProcessApplication.this);
> > > >>   };
> > > >>   @Override
> > > >>   protected void afterExecute(final Runnable r, final
> > Throwable
> > > >> t) {
> > > >>   ThreadContext.setApplication(null);
> > > >>   }
> > > >> };
> > > >>
> > > >> seems to work.
> > > >>
> > > >> On Thu, Nov 20, 2014 at 8:33 PM, Warren Bell <
> > > warr...@clarksnutrition.com>
> > > >> wrote:
> > > >>
> > > >>> I have seen this from a 2010 post:
> > > >>>
> > > >>> final Application app = Application.get();
> > > >>>  final ExecutorService service = new
> > > >>> ScheduledThreadPoolExecutor(1) {
> > > >>>@Override
> > > >>>protected void beforeExecute(final Thread t, final
> > Runnable
> > > >>> r) {
> > > >>>  Application.set(app);
> > > >>>};
> > > >>>@Override
> > > >>>protected void afterExecute(final Runnable r, final
> > > Throwable
> > > >>> t) {
> > > >>>  Application.unset();
> > > >>>}
> > > >>>  };
> > > >>>
> > > >>> But there is no more Application#set(app) and Application#unset()
> in
> > > >>> Wicket 6. Does Wicket 6 have some built in way of creating
> secondary
> > > >>> processes, maybe an internal thread pool that can be set-up ?
> > > >>>
> > > >>> Warren Bell
> > > >>>
> > > >>> On Nov 20, 2014, at 10:03 AM, Warren Bell <
> > warr...@clarksnutrition.com
> > > >>> > wrote:
> > > >>>
> > > >>> Ernesto, great job putting all that code together so quickly. I
> > cloned
> > > >>> your project and cherry picked out the code that I needed, I don’t
> > > need all
> > > >>> the process progress code you have. I don’t really care what the
> > > process
> > > >>> progress is or even if it completes ok, just don’t want it holding
> up
> > > my
> > > >>> response.
> > > >>>
> > > >>> I ended up using your ExecutionBridge, TasksRunnable, and ITask
> > classes
> > > >>> and interfaces. But I still don’t know where and how to inject my
> > > service
> > > >>> into this new task/thread or ExecutionBridge without getting this
> > > exception:
> > > >>>
> > > >>> Exception in thread "pool-1-thread-1"
> > > >>> org.apache.wicket.WicketRuntimeException: There is no application
> > > attached
> > > >>> to current thread pool-1-thread-1
> > > >>>
> > > >>> Do I need to get the application attached

Re: Wicket6 setResponsePage() stackoverflow error.

[Paul Bors]

I'm no expert but it looks as if your filter from Liferay is looping calls
into Wicket's filter and vice-versa.

What's your web.xml config?

On Tue, Nov 25, 2014 at 12:22 AM, Milind  wrote:

> Hello,
>
> I am using Liferay "liferay-portal-6.2-ce-ga2" with Wicket6 and when
> setResponsePage(MyClass.class, params); is called it gives stackoverflow
> error. Does anyone came across similar error?
>
> http://www.liferay.com/community/forums/-/message_boards/message/45604006
>  >
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket6-setResponsePage-stackoverflow-error-tp4668538.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Wicket6 setResponsePage() stackoverflow error.

[Milind]

Hello,

I am using Liferay "liferay-portal-6.2-ce-ga2" with Wicket6 and when
setResponsePage(MyClass.class, params); is called it gives stackoverflow
error. Does anyone came across similar error?

http://www.liferay.com/community/forums/-/message_boards/message/45604006
  



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket6-setResponsePage-stackoverflow-error-tp4668538.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Question on Double Submit and rendering strategy

[Hesketh, Mark]

Thanks for that Martin - I understand. Thanks also for the alternate approaches.

I think we might experiment with the AjaxChannel#ACTIVE approach as an 
alternative although we do have the veil approach ready to ship.

Cheers.

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Monday, 24 November 2014 7:08 PM
To: users@wicket.apache.org
Subject: Re: Question on Double Submit and rendering strategy

Hi,

What you observe is correct !

Wicket support for Redirect after Post
 is to prevent double submit of 
a form if the user reloads the page (Ctrl+R or F5) or if the user navigates 
back. In these cases usually the browser would ask you whether you want to 
re-send the form data. With the REDIRECT_TO_XYZ strategies this is avoided.

As you have found out this doesn't cover the cases when the user clicks several 
times on a submit button/link. The only support for this in Wicket is to use 
AjaxChannel#ACTIVE for Ajax submit buttons/links. Using an active channel will 
prevent any following Ajax call while there is an active one with the same 
channel name. But this solution doesn't provide visual feedback for the user. 
It just silently ignores the click event.

Other ways to prevent multiple submits are not so generic and that's why they 
are not provided by Wicket itself.
These include:
- Disable the button/link somehow
Wicket 6.x replaces  with  by default but this is not acceptable 
by some applications.
Wicket-Bootstrap  for example 
follows Bootstrap recommendations for making the button/link look and act as 
disabled
- Show a veil
Some apps prefer to veil only the button. Others the whole screen. Others some 
area, e.g. just the form.
The UI used as a veil also differs for most applications... That's why Wicket 
doesn't provide a generic solution here.

Any feedback about this and other topics in Wicket are very welcome !

On Mon, Nov 24, 2014 at 1:36 AM, Hesketh, Mark 
wrote:

> Hi
>
> Please give more details what you try to avoid exactly by making
> changes in this area.
> [MH] Hello again,
> [MH] Well, I'm trying to avoid Double Submit through repeatedly button
> clicking (or submitting a form). We're currently [MH] porting all our
> web applications to Wicket. We have had to include a veil function
> around the Next button [MH] to block subsequent clicks explicitly as
> Wicket's Double Submit prevention (we are using the default
> RENDER_TO_BUFFER render strategy) [MH] is allowing repeated requests
> through. I've stepped through
> WebPageRenderer::respond() and noticed that there's a call [MH] to
> getAndRemoveBufferedResponse() and stopped looking since I could see
> that responses were being discarded. I just assumed that I am
> misunderstanding [MH] the full intent of the Double Submit treatment
> in Wicket. Hope that makes sense. I'm not wanting to *change* Wicket
> here, I'm chasing clarification only given what [MH] what I've stepped
> through and hear that from the maintainers directly. I guess I'm
> confused about what happens when there's more than one duplicate
> request when [MH] clearly the implementation is discarding (by design)
> the buffered response to an identical earlier request.
> [MH]
> [MH] Many thanks
>
> > Hello,
> >
> > I just wanted to know what the impact of removing the buffered
> > response (referring to javadoc below for REDIRECT_TO_BUFFER) for a
> > request is if there's presumably a bunch of other duplicate requests
> > following it on solving the Double Submit problem.
> > (
> > http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/s
> > et
> > tings/IRequestCycleSettings.html
> > )
> >
> > I'm puzzled about throwing a response away when I would have thought
> > it's buffered and reused to service the (duplicate) requests following?
> >
> > Many thanks
> >
> > cheers.
> > -m.
> >
> >
> > 
> > --
> > - This email, and any attachments, may be confidential and also
> > privileged.
> > If you are not the intended recipient, please notify the sender and
> > delete all copies of this transmission along with any attachments
> > immediately. You should not copy or use it for any purpose, nor
> > disclose its contents to any other person.
> > 
> > --
> > -
> >
> --
> - This email, and any attachments, may be confidential and also
> privileged.
> If you are not the intended recipient, please notify the sender and
> delete all copies of this transmission along with any attachments
> immediately. You should not copy or use it for any purpose, nor
> disclose its contents to any other person.
> --
> -
>
---

Re: IComponentOnBeforeRenderListener and ListView

[mscoon]

Martin,

I'll try once again to explain my problem and if it's still unclear I'll
make the quickstart.

What you say is right, the sequence of events is as you said.

My problem is that everything happens in AbstractRepeater#onBeforeRender().
So I have to put my code "attachValidationErrors" either before or after
AbstractRepeater#onBeforeRender().

If I put it before, the form components have not yet been created
(onPopulate() has not yet been called).

If I put it after, the componentPostOnBeforeRenderListeners have already
run so the ErrorDecorator thinks there are no errors.

What I need is a way for my code to run *after* onPopulate() but *before*
onBeforeRenderChildren(). There is no such hook though.

Let me also expand my pseudocode a bit in case this helps:

class MyPage extends WebPage {

pyblic MyPage() {

   Form form = new Form("form", model) {
   override onBeforeRender() {
   attachValidationErrors();
   onBeforeRender();
   }
   };
   add(form);

   ListView list = new ListView("list", model2) {
   public populateItem(ListItem listItem) {
   add(new TextField("name", new PropertyModel(model2, "name")));
   }
   }
   form.add(list);

}

void attachValidationErrors() {
  form.visitChildren(FormComponent.class, new
IVisitor() {
  void component(FormComponent obj, IVisit visit) {
  if (obj.getId().equals("name") /* and some other complex
logic here */) {
  obj.error("Please provide a name");
  }
  }
  });
}

I think this makes my problem quite evident. I can't find the right place
to put the call to attachValidationErrors().

Or perhaps I need a different implements for FormErrorDecorator.



On Mon, Nov 24, 2014 at 5:13 PM, Martin Grigorov 
wrote:

> Hi,
>
> Maybe I miss something from your description but I think ListView's items
> should have their #onBeforeRender() method called as any other component in
> the tree.
>
> org.apache.wicket.markup.repeater.AbstractRepeater#onBeforeRender() first
> calls #onPopulate() (where ListView adds its children) and then calls
> super.onBeforeRender()
> where org.apache.wicket.MarkupContainer#onBeforeRenderChildren() that calls
> #onBeforeRender() for all children components. So
> IComponentOnBeforeRenderListener should be notified.
>
> Maybe a quickstart will make it easier for understanding where is the
> problem.
>
>
> On Mon, Nov 24, 2014 at 4:52 PM, mscoon  wrote:
>
> > Martin,
> >
> > Application#getComponentPostOnBeforeRenderListeners is how I am already
> > registering my FormErrorDecorator.
> >
> > Attaching the validation errors after super.onBeforeRender() does not
> work
> > even for components that are statically added and not part of a list
> view.
> >
> > Here's some psuedocode:
> >
> > Form form = new Form("form", model) {
> >protected void onBeforeRender() {
> >super.onBeforeRender();
> >attachValidationErrors();
> >}
> > }
> >
> > super.onBeforeRender() calls onBeforeRender() on all children which in
> turn
> > calls both the componentPreOnBeforeRenderListeners and the
> > componentPostOnBeforeRenderListeners. So by the time
> > attachValidationErrors() is called the error decorator has run and
> finished
> > (and done nothing as it found no errors).
> >
> > If I move attachValidationErrors before super.onBeforeRender(), then it
> > works for statically added form components. It does not work for
> components
> > within ListViews because populateItem has not yet been called.
> >
> > I could move some of the error attaching logic within populateItem but
> this
> > is ugly and leads to code duplication (as populateItem will not always be
> > called because I need setReuseItems(true)).
> >
> > Any other ideas?
> >
> >
> >
> >
> >
> > On Mon, Nov 24, 2014 at 3:23 PM, Martin Grigorov 
> > wrote:
> >
> > > Hi,
> > >
> > > Try with org.apache.wicket.Application#getComponent*Post*
> > > OnBeforeRenderListeners()
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Mon, Nov 24, 2014 at 2:50 PM, mscoon  wrote:
> > >
> > > > Hi all,
> > > >
> > > > I am using a FormErrorDecorator that implements an
> > > > IComponentOnBeforeRenderListener in order to automatically attach a
> css
> > > > class to form components with validation errors (see
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/WICKET/Automatic+styling+of+form+errors
> > > > ).
> > > >
> > > > Sometimes I want to manually add errors to form components and I was
> > > doing
> > > > that in onBeforeRender() before the call to super.onBeforeRender(). I
> > do
> > > > this because sometimes the object being edited is in an invalid state
> > > and I
> > > > want to show the validation errors right when the form opens and not
> > > after
> > > > a submit. This is working fine for most cases as the errors are
> > attached
> > > to
> > > > the form components before the FormErrorDe

Re: Why doesn't Wicket seem to call Session.replaceSession automatically?

[Martin Grigorov]

https://issues.apache.org/jira/browse/WICKET-5775

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Nov 24, 2014 at 11:36 AM, Martin Grigorov 
wrote:

> Hi,
>
> wicket-auth-roles module was designed and advertised as an example rather
> than an extension for security best practices.
> But I agree with you that we could add that feature there.
> Please create a ticket at JIRA. Preferably with a patch or pull request at
> GitHub.
> Thank you!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Nov 24, 2014 at 10:55 AM, Thorsten Schöning  > wrote:
>
>> Hi all,
>>
>> during implementing the login a my current project I came across
>> WICKET-1767[1] which deals with session fixation problems, but to my
>> surprise it looks like the newly created method is not called
>> automatically by Wicket. If I search the code base for
>> "replaceSession(" I only get one result, the method itself.
>>
>> Is there any reason why Wicket doesn't call the method automatically?
>> Looks to me like AuthenticatedWebSession.signIn would be a good place
>> to call it automatically. When should I call it instead, at the
>> beginning of AuthenticatedWebSession.authenticate? This would prevent
>> session fixation even if exception got throw during the authentication
>> itself for any reason.
>>
>> [1]: https://issues.apache.org/jira/browse/WICKET-1767
>>
>> Mit freundlichen Grüßen,
>>
>> Thorsten Schöning
>>
>> --
>> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
>> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>>
>> Telefon...05151-  9468- 55
>> Fax...05151-  9468- 88
>> Mobil..0178-8 9468- 04
>>
>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

Re: What is the proper way to start a secondary process in Wicket 6

[Martin Grigorov]

Hi Ernesto,

See https://github.com/reiern70/antilia-bits/pull/1
I've moved the code that exports the Application thread local to
TasksRunnable. This way it is possible to export the Session too.

The code looks good (after removing all annoying whitespaces :-) ). Now it
needs some explanation (i.e. blog article) ;-)

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Sun, Nov 23, 2014 at 8:13 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Warren,
>
> ThreadContext.detach(); seems to be more proper than...
> ThreadContext.setApplication(null); I will update demo.
>
> On Sat, Nov 22, 2014 at 10:58 PM, Warren Bell 
> wrote:
>
> > Ernesto,
> >
> > That’s kind of what I ended up doing except with a different
> > ThreadPoolExecutor implementation.
> >
> > ExecutorService executorService = new ScheduledThreadPoolExecutor(20)
> > {
> > @Override
> > protected void beforeExecute(Thread t, Runnable r) {
> > ThreadContext.setApplication(MyApplication.this);
> > }
> >
> > @Override
> > protected void afterExecute(Runnable r, Throwable t) {
> > ThreadContext.detach();
> > }
> > };
> >
> > No particular reason why I picked ScheduledThreadPoolExecutor other than
> > it looked a little easier to use. I need to look more into the different
> > types of Thread pools and such.
> >
> > I used:
> >
> > ThreadContext.detach();
> >
> > instead of:
> >
> > ThreadContext.setApplication(null);
> >
> > Warren Bell
> >
> >
> > On Nov 22, 2014, at 11:18 AM, Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> wrote:
> >
> > > pushed a new version including injecting a Guice managed service class
> > >
> > > On Sat, Nov 22, 2014 at 8:08 PM, Ernesto Reinaldo Barreiro <
> > > reier...@gmail.com> wrote:
> > >
> > >> Warren,
> > >>
> > >> Something like:
> > >>
> > >> ExecutorService executorService =  new ThreadPoolExecutor(10, 10,
> > >>0L, TimeUnit.MILLISECONDS,
> > >>new LinkedBlockingQueue()) {
> > >>   @Override
> > >>   protected void beforeExecute(final Thread t, final Runnable
> > r) {
> > >>   ThreadContext.setApplication(BgProcessApplication.this);
> > >>   };
> > >>   @Override
> > >>   protected void afterExecute(final Runnable r, final
> Throwable
> > >> t) {
> > >>   ThreadContext.setApplication(null);
> > >>   }
> > >> };
> > >>
> > >> seems to work.
> > >>
> > >> On Thu, Nov 20, 2014 at 8:33 PM, Warren Bell <
> > warr...@clarksnutrition.com>
> > >> wrote:
> > >>
> > >>> I have seen this from a 2010 post:
> > >>>
> > >>> final Application app = Application.get();
> > >>>  final ExecutorService service = new
> > >>> ScheduledThreadPoolExecutor(1) {
> > >>>@Override
> > >>>protected void beforeExecute(final Thread t, final
> Runnable
> > >>> r) {
> > >>>  Application.set(app);
> > >>>};
> > >>>@Override
> > >>>protected void afterExecute(final Runnable r, final
> > Throwable
> > >>> t) {
> > >>>  Application.unset();
> > >>>}
> > >>>  };
> > >>>
> > >>> But there is no more Application#set(app) and Application#unset() in
> > >>> Wicket 6. Does Wicket 6 have some built in way of creating secondary
> > >>> processes, maybe an internal thread pool that can be set-up ?
> > >>>
> > >>> Warren Bell
> > >>>
> > >>> On Nov 20, 2014, at 10:03 AM, Warren Bell <
> warr...@clarksnutrition.com
> > >>> > wrote:
> > >>>
> > >>> Ernesto, great job putting all that code together so quickly. I
> cloned
> > >>> your project and cherry picked out the code that I needed, I don’t
> > need all
> > >>> the process progress code you have. I don’t really care what the
> > process
> > >>> progress is or even if it completes ok, just don’t want it holding up
> > my
> > >>> response.
> > >>>
> > >>> I ended up using your ExecutionBridge, TasksRunnable, and ITask
> classes
> > >>> and interfaces. But I still don’t know where and how to inject my
> > service
> > >>> into this new task/thread or ExecutionBridge without getting this
> > exception:
> > >>>
> > >>> Exception in thread "pool-1-thread-1"
> > >>> org.apache.wicket.WicketRuntimeException: There is no application
> > attached
> > >>> to current thread pool-1-thread-1
> > >>>
> > >>> Do I need to get the application attached to my new threads somehow
> so
> > I
> > >>> can use my injected service, and if so, how do I do that ?
> > >>>
> > >>> Warren
> > >>>
> > >>> On Nov 20, 2014, at 5:47 AM, Ernesto Reinaldo Barreiro <
> > >>> reier...@gmail.com > reier...@gmail.com>>
> > >>> wrote:
> > >>>
> > >>> Martin,
> > >>>
> > >>> I have created
> > >>>
> > >>> https://github.com/reiern70/antilia-bits/tree/master/bgprocess
> > >>>
> > >>> My only caveats are
> > >>>
> > >>>
> > >>>
> >
> https://githu

Re: IComponentOnBeforeRenderListener and ListView

[Martin Grigorov]

Hi,

Maybe I miss something from your description but I think ListView's items
should have their #onBeforeRender() method called as any other component in
the tree.

org.apache.wicket.markup.repeater.AbstractRepeater#onBeforeRender() first
calls #onPopulate() (where ListView adds its children) and then calls
super.onBeforeRender()
where org.apache.wicket.MarkupContainer#onBeforeRenderChildren() that calls
#onBeforeRender() for all children components. So
IComponentOnBeforeRenderListener should be notified.

Maybe a quickstart will make it easier for understanding where is the
problem.


On Mon, Nov 24, 2014 at 4:52 PM, mscoon  wrote:

> Martin,
>
> Application#getComponentPostOnBeforeRenderListeners is how I am already
> registering my FormErrorDecorator.
>
> Attaching the validation errors after super.onBeforeRender() does not work
> even for components that are statically added and not part of a list view.
>
> Here's some psuedocode:
>
> Form form = new Form("form", model) {
>protected void onBeforeRender() {
>super.onBeforeRender();
>attachValidationErrors();
>}
> }
>
> super.onBeforeRender() calls onBeforeRender() on all children which in turn
> calls both the componentPreOnBeforeRenderListeners and the
> componentPostOnBeforeRenderListeners. So by the time
> attachValidationErrors() is called the error decorator has run and finished
> (and done nothing as it found no errors).
>
> If I move attachValidationErrors before super.onBeforeRender(), then it
> works for statically added form components. It does not work for components
> within ListViews because populateItem has not yet been called.
>
> I could move some of the error attaching logic within populateItem but this
> is ugly and leads to code duplication (as populateItem will not always be
> called because I need setReuseItems(true)).
>
> Any other ideas?
>
>
>
>
>
> On Mon, Nov 24, 2014 at 3:23 PM, Martin Grigorov 
> wrote:
>
> > Hi,
> >
> > Try with org.apache.wicket.Application#getComponent*Post*
> > OnBeforeRenderListeners()
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Mon, Nov 24, 2014 at 2:50 PM, mscoon  wrote:
> >
> > > Hi all,
> > >
> > > I am using a FormErrorDecorator that implements an
> > > IComponentOnBeforeRenderListener in order to automatically attach a css
> > > class to form components with validation errors (see
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/WICKET/Automatic+styling+of+form+errors
> > > ).
> > >
> > > Sometimes I want to manually add errors to form components and I was
> > doing
> > > that in onBeforeRender() before the call to super.onBeforeRender(). I
> do
> > > this because sometimes the object being edited is in an invalid state
> > and I
> > > want to show the validation errors right when the form opens and not
> > after
> > > a submit. This is working fine for most cases as the errors are
> attached
> > to
> > > the form components before the FormErrorDecorator runs.
> > >
> > > However, form components inside a list view are not created until the
> end
> > > of ListView.onBeforeRender(). This means that I cannot attach errors
> > before
> > > this step because the list view items don't yet exist, and if I attach
> > them
> > > after onBeforeRender they are not picked up by the FormErrorDecorator.
> > >
> > > Any ideas?
> > >
> > > Thanks,
> > > Marios
> > >
> >
>

Re: Remove components from AjaxRequestTarget

[Andre Camilo]

Hey,

that worked, thanks :)

On 24-11-2014 12:02, Martin Grigorov wrote:

Hi,

You can
use org.apache.wicket.ajax.AjaxRequestTarget.IListener#onBeforeRespond(Map,
AjaxRequestTarget) and remove entries from the map.
See
https://github.com/apache/wicket/blob/master/wicket-core/src/test/java/org/apache/wicket/ajax/GlobalUpdateAjaxAttributesTest.java#L40
for how to setup.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Nov 24, 2014 at 1:47 PM, Andre Camilo <
andre.cam...@premium-minds.com> wrote:



Hi all,

I'm trying to create a component that has better Ajax support for
ListViews with Form components. I'm doing this by making diffs on the List
for each ajax request and reordering the elements with javascript.

Now I'm trying to remove my component from AjaxRequestTarget beforeRender
because of the "ajax repeater" exception.

I know I have alternatives to *target.remove(ajaxListView)*, but wouldn't
this be a good thing?
The ability to remove components from AjaxResponse at certain stage in the
rendering process?

Thanks :)

--

André Camilo
Software Architect

Premium Minds
Av. Marquês de Tomar nº69, 1º Andar
1050-154 Lisboa
www.premium-minds.com

Geral: +351 217 817 555
Tlm: +351 914 515 010
andre.cam...@premium-minds.com







--

André Camilo
Software Architect

Premium Minds
Av. Marquês de Tomar nº69, 1º Andar
1050-154 Lisboa
www.premium-minds.com

Geral: +351 217 817 555
Tlm: +351 914 515 010
andre.cam...@premium-minds.com

Re: IComponentOnBeforeRenderListener and ListView

[mscoon]

Martin,

Application#getComponentPostOnBeforeRenderListeners is how I am already
registering my FormErrorDecorator.

Attaching the validation errors after super.onBeforeRender() does not work
even for components that are statically added and not part of a list view.

Here's some psuedocode:

Form form = new Form("form", model) {
   protected void onBeforeRender() {
   super.onBeforeRender();
   attachValidationErrors();
   }
}

super.onBeforeRender() calls onBeforeRender() on all children which in turn
calls both the componentPreOnBeforeRenderListeners and the
componentPostOnBeforeRenderListeners. So by the time
attachValidationErrors() is called the error decorator has run and finished
(and done nothing as it found no errors).

If I move attachValidationErrors before super.onBeforeRender(), then it
works for statically added form components. It does not work for components
within ListViews because populateItem has not yet been called.

I could move some of the error attaching logic within populateItem but this
is ugly and leads to code duplication (as populateItem will not always be
called because I need setReuseItems(true)).

Any other ideas?





On Mon, Nov 24, 2014 at 3:23 PM, Martin Grigorov 
wrote:

> Hi,
>
> Try with org.apache.wicket.Application#getComponent*Post*
> OnBeforeRenderListeners()
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Nov 24, 2014 at 2:50 PM, mscoon  wrote:
>
> > Hi all,
> >
> > I am using a FormErrorDecorator that implements an
> > IComponentOnBeforeRenderListener in order to automatically attach a css
> > class to form components with validation errors (see
> >
> >
> https://cwiki.apache.org/confluence/display/WICKET/Automatic+styling+of+form+errors
> > ).
> >
> > Sometimes I want to manually add errors to form components and I was
> doing
> > that in onBeforeRender() before the call to super.onBeforeRender(). I do
> > this because sometimes the object being edited is in an invalid state
> and I
> > want to show the validation errors right when the form opens and not
> after
> > a submit. This is working fine for most cases as the errors are attached
> to
> > the form components before the FormErrorDecorator runs.
> >
> > However, form components inside a list view are not created until the end
> > of ListView.onBeforeRender(). This means that I cannot attach errors
> before
> > this step because the list view items don't yet exist, and if I attach
> them
> > after onBeforeRender they are not picked up by the FormErrorDecorator.
> >
> > Any ideas?
> >
> > Thanks,
> > Marios
> >
>

Re: IComponentOnBeforeRenderListener and ListView

[Martin Grigorov]

Hi,

Try with org.apache.wicket.Application#getComponent*Post*
OnBeforeRenderListeners()

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Nov 24, 2014 at 2:50 PM, mscoon  wrote:

> Hi all,
>
> I am using a FormErrorDecorator that implements an
> IComponentOnBeforeRenderListener in order to automatically attach a css
> class to form components with validation errors (see
>
> https://cwiki.apache.org/confluence/display/WICKET/Automatic+styling+of+form+errors
> ).
>
> Sometimes I want to manually add errors to form components and I was doing
> that in onBeforeRender() before the call to super.onBeforeRender(). I do
> this because sometimes the object being edited is in an invalid state and I
> want to show the validation errors right when the form opens and not after
> a submit. This is working fine for most cases as the errors are attached to
> the form components before the FormErrorDecorator runs.
>
> However, form components inside a list view are not created until the end
> of ListView.onBeforeRender(). This means that I cannot attach errors before
> this step because the list view items don't yet exist, and if I attach them
> after onBeforeRender they are not picked up by the FormErrorDecorator.
>
> Any ideas?
>
> Thanks,
> Marios
>

IComponentOnBeforeRenderListener and ListView

[mscoon]

Hi all,

I am using a FormErrorDecorator that implements an
IComponentOnBeforeRenderListener in order to automatically attach a css
class to form components with validation errors (see
https://cwiki.apache.org/confluence/display/WICKET/Automatic+styling+of+form+errors
).

Sometimes I want to manually add errors to form components and I was doing
that in onBeforeRender() before the call to super.onBeforeRender(). I do
this because sometimes the object being edited is in an invalid state and I
want to show the validation errors right when the form opens and not after
a submit. This is working fine for most cases as the errors are attached to
the form components before the FormErrorDecorator runs.

However, form components inside a list view are not created until the end
of ListView.onBeforeRender(). This means that I cannot attach errors before
this step because the list view items don't yet exist, and if I attach them
after onBeforeRender they are not picked up by the FormErrorDecorator.

Any ideas?

Thanks,
Marios

Re: Remove components from AjaxRequestTarget

[Martin Grigorov]

Hi,

You can
use org.apache.wicket.ajax.AjaxRequestTarget.IListener#onBeforeRespond(Map,
AjaxRequestTarget) and remove entries from the map.
See
https://github.com/apache/wicket/blob/master/wicket-core/src/test/java/org/apache/wicket/ajax/GlobalUpdateAjaxAttributesTest.java#L40
for how to setup.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Nov 24, 2014 at 1:47 PM, Andre Camilo <
andre.cam...@premium-minds.com> wrote:

> Hi all,
>
> I'm trying to create a component that has better Ajax support for
> ListViews with Form components. I'm doing this by making diffs on the List
> for each ajax request and reordering the elements with javascript.
>
> Now I'm trying to remove my component from AjaxRequestTarget beforeRender
> because of the "ajax repeater" exception.
>
> I know I have alternatives to *target.remove(ajaxListView)*, but wouldn't
> this be a good thing?
> The ability to remove components from AjaxResponse at certain stage in the
> rendering process?
>
> Thanks :)
>
> --
>
> André Camilo
> Software Architect
>
> Premium Minds
> Av. Marquês de Tomar nº69, 1º Andar
> 1050-154 Lisboa
> www.premium-minds.com
>
> Geral: +351 217 817 555
> Tlm: +351 914 515 010
> andre.cam...@premium-minds.com
>

Remove components from AjaxRequestTarget

[Andre Camilo]

Hi all,

I'm trying to create a component that has better Ajax support for ListViews 
with Form components. I'm doing this by making diffs on the List for each ajax 
request and reordering the elements with javascript.

Now I'm trying to remove my component from AjaxRequestTarget beforeRender 
because of the "ajax repeater" exception.

I know I have alternatives to *target.remove(ajaxListView)*, but wouldn't this 
be a good thing?
The ability to remove components from AjaxResponse at certain stage in the 
rendering process?

Thanks :)

--

André Camilo
Software Architect

Premium Minds
Av. Marquês de Tomar nº69, 1º Andar
1050-154 Lisboa
www.premium-minds.com

Geral: +351 217 817 555
Tlm: +351 914 515 010
andre.cam...@premium-minds.com

Re: Why doesn't Wicket seem to call Session.replaceSession automatically?

[Martin Grigorov]

Hi,

wicket-auth-roles module was designed and advertised as an example rather
than an extension for security best practices.
But I agree with you that we could add that feature there.
Please create a ticket at JIRA. Preferably with a patch or pull request at
GitHub.
Thank you!

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Nov 24, 2014 at 10:55 AM, Thorsten Schöning 
wrote:

> Hi all,
>
> during implementing the login a my current project I came across
> WICKET-1767[1] which deals with session fixation problems, but to my
> surprise it looks like the newly created method is not called
> automatically by Wicket. If I search the code base for
> "replaceSession(" I only get one result, the method itself.
>
> Is there any reason why Wicket doesn't call the method automatically?
> Looks to me like AuthenticatedWebSession.signIn would be a good place
> to call it automatically. When should I call it instead, at the
> beginning of AuthenticatedWebSession.authenticate? This would prevent
> session fixation even if exception got throw during the authentication
> itself for any reason.
>
> [1]: https://issues.apache.org/jira/browse/WICKET-1767
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Why doesn't Wicket seem to call Session.replaceSession automatically?

[Thorsten Schöning]

Hi all,

during implementing the login a my current project I came across
WICKET-1767[1] which deals with session fixation problems, but to my
surprise it looks like the newly created method is not called
automatically by Wicket. If I search the code base for
"replaceSession(" I only get one result, the method itself.

Is there any reason why Wicket doesn't call the method automatically?
Looks to me like AuthenticatedWebSession.signIn would be a good place
to call it automatically. When should I call it instead, at the
beginning of AuthenticatedWebSession.authenticate? This would prevent
session fixation even if exception got throw during the authentication
itself for any reason.

[1]: https://issues.apache.org/jira/browse/WICKET-1767

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Question on Double Submit and rendering strategy

[Martin Grigorov]

Hi,

What you observe is correct !

Wicket support for Redirect after Post
 is to prevent double
submit of a form if the user reloads the page (Ctrl+R or F5) or if the user
navigates back. In these cases usually the browser would ask you whether
you want to re-send the form data. With the REDIRECT_TO_XYZ strategies this
is avoided.

As you have found out this doesn't cover the cases when the user clicks
several times on a submit button/link. The only support for this in Wicket
is to use AjaxChannel#ACTIVE for Ajax submit buttons/links. Using an active
channel will prevent any following Ajax call while there is an active one
with the same channel name. But this solution doesn't provide visual
feedback for the user. It just silently ignores the click event.

Other ways to prevent multiple submits are not so generic and that's why
they are not provided by Wicket itself.
These include:
- Disable the button/link somehow
Wicket 6.x replaces  with  by default but this is not
acceptable by some applications.
Wicket-Bootstrap  for
example follows Bootstrap recommendations for making the button/link look
and act as disabled
- Show a veil
Some apps prefer to veil only the button. Others the whole screen. Others
some area, e.g. just the form.
The UI used as a veil also differs for most applications... That's why
Wicket doesn't provide a generic solution here.

Any feedback about this and other topics in Wicket are very welcome !

On Mon, Nov 24, 2014 at 1:36 AM, Hesketh, Mark 
wrote:

> Hi
>
> Please give more details what you try to avoid exactly by making changes
> in this area.
> [MH] Hello again,
> [MH] Well, I'm trying to avoid Double Submit through repeatedly button
> clicking (or submitting a form). We're currently
> [MH] porting all our web applications to Wicket. We have had to include a
> veil function around the Next button
> [MH] to block subsequent clicks explicitly as Wicket's Double Submit
> prevention (we are using the default RENDER_TO_BUFFER render strategy)
> [MH] is allowing repeated requests through. I've stepped through
> WebPageRenderer::respond() and noticed that there's a call
> [MH] to getAndRemoveBufferedResponse() and stopped looking since I could
> see that responses were being discarded. I just assumed that I am
> misunderstanding
> [MH] the full intent of the Double Submit treatment in Wicket. Hope that
> makes sense. I'm not wanting to *change* Wicket here, I'm chasing
> clarification only given what
> [MH] what I've stepped through and hear that from the maintainers
> directly. I guess I'm confused about what happens when there's more than
> one duplicate request when
> [MH] clearly the implementation is discarding (by design) the buffered
> response to an identical earlier request.
> [MH]
> [MH] Many thanks
>
> > Hello,
> >
> > I just wanted to know what the impact of removing the buffered
> > response (referring to javadoc below for REDIRECT_TO_BUFFER) for a
> > request is if there's presumably a bunch of other duplicate requests
> > following it on solving the Double Submit problem.
> > (
> > http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/set
> > tings/IRequestCycleSettings.html
> > )
> >
> > I'm puzzled about throwing a response away when I would have thought
> > it's buffered and reused to service the (duplicate) requests following?
> >
> > Many thanks
> >
> > cheers.
> > -m.
> >
> >
> > --
> > - This email, and any attachments, may be confidential and also
> > privileged.
> > If you are not the intended recipient, please notify the sender and
> > delete all copies of this transmission along with any attachments
> > immediately. You should not copy or use it for any purpose, nor
> > disclose its contents to any other person.
> > --
> > -
> >
> ---
> This email, and any attachments, may be confidential and also privileged.
> If you are not the intended recipient, please notify the sender and delete
> all copies of this transmission along with any attachments immediately. You
> should not copy or use it for any purpose, nor disclose its contents to any
> other person.
> ---
>