Re: SV: PageableListView to work with Set

2010-12-02 Thread nivs

Hi Thanks for the link. Would have to use a repeater to support more generic
ones. Thanks
niv
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/PageableListView-to-work-with-Set-tp3064909p3068641.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



wiQuery: Release 1.1.2

2010-12-02 Thread julien roche AKA indiana_jules
Hi,

Just a little annoucement for an intermediate release of wiQuery: the 1.1.2.

What kind of changes ?
* Use of jQuery 1.4.4  jQuery UI 1.8.6
* IModel enhancement for the options
* Javascript and Stylesheet enhancement
* Animate for the jQuery effect
* IWiQueryInitializer  wiquery.properties (like the wicket.properties)
* More tests
*  Issue 128
*  Issue 130

We have created too some new wiquery sites:
* http://code.google.com/p/wiquery-plugins/  // Which contains some
wiQuery plugins
* http://code.google.com/p/wiquery-demos/  // Sources for all
wiQuery examples
* http://code.google.com/p/wiquery-maven-archetype/ // Base for wiQuery
Maven Archetype

Best regards

Julien Roche


Re: Logout (Session destroy) on the last (stateful) page?

2010-12-02 Thread Matthias Keller

Hi Randy

Yes it appears to have something to do with that. Our app uses the 
REDIRECT_BUFFER by default (we never actively configured this though) 
which appears to be a sensible option for normal operation. I'm not very 
familiar with the render strategies but you appear to be right: The page 
is actually rendered at the end of the previous request where the 
session is invalidated too. Then a redirect happens to the pre-rendered 
page which fails because the Session is already gone...


Is there any hook that will be called at the end of the second request 
serving the pre-rendered content?
I found a workaround for the moment: In the previous page, I explicitly 
set setRedirect(false); but this has the consequence that if the user 
hits reload on the confirmation page, he will first be asked about 
resending the POST parameters...


Anything we could do to invalidate the session at the end of the serving 
of the prerendered page?


Thanks a lot

Matt

On 2010-12-01 20:44, Randy S. wrote:

Does the redirect to the home page happen because of Wicket's default render
strategy (REDIRECT_TO_BUFFER) that causes two requests?  You invalidate
session on the first which redirects to the buffered response. When the
second request comes in expecting to get the already-rendered response, you
get a new session.


On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi
martin.maku...@koodaripalvelut.com  wrote:


Hi!

I am curious too. For this reason we had to build our logoutpage so
that it invalidtes session logically but not in httpsession sense.

Only clicking something from login page will do that.

But it's a hack, I would like to know what's the proper way ;)

**
Martin



2010/12/1 Matthias Kellermatthias.kel...@ergon.ch:

Hi

I've got the following problem:
After a user completes a wizard, he sees a last confirmation page

containing

some data, thus it must be a stateful page called by the following code

from

the wizard:

setResponsePage(new ConfirmationPage(myBean));

This ConfirmationPage must only be displayed once, thus if the user does

a

refresh it must not be available anymore.
I expected that I would be able to call  session.invalidate() from

somewhere

within the ConfirmationPage's onAfterRender or onDetach methods.
Unfortunately, whenever I do this, the user is automatically redirected

to

the home page without a trace in the logs
Any idea how to do that?

Thanks

Matt







smime.p7s
Description: S/MIME Cryptographic Signature


Re: Problem on wicket-auth-role ve Spring-security integration

2010-12-02 Thread Altuğ Bilgin Altıntaş
why you don't just use Spring Security + Wicket ?



2010/12/2 Taner Diler jtdde...@gmail.com

 Hi,

 I'm trying to integrate Wicket-auth-roles 1.4.9 and Spring Security 3.0.4
 by
 following
 https://cwiki.apache.org/WICKET/spring-security-and-wicket-auth-roles.html
 .

 @AuthorizeAction and @AuthorizeInstantiation annotations are not working.

 The blog says 

 The only filter we need defined from Acegi is the
 HttpSessionContextIntegrationFilter. This filter will ensure that the
 SecurityContext is transported to and from the HttpSession onto the Thread
 context. All authorization is delegated to the wicket-auth-roles module
 which uses Annotations (@AuthorizeInstantiation).

 So how can I make configuration to provide this?



Re: AjaxButton + Form

2010-12-02 Thread alex shubert
Sure. Just add a Form and AjaxButton and see.
I replaced Button with Link as assembly of object to be ready before
button handler called sounds reasonable for me.

On 1 December 2010 17:46, Andrea Del Bene adelb...@ciseonweb.it wrote:
 That sounds strange. AjaxButton implements  IFormSubmittingComponent
 interface,  hence it should first invoke its onsubmit method and then parent
 form's onSubmit (as described in Form class JavaDoc).

 Is your AjaxButton inside form's hierarchy?

 It is
 public final void onFormSubmitted()

 No, Form#onSubmit is not called at all. After successful execution of
 internal submission trace proceed to
 AjaxButton#onSubmit(AjaxRequestTarget target, Form?  form)






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





-- 
Best regards
Alex

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



Re: Problem on wicket-auth-role ve Spring-security integration

2010-12-02 Thread alex shubert
Let me guess may be the reason is that document is pretty outdated
and provides no help if one looking for a how-to manual?
It just looks pretty useless for whos already familiar with JAAS and
SpringSecurity 'cos they will not found anything new and almost
unhelpful for whom doesn't .
 :)

For unknown reason the page looks locked so one can't propose new version.

2010/12/2 Altuğ Bilgin Altıntaş alt...@gmail.com:
 why you don't just use Spring Security + Wicket ?



 2010/12/2 Taner Diler jtdde...@gmail.com

 Hi,

 I'm trying to integrate Wicket-auth-roles 1.4.9 and Spring Security 3.0.4
 by
 following
 https://cwiki.apache.org/WICKET/spring-security-and-wicket-auth-roles.html
 .

 @AuthorizeAction and @AuthorizeInstantiation annotations are not working.

 The blog says 

 The only filter we need defined from Acegi is the
 HttpSessionContextIntegrationFilter. This filter will ensure that the
 SecurityContext is transported to and from the HttpSession onto the Thread
 context. All authorization is delegated to the wicket-auth-roles module
 which uses Annotations (@AuthorizeInstantiation).

 So how can I make configuration to provide this?





-- 
Best regards
Alex

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



Re: Logout (Session destroy) on the last (stateful) page?

2010-12-02 Thread Ernesto Reinaldo Barreiro
Matt,

Can't you just do some kind of trick so that your ConfirmationPage is
served as the home page? So that you invalidate the session but at
getHomePage() you temporarily return your ConfirmationPage?

Regards,

Ernesto

On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller
matthias.kel...@ergon.ch wrote:
 Hi Randy

 Yes it appears to have something to do with that. Our app uses the
 REDIRECT_BUFFER by default (we never actively configured this though) which
 appears to be a sensible option for normal operation. I'm not very familiar
 with the render strategies but you appear to be right: The page is actually
 rendered at the end of the previous request where the session is invalidated
 too. Then a redirect happens to the pre-rendered page which fails because
 the Session is already gone...

 Is there any hook that will be called at the end of the second request
 serving the pre-rendered content?
 I found a workaround for the moment: In the previous page, I explicitly set
 setRedirect(false); but this has the consequence that if the user hits
 reload on the confirmation page, he will first be asked about resending the
 POST parameters...

 Anything we could do to invalidate the session at the end of the serving of
 the prerendered page?

 Thanks a lot

 Matt

 On 2010-12-01 20:44, Randy S. wrote:

 Does the redirect to the home page happen because of Wicket's default
 render
 strategy (REDIRECT_TO_BUFFER) that causes two requests?  You invalidate
 session on the first which redirects to the buffered response. When the
 second request comes in expecting to get the already-rendered response,
 you
 get a new session.


 On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com  wrote:

 Hi!

 I am curious too. For this reason we had to build our logoutpage so
 that it invalidtes session logically but not in httpsession sense.

 Only clicking something from login page will do that.

 But it's a hack, I would like to know what's the proper way ;)

 **
 Martin



 2010/12/1 Matthias Kellermatthias.kel...@ergon.ch:

 Hi

 I've got the following problem:
 After a user completes a wizard, he sees a last confirmation page

 containing

 some data, thus it must be a stateful page called by the following code

 from

 the wizard:

 setResponsePage(new ConfirmationPage(myBean));

 This ConfirmationPage must only be displayed once, thus if the user does

 a

 refresh it must not be available anymore.
 I expected that I would be able to call  session.invalidate() from

 somewhere

 within the ConfirmationPage's onAfterRender or onDetach methods.
 Unfortunately, whenever I do this, the user is automatically redirected

 to

 the home page without a trace in the logs
 Any idea how to do that?

 Thanks

 Matt






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



Re: webapp shutdown listeners

2010-12-02 Thread alex shubert
Why dont you add you very own listener to servlet container?



-- 
Best regards
Alex

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



Re: Wicket-Hibernate Related LazyInitializationException

2010-12-02 Thread vineet semwal
do you see the exception when you try this?
 @Override
   protected Object load() {
  // return containerForm.getModelObject().getPhoneList();
return service.getRequiredObject(*).getPhoneList(); //or any thing like it
..

   }

On Thu, Dec 2, 2010 at 12:12 PM, Nivedan Nadaraj shravann...@gmail.comwrote:

 Hi James

 Thanks for the time. I use the CPM for the whole use case. Mmm..is LDM
 mandatory for such a use case? Am open for thoughts just want the best way
 to implement it.
 Can you explain a bit further what your thought was please?

 Thank you
 Regards




 On Thu, Dec 2, 2010 at 2:13 PM, James Carman ja...@carmanconsulting.com
 wrote:

  Just make sure your form's model is a LDM too.
 
  On Thu, Dec 2, 2010 at 12:23 AM, Nivedan Nadaraj shravann...@gmail.com
  wrote:
   Hi All
  
   I am guessing this is more of a Hibernate thing/issue but if some one
 has
   encountered this and has a explanation that I can probably use from the
   Wicket front would be great.
  
   https://forum.hibernate.org/viewtopic.php?f=1t=1008473
  
  
   I have a LazyIntializationException when i page through some items. I
 use
   the PageableListView, the List item(s) are entities that are retrieved
  via
   an association Person.phones which is  a Set type.
   The funny thing is, the LIException is intermittent. I am also using
   OpenSessionInViewFilter. Any thoughts?
  
   By the way the this is the load() implemenation, I have set the Model
   Object's phoneList with a list of values fetched via the Service-DAO.
 I
   have used this with other entities without association and it works
  but
  I
   guess is a different scenario(not associations)
  
   Model = new LoadableDetachableModelObject() {
  @Override
  protected Object load() {
  return containerForm.getModelObject().getPhoneList();
  }
  };
   }
  
   If someone has any thoughts would appreiciate hearing from you.
  
  
   Cheers
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 




-- 
regards,
Vineet Semwal


Re: Logout (Session destroy) on the last (stateful) page?

2010-12-02 Thread Matthias Keller

Hi Ernesto

No that's not possible because the ConfirmationPage is *stateful* and 
contains lots of information from the session/page state, so it must be 
allowed to display the pre-rendered page once but after that request, 
the session must be invalidated.


Thanks

Matt

On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote:

Matt,

Can't you just do some kind of trick so that your ConfirmationPage is
served as the home page? So that you invalidate the session but at
getHomePage() you temporarily return your ConfirmationPage?

Regards,

Ernesto

On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller
matthias.kel...@ergon.ch  wrote:

Hi Randy

Yes it appears to have something to do with that. Our app uses the
REDIRECT_BUFFER by default (we never actively configured this though) which
appears to be a sensible option for normal operation. I'm not very familiar
with the render strategies but you appear to be right: The page is actually
rendered at the end of the previous request where the session is invalidated
too. Then a redirect happens to the pre-rendered page which fails because
the Session is already gone...

Is there any hook that will be called at the end of the second request
serving the pre-rendered content?
I found a workaround for the moment: In the previous page, I explicitly set
setRedirect(false); but this has the consequence that if the user hits
reload on the confirmation page, he will first be asked about resending the
POST parameters...

Anything we could do to invalidate the session at the end of the serving of
the prerendered page?

Thanks a lot

Matt

On 2010-12-01 20:44, Randy S. wrote:

Does the redirect to the home page happen because of Wicket's default
render
strategy (REDIRECT_TO_BUFFER) that causes two requests?  You invalidate
session on the first which redirects to the buffered response. When the
second request comes in expecting to get the already-rendered response,
you
get a new session.


On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi
martin.maku...@koodaripalvelut.comwrote:


Hi!

I am curious too. For this reason we had to build our logoutpage so
that it invalidtes session logically but not in httpsession sense.

Only clicking something from login page will do that.

But it's a hack, I would like to know what's the proper way ;)

**
Martin



2010/12/1 Matthias Kellermatthias.kel...@ergon.ch:

Hi

I've got the following problem:
After a user completes a wizard, he sees a last confirmation page

containing

some data, thus it must be a stateful page called by the following code

from

the wizard:

setResponsePage(new ConfirmationPage(myBean));

This ConfirmationPage must only be displayed once, thus if the user does

a

refresh it must not be available anymore.
I expected that I would be able to call  session.invalidate() from

somewhere

within the ConfirmationPage's onAfterRender or onDetach methods.
Unfortunately, whenever I do this, the user is automatically redirected

to

the home page without a trace in the logs
Any idea how to do that?

Thanks

Matt







smime.p7s
Description: S/MIME Cryptographic Signature


Re: Logout (Session destroy) on the last (stateful) page?

2010-12-02 Thread Ernesto Reinaldo Barreiro
Hi Matt,

I see. Then maybe adding some onDomReady javascript to
ConfirmationPage that simply goes back to the server and invalidates
the session? Probably this can't use wicket AJAX machinery: because
that will probably will also trigger a redirect.

Regards,

Ernesto

On Thu, Dec 2, 2010 at 10:46 AM, Matthias Keller
matthias.kel...@ergon.ch wrote:
 Hi Ernesto

 No that's not possible because the ConfirmationPage is *stateful* and
 contains lots of information from the session/page state, so it must be
 allowed to display the pre-rendered page once but after that request, the
 session must be invalidated.

 Thanks

 Matt

 On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote:

 Matt,

 Can't you just do some kind of trick so that your ConfirmationPage is
 served as the home page? So that you invalidate the session but at
 getHomePage() you temporarily return your ConfirmationPage?

 Regards,

 Ernesto

 On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller
 matthias.kel...@ergon.ch  wrote:

 Hi Randy

 Yes it appears to have something to do with that. Our app uses the
 REDIRECT_BUFFER by default (we never actively configured this though)
 which
 appears to be a sensible option for normal operation. I'm not very
 familiar
 with the render strategies but you appear to be right: The page is
 actually
 rendered at the end of the previous request where the session is
 invalidated
 too. Then a redirect happens to the pre-rendered page which fails because
 the Session is already gone...

 Is there any hook that will be called at the end of the second request
 serving the pre-rendered content?
 I found a workaround for the moment: In the previous page, I explicitly
 set
 setRedirect(false); but this has the consequence that if the user hits
 reload on the confirmation page, he will first be asked about resending
 the
 POST parameters...

 Anything we could do to invalidate the session at the end of the serving
 of
 the prerendered page?

 Thanks a lot

 Matt

 On 2010-12-01 20:44, Randy S. wrote:

 Does the redirect to the home page happen because of Wicket's default
 render
 strategy (REDIRECT_TO_BUFFER) that causes two requests?  You invalidate
 session on the first which redirects to the buffered response. When the
 second request comes in expecting to get the already-rendered response,
 you
 get a new session.


 On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com    wrote:

 Hi!

 I am curious too. For this reason we had to build our logoutpage so
 that it invalidtes session logically but not in httpsession sense.

 Only clicking something from login page will do that.

 But it's a hack, I would like to know what's the proper way ;)

 **
 Martin



 2010/12/1 Matthias Kellermatthias.kel...@ergon.ch:

 Hi

 I've got the following problem:
 After a user completes a wizard, he sees a last confirmation page

 containing

 some data, thus it must be a stateful page called by the following
 code

 from

 the wizard:

 setResponsePage(new ConfirmationPage(myBean));

 This ConfirmationPage must only be displayed once, thus if the user
 does

 a

 refresh it must not be available anymore.
 I expected that I would be able to call  session.invalidate() from

 somewhere

 within the ConfirmationPage's onAfterRender or onDetach methods.
 Unfortunately, whenever I do this, the user is automatically
 redirected

 to

 the home page without a trace in the logs
 Any idea how to do that?

 Thanks

 Matt






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



Re: Logout (Session destroy) on the last (stateful) page?

2010-12-02 Thread Ernesto Reinaldo Barreiro
e.g. you could:

1-Place and AbstractDefaultAjaxBehavior on you page (e.g. to some div
on your page). Use urlFor to generate the URL to this behavior.  On

respond(AjaxRequestTarget target) {
Invalidate your session.
}

2-Make your page implement IHeaderContributor and on

public void renderHead(IHeaderResponse response)  {
response.renderOnDomReadyJavascript(here use jquery AJAX to 
call
URL of step 1);
}

Ernesto

On Thu, Dec 2, 2010 at 10:54 AM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
 Hi Matt,

 I see. Then maybe adding some onDomReady javascript to
 ConfirmationPage that simply goes back to the server and invalidates
 the session? Probably this can't use wicket AJAX machinery: because
 that will probably will also trigger a redirect.

 Regards,

 Ernesto

 On Thu, Dec 2, 2010 at 10:46 AM, Matthias Keller
 matthias.kel...@ergon.ch wrote:
 Hi Ernesto

 No that's not possible because the ConfirmationPage is *stateful* and
 contains lots of information from the session/page state, so it must be
 allowed to display the pre-rendered page once but after that request, the
 session must be invalidated.

 Thanks

 Matt

 On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote:

 Matt,

 Can't you just do some kind of trick so that your ConfirmationPage is
 served as the home page? So that you invalidate the session but at
 getHomePage() you temporarily return your ConfirmationPage?

 Regards,

 Ernesto

 On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller
 matthias.kel...@ergon.ch  wrote:

 Hi Randy

 Yes it appears to have something to do with that. Our app uses the
 REDIRECT_BUFFER by default (we never actively configured this though)
 which
 appears to be a sensible option for normal operation. I'm not very
 familiar
 with the render strategies but you appear to be right: The page is
 actually
 rendered at the end of the previous request where the session is
 invalidated
 too. Then a redirect happens to the pre-rendered page which fails because
 the Session is already gone...

 Is there any hook that will be called at the end of the second request
 serving the pre-rendered content?
 I found a workaround for the moment: In the previous page, I explicitly
 set
 setRedirect(false); but this has the consequence that if the user hits
 reload on the confirmation page, he will first be asked about resending
 the
 POST parameters...

 Anything we could do to invalidate the session at the end of the serving
 of
 the prerendered page?

 Thanks a lot

 Matt

 On 2010-12-01 20:44, Randy S. wrote:

 Does the redirect to the home page happen because of Wicket's default
 render
 strategy (REDIRECT_TO_BUFFER) that causes two requests?  You invalidate
 session on the first which redirects to the buffered response. When the
 second request comes in expecting to get the already-rendered response,
 you
 get a new session.


 On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com    wrote:

 Hi!

 I am curious too. For this reason we had to build our logoutpage so
 that it invalidtes session logically but not in httpsession sense.

 Only clicking something from login page will do that.

 But it's a hack, I would like to know what's the proper way ;)

 **
 Martin



 2010/12/1 Matthias Kellermatthias.kel...@ergon.ch:

 Hi

 I've got the following problem:
 After a user completes a wizard, he sees a last confirmation page

 containing

 some data, thus it must be a stateful page called by the following
 code

 from

 the wizard:

 setResponsePage(new ConfirmationPage(myBean));

 This ConfirmationPage must only be displayed once, thus if the user
 does

 a

 refresh it must not be available anymore.
 I expected that I would be able to call  session.invalidate() from

 somewhere

 within the ConfirmationPage's onAfterRender or onDetach methods.
 Unfortunately, whenever I do this, the user is automatically
 redirected

 to

 the home page without a trace in the logs
 Any idea how to do that?

 Thanks

 Matt







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



Re: webapp shutdown listeners

2010-12-02 Thread Sebastian
we are working on an extension for wicket apps and want to make the 
usage as easy as possible for users. When in usage, the extension should 
be able to register itself to a webapp shutdown event transparently 
without requiring the user do modify their webapps onDestroy method or 
need to add a ServletContextListener. because this has the potential 
that the user forgets to add this potentially resulting in memory leaks 
on webapp restart.



On 02.12.2010 10:38, alex shubert wrote:

Why dont you add you very own listener to servlet container?







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



Re: nested form in FormComponentPanel validation issue

2010-12-02 Thread Joseph Pachod

On 11/26/2010 05:41 PM, Igor Vaynberg wrote:

quickstart, jira issue.

-igor


hi igor

I've created a quickstart for it (cf attachement)

however, it may be linked to self made DecoratedEdit/TextFieldEdit 
classes (cf attachement again).


As such, I'm not sure if it's a wicket bug or not, so I prefered not to 
create an issue for it. Let me know if I should.


Anyway, when you run the quick start, you will have a form. If you input 
something in its structured part, you'll need to do 2 submits on the 
ok for the structured part content to be taken in account (there's a 
display of the backing bean on each submit, so it's easy to spot).


thanks again

best
joseph


forminformcomponentpanel.tar.gz
Description: GNU Zip compressed data

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

Re: Feedback panel on modal window

2010-12-02 Thread Andrea Del Bene

Hi Tito,

how do you send form inside modal window? I guess you are sending it by 
AJAX. I've written a similar modal window few weeks ago. Be sure to add 
your feedback panel to thw AjaxRequestTarget object of submitting component.


Bye.

Hi, I have one model window with a panel atached.
I added a validator to one form in model window. But when I try to submit I
can't show errors.
Whatching the console I found it: WARN  - WebSession -
Component-targetted feedback message was left unrendered. This could be
because you are missing a FeedbackPanel on the page.
I have a feedback panel on page, however I would like to have another one on
modal window.
But now I'm not getting any kind of message.

Thanks
Tito

   



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



Display component feedback message once: safety net renders them always before

2010-12-02 Thread Joseph Pachod

Hi

I'm trying to apply the behaviors presented by Alastair Maw in his 
presentation Wicket Forms
with Flair (cf 
http://code.google.com/p/londonwicket/downloads/detail?name=LondonWicket-FormsWithFlair.pdfcan=2q= 
)


Basically, Alastair uses behavior to display feedback message specific 
to some components next to the component in question.


We use our components in form with feedback panel, for non component 
specific messages.


Overall, we would like these functionalities:
A - no message should be rendered twice
B - no message should be left unrendered (safety net)
C - component specific message should be rendered next to their component
D - when some messages were displayed next to their components, the 
feedback panel should display a message for it (like one of more input 
didn't validate, please check them)


In order to try to achieve that, I used the FeedbackMessage.isRendered() 
method in both the behaviors and the feedback panel IFeedbackMessageFilter.


However, it looks like the feedback panel is always the first to be 
rendered, whatever the components ordering. As such, it always get to 
render first the feedback messages.


I tried to use only behavior based feedback messages display, but looks 
like the behavior added on the top level elements also always get 
rendered first.


Next stuff coming in my mind is to keep track of all these behaviors to 
be able to ask each of these if they would render some message. Doing so 
in the safety net component would allow to avoid duplicates. However, 
this feels poor to do (list to give around or to access somehow in the 
background, maybe through some thread local container).


so, the big question: is there a nice and easy way to do that ? Anything 
better than this behavior tracking stuff is welcome ;)


best
--

Joseph Pachod
IT

THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T  + 49 761 3 85 59 506
F  + 49 761 3 85 59 550
E  joseph.pac...@thomas-daily.de
www.thomas-daily.de

Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947

Registrieren Sie sich unter https://www.thomas-daily.de/user/sign-in für die TD 
Morning News, eine kostenlose Auswahl aktueller Themen aus TD Premium, morgens 
ab 9:15 in Ihrer Mailbox.

Aktuelle Presseinformationen für die TD Morning News und TD Premium nimmt 
unsere Redaktion unter redakt...@thomas-daily.de entgegen.
Redaktionsschluss für die TD Morning News ist täglich um 8:45.

Register free of charge at https://www.thomas-daily.de/user/sign-in to have the 
TD Morning News, a selection of the latest topics from TD Premium, delivered to 
your mailbox from 9:15 every morning.

Our editorial department receives the latest press releases for the TD Morning 
News and TD Premium at redakt...@thomas-daily.de. The editorial deadline for 
the TD Morning News is 8.45am daily.


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



mount QueryStringUrlCodingStrategy issue when coming via Apache

2010-12-02 Thread Arjun Dhar

Hi,
 I'm getting a wierd issue.

Have this code: mount(new QueryStringUrlCodingStrategy(admin/login.html,
login.class));
So there is an Admin module for our Web App. All Login  Admin pages are
distinctly relative to admin/.

On tomcat this works fine, but when the request comes via Apache I get a
404.

I have also overridden public IResourceStream locate(final Class? clazz,
final String path) {} so that the Package based names are translated to a
folder location for HTML markups outside the classpath.

Any ideas?
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/mount-QueryStringUrlCodingStrategy-issue-when-coming-via-Apache-tp3069010p3069010.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: URLs using wicket wizard

2010-12-02 Thread bamse

Using HybridURLCodingStrategy did the trick, though I ran into some strange
behaviour using the browsers back-button. That may however be a result from
things I have done in my code.
Thanks for your help!
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/URLs-using-wicket-wizard-tp3066862p3069072.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: UrlRewrite rule and Wicket

2010-12-02 Thread Krzysztof Kowalczyk
Thank you Erik, the idea is nice, but it does not work ;)

I wanted to implement my own ~ Root Mounting Strategy just when I've
got your email. The idea with overriding getRequestPath sounds good, I
was afraid that I will need to implement my own RequestCycle with
custom logic replacing path.startWith(mountPath()) part.

Unfortunately your solution doesn't seem to play well with forms. When
using the RootWebRequestProcessor pages using HybridUrlCodingStrategy
work on first get request, but after button submit they are redirected
to ?wicket:... page and the state of the page is lost (all values of
fields, no validation errors). I have no idea why it works like that
and does it breaks other strategies.

ps. I had to add
configuration
  webAppConfig
contextPath//contextPath
  /webAppConfig
/configuration
to the POM to make the example run properly with jetty:run. The
default configuration mount the app on /wicket-rootmount-demo so most
of the links does not work.

Regards,
Krzysztof Kowalczyk

On Wed, Dec 1, 2010 at 1:59 PM, Erik van Oosten e.vanoos...@grons.nl wrote:
 You can try the approach from
 http://blog.jteam.nl/2010/02/24/wicket-root-mounts/

 This allows you to install a URL mounter that implements the following
 interface:

 interface RootMountedUrlCodingStrategy {
  boolean accepts(String rawPath);
 }

 Regards,
    Erik.


 Op 30-11-10 11:21, Krzysztof Kowalczyk wrote:

 Hi,

 We have existing urls in a form:

 /long,and,complex,title,id/new_opinion
 /long,and,complex,title,id/something

 or sometimes

 /long,title/id/new_opinion

 The links like /long,and,complex,title are managed by fast and
 scalable view, and are stateless. Now we are using Wicket in the same
 war. It is mounted to /cms.

 We are trying to replace forms, that are pure evil in the first
 technology with wicket based forms. But we need to keep the links
 untouched.

 So I created  UrlRewrite (http://www.tuckey.org/urlrewrite/) rules:

 urlrewrite use-query-string=true

 rule
        from^/(.*),(\d+)/new_opinion$/from
        to/cms/new_opinion/id/$2/url/$1/to
 /rule

 rule
        from^/(\?wicket.*)/from
        to/cms/$1/to
 /rule
 ...


 I have a wicket page - that is mounted on /new_opinion with enhanced
 HybridUrlCodingStrategy with:
 - redirectOnBookmarkableRequest = false

 First rule forwards the request to proper place. Wicket gets the
 correct requestUri and all the stuff. But the rule does not work if we
 have redirectOnBookmarkableRequest = true because Wicket constructs
 wrong urls in ServletWebRequest.getRelativePathPrefixToWicketHandler :

                if (!Strings.isEmpty(forwardUrl))
                {
                        // If this is an error page, this will be /mount or
 /?wicket:foo
                        relativeUrl = forwardUrl.substring(1);
                        relativeUrl =
 relativeUrl.substring(filterPath.length());
                }

 before this fragment Wicket has correct link, after this we get:
 g,and,complex,title,id/new_opinion, or errors (sometimes the link is
 shorter and I get array index out of bounds). If method does not throw
 exception it returns wrong number of ../ . Unfortunately
 redirectOnBookmarkableRequest = false does not solve the problem as
 the second rule catches Wicket that are redirected if they hit
 bookmarkable page. So this fragment need to be fixed in order to have
 working bookmarkable links with UrlRewrite.

 My temporary workaround is custom delegating WebRequest with small hack:

 public String getRelativePathPrefixToWicketHandler() {
        HttpServletRequest httpRequest = getHttpServletRequest();

        String forwardUrl =
 (String)httpRequest.getAttribute(javax.servlet.forward.servlet_path);
        final String filterPath =
 (String)httpRequest.getAttribute(WicketFilter.FILTER_PATH_ATTR);

        if (!Strings.isEmpty(forwardUrl))
        {
                int count = forwardUrl.split(/).length;

                String string = ;

                for (int i = 1; i  count; i++) {
                        string += ../;
                }

                return string + filterPath;
        }else {
                return
 wrappedReqest.getRelativePathPrefixToWicketHandler();
        }
 }

 I guess it will not work in all cases though...

 If there is a different way of doing url rewriting? If not, I consider
 it a bug in Wicket.

 Regards,
 Krzysztof Kowalczyk

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



 --
 Erik van Oosten
 http://www.day-to-day-stuff.blogspot.com/


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



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

Error Flushing Page because of java.io.FileNotFoundException

2010-12-02 Thread ft

Hello,

I have the following error (seemingly without further influence on the
application) in an application that runs on a tomcat 5.5.20 server. The disk
is not full or something.

When I look in the directory
work/Catalina/localhost/idp2009/IdpApplication-filestore it is empty...

Does anyone have an idea what might be the cause?


2010-12-02 16:27:08,430 ERROR
[org.apache.wicket.protocol.http.pagestore.DiskPageStore] Error flushing
page
java.lang.RuntimeException: java.io.FileNotFoundException:
/usr/local/apache-tomcat-5.5.20/work/Catalina/localhost/idp2009/IdpApplication-filestore/6432/1402/2C47AFD3CCE8EFB724777A0B780EC109/pm-null
(No such file or directory)
at
org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel(FileChannelPool.java:103)
at
org.apache.wicket.protocol.http.pagestore.FileChannelPool.getFileChannel(FileChannelPool.java:170)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage(DiskPageStore.java:241)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList(DiskPageStore.java:924)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run(DiskPageStore.java:996)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.FileNotFoundException:
/usr/local/apache-tomcat-5.5.20/work/Catalina/localhost/idp2009/IdpApplication-filestore/6
432/1402/2C47AFD3CCE8EFB724777A0B780EC109/pm-null (No such file or
directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:212)
at
org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel(FileChannelPool.java:98)
... 5 more
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Error-Flushing-Page-because-of-java-io-FileNotFoundException-tp3069562p3069562.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: Wicket-Hibernate Related LazyInitializationException

2010-12-02 Thread Dan Retzlaff
Yes, copying entities from the entity's association collection into another
collection will initialize the collection. If you're still getting an LIE,
there may be another association at play (a child of Phone?).

Note that I don't fully endorse the session reattachment aspect I posted.
Not only is weaving those Hibernate classes a little tricky and a lot of
hacky, it can cause undesirable amounts of entities to be added into the
session. James' suggestion of putting the collection behind a Wicket model
is more elegant. To this end, you might develop a utility which, given a
list of Persons, returns an IModelListPerson while storing only their
IDs in the session. In the following code, BasicDao.getIdentifier() and
BasicDao.get() simply map to Hibernate Session methods of the same name for
entity class T.

public static T IModelListT createListModelFromObjects(final
BasicDaoT dao, ListT objectList) {
final ListSerializable idList = new
ArrayListSerializable(objectList.size());
for (T object : objectList) {
idList.add(dao.getIdentifier(object));
}
 return new LoadableDetachableModelListT(objectList) {
@Override
protected ListT load() {
return loadList(dao, idList);
}
};
}

private static T ListT loadList(BasicDaoT dao, List? extends
Serializable idList) {
ListT loadList = new ArrayListT(idList.size());
for (Serializable id : idList) {
loadList.add(dao.get(id));
}
return loadList;
}


On Wed, Dec 1, 2010 at 10:26 PM, Nivedan Nadaraj shravann...@gmail.comwrote:

 Hi Dan,

 Thanks for your time most appreciated.

 1. Option 1 as you may agree, not always is a good thing to do so I would
 drop that.

 2. Option 2 - I have tried this in the following manner.

 As part of the look up for the Subjects via the DAO, I iterate through the
 list of Person.Phones collection and assign them into a CollectionPhones
 and set it into a value Object with has a List. This is because i cannot
 use
 the Set in the PageableListView. In doing so, I have forced the entities in
 the collection/proxy to be intialised isn't it? Looks like even with this
 it
 beats me.

 3. Option 3 - I have to read up more on how I can use this code/or
 something
 similar, we use Spring for DI.

 Further, each time I want to view a Person detail, I do a second look up
 when the user clicks from a list of Persons. I send issue a lookup into the
 DAO to get the Person's details afresh(the exact same method I used to list
 all Subjects in the first place), so this again would have refreshed the
 Phones collection on the Person in context.

 I will try to track it down I guess it has to do with session anyway. I
 also
 use the CPM to hold the Model for the whole page. Not a LDM.

 Thanks again for the time
 Cheers
 Niv


 On Thu, Dec 2, 2010 at 1:47 PM, Dan Retzlaff dretzl...@gmail.com wrote:

  Hi Nivedan,
 
  Even though the subsequent requests have a Session open, the entities
 with
  the uninitialized collections don't know about it. I'm sure if you track
 it
  down, you can explain the intermittent behavior by prior access to the
  collection when the original session is open.
 
  I'd say you can either (1) configure Hibernate to load the collections to
  load unlazily, (2) manually access the collections to force them to
  initialize in the specific cases you're encountering LIEs, or (3) employ
  some kind of AOP hack to reinject the new session right before the
  collection is accessed. They're all kind of ugly, and I've never heard of
  anyone else doing the last, but it's been working well for my team.
 
  For your reference, here is the AspectJ aspect I wrote. (We use Guice for
  dependency injection.)
 
  /**
   * Reattaches entities whose lazy collections are about to be initialized
   * p
   * Can we keep track of all lazy relationships that get initialized, and
   * uninitialize them at the end of the request? This would prevent
  referenced
   * entities from being serialized and replicated (unless separate
  references
   * were created to them).
   *
   * @author dan
   */
  @Aspect
  public class ReattachAspect {
  private static final Logger LOG = Logger.getLogger(ReattachAspect.class);
 
  private ProviderSession sessionProvider;
 
  @Before(call(public final void
  org.hibernate.proxy.AbstractLazyInitializer.initialize()) 
  target(initializer))
  public void reattachLazyInitializer(LazyInitializer initializer) {
  if (initializer.getSession() == null  sessionProvider != null) {
  if (LOG.isDebugEnabled()) {
  LOG.debug(reattaching session to lazy initializer for  +
  initializer.getEntityName());
  }
  Session session = sessionProvider.get();
  initializer.setSession((SessionImplementor) session);
  }
  }
 
  @Before(call(private void
  org.hibernate.collection.AbstractPersistentCollection
  + .throwLazyInitializationExceptionIfNotConnected()) 
  target(collection))
  public void reattachPersistentCollection(PersistentCollection collection)
 {
  SessionImplementor session = ((AbstractPersistentCollection)
  

Re: Problem on wicket-auth-role ve Spring-security integration

2010-12-02 Thread Fernando Wermus
try wicket-shiro!

On Thu, Dec 2, 2010 at 7:33 AM, alex shubert alex.shub...@gmail.com wrote:

 Let me guess may be the reason is that document is pretty outdated
 and provides no help if one looking for a how-to manual?
 It just looks pretty useless for whos already familiar with JAAS and
 SpringSecurity 'cos they will not found anything new and almost
 unhelpful for whom doesn't .
  :)

 For unknown reason the page looks locked so one can't propose new version.

 2010/12/2 Altuğ Bilgin Altıntaş alt...@gmail.com:
  why you don't just use Spring Security + Wicket ?
 
 
 
  2010/12/2 Taner Diler jtdde...@gmail.com
 
  Hi,
 
  I'm trying to integrate Wicket-auth-roles 1.4.9 and Spring Security
 3.0.4
  by
  following
 
 https://cwiki.apache.org/WICKET/spring-security-and-wicket-auth-roles.html
  .
 
  @AuthorizeAction and @AuthorizeInstantiation annotations are not
 working.
 
  The blog says 
 
  The only filter we need defined from Acegi is the
  HttpSessionContextIntegrationFilter. This filter will ensure that the
  SecurityContext is transported to and from the HttpSession onto the
 Thread
  context. All authorization is delegated to the wicket-auth-roles module
  which uses Annotations (@AuthorizeInstantiation).
 
  So how can I make configuration to provide this?
 
 



 --
 Best regards
 Alex

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




-- 
Fernando Wermus.

www.linkedin.com/in/fernandowermus


Re: Feedback panel on modal window

2010-12-02 Thread Tito
Good I fixed it. Thanks.
I added feedback panel to target. But I redined onError to do that, because
feedback is for errors in my case.

Thanks for the answer.

Bye
Tito

2010/12/2 Andrea Del Bene adelb...@ciseonweb.it

 Hi Tito,

 how do you send form inside modal window? I guess you are sending it by
 AJAX. I've written a similar modal window few weeks ago. Be sure to add your
 feedback panel to thw AjaxRequestTarget object of submitting component.

 Bye.

  Hi, I have one model window with a panel atached.
 I added a validator to one form in model window. But when I try to submit
 I
 can't show errors.
 Whatching the console I found it: WARN  - WebSession -
 Component-targetted feedback message was left unrendered. This could be
 because you are missing a FeedbackPanel on the page.
 I have a feedback panel on page, however I would like to have another one
 on
 modal window.
 But now I'm not getting any kind of message.

 Thanks
 Tito





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




Validate after Submit?

2010-12-02 Thread splitshade

Hi,

a general Question, and I am interested in how you would solve that?

I have a couple of form elements, that I want to submit.
I send some values to a backend and get an error code back - say an Enum
with errorcode and Message Error, User-ID already registered.

What I want to do now is, i want to assign this errormessage to the
inputtextfield for userid.

All Fields are hidden within Panels, so in the Page, I do not have access to
the TextFIeld itself, and I do not want to make it accessible through some
kind of getters or something.

is there a way to assign an Error to a component from outside (with a
FormVisitor or something)?
Just looking for some directions.

Thanks

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Validate-after-Submit-tp3070168p3070168.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: webapp shutdown listeners

2010-12-02 Thread Rodolfo Hansen
The correct way, I believe is using the IDestryer (and Iinitializer) along
with the correct wicket.properties in the classpath.

On Thu, Dec 2, 2010 at 3:16 AM, Sebastian nospam...@gmx.net wrote:

 we are working on an extension for wicket apps and want to make the usage
 as easy as possible for users. When in usage, the extension should be able
 to register itself to a webapp shutdown event transparently without
 requiring the user do modify their webapps onDestroy method or need to add a
 ServletContextListener. because this has the potential that the user forgets
 to add this potentially resulting in memory leaks on webapp restart.



 On 02.12.2010 10:38, alex shubert wrote:

 Why dont you add you very own listener to servlet container?






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




-- 
Rodolfo Hansen
CTO, KindleIT Software Development
Email: rhan...@kitsd.com
Mobile: +1 (809) 860-6669


Re: webapp shutdown listeners

2010-12-02 Thread Sebastian

That is cool!

From the docs at 
http://wicket.apache.org/apidocs/1.4/org/apache/wicket/IInitializer.html:


public interface IInitializer

Initializes something when application loads. ...

You don't have to pre-register package resources, as they can be 
initialized lazily.


Initializers can be configured by having a wicket.properties file in the 
class path root, with property 'initializer=${initializer class name}'. 
You can have one such properties per jar file, but the initializer that 
property denotes can delegate to other initializers of that library.


If an initializer also implements IDestroyer, the instance will be kept 
for destroying, so that it may clean up whatever it did when initializing.



On 02.12.2010 22:13, Rodolfo Hansen wrote:

The correct way, I believe is using the IDestryer (and Iinitializer) along
with the correct wicket.properties in the classpath.

On Thu, Dec 2, 2010 at 3:16 AM, Sebastiannospam...@gmx.net  wrote:


we are working on an extension for wicket apps and want to make the usage
as easy as possible for users. When in usage, the extension should be able
to register itself to a webapp shutdown event transparently without
requiring the user do modify their webapps onDestroy method or need to add a
ServletContextListener. because this has the potential that the user forgets
to add this potentially resulting in memory leaks on webapp restart.



On 02.12.2010 10:38, alex shubert wrote:


Why dont you add you very own listener to servlet container?







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









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



Re: Wicket-Hibernate Related LazyInitializationException

2010-12-02 Thread Nivedan Nadaraj
Vineet
I have not tried that. In this scenario, it will overwrite the phone's the
user may have added to a list on the UI and is yet to be persisted. If you
know what I mean.

1, Initial fetch of Subject along with his phones ( 5 items)
2. User adds a new phone number to the subject ( 5 + 1 (yet to be persisted)
3. If user navigates and the load() gets a list of Phones for the subject it
will overwrite the ones user has added.

Not sure if that made sense, thanks for your thoughts
Will ping back
Niv


On Thu, Dec 2, 2010 at 5:43 PM, vineet semwal vineetsemwal1...@gmail.comwrote:

 do you see the exception when you try this?
  @Override
   protected Object load() {
  // return containerForm.getModelObject().getPhoneList();
 return service.getRequiredObject(*).getPhoneList(); //or any thing like it
 ..

   }

 On Thu, Dec 2, 2010 at 12:12 PM, Nivedan Nadaraj shravann...@gmail.com
 wrote:

  Hi James
 
  Thanks for the time. I use the CPM for the whole use case. Mmm..is LDM
  mandatory for such a use case? Am open for thoughts just want the best
 way
  to implement it.
  Can you explain a bit further what your thought was please?
 
  Thank you
  Regards
 
 
 
 
  On Thu, Dec 2, 2010 at 2:13 PM, James Carman ja...@carmanconsulting.com
  wrote:
 
   Just make sure your form's model is a LDM too.
  
   On Thu, Dec 2, 2010 at 12:23 AM, Nivedan Nadaraj 
 shravann...@gmail.com
   wrote:
Hi All
   
I am guessing this is more of a Hibernate thing/issue but if some one
  has
encountered this and has a explanation that I can probably use from
 the
Wicket front would be great.
   
https://forum.hibernate.org/viewtopic.php?f=1t=1008473
   
   
I have a LazyIntializationException when i page through some items. I
  use
the PageableListView, the List item(s) are entities that are
 retrieved
   via
an association Person.phones which is  a Set type.
The funny thing is, the LIException is intermittent. I am also using
OpenSessionInViewFilter. Any thoughts?
   
By the way the this is the load() implemenation, I have set the Model
Object's phoneList with a list of values fetched via the
 Service-DAO.
  I
have used this with other entities without association and it works
   but
   I
guess is a different scenario(not associations)
   
Model = new LoadableDetachableModelObject() {
   @Override
   protected Object load() {
   return containerForm.getModelObject().getPhoneList();
   }
   };
}
   
If someone has any thoughts would appreiciate hearing from you.
   
   
Cheers
   
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
 



 --
 regards,
 Vineet Semwal



Re: Wicket-Hibernate Related LazyInitializationException

2010-12-02 Thread vineet semwal
afaik,if your collection is lazy ,you will be able to initialize it in the
same session ..
if you are trying to initialize it in a new/different session you will not
be able to initialize it..
what i did was making sure that you have a associate collection which is in
the same session..
i think better way would be persisting a user's new entry  and then showing
him the actual list which is a reflection of your database..


On Fri, Dec 3, 2010 at 12:50 PM, Nivedan Nadaraj shravann...@gmail.comwrote:

 Vineet
 I have not tried that. In this scenario, it will overwrite the phone's the
 user may have added to a list on the UI and is yet to be persisted. If you
 know what I mean.

 1, Initial fetch of Subject along with his phones ( 5 items)
 2. User adds a new phone number to the subject ( 5 + 1 (yet to be
 persisted)
 3. If user navigates and the load() gets a list of Phones for the subject
 it
 will overwrite the ones user has added.

 Not sure if that made sense, thanks for your thoughts
 Will ping back
 Niv


 On Thu, Dec 2, 2010 at 5:43 PM, vineet semwal vineetsemwal1...@gmail.com
 wrote:

  do you see the exception when you try this?
   @Override
protected Object load() {
   // return containerForm.getModelObject().getPhoneList();
  return service.getRequiredObject(*).getPhoneList(); //or any thing like
 it
  ..
 
}
 
  On Thu, Dec 2, 2010 at 12:12 PM, Nivedan Nadaraj shravann...@gmail.com
  wrote:
 
   Hi James
  
   Thanks for the time. I use the CPM for the whole use case. Mmm..is LDM
   mandatory for such a use case? Am open for thoughts just want the best
  way
   to implement it.
   Can you explain a bit further what your thought was please?
  
   Thank you
   Regards
  
  
  
  
   On Thu, Dec 2, 2010 at 2:13 PM, James Carman 
 ja...@carmanconsulting.com
   wrote:
  
Just make sure your form's model is a LDM too.
   
On Thu, Dec 2, 2010 at 12:23 AM, Nivedan Nadaraj 
  shravann...@gmail.com
wrote:
 Hi All

 I am guessing this is more of a Hibernate thing/issue but if some
 one
   has
 encountered this and has a explanation that I can probably use from
  the
 Wicket front would be great.

 https://forum.hibernate.org/viewtopic.php?f=1t=1008473


 I have a LazyIntializationException when i page through some items.
 I
   use
 the PageableListView, the List item(s) are entities that are
  retrieved
via
 an association Person.phones which is  a Set type.
 The funny thing is, the LIException is intermittent. I am also
 using
 OpenSessionInViewFilter. Any thoughts?

 By the way the this is the load() implemenation, I have set the
 Model
 Object's phoneList with a list of values fetched via the
  Service-DAO.
   I
 have used this with other entities without association and it works
but
I
 guess is a different scenario(not associations)

 Model = new LoadableDetachableModelObject() {
@Override
protected Object load() {
return
 containerForm.getModelObject().getPhoneList();
}
};
 }

 If someone has any thoughts would appreiciate hearing from you.


 Cheers

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




-- 
regards,
Vineet Semwal