date:20090915

Ahh, I misunderstood then, I though that every thing that were not in
compliance was commented out.

Looks really nice with the new simplified names.

2009/9/15 Jeremy Thomerson jer...@wickettraining.com:

 Nino,

  Thanks for taking a look at this.  This is only half the battle, though.
 Looking back earlier in this thread, you'll see that the actual problem was
 that jquery is not following the naming conventions in
 /wicketstuff-core/jquery-parent/jquery/pom.xml it uses an artifact ID of
 wicketstuff-jquery.  There are two problems with this.  One, we were
 removing all of the wicketstuff- names from the children modules, and
 leaving it only on the parent - wicketstuff-core.  The other is that it
 doesn't match the folder name (jquery) - which causes some minor issues
 with some of the maven plugins that (blindly) rely on the folder and
 artifact ID to be the same.

 So, in this case, the pom.xml should be changed so that artifact ID is
 jquery - to match the convention and the folder name.

 There may be others - I just don't know - haven't looked in a while.

 --
 Jeremy Thomerson
 http://www.wickettraining.com



 On Mon, Sep 14, 2009 at 4:10 AM, nino martinez wael 
 nino.martinez.w...@gmail.com wrote:

 Hmm seems the only one who are not compiling are ddcalendar.. The
 other two are syringe and shiro-security, until their dependencies
 become available..

 There seems to be something here :

 http://repository.apache.org/snapshots/org/apache/shiro/

 Tauren mentioned that he would correct the pom..? Or did he mean that
 it had to be on the common maven repository..?

 And as for syringe commons proxy 1.1 is still not out :(

 -Nino

 2009/9/11 nino martinez wael nino.martinez.w...@gmail.com:
  Let me see if I could do that in the coming weeks. However we could
  have a red zone for projects that are becoming outdated.. If of course
  there are any? Just to tell the authors that they are in danger of
  being removed - attic.
 
  2009/9/10 Jeremy Thomerson jer...@wickettraining.com:
  In the time it would take to generate the list, you could fix the
 problems.
  I wrote detailed instructions for adding projects to WS-core, so someone
  should be able to take those and fix the projects that are not meeting
 those
  standards.
 
  You want to do it?
 
  --
  Jeremy Thomerson
  http://www.wickettraining.com
 
 
 
  On Thu, Sep 10, 2009 at 1:11 PM, nino martinez wael 
  nino.martinez.w...@gmail.com wrote:
 
  Hi Jeremy
 
  Should we have a list of offendending project?
 
  2009/9/6 Jeremy Thomerson jer...@wickettraining.com:
   First, jquery was built.  They don't follow the naming conventions
 like
  they
   should, so you have to look into the pom to realize that it's
 actually
   wicketstuff-jquery [1].
  
   Second, regarding merged resources - there's a link on the wiki [2]
 that
   explains how.  Please make sure to follow all conventions and run
 mvn
  clean
   install as well as mvn site:site on all of wicketstuff-core when
 you
  are
   done.  If you can't build everything or you can't generate sites,
 please
   don't commit.  I just comment out projects that can't easily be fixed
 and
   built when building releases.
  
   [1]
  
 
 http://wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-jquery/1.4.1/
   [2]
  
 
 http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Core+-+Migration+Guide
  
   Best regards,
  
   --
   Jeremy Thomerson
   http://www.wickettraining.com
  
  
  
   On Sun, Sep 6, 2009 at 11:22 AM, Jörn Zaefferer 
   joern.zaeffe...@googlemail.com wrote:
  
   So jquery-parent was build, which just references jquery and
   jquery-examples - neither of which were build. Whats the point of
   that?
  
   Also, how can we get wicketstuff-merged-resources included in the
 next
   release?
  
   Jörn
  
   On Mon, Aug 31, 2009 at 10:20 PM, Jeremy
   Thomersonjer...@wickettraining.com wrote:
I have the credentials and think that I will definitely be trying
 this
  on
the next release :)
   
--
Jeremy Thomerson
http://www.wickettraining.com
   
   
   
On Mon, Aug 31, 2009 at 3:16 PM, Martijn Dashorst 
martijn.dasho...@gmail.com wrote:
   
Perhaps it's more beneficial to do the actual release local on
 the
machine? I'm sure Johan can provide you with the credentials to
 do
  so.
   
Martijn
   
On Mon, Aug 31, 2009 at 9:27 PM, Jeremy
Thomersonjer...@wickettraining.com wrote:
 It's mostly uploading and then merging the POMs on the remote
  server.
 The
 build isn't actually that bad (maybe 15 or 20 minutes for the
  release
 procedure, including tagging, etc).

 --
 Jeremy Thomerson
 http://www.wickettraining.com



 On Mon, Aug 31, 2009 at 2:14 PM, Nicolas Melendez 
nmelen...@getsense.com.ar
 wrote:

 very slow build :)

 On Mon, Aug 31, 2009 at 9:07 PM, Jeremy
 Thomersonjer...@wickettraining.com wrote:
  Wicket Stuff Core 1.4.1 is

HttpSessionStore instead of the default SecondLevelCacheSessionStore

2009-09-15 Thread Eyal Golan

Hi,
I read this post
http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
and he suggested to use HttpSessionStore instead of the second cache...

I looked into the javadoc and the code itself and understood the
differences.

However, can anyone explain in a bit more detail the implications /
differences of using the Http instead of the SecondLayer?
The reason I'm asking this, is because, if it's better use, then I want to
convince my team that we change the implementation of our application to use
Http store.


Thanks very much.

Eyal Golan
egola...@gmail.com

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74

P  Save a tree. Please don't print this e-mail unless it's really necessary

Re: HttpSessionStore instead of the default SecondLevelCacheSessionStore

2009-09-15 Thread Matej Knopp

There really is no good reason to use http session store instead of
secondlevelcachesessionstore unless you are experiencing performance
problems. HttpSessionStore uses more memory and keeps much shorter
history so your users will be experiencing page expiration much more
often.

-Matej

On Tue, Sep 15, 2009 at 10:54 AM, Eyal Golan egola...@gmail.com wrote:
 Hi,
 I read this post
 http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
 and he suggested to use HttpSessionStore instead of the second cache...

 I looked into the javadoc and the code itself and understood the
 differences.

 However, can anyone explain in a bit more detail the implications /
 differences of using the Http instead of the SecondLayer?
 The reason I'm asking this, is because, if it's better use, then I want to
 convince my team that we change the implementation of our application to use
 Http store.


 Thanks very much.

 Eyal Golan
 egola...@gmail.com

 Visit: http://jvdrums.sourceforge.net/
 LinkedIn: http://www.linkedin.com/in/egolan74

 P  Save a tree. Please don't print this e-mail unless it's really necessary


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

Re: HttpSessionStore instead of the default SecondLevelCacheSessionStore

2009-09-15 Thread Johan Compagner

And that back and forward buttons in the browser dont really work well in
the HttpSessionStore

But i cant believe that the overhead he is reporting is really the
overhead..

It could be an Antivirus checker or other stuff like that.
Besides that if that would be a problem just get an SSD and place that into
your server where you point the DiskStore to
Then you will really not see any difference

johan


On Tue, Sep 15, 2009 at 11:07, Matej Knopp matej.kn...@gmail.com wrote:

 There really is no good reason to use http session store instead of
 secondlevelcachesessionstore unless you are experiencing performance
 problems. HttpSessionStore uses more memory and keeps much shorter
 history so your users will be experiencing page expiration much more
 often.

 -Matej

 On Tue, Sep 15, 2009 at 10:54 AM, Eyal Golan egola...@gmail.com wrote:
  Hi,
  I read this post
 
 http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
  and he suggested to use HttpSessionStore instead of the second cache...
 
  I looked into the javadoc and the code itself and understood the
  differences.
 
  However, can anyone explain in a bit more detail the implications /
  differences of using the Http instead of the SecondLayer?
  The reason I'm asking this, is because, if it's better use, then I want
 to
  convince my team that we change the implementation of our application to
 use
  Http store.
 
 
  Thanks very much.
 
  Eyal Golan
  egola...@gmail.com
 
  Visit: http://jvdrums.sourceforge.net/
  LinkedIn: http://www.linkedin.com/in/egolan74
 
  P  Save a tree. Please don't print this e-mail unless it's really
 necessary
 

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

Re: HttpSessionStore instead of the default SecondLevelCacheSessionStore

2009-09-15 Thread Matej Knopp

Well,

there are two kinds of overhead with SecondLevelCacheSessionStore.
Object serialization and writing to disk. I can imagine antivirus
interfering with the writing.

-Matej

On Tue, Sep 15, 2009 at 11:25 AM, Johan Compagner jcompag...@gmail.com wrote:
 And that back and forward buttons in the browser dont really work well in
 the HttpSessionStore

 But i cant believe that the overhead he is reporting is really the
 overhead..

 It could be an Antivirus checker or other stuff like that.
 Besides that if that would be a problem just get an SSD and place that into
 your server where you point the DiskStore to
 Then you will really not see any difference

 johan


 On Tue, Sep 15, 2009 at 11:07, Matej Knopp matej.kn...@gmail.com wrote:

 There really is no good reason to use http session store instead of
 secondlevelcachesessionstore unless you are experiencing performance
 problems. HttpSessionStore uses more memory and keeps much shorter
 history so your users will be experiencing page expiration much more
 often.

 -Matej

 On Tue, Sep 15, 2009 at 10:54 AM, Eyal Golan egola...@gmail.com wrote:
  Hi,
  I read this post
 
 http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
  and he suggested to use HttpSessionStore instead of the second cache...
 
  I looked into the javadoc and the code itself and understood the
  differences.
 
  However, can anyone explain in a bit more detail the implications /
  differences of using the Http instead of the SecondLayer?
  The reason I'm asking this, is because, if it's better use, then I want
 to
  convince my team that we change the implementation of our application to
 use
  Http store.
 
 
  Thanks very much.
 
  Eyal Golan
  egola...@gmail.com
 
  Visit: http://jvdrums.sourceforge.net/
  LinkedIn: http://www.linkedin.com/in/egolan74
 
  P  Save a tree. Please don't print this e-mail unless it's really
 necessary
 

 -
 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: HttpSessionStore instead of the default SecondLevelCacheSessionStore

2009-09-15 Thread Peter Thomas

On Tue, Sep 15, 2009 at 3:03 PM, Matej Knopp matej.kn...@gmail.com wrote:

 Well,

 there are two kinds of overhead with SecondLevelCacheSessionStore.
 Object serialization and writing to disk. I can imagine antivirus
 interfering with the writing.


I did mention in comment #2 under the blog post the point about Windows /
AntiVirus possibly having something to do with it.  IMO the difference in
performance is negligible and yes, may not even exist on *nix (needs
confirmation) - and as Matej said, the benefits are reduced page expiration
situations etc.

When posting the blog entry, my intention was not to recommend using the
HttpSession store.  Just that the performance test does not simulate the
back-button at all and Tapestry does not have anything similar to the
DiskStore etc.

I do want to report a couple of settings that seemed to make a difference:

   getMarkupSettings().setCompressWhitespace(true);

This almost cut page sizes in half for large HTML pages (having lots of
repeater indenting etc), and improved performance.

Also:

@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new UrlCompressingWebRequestProcessor();
}

This setting can help reduce the size of HTML in cases where you have a
large-sized repeater containing hyperlinks.

- Peter.

P.S: DZone link ;)
http://www.dzone.com/links/rss/wicket_beats_grails_jsfseam_and_tapestry_in_shoot.html



 -Matej

 On Tue, Sep 15, 2009 at 11:25 AM, Johan Compagner jcompag...@gmail.com
 wrote:
  And that back and forward buttons in the browser dont really work well in
  the HttpSessionStore
 
  But i cant believe that the overhead he is reporting is really the
  overhead..
 
  It could be an Antivirus checker or other stuff like that.
  Besides that if that would be a problem just get an SSD and place that
 into
  your server where you point the DiskStore to
  Then you will really not see any difference
 
  johan
 
 
  On Tue, Sep 15, 2009 at 11:07, Matej Knopp matej.kn...@gmail.com
 wrote:
 
  There really is no good reason to use http session store instead of
  secondlevelcachesessionstore unless you are experiencing performance
  problems. HttpSessionStore uses more memory and keeps much shorter
  history so your users will be experiencing page expiration much more
  often.
 
  -Matej
 
  On Tue, Sep 15, 2009 at 10:54 AM, Eyal Golan egola...@gmail.com
 wrote:
   Hi,
   I read this post
  
 
 http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
   and he suggested to use HttpSessionStore instead of the second
 cache...
  
   I looked into the javadoc and the code itself and understood the
   differences.
  
   However, can anyone explain in a bit more detail the implications /
   differences of using the Http instead of the SecondLayer?
   The reason I'm asking this, is because, if it's better use, then I
 want
  to
   convince my team that we change the implementation of our application
 to
  use
   Http store.
  
  
   Thanks very much.
  
   Eyal Golan
   egola...@gmail.com
  
   Visit: http://jvdrums.sourceforge.net/
   LinkedIn: http://www.linkedin.com/in/egolan74
  
   P  Save a tree. Please don't print this e-mail unless it's really
  necessary
  
 
  -
  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: Ajax Redirect with Busy Indicator

2009-09-15 Thread Stijn Maller

I'm looking to make an improvement to the generic busy indicator. I believe
the showBusysign() script should also be triggered by the onchange method of
choice components (non ajax) with wantOnSelectionChangedNotifications set to
true. Any idea's how to tackle this?

Re: Wicket Stuff Core 1.4.1 Release[ing]

2009-09-15 Thread Jeremy Thomerson

You're still missing the point. Look at the following URL. See where it
says wicketstuff-jquery. This should be jquery. That's what caused the
confusion that started this thread. That's what should be fixed. I'm not
sure how many other projects do the same. Haven't had time to test.

https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent/jquery/pom.xml

--
Jeremy Thomerson
http://www.wickettraining.com

On Tue, Sep 15, 2009 at 2:15 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Ahh, I misunderstood then, I though that every thing that were not in
compliance was commented out.

Looks really nice with the new simplified names.

2009/9/15 Jeremy Thomerson jer...@wickettraining.com:

Nino,

Thanks for taking a look at this. This is only half the battle, though.
Looking back earlier in this thread, you'll see that the actual problem
was
that jquery is not following the naming conventions in
/wicketstuff-core/jquery-parent/jquery/pom.xml it uses an artifact ID of
wicketstuff-jquery. There are two problems with this. One, we were
removing all of the wicketstuff- names from the children modules, and
leaving it only on the parent - wicketstuff-core. The other is that it
doesn't match the folder name (jquery) - which causes some minor issues
with some of the maven plugins that (blindly) rely on the folder and
artifact ID to be the same.

So, in this case, the pom.xml should be changed so that artifact ID is
jquery - to match the convention and the folder name.

There may be others - I just don't know - haven't looked in a while.

--
Jeremy Thomerson
http://www.wickettraining.com

On Mon, Sep 14, 2009 at 4:10 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Hmm seems the only one who are not compiling are ddcalendar.. The
other two are syringe and shiro-security, until their dependencies
become available..

There seems to be something here :

http://repository.apache.org/snapshots/org/apache/shiro/

Tauren mentioned that he would correct the pom..? Or did he mean that
it had to be on the common maven repository..?

And as for syringe commons proxy 1.1 is still not out :(

-Nino

2009/9/11 nino martinez wael nino.martinez.w...@gmail.com:
Let me see if I could do that in the coming weeks. However we could
have a red zone for projects that are becoming outdated.. If of course
there are any? Just to tell the authors that they are in danger of
being removed - attic.

2009/9/10 Jeremy Thomerson jer...@wickettraining.com:
In the time it would take to generate the list, you could fix the
problems.
I wrote detailed instructions for adding projects to WS-core, so
someone
should be able to take those and fix the projects that are not
meeting
those
standards.

You want to do it?

--
Jeremy Thomerson
http://www.wickettraining.com

On Thu, Sep 10, 2009 at 1:11 PM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Hi Jeremy

Should we have a list of offendending project?

2009/9/6 Jeremy Thomerson jer...@wickettraining.com:
First, jquery was built. They don't follow the naming conventions
like
they
should, so you have to look into the pom to realize that it's
actually
wicketstuff-jquery [1].

Second, regarding merged resources - there's a link on the wiki
[2]
that
explains how. Please make sure to follow all conventions and run
mvn
clean
install as well as mvn site:site on all of wicketstuff-core
when
you
are
done. If you can't build everything or you can't generate sites,
please
don't commit. I just comment out projects that can't easily be
fixed
and
built when building releases.

[1]

http://wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-jquery/1.4.1/
[2]

http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Core+-+Migration+Guide

Best regards,

--
Jeremy Thomerson
http://www.wickettraining.com

On Sun, Sep 6, 2009 at 11:22 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:

So jquery-parent was build, which just references jquery and
jquery-examples - neither of which were build. Whats the point of
that?

Also, how can we get wicketstuff-merged-resources included in the
next
release?

Jörn

On Mon, Aug 31, 2009 at 10:20 PM, Jeremy
Thomersonjer...@wickettraining.com wrote:
I have the credentials and think that I will definitely be
trying
this
on
the next release :)

--
Jeremy Thomerson
http://www.wickettraining.com

On Mon, Aug 31, 2009 at 3:16 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:

Perhaps it's more beneficial to do the actual release local on
the
machine? I'm sure Johan

Selectively ignoring required fields

Hello,

I'm currently working on a search interface, where the required-ness
of some fields depends on the value of some other.  In particular, the
form looks something like

(+) search by X
a: [_]
b: [_]

() search by Y
...

() search by Z
...

So the radio button selects a group of fields, in which any number may
be required.  Each group of options is its own panel, and basically
independent.  Is it possible for me to ignore protests from the fields
in sections Y and Z, after reading the input from the radio button?
Ideally I'd like to record the values from every field, and keep it
around as raw input, but I don't want to know if it is missing or
fails to convert/validate.

Thanks for any help.

-- 
Phil Housley

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

Re: Selectively ignoring required fields

You can override isRequired for any component.

**
Martin

2009/9/15 Phil Housley undeconstruc...@gmail.com:
 Hello,

 I'm currently working on a search interface, where the required-ness
 of some fields depends on the value of some other.  In particular, the
 form looks something like

 (+) search by X
 a: [_]
 b: [_]

 () search by Y
 ...

 () search by Z
 ...

 So the radio button selects a group of fields, in which any number may
 be required.  Each group of options is its own panel, and basically
 independent.  Is it possible for me to ignore protests from the fields
 in sections Y and Z, after reading the input from the radio button?
 Ideally I'd like to record the values from every field, and keep it
 around as raw input, but I don't want to know if it is missing or
 fails to convert/validate.

 Thanks for any help.

 --
 Phil Housley

 -
 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

FYI: wicket multipart post pageparameters

Hi!

If someone is looking for a quick way to handle multipart posts using
pageparameters, the following is sufficient:

...
  public PostOrGetPage(PageParameters pageParameters) {
if (pageParameters.size() = 0) {
  final WebRequest multipartWebRequest =
((WebRequest)getRequest()).newMultipartWebRequest(getApplication().getApplicationSettings().getDefaultMaximumUploadSize());
  getRequestCycle().setRequest(multipartWebRequest);
  pageParameters = new
PageParameters(multipartWebRequest.getParameterMap());
}

... operate on pageParameters normally
}

It seems to have been a somewhat hot topic once:
* 
http://www.nabble.com/Retrieving-Post-Parameters-with-PageParameters-tf4697756.html#a13428705
* http://www.mail-archive.com/wicket-u...@lists.sourceforge.net/msg12583.html

**
Martin

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

Re: Selectively ignoring required fields

2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:
 You can override isRequired for any component.

 **
 Martin


Thanks, but I really don't want to have to make the individual fields
context aware unless I have to.  We have quite a few custom form
controls, which are used both in searching and various other places,
so it would be a lot of work to make them all respond to this
particular use.  A way to just prevent the required check/validation
from the top would fit the bill better.

 2009/9/15 Phil Housley undeconstruc...@gmail.com:
 Hello,

 I'm currently working on a search interface, where the required-ness
 of some fields depends on the value of some other.  In particular, the
 form looks something like

 (+) search by X
 a: [_]
 b: [_]

 () search by Y
 ...

 () search by Z
 ...

 So the radio button selects a group of fields, in which any number may
 be required.  Each group of options is its own panel, and basically
 independent.  Is it possible for me to ignore protests from the fields
 in sections Y and Z, after reading the input from the radio button?
 Ideally I'd like to record the values from every field, and keep it
 around as raw input, but I don't want to know if it is missing or
 fails to convert/validate.

 Thanks for any help.

 --
 Phil Housley

 -
 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



-- 
Phil Housley

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

Re: Selectively ignoring required fields

2009-09-15 Thread Matthias Keller


Hi

You could also write your own FormValidator which does the 'required' 
validation on its own by checking whether the field's input string is 
empty/null.


Matt

Phil Housley wrote:

2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:
  

You can override isRequired for any component.

**
Martin




Thanks, but I really don't want to have to make the individual fields
context aware unless I have to.  We have quite a few custom form
controls, which are used both in searching and various other places,
so it would be a lot of work to make them all respond to this
particular use.  A way to just prevent the required check/validation
from the top would fit the bill better.

  

2009/9/15 Phil Housley undeconstruc...@gmail.com:


Hello,

I'm currently working on a search interface, where the required-ness
of some fields depends on the value of some other.  In particular, the
form looks something like

(+) search by X
a: [_]
b: [_]

() search by Y
...

() search by Z
...

So the radio button selects a group of fields, in which any number may
be required.  Each group of options is its own panel, and basically
independent.  Is it possible for me to ignore protests from the fields
in sections Y and Z, after reading the input from the radio button?
Ideally I'd like to record the values from every field, and keep it
around as raw input, but I don't want to know if it is missing or
fails to convert/validate.

Thanks for any help.

--
Phil Housley

-
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





  



--
matthias.kel...@ergon.ch  +41 44 268 83 98
Ergon Informatik AG, Kleinstrasse 15, CH-8008 Zürich
http://www.ergon.ch
__
e r g o nsmart people - smart software




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Selectively ignoring required fields

2009-09-15 Thread Bas Gooren


Phil,

The way we deal with this is by using an ajax behavior on radiobuttons, and 
update the required flag on dependant fields from there.


Another way (without ajax) could be to update the required flag on the form 
components on submit, prior to validation.
E.g. by overriding Form.process() (or Form.validate(), since this is related 
to validation).


E.g. something like

Form form = new Form( id, ... ) {
   protected void validate() {
   // Update required flags on fields
   // ...

   // Call regular validation
   super.validate();
   }
}

Regards,

Bas

- Original Message - 
From: Phil Housley undeconstruc...@gmail.com

To: users@wicket.apache.org
Sent: Tuesday, September 15, 2009 2:30 PM
Subject: Re: Selectively ignoring required fields


2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:

You can override isRequired for any component.

**
Martin



Thanks, but I really don't want to have to make the individual fields
context aware unless I have to.  We have quite a few custom form
controls, which are used both in searching and various other places,
so it would be a lot of work to make them all respond to this
particular use.  A way to just prevent the required check/validation
from the top would fit the bill better.


2009/9/15 Phil Housley undeconstruc...@gmail.com:

Hello,

I'm currently working on a search interface, where the required-ness
of some fields depends on the value of some other. In particular, the
form looks something like

(+) search by X
a: [_]
b: [_]

() search by Y
...

() search by Z
...

So the radio button selects a group of fields, in which any number may
be required. Each group of options is its own panel, and basically
independent. Is it possible for me to ignore protests from the fields
in sections Y and Z, after reading the input from the radio button?
Ideally I'd like to record the values from every field, and keep it
around as raw input, but I don't want to know if it is missing or
fails to convert/validate.

Thanks for any help.

--
Phil Housley

-
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




--
Phil Housley

-
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: Selectively ignoring required fields

It is easier just to make your own components, say

CentrallyControlledRequiredCheckBox extends CheckBox etc.

In this way you can put  your central code into
CentrallyControlledRequiredCheckBox and reuse that component.

There cannot be an easier way... how difficult is that anyways?

**
Martin

2009/9/15 Phil Housley undeconstruc...@gmail.com:
 2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:
 You can override isRequired for any component.

 **
 Martin


 Thanks, but I really don't want to have to make the individual fields
 context aware unless I have to.  We have quite a few custom form
 controls, which are used both in searching and various other places,
 so it would be a lot of work to make them all respond to this
 particular use.  A way to just prevent the required check/validation
 from the top would fit the bill better.

 2009/9/15 Phil Housley undeconstruc...@gmail.com:
 Hello,

 I'm currently working on a search interface, where the required-ness
 of some fields depends on the value of some other.  In particular, the
 form looks something like

 (+) search by X
 a: [_]
 b: [_]

 () search by Y
 ...

 () search by Z
 ...

 So the radio button selects a group of fields, in which any number may
 be required.  Each group of options is its own panel, and basically
 independent.  Is it possible for me to ignore protests from the fields
 in sections Y and Z, after reading the input from the radio button?
 Ideally I'd like to record the values from every field, and keep it
 around as raw input, but I don't want to know if it is missing or
 fails to convert/validate.

 Thanks for any help.

 --
 Phil Housley

 -
 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



 --
 Phil Housley

 -
 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: Wicketstuff really needs some updates

2009-09-15 Thread Johannes Schneider

Come on guys. Please help me. Since there is an invalid repository
definition no one out there will be able to use a project using
input-events...
I have the necessary patches sitting right here. I have created a Jira
entry and I am willing to commit them if anybody gives me commit access.

Please don't force me to release my own version. That would be just
duplicate work done.


Sincerly

Johannes

Johannes Schneider wrote:
 I have created some patches that help me a bit.
 Can be found here (found no better place).
 
 http://wicketstuff.org/jira/browse/WSMINIS-10
 
 Those are created using git. I hope the patch format is ok
 
 
 Sincerly,
 
 Johannes
 
 Johannes Schneider wrote:
 Well, who is the One?

 Igor Vaynberg wrote:
 or you can request commit access and eat your own donuts :)

 -igor

 On Fri, Sep 4, 2009 at 10:43 AM, Johannes
 Schneidermaili...@cedarsoft.com wrote:
 Hi,

 I really love the work that has been put into WicketStuff. The world is
 much better *with* WicketStuff.
 But unfortunately several files are outdated and many releases are missing.

 So at first I want to say thank you to everybody who has put work into
 that project. Then I want to motivate those with commit rights to update
 the projects and release some of the modules...
 I am offering some donuts ;-)


 Thanks,

 Johannes

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


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

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

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

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

Re: Selectively ignoring required fields

Several interesting ideas, but they all seem to involve more invasive
changes than I really want to make - either changing component classes
or changing values of components at process time, which would be hard
to undo (and maybe not possible, as some components already have logic
to say if they are required.)

From hunting through the code, what would be about perfect would be to
override org.apache.wicket.markup.html.form.Form#validateComponents(),
but unfortunately that is final.  Even if I were to copy some of the
code into my form class, there are some private methods of Form that I
would need to call.

Has anyone perhaps had a similar issue somewhere else?

Thanks again,

Phil.

2009/9/15 Bas Gooren b...@iswd.nl:
 Phil,

 The way we deal with this is by using an ajax behavior on radiobuttons, and
 update the required flag on dependant fields from there.

 Another way (without ajax) could be to update the required flag on the form
 components on submit, prior to validation.
 E.g. by overriding Form.process() (or Form.validate(), since this is related
 to validation).

 E.g. something like

 Form form = new Form( id, ... ) {
   protected void validate() {
       // Update required flags on fields
       // ...

       // Call regular validation
       super.validate();
   }
 }

 Regards,

 Bas

 - Original Message - From: Phil Housley
 undeconstruc...@gmail.com
 To: users@wicket.apache.org
 Sent: Tuesday, September 15, 2009 2:30 PM
 Subject: Re: Selectively ignoring required fields


 2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:

 You can override isRequired for any component.

 **
 Martin


 Thanks, but I really don't want to have to make the individual fields
 context aware unless I have to.  We have quite a few custom form
 controls, which are used both in searching and various other places,
 so it would be a lot of work to make them all respond to this
 particular use.  A way to just prevent the required check/validation
 from the top would fit the bill better.

 2009/9/15 Phil Housley undeconstruc...@gmail.com:

 Hello,

 I'm currently working on a search interface, where the required-ness
 of some fields depends on the value of some other. In particular, the
 form looks something like

 (+) search by X
 a: [_]
 b: [_]

 () search by Y
 ...

 () search by Z
 ...

 So the radio button selects a group of fields, in which any number may
 be required. Each group of options is its own panel, and basically
 independent. Is it possible for me to ignore protests from the fields
 in sections Y and Z, after reading the input from the radio button?
 Ideally I'd like to record the values from every field, and keep it
 around as raw input, but I don't want to know if it is missing or
 fails to convert/validate.

 Thanks for any help.

 --
 Phil Housley

 -
 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



 --
 Phil Housley

 -
 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





-- 
Phil Housley

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

Re: Selectively ignoring required fields

2009-09-15 Thread Bas Gooren

The fact of the matter is that you will need extra logic _somewhere_. It's a 
matter of personal preference where you put it (overriden components, ajax, 
override form methods, ...).


If what you're trying to accomplish is difficult given a certain set of 
tools, my experience is that it's good to rethink the problem.


On the one hand you want isolation (components can have logic to say if they 
are required), and on the other hand you want to break outside of this 
isolation (form needs to control required flag on components). Having this 
logic in two different places is error-prone (at least from my experience).
So why not have a single point in your code where you deal with the required 
flags of these components?


Bas

- Original Message - 
From: Phil Housley undeconstruc...@gmail.com

To: users@wicket.apache.org
Sent: Tuesday, September 15, 2009 3:37 PM
Subject: Re: Selectively ignoring required fields


Several interesting ideas, but they all seem to involve more invasive
changes than I really want to make - either changing component classes
or changing values of components at process time, which would be hard
to undo (and maybe not possible, as some components already have logic
to say if they are required.)


From hunting through the code, what would be about perfect would be to

override org.apache.wicket.markup.html.form.Form#validateComponents(),
but unfortunately that is final.  Even if I were to copy some of the
code into my form class, there are some private methods of Form that I
would need to call.

Has anyone perhaps had a similar issue somewhere else?

Thanks again,

Phil.

2009/9/15 Bas Gooren b...@iswd.nl:

Phil,

The way we deal with this is by using an ajax behavior on radiobuttons, 
and

update the required flag on dependant fields from there.

Another way (without ajax) could be to update the required flag on the 
form

components on submit, prior to validation.
E.g. by overriding Form.process() (or Form.validate(), since this is 
related

to validation).

E.g. something like

Form form = new Form( id, ... ) {
protected void validate() {
// Update required flags on fields
// ...

// Call regular validation
super.validate();
}
}

Regards,

Bas

- Original Message - From: Phil Housley
undeconstruc...@gmail.com
To: users@wicket.apache.org
Sent: Tuesday, September 15, 2009 2:30 PM
Subject: Re: Selectively ignoring required fields


2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:


You can override isRequired for any component.

**
Martin



Thanks, but I really don't want to have to make the individual fields
context aware unless I have to. We have quite a few custom form
controls, which are used both in searching and various other places,
so it would be a lot of work to make them all respond to this
particular use. A way to just prevent the required check/validation
from the top would fit the bill better.


2009/9/15 Phil Housley undeconstruc...@gmail.com:


Hello,

I'm currently working on a search interface, where the required-ness
of some fields depends on the value of some other. In particular, the
form looks something like

(+) search by X
a: [_]
b: [_]

() search by Y
...

() search by Z
...

So the radio button selects a group of fields, in which any number may
be required. Each group of options is its own panel, and basically
independent. Is it possible for me to ignore protests from the fields
in sections Y and Z, after reading the input from the radio button?
Ideally I'd like to record the values from every field, and keep it
around as raw input, but I don't want to know if it is missing or
fails to convert/validate.

Thanks for any help.

--
Phil Housley

-
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




--
Phil Housley

-
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






--
Phil Housley

-
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: Selectively ignoring required fields

Well.. all IFormSubmittingComponents have this method called
getDefaultFormProcessing. To me it sounds like that would at least do
what you need.

**
Martin

2009/9/15 Phil Housley undeconstruc...@gmail.com:
 Several interesting ideas, but they all seem to involve more invasive
 changes than I really want to make - either changing component classes
 or changing values of components at process time, which would be hard
 to undo (and maybe not possible, as some components already have logic
 to say if they are required.)

 From hunting through the code, what would be about perfect would be to
 override org.apache.wicket.markup.html.form.Form#validateComponents(),
 but unfortunately that is final.  Even if I were to copy some of the
 code into my form class, there are some private methods of Form that I
 would need to call.

 Has anyone perhaps had a similar issue somewhere else?

 Thanks again,

 Phil.

 2009/9/15 Bas Gooren b...@iswd.nl:
 Phil,

 The way we deal with this is by using an ajax behavior on radiobuttons, and
 update the required flag on dependant fields from there.

 Another way (without ajax) could be to update the required flag on the form
 components on submit, prior to validation.
 E.g. by overriding Form.process() (or Form.validate(), since this is related
 to validation).

 E.g. something like

 Form form = new Form( id, ... ) {
   protected void validate() {
       // Update required flags on fields
       // ...

       // Call regular validation
       super.validate();
   }
 }

 Regards,

 Bas

 - Original Message - From: Phil Housley
 undeconstruc...@gmail.com
 To: users@wicket.apache.org
 Sent: Tuesday, September 15, 2009 2:30 PM
 Subject: Re: Selectively ignoring required fields


 2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:

 You can override isRequired for any component.

 **
 Martin


 Thanks, but I really don't want to have to make the individual fields
 context aware unless I have to.  We have quite a few custom form
 controls, which are used both in searching and various other places,
 so it would be a lot of work to make them all respond to this
 particular use.  A way to just prevent the required check/validation
 from the top would fit the bill better.

 2009/9/15 Phil Housley undeconstruc...@gmail.com:

 Hello,

 I'm currently working on a search interface, where the required-ness
 of some fields depends on the value of some other. In particular, the
 form looks something like

 (+) search by X
 a: [_]
 b: [_]

 () search by Y
 ...

 () search by Z
 ...

 So the radio button selects a group of fields, in which any number may
 be required. Each group of options is its own panel, and basically
 independent. Is it possible for me to ignore protests from the fields
 in sections Y and Z, after reading the input from the radio button?
 Ideally I'd like to record the values from every field, and keep it
 around as raw input, but I don't want to know if it is missing or
 fails to convert/validate.

 Thanks for any help.

 --
 Phil Housley

 -
 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



 --
 Phil Housley

 -
 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





 --
 Phil Housley

 -
 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: HttpSessionStore instead of the default SecondLevelCacheSessionStore

2009-09-15 Thread Eyal Golan

Thank you all.
This thread was very informative and educated.
Peter, I will try the two suggestions you've mentioned.


Eyal Golan
egola...@gmail.com

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74

P  Save a tree. Please don't print this e-mail unless it's really necessary

Re: Selectively ignoring required fields

2009/9/15 Bas Gooren b...@iswd.nl:
 The fact of the matter is that you will need extra logic _somewhere_. It's a
 matter of personal preference where you put it (overriden components, ajax,
 override form methods, ...).

 If what you're trying to accomplish is difficult given a certain set of
 tools, my experience is that it's good to rethink the problem.

 On the one hand you want isolation (components can have logic to say if they
 are required), and on the other hand you want to break outside of this
 isolation (form needs to control required flag on components). Having this
 logic in two different places is error-prone (at least from my experience).
 So why not have a single point in your code where you deal with the required
 flags of these components?

 Bas

A good point, but I don't think it exactly applies in this case.  What
I really want is for each component to know whether it is required
within a very small context.  For example, a might have a criteria
panel (one of the sub-parts of the searcher) set out as follows:

[x] must be a foo called [_]

In which case, the sub panel will be in total charge of whether the
text field is required.

On the other hand, maybe that whole criteria panel is deselected, in
which case I want to be able to stop the whole thing from doing any
validation at all, so it won't even look at whether the check box is
checked.

What I am thinking currently is to sadly discard the built in
validation, and have each criteria panel report its errors manually
when asked to by the parent to pass on its generated set of criteria
(a map basically), which it has built out of its input.  I don't like
it at all, as it lets bad data get too far into the system, but I
think it will solve the immediate problem.

Phil.

 - Original Message - From: Phil Housley
 undeconstruc...@gmail.com
 To: users@wicket.apache.org
 Sent: Tuesday, September 15, 2009 3:37 PM
 Subject: Re: Selectively ignoring required fields


 Several interesting ideas, but they all seem to involve more invasive
 changes than I really want to make - either changing component classes
 or changing values of components at process time, which would be hard
 to undo (and maybe not possible, as some components already have logic
 to say if they are required.)

 From hunting through the code, what would be about perfect would be to
 override org.apache.wicket.markup.html.form.Form#validateComponents(),
 but unfortunately that is final.  Even if I were to copy some of the
 code into my form class, there are some private methods of Form that I
 would need to call.

 Has anyone perhaps had a similar issue somewhere else?

 Thanks again,

 Phil.

 2009/9/15 Bas Gooren b...@iswd.nl:

 Phil,

 The way we deal with this is by using an ajax behavior on radiobuttons,
 and
 update the required flag on dependant fields from there.

 Another way (without ajax) could be to update the required flag on the
 form
 components on submit, prior to validation.
 E.g. by overriding Form.process() (or Form.validate(), since this is
 related
 to validation).

 E.g. something like

 Form form = new Form( id, ... ) {
 protected void validate() {
 // Update required flags on fields
 // ...

 // Call regular validation
 super.validate();
 }
 }

 Regards,

 Bas

 - Original Message - From: Phil Housley
 undeconstruc...@gmail.com
 To: users@wicket.apache.org
 Sent: Tuesday, September 15, 2009 2:30 PM
 Subject: Re: Selectively ignoring required fields


 2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:

 You can override isRequired for any component.

 **
 Martin


 Thanks, but I really don't want to have to make the individual fields
 context aware unless I have to. We have quite a few custom form
 controls, which are used both in searching and various other places,
 so it would be a lot of work to make them all respond to this
 particular use. A way to just prevent the required check/validation
 from the top would fit the bill better.

 2009/9/15 Phil Housley undeconstruc...@gmail.com:

 Hello,

 I'm currently working on a search interface, where the required-ness
 of some fields depends on the value of some other. In particular, the
 form looks something like

 (+) search by X
 a: [_]
 b: [_]

 () search by Y
 ...

 () search by Z
 ...

 So the radio button selects a group of fields, in which any number may
 be required. Each group of options is its own panel, and basically
 independent. Is it possible for me to ignore protests from the fields
 in sections Y and Z, after reading the input from the radio button?
 Ideally I'd like to record the values from every field, and keep it
 around as raw input, but I don't want to know if it is missing or
 fails to convert/validate.

 Thanks for any help.

 --
 Phil Housley

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

Re: Selectively ignoring required fields

Maybe you should turn your enforcements to the framework hot spots.

 (+) search by X
 a: [_]
 b: [_]

 () search by Y
 ...

 () search by Z

Each group of options is its own panel

You can create an validation with those conditions, and add only on
necessary fiels.
Ex:

private class NotNullWhenGroupSelected implements IValidator{
private FormComponent formComponent;
private Model radioButtonModel;

public void validate(IValidatable validatable) {

if(radioButtonModel.getObject().isValidationMandatoryTo(formComponent){
   if(validatable.getValue() == null){
  validatable.error(new IValidationError());
   }
}
}
}


On Tue, Sep 15, 2009 at 10:37 AM, Phil Housley undeconstruc...@gmail.comwrote:

 Several interesting ideas, but they all seem to involve more invasive
 changes than I really want to make - either changing component classes
 or changing values of components at process time, which would be hard
 to undo (and maybe not possible, as some components already have logic
 to say if they are required.)

 From hunting through the code, what would be about perfect would be to
 override org.apache.wicket.markup.html.form.Form#validateComponents(),
 but unfortunately that is final.  Even if I were to copy some of the
 code into my form class, there are some private methods of Form that I
 would need to call.

 Has anyone perhaps had a similar issue somewhere else?

 Thanks again,

 Phil.

 2009/9/15 Bas Gooren b...@iswd.nl:
  Phil,
 
  The way we deal with this is by using an ajax behavior on radiobuttons,
 and
  update the required flag on dependant fields from there.
 
  Another way (without ajax) could be to update the required flag on the
 form
  components on submit, prior to validation.
  E.g. by overriding Form.process() (or Form.validate(), since this is
 related
  to validation).
 
  E.g. something like
 
  Form form = new Form( id, ... ) {
protected void validate() {
// Update required flags on fields
// ...
 
// Call regular validation
super.validate();
}
  }
 
  Regards,
 
  Bas
 
  - Original Message - From: Phil Housley
  undeconstruc...@gmail.com
  To: users@wicket.apache.org
  Sent: Tuesday, September 15, 2009 2:30 PM
  Subject: Re: Selectively ignoring required fields
 
 
  2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:
 
  You can override isRequired for any component.
 
  **
  Martin
 
 
  Thanks, but I really don't want to have to make the individual fields
  context aware unless I have to.  We have quite a few custom form
  controls, which are used both in searching and various other places,
  so it would be a lot of work to make them all respond to this
  particular use.  A way to just prevent the required check/validation
  from the top would fit the bill better.
 
  2009/9/15 Phil Housley undeconstruc...@gmail.com:
 
  Hello,
 
  I'm currently working on a search interface, where the required-ness
  of some fields depends on the value of some other. In particular, the
  form looks something like
 
  (+) search by X
  a: [_]
  b: [_]
 
  () search by Y
  ...
 
  () search by Z
  ...
 
  So the radio button selects a group of fields, in which any number may
  be required. Each group of options is its own panel, and basically
  independent. Is it possible for me to ignore protests from the fields
  in sections Y and Z, after reading the input from the radio button?
  Ideally I'd like to record the values from every field, and keep it
  around as raw input, but I don't want to know if it is missing or
  fails to convert/validate.
 
  Thanks for any help.
 
  --
  Phil Housley
 
  -
  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
 
 
 
  --
  Phil Housley
 
  -
  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
 
 



 --
 Phil Housley

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

Re: Selectively ignoring required fields

2009-09-15 Thread John Krasnay

On Tue, Sep 15, 2009 at 03:10:51PM +0100, Phil Housley wrote:
 
 A good point, but I don't think it exactly applies in this case.  What
 I really want is for each component to know whether it is required
 within a very small context.  For example, a might have a criteria
 panel (one of the sub-parts of the searcher) set out as follows:
 
 [x] must be a foo called [_]
 
 In which case, the sub panel will be in total charge of whether the
 text field is required.
 

I like to do this as described here:

http://cwiki.apache.org/WICKET/conditional-validation.html#ConditionalValidation-CheckBox

final CheckBox checkBox = new CheckBox(cb);
form.add(checkBox);

TextField foo = new TextField(foo) {
public boolean isRequired() {
return Strings.isTrue(checkBox.getValue());
}
}
form.add(foo);

 On the other hand, maybe that whole criteria panel is deselected, in
 which case I want to be able to stop the whole thing from doing any
 validation at all, so it won't even look at whether the check box is
 checked.
 

I assume here that the checkbox/radiobutton is implemented at a higher level in
the hierarchy and you don't want the internals of the panel to know about it.
Is that right?

In this case, I usually implement a method on my panel, then delegate the
isRequired method on my form components to this panel method:

public class MyPanel extends Panel {
public MyPanel(String panelId, ...) {
super(panelId);
new TextField(foo) {
public boolean isRequired() {
return MyPanel.this.isRequired();
}
}
}

/** Override to control whether my child components are required */
public boolean isRequired() {
return true;
}
}

You can then just repeat the pattern above, overriding MyPanel.isRequired() and
checking your checkbox/radiobutton there.

jk


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

Re: Extract method suggestion in MultipartServletWebRequest class

2009-09-15 Thread nico2884


I am using GAE + Wicket too, and I also had to copy/paste that class.
Any chances of making a refactor in a future release?

Thanks a lot! :)

Nico


Esteban Masoero-2 wrote:
 
 Hi there:
 
 In MultipartServletWebRequest constructor we have:
 ...
 (line 93) DiskFileItemFactory factory = new DiskFileItemFactory();
 ...
 which inhibits anyone from reusing MultipartServletWebRequest  with a 
 different factory. The only solution is generate a new class that is a 
 copy of this one, with that line changed.
 
 Would it be possible to extract this code in  a method like:
 
 /** Creates and returns a new file item factory. Subclasses can 
 override this method to use a different factory
  * @returns a recently created FileItemFactory object
  */
 protected FileItemFactory getNewFileItemFactory() {
 return new DiskFileItemFactory();
 }
 
 This way, we could just extend this class when there's a need to use a 
 different factory (as in GAE applications)
 
 Thanks in advance,
 
 Esteban
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Extract-method-suggestion-in-MultipartServletWebRequest-class-tp25390796p25456459.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Wicketstuff really needs some updates

2009-09-15 Thread Jeremy Thomerson

Have you asked for commit access?  I don't see your sf.net username on the
thread.  Nobody is stingy with wicketstuff commit access.  Just send your
username.

--
Jeremy Thomerson
http://www.wickettraining.com



On Tue, Sep 15, 2009 at 8:12 AM, Johannes Schneider
maili...@cedarsoft.comwrote:

 Come on guys. Please help me. Since there is an invalid repository
 definition no one out there will be able to use a project using
 input-events...
 I have the necessary patches sitting right here. I have created a Jira
 entry and I am willing to commit them if anybody gives me commit access.

 Please don't force me to release my own version. That would be just
 duplicate work done.


 Sincerly

 Johannes

 Johannes Schneider wrote:
  I have created some patches that help me a bit.
  Can be found here (found no better place).
 
  http://wicketstuff.org/jira/browse/WSMINIS-10
 
  Those are created using git. I hope the patch format is ok
 
 
  Sincerly,
 
  Johannes
 
  Johannes Schneider wrote:
  Well, who is the One?
 
  Igor Vaynberg wrote:
  or you can request commit access and eat your own donuts :)
 
  -igor
 
  On Fri, Sep 4, 2009 at 10:43 AM, Johannes
  Schneidermaili...@cedarsoft.com wrote:
  Hi,
 
  I really love the work that has been put into WicketStuff. The world
 is
  much better *with* WicketStuff.
  But unfortunately several files are outdated and many releases are
 missing.
 
  So at first I want to say thank you to everybody who has put work into
  that project. Then I want to motivate those with commit rights to
 update
  the projects and release some of the modules...
  I am offering some donuts ;-)
 
 
  Thanks,
 
  Johannes
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 

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

Re: Extract method suggestion in MultipartServletWebRequest class

2009-09-15 Thread Igor Vaynberg

No chance without a Jira issue.

-igor

On 9/15/09, nico2884 fernandonicolasmelen...@gmail.com wrote:

 I am using GAE + Wicket too, and I also had to copy/paste that class.
 Any chances of making a refactor in a future release?

 Thanks a lot! :)

 Nico


 Esteban Masoero-2 wrote:

 Hi there:

 In MultipartServletWebRequest constructor we have:
 ...
 (line 93) DiskFileItemFactory factory = new DiskFileItemFactory();
 ...
 which inhibits anyone from reusing MultipartServletWebRequest  with a
 different factory. The only solution is generate a new class that is a
 copy of this one, with that line changed.

 Would it be possible to extract this code in  a method like:

 /** Creates and returns a new file item factory. Subclasses can
 override this method to use a different factory
  * @returns a recently created FileItemFactory object
  */
 protected FileItemFactory getNewFileItemFactory() {
 return new DiskFileItemFactory();
 }

 This way, we could just extend this class when there's a need to use a
 different factory (as in GAE applications)

 Thanks in advance,

 Esteban

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




 --
 View this message in context:
 http://www.nabble.com/Extract-method-suggestion-in-MultipartServletWebRequest-class-tp25390796p25456459.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

Re: Wicketstuff really needs some updates

 Great Jeremy, I were about to ask the same, so Johannes please give
us the sf account and we will add you to the project. And thanks for
these updates.. :)

regards Nino

2009/9/15 Jeremy Thomerson jer...@wickettraining.com:
 Have you asked for commit access?  I don't see your sf.net username on the
 thread.  Nobody is stingy with wicketstuff commit access.  Just send your
 username.

 --
 Jeremy Thomerson
 http://www.wickettraining.com



 On Tue, Sep 15, 2009 at 8:12 AM, Johannes Schneider
 maili...@cedarsoft.comwrote:

 Come on guys. Please help me. Since there is an invalid repository
 definition no one out there will be able to use a project using
 input-events...
 I have the necessary patches sitting right here. I have created a Jira
 entry and I am willing to commit them if anybody gives me commit access.

 Please don't force me to release my own version. That would be just
 duplicate work done.


 Sincerly

 Johannes

 Johannes Schneider wrote:
  I have created some patches that help me a bit.
  Can be found here (found no better place).
 
  http://wicketstuff.org/jira/browse/WSMINIS-10
 
  Those are created using git. I hope the patch format is ok
 
 
  Sincerly,
 
  Johannes
 
  Johannes Schneider wrote:
  Well, who is the One?
 
  Igor Vaynberg wrote:
  or you can request commit access and eat your own donuts :)
 
  -igor
 
  On Fri, Sep 4, 2009 at 10:43 AM, Johannes
  Schneidermaili...@cedarsoft.com wrote:
  Hi,
 
  I really love the work that has been put into WicketStuff. The world
 is
  much better *with* WicketStuff.
  But unfortunately several files are outdated and many releases are
 missing.
 
  So at first I want to say thank you to everybody who has put work into
  that project. Then I want to motivate those with commit rights to
 update
  the projects and release some of the modules...
  I am offering some donuts ;-)
 
 
  Thanks,
 
  Johannes
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 

 -
 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 Stuff Core 1.4.1 Release[ing]

No I understood what you said.. I'll fix them..

2009/9/15 Jeremy Thomerson jer...@wickettraining.com:
You're still missing the point. Look at the following URL. See where it
says wicketstuff-jquery. This should be jquery. That's what caused the
confusion that started this thread. That's what should be fixed. I'm not
sure how many other projects do the same. Haven't had time to test.

https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent/jquery/pom.xml

--
Jeremy Thomerson
http://www.wickettraining.com

On Tue, Sep 15, 2009 at 2:15 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Ahh, I misunderstood then, I though that every thing that were not in
compliance was commented out.

Looks really nice with the new simplified names.

2009/9/15 Jeremy Thomerson jer...@wickettraining.com:

Nino,

So, in this case, the pom.xml should be changed so that artifact ID is
jquery - to match the convention and the folder name.

There may be others - I just don't know - haven't looked in a while.

--
Jeremy Thomerson
http://www.wickettraining.com

On Mon, Sep 14, 2009 at 4:10 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Hmm seems the only one who are not compiling are ddcalendar.. The
other two are syringe and shiro-security, until their dependencies
become available..

There seems to be something here :

http://repository.apache.org/snapshots/org/apache/shiro/

Tauren mentioned that he would correct the pom..? Or did he mean that
it had to be on the common maven repository..?

And as for syringe commons proxy 1.1 is still not out :(

-Nino

You want to do it?

--
Jeremy Thomerson
http://www.wickettraining.com

On Thu, Sep 10, 2009 at 1:11 PM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Hi Jeremy

Should we have a list of offendending project?

[1]

http://wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-jquery/1.4.1/
[2]

http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Core+-+Migration+Guide

Best regards,

--
Jeremy Thomerson
http://www.wickettraining.com

On Sun, Sep 6, 2009 at 11:22 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:

So jquery-parent was build, which just references jquery and
jquery-examples - neither of which were build. Whats the point of
that?

Also, how can we get wicketstuff-merged-resources included in the
next
release?

Jörn

On Mon, Aug 31, 2009 at 10:20 PM, Jeremy
Thomersonjer...@wickettraining.com wrote:
I have the credentials and think that I will definitely be
trying
this
on
the next release :)

--
Jeremy Thomerson
http://www.wickettraining.com

On Mon, Aug 31, 2009 at 3:16 PM, Martijn Dashorst
martijn.dasho...@gmail.com

Re: Wicket Stuff Core 1.4.1 Release[ing]

Ok fixed the jquery one.. Everybody else seems to comply (not having
contrib or stuff in their name), although alot of projects has a
naming like this : wicket-projectname

Im not sure if that fits the standard?

2009/9/15 nino martinez wael nino.martinez.w...@gmail.com:
No I understood what you said.. I'll fix them..

https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent/jquery/pom.xml

--
Jeremy Thomerson
http://www.wickettraining.com

On Tue, Sep 15, 2009 at 2:15 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Ahh, I misunderstood then, I though that every thing that were not in
compliance was commented out.

Looks really nice with the new simplified names.

2009/9/15 Jeremy Thomerson jer...@wickettraining.com:

Nino,

So, in this case, the pom.xml should be changed so that artifact ID is
jquery - to match the convention and the folder name.

There may be others - I just don't know - haven't looked in a while.

--
Jeremy Thomerson
http://www.wickettraining.com

On Mon, Sep 14, 2009 at 4:10 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Hmm seems the only one who are not compiling are ddcalendar.. The
other two are syringe and shiro-security, until their dependencies
become available..

There seems to be something here :

http://repository.apache.org/snapshots/org/apache/shiro/

Tauren mentioned that he would correct the pom..? Or did he mean that
it had to be on the common maven repository..?

And as for syringe commons proxy 1.1 is still not out :(

-Nino

You want to do it?

--
Jeremy Thomerson
http://www.wickettraining.com

On Thu, Sep 10, 2009 at 1:11 PM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Hi Jeremy

Should we have a list of offendending project?

[1]

http://wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-jquery/1.4.1/
[2]

http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Core+-+Migration+Guide

Best regards,

--
Jeremy Thomerson
http://www.wickettraining.com

On Sun, Sep 6, 2009 at 11:22 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:

So jquery-parent was build, which just references jquery and
jquery-examples - neither of which were build. Whats the point of
that?

Also, how can we get wicketstuff-merged-resources included in the
next
release?

Jörn

On Mon, Aug 31, 2009 at 10:20 PM, Jeremy
Thomersonjer...@wickettraining.com wrote:
I have

Re: Wicket Stuff Core 1.4.1 Release[ing]

Btw went trough all the project.. There a lot of them these days.. I
should try some of them out :)

Although almost every of them are not described on the wicketstuff
wiki, that is sad (I know im one of the sinners aswell)..

This could be used as template page (although the part about maven are
pretty out dated):

http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-openlayers

2009/9/15 nino martinez wael nino.martinez.w...@gmail.com:
Ok fixed the jquery one.. Everybody else seems to comply (not having
contrib or stuff in their name), although alot of projects has a
naming like this : wicket-projectname

Im not sure if that fits the standard?

2009/9/15 nino martinez wael nino.martinez.w...@gmail.com:
No I understood what you said.. I'll fix them..

https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent/jquery/pom.xml

--
Jeremy Thomerson
http://www.wickettraining.com

On Tue, Sep 15, 2009 at 2:15 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Ahh, I misunderstood then, I though that every thing that were not in
compliance was commented out.

Looks really nice with the new simplified names.

2009/9/15 Jeremy Thomerson jer...@wickettraining.com:

Nino,

So, in this case, the pom.xml should be changed so that artifact ID is
jquery - to match the convention and the folder name.

There may be others - I just don't know - haven't looked in a while.

--
Jeremy Thomerson
http://www.wickettraining.com

On Mon, Sep 14, 2009 at 4:10 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Hmm seems the only one who are not compiling are ddcalendar.. The
other two are syringe and shiro-security, until their dependencies
become available..

There seems to be something here :

http://repository.apache.org/snapshots/org/apache/shiro/

Tauren mentioned that he would correct the pom..? Or did he mean that
it had to be on the common maven repository..?

And as for syringe commons proxy 1.1 is still not out :(

-Nino

You want to do it?

--
Jeremy Thomerson
http://www.wickettraining.com

On Thu, Sep 10, 2009 at 1:11 PM, nino martinez wael
nino.martinez.w...@gmail.com wrote:

Hi Jeremy

Should we have a list of offendending project?

[1]

http://wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-jquery/1.4.1/
[2]

http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Core+-+Migration+Guide

Best regards,

--
Jeremy Thomerson
http://www.wickettraining.com

Re: Selectively ignoring required fields

On the other hand, maybe that whole criteria panel is deselected, in
which case I want to be able to stop the whole thing from doing any
validation at all, so it won't even look at whether the check box is
checked.

disable panel don't work on that case?

On Tue, Sep 15, 2009 at 11:10 AM, Phil Housley undeconstruc...@gmail.comwrote:

 2009/9/15 Bas Gooren b...@iswd.nl:
  The fact of the matter is that you will need extra logic _somewhere_.
 It's a
  matter of personal preference where you put it (overriden components,
 ajax,
  override form methods, ...).
 
  If what you're trying to accomplish is difficult given a certain set of
  tools, my experience is that it's good to rethink the problem.
 
  On the one hand you want isolation (components can have logic to say if
 they
  are required), and on the other hand you want to break outside of this
  isolation (form needs to control required flag on components). Having
 this
  logic in two different places is error-prone (at least from my
 experience).
  So why not have a single point in your code where you deal with the
 required
  flags of these components?
 
  Bas

 A good point, but I don't think it exactly applies in this case.  What
 I really want is for each component to know whether it is required
 within a very small context.  For example, a might have a criteria
 panel (one of the sub-parts of the searcher) set out as follows:

 [x] must be a foo called [_]

 In which case, the sub panel will be in total charge of whether the
 text field is required.

 On the other hand, maybe that whole criteria panel is deselected, in
 which case I want to be able to stop the whole thing from doing any
 validation at all, so it won't even look at whether the check box is
 checked.

 What I am thinking currently is to sadly discard the built in
 validation, and have each criteria panel report its errors manually
 when asked to by the parent to pass on its generated set of criteria
 (a map basically), which it has built out of its input.  I don't like
 it at all, as it lets bad data get too far into the system, but I
 think it will solve the immediate problem.

 Phil.

  - Original Message - From: Phil Housley
  undeconstruc...@gmail.com
  To: users@wicket.apache.org
  Sent: Tuesday, September 15, 2009 3:37 PM
  Subject: Re: Selectively ignoring required fields
 
 
  Several interesting ideas, but they all seem to involve more invasive
  changes than I really want to make - either changing component classes
  or changing values of components at process time, which would be hard
  to undo (and maybe not possible, as some components already have logic
  to say if they are required.)
 
  From hunting through the code, what would be about perfect would be to
  override org.apache.wicket.markup.html.form.Form#validateComponents(),
  but unfortunately that is final.  Even if I were to copy some of the
  code into my form class, there are some private methods of Form that I
  would need to call.
 
  Has anyone perhaps had a similar issue somewhere else?
 
  Thanks again,
 
  Phil.
 
  2009/9/15 Bas Gooren b...@iswd.nl:
 
  Phil,
 
  The way we deal with this is by using an ajax behavior on radiobuttons,
  and
  update the required flag on dependant fields from there.
 
  Another way (without ajax) could be to update the required flag on the
  form
  components on submit, prior to validation.
  E.g. by overriding Form.process() (or Form.validate(), since this is
  related
  to validation).
 
  E.g. something like
 
  Form form = new Form( id, ... ) {
  protected void validate() {
  // Update required flags on fields
  // ...
 
  // Call regular validation
  super.validate();
  }
  }
 
  Regards,
 
  Bas
 
  - Original Message - From: Phil Housley
  undeconstruc...@gmail.com
  To: users@wicket.apache.org
  Sent: Tuesday, September 15, 2009 2:30 PM
  Subject: Re: Selectively ignoring required fields
 
 
  2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:
 
  You can override isRequired for any component.
 
  **
  Martin
 
 
  Thanks, but I really don't want to have to make the individual fields
  context aware unless I have to. We have quite a few custom form
  controls, which are used both in searching and various other places,
  so it would be a lot of work to make them all respond to this
  particular use. A way to just prevent the required check/validation
  from the top would fit the bill better.
 
  2009/9/15 Phil Housley undeconstruc...@gmail.com:
 
  Hello,
 
  I'm currently working on a search interface, where the required-ness
  of some fields depends on the value of some other. In particular, the
  form looks something like
 
  (+) search by X
  a: [_]
  b: [_]
 
  () search by Y
  ...
 
  () search by Z
  ...
 
  So the radio button selects a group of fields, in which any number may
  be required. Each group of options is its own panel, and basically
  independent. Is it possible for me to ignore protests from the fields

Unable to close ModalWindow 1.4.1



Looking for hints to debug the situation I am in. Thanks.

Using wickets 1.4.1 

I have tried a simple scenario  - opening a page in a modal window and then 
using a link in the page to close the window. Works fine.

Now I am opening a more complicated page with its own javascript - performing a 
bunch of operations on that page using js while it is opened in a modal window. 
At the end of the operations I hide all the divs and then show a div that has a 
close link 

The link does not close the modal window - I see the request coming to the 
server I call close(target) tried ModalWindow.close(target) too but nothing 
happens.

The window closes with the X close button on the top right. 

the wicket debug shows the operation / at least being able to fetch the code to 
shut the window down succeeding .

http://hostname/?wicket:interface=mymodalWindow:3:doneInstall::IBehaviorListener:0:random=0.3818687947575885
 

?xml version=1.0 encoding=UTF-8?ajax-responseevaluate![CDATA[var win;
try {
win = window.parent.Wicket.Window;
} catch (ignore) {
}
if (typeof(win) == undefined || typeof(win.current) == undefined) {
  try {
 win = window.Wicket.Window;
  } catch (ignore) {
  }
}
if (typeof(win) != undefined  typeof(win.current) != undefined) {
 var close = function(w) { w.setTimeout(function() {
win.current.close();
}, 0);  } 
try { close(window.parent); } catch (ignore) { close(window); };
}]]/evaluateevaluate![CDATA[var win;
try {
win = window.parent.Wicket.Window;
} catch (ignore) {
}
if (typeof(win) == undefined || typeof(win.current) == undefined) {
  try {
 win = window.Wicket.Window;
  } catch (ignore) {
  }
}
if (typeof(win) != undefined  typeof(win.current) != undefined) {
 var close = function(w) { w.setTimeout(function() {
win.current.close();
}, 0);  } 
try { close(window.parent); } catch (ignore) { close(window); };
}]]/evaluate/ajax-response

_
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/

Re: Unable to close ModalWindow 1.4.1

On this ajax response, we can see that the close script was appended 2
times. Make sure that it appended only once, by close(target) or
ModalWindow.close(target).
Before click the close link, in a moment that was causing trouble, see if
these variables are not null:

Wicket.Window.current
window.parent.Wicket.Window.current

If so, look at what moment they are nullified. The close method called on
response:
win.current.close()
depends on these variables.

On Tue, Sep 15, 2009 at 4:54 PM, Ed _ ed_b...@hotmail.com wrote:



 Looking for hints to debug the situation I am in. Thanks.

 Using wickets 1.4.1

 I have tried a simple scenario  - opening a page in a modal window and then
 using a link in the page to close the window. Works fine.

 Now I am opening a more complicated page with its own javascript -
 performing a bunch of operations on that page using js while it is opened in
 a modal window. At the end of the operations I hide all the divs and then
 show a div that has a close link

 The link does not close the modal window - I see the request coming to the
 server I call close(target) tried ModalWindow.close(target) too but nothing
 happens.

 The window closes with the X close button on the top right.

 the wicket debug shows the operation / at least being able to fetch the
 code to shut the window down succeeding .


 http://hostname/?wicket:interface=mymodalWindow:3:doneInstall::IBehaviorListener:0:random=0.3818687947575885

 ?xml version=1.0 encoding=UTF-8?ajax-responseevaluate![CDATA[var
 win;
 try {
win = window.parent.Wicket.Window;
 } catch (ignore) {
 }
 if (typeof(win) == undefined || typeof(win.current) == undefined) {
  try {
 win = window.Wicket.Window;
  } catch (ignore) {
  }
 }
 if (typeof(win) != undefined  typeof(win.current) != undefined) {
  var close = function(w) { w.setTimeout(function() {
win.current.close();
}, 0);  }
try { close(window.parent); } catch (ignore) { close(window); };
 }]]/evaluateevaluate![CDATA[var win;
 try {
win = window.parent.Wicket.Window;
 } catch (ignore) {
 }
 if (typeof(win) == undefined || typeof(win.current) == undefined) {
  try {
 win = window.Wicket.Window;
  } catch (ignore) {
  }
 }
 if (typeof(win) != undefined  typeof(win.current) != undefined) {
  var close = function(w) { w.setTimeout(function() {
win.current.close();
}, 0);  }
try { close(window.parent); } catch (ignore) { close(window); };
 }]]/evaluate/ajax-response

 _
 Hotmail: Free, trusted and rich email service.
 http://clk.atdmt.com/GBL/go/171222984/direct/01/

Re: Unable to close ModalWindow 1.4.1

 by close(target) or ModalWindow.close(target)
-- use close(target), to maintain ModalWindow internal states updated.

On Tue, Sep 15, 2009 at 5:56 PM, Pedro Santos pedros...@gmail.com wrote:

 On this ajax response, we can see that the close script was appended 2
 times. Make sure that it appended only once, by close(target) or
 ModalWindow.close(target).
 Before click the close link, in a moment that was causing trouble, see if
 these variables are not null:

 Wicket.Window.current
 window.parent.Wicket.Window.current

 If so, look at what moment they are nullified. The close method called on
 response:
 win.current.close()
 depends on these variables.


 On Tue, Sep 15, 2009 at 4:54 PM, Ed _ ed_b...@hotmail.com wrote:



 Looking for hints to debug the situation I am in. Thanks.

 Using wickets 1.4.1

 I have tried a simple scenario  - opening a page in a modal window and
 then using a link in the page to close the window. Works fine.

 Now I am opening a more complicated page with its own javascript -
 performing a bunch of operations on that page using js while it is opened in
 a modal window. At the end of the operations I hide all the divs and then
 show a div that has a close link

 The link does not close the modal window - I see the request coming to the
 server I call close(target) tried ModalWindow.close(target) too but nothing
 happens.

 The window closes with the X close button on the top right.

 the wicket debug shows the operation / at least being able to fetch the
 code to shut the window down succeeding .


 http://hostname/?wicket:interface=mymodalWindow:3:doneInstall::IBehaviorListener:0:random=0.3818687947575885

 ?xml version=1.0
 encoding=UTF-8?ajax-responseevaluate![CDATA[var win;
 try {
win = window.parent.Wicket.Window;
 } catch (ignore) {
 }
 if (typeof(win) == undefined || typeof(win.current) == undefined) {
  try {
 win = window.Wicket.Window;
  } catch (ignore) {
  }
 }
 if (typeof(win) != undefined  typeof(win.current) != undefined) {
  var close = function(w) { w.setTimeout(function() {
win.current.close();
}, 0);  }
try { close(window.parent); } catch (ignore) { close(window); };
 }]]/evaluateevaluate![CDATA[var win;
 try {
win = window.parent.Wicket.Window;
 } catch (ignore) {
 }
 if (typeof(win) == undefined || typeof(win.current) == undefined) {
  try {
 win = window.Wicket.Window;
  } catch (ignore) {
  }
 }
 if (typeof(win) != undefined  typeof(win.current) != undefined) {
  var close = function(w) { w.setTimeout(function() {
win.current.close();
}, 0);  }
try { close(window.parent); } catch (ignore) { close(window); };
 }]]/evaluate/ajax-response

 _
 Hotmail: Free, trusted and rich email service.
 http://clk.atdmt.com/GBL/go/171222984/direct/01/

Re: Extract method suggestion in MultipartServletWebRequest class

2009-09-15 Thread Esteban Masoero


Done: https://issues.apache.org/jira/browse/WICKET-2469

Thanks,

Esteban

Igor Vaynberg escribió:

No chance without a Jira issue.

-igor

On 9/15/09, nico2884 fernandonicolasmelen...@gmail.com wrote:
  

I am using GAE + Wicket too, and I also had to copy/paste that class.
Any chances of making a refactor in a future release?

Thanks a lot! :)

Nico


Esteban Masoero-2 wrote:


Hi there:

In MultipartServletWebRequest constructor we have:
...
(line 93) DiskFileItemFactory factory = new DiskFileItemFactory();
...
which inhibits anyone from reusing MultipartServletWebRequest  with a
different factory. The only solution is generate a new class that is a
copy of this one, with that line changed.

Would it be possible to extract this code in  a method like:

/** Creates and returns a new file item factory. Subclasses can
override this method to use a different factory
 * @returns a recently created FileItemFactory object
 */
protected FileItemFactory getNewFileItemFactory() {
return new DiskFileItemFactory();
}

This way, we could just extend this class when there's a need to use a
different factory (as in GAE applications)

Thanks in advance,

Esteban

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



  

--
View this message in context:
http://www.nabble.com/Extract-method-suggestion-in-MultipartServletWebRequest-class-tp25390796p25456459.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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





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


  


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

Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request

2009-09-15 Thread Vladimir K


Igor, could you plan it for 1.4.2?


Vladimir K wrote:
 
 done
 
 https://issues.apache.org/jira/browse/WICKET-2463
 
 
 Vladimir K wrote:
 
 sure
 
 
 igor.vaynberg wrote:
 
 i guess create a quickstart and attach it to a jira issue. when i
 tested buttons, while developing the feature, it seemed to work fine.
 
 -igor
 
 On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote:

 it is attached to the input tag as follows:

                        form wicket:id=actionForm
 enctype='multipart/form-data'
                                div class=buttonBox
                                        input wicket:id=cancelAction
 type=submit
 wicket:message=value:command.cancelAction/input
                                /div
                        /form

 From my perspective the request is submitted very similar to as I
 remember
 submitting drop downs many years ago
 select onchange=this.form.submit();
 The request parameters contain the name of the form instead of the name
 of
 the button.


 igor.vaynberg wrote:

 this bit of javascript:

 if (submitButton != null) { s += Wicket.Form.encode(submitButton) +
 =1;
 }

 is needed because we do perform a custom form serialization - really
 just constructing the query string - that we submit back to server via
 ajax. the multipart handling performs a regular post into a hidden
 iframe so the browser performs the serialization - and that should
 include the button. what markup is your button attached to?

 -igor

 On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com
 wrote:
 I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false)
 to
 the
 multipart form and when it is pressed the form is handled as well as
 the
 button would have defaultFormProcessing=true.

 It happens because request parameters does not contain the name of
 the
 submitting button.

 The magic is in the new code in wicket-ajax.js

    // Submits a form using ajax.
    // This method serializes a form and sends it as POST body.
    submitForm: function(form, submitButton) {
        if (this.handleMultipart(form)) {
            return true;
        }
        var body = function() {
            var s = Wicket.Form.serialize(form);
            if (submitButton != null) {
                s += Wicket.Form.encode(submitButton) + =1;
            }
            return s;
        }
        return this.request.post(body);
    },

 I believe the problem is caused by handleMultipart(form) invocation.
 submitForm function accepts submitButton parameter but does not
 passes it
 to
 handleMultipart function.

 Igor could you clarify that?


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




 --
 View this message in context:
 http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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


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

-- 
View this message in context: 
http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25463838.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

RE: Unable to close ModalWindow 1.4.1


Thanks for the suggestion.

I have been using close(target) - unfortunately attached a run when I was using 
both methods. Even with one ajax response appended it doesn't work.

New to JS - can you tell me how to test the variables. If I add 

var status = window.parent.Wicket.Window; as part of my JS - I get permission 
denied exception as reported by firebug. 


My html file includes a head section with my javascript and the markup has 
wicket elements viz where the close links are rendered. I have two such links - 
both of which are rendered useless when used in this configuration - although 
the main close button of the modalwindow continues to work.

thanks

 Date: Tue, 15 Sep 2009 18:00:47 -0300
 Subject: Re: Unable to close ModalWindow 1.4.1
 From: pedros...@gmail.com
 To: users@wicket.apache.org
 
  by close(target) or ModalWindow.close(target)
 -- use close(target), to maintain ModalWindow internal states updated.
 
 On Tue, Sep 15, 2009 at 5:56 PM, Pedro Santos pedros...@gmail.com wrote:
 
  On this ajax response, we can see that the close script was appended 2
  times. Make sure that it appended only once, by close(target) or
  ModalWindow.close(target).
  Before click the close link, in a moment that was causing trouble, see if
  these variables are not null:
 
  Wicket.Window.current
  window.parent.Wicket.Window.current
 
  If so, look at what moment they are nullified. The close method called on
  response:
  win.current.close()
  depends on these variables.
 
 
  On Tue, Sep 15, 2009 at 4:54 PM, Ed _ ed_b...@hotmail.com wrote:
 
 
 
  Looking for hints to debug the situation I am in. Thanks.
 
  Using wickets 1.4.1
 
  I have tried a simple scenario  - opening a page in a modal window and
  then using a link in the page to close the window. Works fine.
 
  Now I am opening a more complicated page with its own javascript -
  performing a bunch of operations on that page using js while it is opened 
  in
  a modal window. At the end of the operations I hide all the divs and then
  show a div that has a close link
 
  The link does not close the modal window - I see the request coming to the
  server I call close(target) tried ModalWindow.close(target) too but nothing
  happens.
 
  The window closes with the X close button on the top right.
 
  the wicket debug shows the operation / at least being able to fetch the
  code to shut the window down succeeding .
 
 
  http://hostname/?wicket:interface=mymodalWindow:3:doneInstall::IBehaviorListener:0:random=0.3818687947575885
 
  ?xml version=1.0
  encoding=UTF-8?ajax-responseevaluate![CDATA[var win;
  try {
 win = window.parent.Wicket.Window;
  } catch (ignore) {
  }
  if (typeof(win) == undefined || typeof(win.current) == undefined) {
   try {
  win = window.Wicket.Window;
   } catch (ignore) {
   }
  }
  if (typeof(win) != undefined  typeof(win.current) != undefined) {
   var close = function(w) { w.setTimeout(function() {
 win.current.close();
 }, 0);  }
 try { close(window.parent); } catch (ignore) { close(window); };
  }]]/evaluateevaluate![CDATA[var win;
  try {
 win = window.parent.Wicket.Window;
  } catch (ignore) {
  }
  if (typeof(win) == undefined || typeof(win.current) == undefined) {
   try {
  win = window.Wicket.Window;
   } catch (ignore) {
   }
  }
  if (typeof(win) != undefined  typeof(win.current) != undefined) {
   var close = function(w) { w.setTimeout(function() {
 win.current.close();
 }, 0);  }
 try { close(window.parent); } catch (ignore) { close(window); };
  }]]/evaluate/ajax-response
 
  _
  Hotmail: Free, trusted and rich email service.
  http://clk.atdmt.com/GBL/go/171222984/direct/01/
 
 
 

_
Bing brings you health info from trusted sources.
http://www.bing.com/search?q=pet+allergyform=MHEINApubl=WLHMTAGcrea=TXT_MHEINA_Health_Health_PetAllergy_1x1

RE: Unable to close ModalWindow 1.4.1



Here is the wicket AJax Debug

INFO: focus set on cancelUpdatea8INFO: Using XMLHttpRequest transportINFO: 
INFO: Initiating Ajax GET request on 
?wicket:interface=modal-dialog-pagemap:26:cancelUpdate::IBehaviorListener:0:random=0.5391539823210829INFO:
 Invoking pre-call handler(s)...INFO: Received ajax response (541 
characters)INFO: 
?xml version=1.0 encoding=UTF-8?ajax-responseevaluate![CDATA[var win;
try {
win = window.parent.Wicket.Window;
} catch (ignore) {
}
if (typeof(win) == undefined || typeof(win.current) == undefined) {
  try {
 win = window.Wicket.Window;
  } catch (ignore) {
  }
}
if (typeof(win) != undefined  typeof(win.current) != undefined) {
 var close = function(w) { w.setTimeout(function() {
win.current.close();
}, 0);  } 
try { close(window.parent); } catch (ignore) { close(window); };
}]]/evaluate/ajax-responseINFO: Response parsed. Now invoking 
steps...INFO: Response processed successfully.INFO: Invoking post-call 
handler(s)...INFO: refocus last focused component not needed/allowedINFO: focus 
removed from cancelUpdatea8




 Date: Tue, 15 Sep 2009 18:00:47 -0300
 Subject: Re: Unable to close ModalWindow 1.4.1
 From: pedros...@gmail.com
 To: users@wicket.apache.org
 
  by close(target) or ModalWindow.close(target)
 -- use close(target), to maintain ModalWindow internal states updated.
 
 On Tue, Sep 15, 2009 at 5:56 PM, Pedro Santos pedros...@gmail.com wrote:
 
  On this ajax response, we can see that the close script was appended 2
  times. Make sure that it appended only once, by close(target) or
  ModalWindow.close(target).
  Before click the close link, in a moment that was causing trouble, see if
  these variables are not null:
 
  Wicket.Window.current
  window.parent.Wicket.Window.current
 
  If so, look at what moment they are nullified. The close method called on
  response:
  win.current.close()
  depends on these variables.
 
 
  On Tue, Sep 15, 2009 at 4:54 PM, Ed _ ed_b...@hotmail.com wrote:
 
 
 
  Looking for hints to debug the situation I am in. Thanks.
 
  Using wickets 1.4.1
 
  I have tried a simple scenario  - opening a page in a modal window and
  then using a link in the page to close the window. Works fine.
 
  Now I am opening a more complicated page with its own javascript -
  performing a bunch of operations on that page using js while it is opened 
  in
  a modal window. At the end of the operations I hide all the divs and then
  show a div that has a close link
 
  The link does not close the modal window - I see the request coming to the
  server I call close(target) tried ModalWindow.close(target) too but nothing
  happens.
 
  The window closes with the X close button on the top right.
 
  the wicket debug shows the operation / at least being able to fetch the
  code to shut the window down succeeding .
 
 
  http://hostname/?wicket:interface=mymodalWindow:3:doneInstall::IBehaviorListener:0:random=0.3818687947575885
 
  ?xml version=1.0
  encoding=UTF-8?ajax-responseevaluate![CDATA[var win;
  try {
 win = window.parent.Wicket.Window;
  } catch (ignore) {
  }
  if (typeof(win) == undefined || typeof(win.current) == undefined) {
   try {
  win = window.Wicket.Window;
   } catch (ignore) {
   }
  }
  if (typeof(win) != undefined  typeof(win.current) != undefined) {
   var close = function(w) { w.setTimeout(function() {
 win.current.close();
 }, 0);  }
 try { close(window.parent); } catch (ignore) { close(window); };
  }]]/evaluateevaluate![CDATA[var win;
  try {
 win = window.parent.Wicket.Window;
  } catch (ignore) {
  }
  if (typeof(win) == undefined || typeof(win.current) == undefined) {
   try {
  win = window.Wicket.Window;
   } catch (ignore) {
   }
  }
  if (typeof(win) != undefined  typeof(win.current) != undefined) {
   var close = function(w) { w.setTimeout(function() {
 win.current.close();
 }, 0);  }
 try { close(window.parent); } catch (ignore) { close(window); };
  }]]/evaluate/ajax-response
 
  _
  Hotmail: Free, trusted and rich email service.
  http://clk.atdmt.com/GBL/go/171222984/direct/01/
 
 
 

_
Bing brings you health info from trusted sources.
http://www.bing.com/search?q=pet+allergyform=MHEINApubl=WLHMTAGcrea=TXT_MHEINA_Health_Health_PetAllergy_1x1

Re: Unable to close ModalWindow 1.4.1

 - I get permission denied exception as reported by firebug.
- head section with my javascript

The firebug firefox plugging has an javascript console. Execute on him (
maybe you will not to get permission denied here):
alert(Wicket.Window.current)
alert(window.parent.Wicket.Window.current)
at the end of the javascript operations you report:

At the end of the operations I hide all the divs and then show a div that
has a close link

and let us to know what value then have.

call the alerts to output the values,

On Tue, Sep 15, 2009 at 9:13 PM, Ed _ ed_b...@hotmail.com wrote:


 Thanks for the suggestion.

 I have been using close(target) - unfortunately attached a run when I was
 using both methods. Even with one ajax response appended it doesn't work.

 New to JS - can you tell me how to test the variables. If I add

 var status = window.parent.Wicket.Window; as part of my JS - I get
 permission denied exception as reported by firebug.


 My html file includes a head section with my javascript and the markup has
 wicket elements viz where the close links are rendered. I have two such
 links - both of which are rendered useless when used in this configuration -
 although the main close button of the modalwindow continues to work.

 thanks

  Date: Tue, 15 Sep 2009 18:00:47 -0300
  Subject: Re: Unable to close ModalWindow 1.4.1
  From: pedros...@gmail.com
  To: users@wicket.apache.org
 
   by close(target) or ModalWindow.close(target)
  -- use close(target), to maintain ModalWindow internal states updated.
 
  On Tue, Sep 15, 2009 at 5:56 PM, Pedro Santos pedros...@gmail.com
 wrote:
 
   On this ajax response, we can see that the close script was appended 2
   times. Make sure that it appended only once, by close(target) or
   ModalWindow.close(target).
   Before click the close link, in a moment that was causing trouble,
 see if
   these variables are not null:
  
   Wicket.Window.current
   window.parent.Wicket.Window.current
  
   If so, look at what moment they are nullified. The close method called
 on
   response:
   win.current.close()
   depends on these variables.
  
  
   On Tue, Sep 15, 2009 at 4:54 PM, Ed _ ed_b...@hotmail.com wrote:
  
  
  
   Looking for hints to debug the situation I am in. Thanks.
  
   Using wickets 1.4.1
  
   I have tried a simple scenario  - opening a page in a modal window and
   then using a link in the page to close the window. Works fine.
  
   Now I am opening a more complicated page with its own javascript -
   performing a bunch of operations on that page using js while it is
 opened in
   a modal window. At the end of the operations I hide all the divs and
 then
   show a div that has a close link
  
   The link does not close the modal window - I see the request coming to
 the
   server I call close(target) tried ModalWindow.close(target) too but
 nothing
   happens.
  
   The window closes with the X close button on the top right.
  
   the wicket debug shows the operation / at least being able to fetch
 the
   code to shut the window down succeeding .
  
  
  
 http://hostname/?wicket:interface=mymodalWindow:3:doneInstall::IBehaviorListener:0:random=0.3818687947575885
  
   ?xml version=1.0
   encoding=UTF-8?ajax-responseevaluate![CDATA[var win;
   try {
  win = window.parent.Wicket.Window;
   } catch (ignore) {
   }
   if (typeof(win) == undefined || typeof(win.current) == undefined)
 {
try {
   win = window.Wicket.Window;
} catch (ignore) {
}
   }
   if (typeof(win) != undefined  typeof(win.current) != undefined)
 {
var close = function(w) { w.setTimeout(function() {
  win.current.close();
  }, 0);  }
  try { close(window.parent); } catch (ignore) { close(window); };
   }]]/evaluateevaluate![CDATA[var win;
   try {
  win = window.parent.Wicket.Window;
   } catch (ignore) {
   }
   if (typeof(win) == undefined || typeof(win.current) == undefined)
 {
try {
   win = window.Wicket.Window;
} catch (ignore) {
}
   }
   if (typeof(win) != undefined  typeof(win.current) != undefined)
 {
var close = function(w) { w.setTimeout(function() {
  win.current.close();
  }, 0);  }
  try { close(window.parent); } catch (ignore) { close(window); };
   }]]/evaluate/ajax-response
  
   _
   Hotmail: Free, trusted and rich email service.
   http://clk.atdmt.com/GBL/go/171222984/direct/01/
  
  
  

 _
 Bing brings you health info from trusted sources.

 http://www.bing.com/search?q=pet+allergyform=MHEINApubl=WLHMTAGcrea=TXT_MHEINA_Health_Health_PetAllergy_1x1

RE: Unable to close ModalWindow 1.4.1


Ok I added this to the html 
script type=text/javascript
alert(window.parent.Wicket.Window.current);
 /script

of my simple page example and the alert poped up with [object Object]



When I add it to my actual page - I get permission denied. :(

alert(Wicket.Window.current) - shows up as an error - undefined in the test 
page.

Thanks



 Date: Tue, 15 Sep 2009 21:45:34 -0300
 Subject: Re: Unable to close ModalWindow 1.4.1
 From: pedros...@gmail.com
 To: users@wicket.apache.org
 
  - I get permission denied exception as reported by firebug.
 - head section with my javascript
 
 The firebug firefox plugging has an javascript console. Execute on him (
 maybe you will not to get permission denied here):
 alert(Wicket.Window.current)
 alert(window.parent.Wicket.Window.current)
 at the end of the javascript operations you report:
 
 At the end of the operations I hide all the divs and then show a div that
 has a close link
 
 and let us to know what value then have.
 
 call the alerts to output the values,
 
 On Tue, Sep 15, 2009 at 9:13 PM, Ed _ ed_b...@hotmail.com wrote:
 
 
  Thanks for the suggestion.
 
  I have been using close(target) - unfortunately attached a run when I was
  using both methods. Even with one ajax response appended it doesn't work.
 
  New to JS - can you tell me how to test the variables. If I add
 
  var status = window.parent.Wicket.Window; as part of my JS - I get
  permission denied exception as reported by firebug.
 
 
  My html file includes a head section with my javascript and the markup has
  wicket elements viz where the close links are rendered. I have two such
  links - both of which are rendered useless when used in this configuration -
  although the main close button of the modalwindow continues to work.
 
  thanks
 
   Date: Tue, 15 Sep 2009 18:00:47 -0300
   Subject: Re: Unable to close ModalWindow 1.4.1
   From: pedros...@gmail.com
   To: users@wicket.apache.org
  
by close(target) or ModalWindow.close(target)
   -- use close(target), to maintain ModalWindow internal states updated.
  
   On Tue, Sep 15, 2009 at 5:56 PM, Pedro Santos pedros...@gmail.com
  wrote:
  
On this ajax response, we can see that the close script was appended 2
times. Make sure that it appended only once, by close(target) or
ModalWindow.close(target).
Before click the close link, in a moment that was causing trouble,
  see if
these variables are not null:
   
Wicket.Window.current
window.parent.Wicket.Window.current
   
If so, look at what moment they are nullified. The close method called
  on
response:
win.current.close()
depends on these variables.
   
   
On Tue, Sep 15, 2009 at 4:54 PM, Ed _ ed_b...@hotmail.com wrote:
   
   
   
Looking for hints to debug the situation I am in. Thanks.
   
Using wickets 1.4.1
   
I have tried a simple scenario  - opening a page in a modal window and
then using a link in the page to close the window. Works fine.
   
Now I am opening a more complicated page with its own javascript -
performing a bunch of operations on that page using js while it is
  opened in
a modal window. At the end of the operations I hide all the divs and
  then
show a div that has a close link
   
The link does not close the modal window - I see the request coming to
  the
server I call close(target) tried ModalWindow.close(target) too but
  nothing
happens.
   
The window closes with the X close button on the top right.
   
the wicket debug shows the operation / at least being able to fetch
  the
code to shut the window down succeeding .
   
   
   
  http://hostname/?wicket:interface=mymodalWindow:3:doneInstall::IBehaviorListener:0:random=0.3818687947575885
   
?xml version=1.0
encoding=UTF-8?ajax-responseevaluate![CDATA[var win;
try {
   win = window.parent.Wicket.Window;
} catch (ignore) {
}
if (typeof(win) == undefined || typeof(win.current) == undefined)
  {
 try {
win = window.Wicket.Window;
 } catch (ignore) {
 }
}
if (typeof(win) != undefined  typeof(win.current) != undefined)
  {
 var close = function(w) { w.setTimeout(function() {
   win.current.close();
   }, 0);  }
   try { close(window.parent); } catch (ignore) { close(window); };
}]]/evaluateevaluate![CDATA[var win;
try {
   win = window.parent.Wicket.Window;
} catch (ignore) {
}
if (typeof(win) == undefined || typeof(win.current) == undefined)
  {
 try {
win = window.Wicket.Window;
 } catch (ignore) {
 }
}
if (typeof(win) != undefined  typeof(win.current) != undefined)
  {
 var close = function(w) { w.setTimeout(function() {
   win.current.close();
   }, 0);  }
   try { close(window.parent); } catch (ignore) { close(window); };
}]]/evaluate/ajax-response
   
_
Hotmail:

RE: Unable to close ModalWindow 1.4.1




Permission denied for http://domain.com to get property Window.Wicket from 
http://subdomain.domain.com:8080.
http://subdomain.domain.com:8080/?wicket:interface=modal-dialog-pagemap:15
Line 265

wonder why it thinks that the domains are different ?

can I force domain.doc value somehow

thx

 Date: Tue, 15 Sep 2009 21:45:34 -0300
 Subject: Re: Unable to close ModalWindow 1.4.1
 From: pedros...@gmail.com
 To: users@wicket.apache.org
 
  - I get permission denied exception as reported by firebug.
 - head section with my javascript
 
 The firebug firefox plugging has an javascript console. Execute on him (
 maybe you will not to get permission denied here):
 alert(Wicket.Window.current)
 alert(window.parent.Wicket.Window.current)
 at the end of the javascript operations you report:
 
 At the end of the operations I hide all the divs and then show a div that
 has a close link
 
 and let us to know what value then have.
 
 call the alerts to output the values,
 
 On Tue, Sep 15, 2009 at 9:13 PM, Ed _ ed_b...@hotmail.com wrote:
 
 
  Thanks for the suggestion.
 
  I have been using close(target) - unfortunately attached a run when I was
  using both methods. Even with one ajax response appended it doesn't work.
 
  New to JS - can you tell me how to test the variables. If I add
 
  var status = window.parent.Wicket.Window; as part of my JS - I get
  permission denied exception as reported by firebug.
 
 
  My html file includes a head section with my javascript and the markup has
  wicket elements viz where the close links are rendered. I have two such
  links - both of which are rendered useless when used in this configuration -
  although the main close button of the modalwindow continues to work.
 
  thanks
 
   Date: Tue, 15 Sep 2009 18:00:47 -0300
   Subject: Re: Unable to close ModalWindow 1.4.1
   From: pedros...@gmail.com
   To: users@wicket.apache.org
  
by close(target) or ModalWindow.close(target)
   -- use close(target), to maintain ModalWindow internal states updated.
  
   On Tue, Sep 15, 2009 at 5:56 PM, Pedro Santos pedros...@gmail.com
  wrote:
  
On this ajax response, we can see that the close script was appended 2
times. Make sure that it appended only once, by close(target) or
ModalWindow.close(target).
Before click the close link, in a moment that was causing trouble,
  see if
these variables are not null:
   
Wicket.Window.current
window.parent.Wicket.Window.current
   
If so, look at what moment they are nullified. The close method called
  on
response:
win.current.close()
depends on these variables.
   
   
On Tue, Sep 15, 2009 at 4:54 PM, Ed _ ed_b...@hotmail.com wrote:
   
   
   
Looking for hints to debug the situation I am in. Thanks.
   
Using wickets 1.4.1
   
I have tried a simple scenario  - opening a page in a modal window and
then using a link in the page to close the window. Works fine.
   
Now I am opening a more complicated page with its own javascript -
performing a bunch of operations on that page using js while it is
  opened in
a modal window. At the end of the operations I hide all the divs and
  then
show a div that has a close link
   
The link does not close the modal window - I see the request coming to
  the
server I call close(target) tried ModalWindow.close(target) too but
  nothing
happens.
   
The window closes with the X close button on the top right.
   
the wicket debug shows the operation / at least being able to fetch
  the
code to shut the window down succeeding .
   
   
   
  http://hostname/?wicket:interface=mymodalWindow:3:doneInstall::IBehaviorListener:0:random=0.3818687947575885
   
?xml version=1.0
encoding=UTF-8?ajax-responseevaluate![CDATA[var win;
try {
   win = window.parent.Wicket.Window;
} catch (ignore) {
}
if (typeof(win) == undefined || typeof(win.current) == undefined)
  {
 try {
win = window.Wicket.Window;
 } catch (ignore) {
 }
}
if (typeof(win) != undefined  typeof(win.current) != undefined)
  {
 var close = function(w) { w.setTimeout(function() {
   win.current.close();
   }, 0);  }
   try { close(window.parent); } catch (ignore) { close(window); };
}]]/evaluateevaluate![CDATA[var win;
try {
   win = window.parent.Wicket.Window;
} catch (ignore) {
}
if (typeof(win) == undefined || typeof(win.current) == undefined)
  {
 try {
win = window.Wicket.Window;
 } catch (ignore) {
 }
}
if (typeof(win) != undefined  typeof(win.current) != undefined)
  {
 var close = function(w) { w.setTimeout(function() {
   win.current.close();
   }, 0);  }
   try { close(window.parent); } catch (ignore) { close(window); };
}]]/evaluate/ajax-response
   
_
Hotmail: Free, trusted and rich email service.

RE: Unable to close ModalWindow 1.4.1