date:20070314

Are you using eclipse + wicket bench? Then you can tell the wicket
bench where your css files live.

Martijn

On 3/14/07, Chris Colman [EMAIL PROTECTED] wrote:
 I'm using wicket and trying to work out how to set up my directories so
 that while editing HTML markups my HTML editor has access to the same
 CSS files that will be used as run time.

 The HTML markups are in my project/src/com/sas/ui/wicket directory with
 my wicket component classes but being in the src directory these files
 are kind of in a different realm to the normal HTML resources of the web
 app.

 Any ideas on how to set up directories so that I can use the CSS in both
 my HTML editor and at run time?

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Apache Con Amsterdam: wicket presence

2007-03-14 Thread Xavier Hanin


On 3/13/07, Martijn Dashorst [EMAIL PROTECTED] wrote:


Who is going to attend Apache Con in Amsterdam? We are planning to
host an evening session, but we would like to know how many would be
interested/attend.



I'll be there, and I'd be interested. I've incremented the counter on the
wiki page.

- Xavier

You can see the schedule here:

http://wiki.apache.org/apachecon/BirdsOfaFeatherEu07

Other presentations featuring Wicket:
- A tutorial on Wicket provided by Matej Knopp on tuesday
- Matt Raible presents a framework comparison on friday.

More information on ApacheCon Amsterdam can be found here:
http://apachecon.com

Martijn

--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Setting up directories to make CSS available

2007-03-14 Thread Dirk Markert


You can include

wicket:remove
 base href=file:///C:/Docs%20and%20Settings/you/your-project/src/webapp/
/
/wicket:remove

in your html head.

2007/3/14, Chris Colman [EMAIL PROTECTED]:


I'm using wicket and trying to work out how to set up my directories so
that while editing HTML markups my HTML editor has access to the same
CSS files that will be used as run time.

The HTML markups are in my project/src/com/sas/ui/wicket directory with
my wicket component classes but being in the src directory these files
are kind of in a different realm to the normal HTML resources of the web
app.

Any ideas on how to set up directories so that I can use the CSS in both
my HTML editor and at run time?

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

2007-03-14 Thread Stefan Lindner

Al Maw wrote
I don't want to do any of A, B or C.

I am not a developer of wicket and it's completely up to yours how you do it, 
but why not the following way:
 
1. Keep Wicket 2 and do the constructor change there. Now you have a java 1.4 
branch (wicket 1.x) and a java 5 branch (wicket 2.0 or call the thing wicket 
1.5 or whatever). The very most of Wicket 2 users will not have big trouble to 
change the constructor. Do the packet name change in 2.0. It's easy to replace 
wicket with org.apache.wicket...
 
2. Create a branch from 2.0 and call it 1.4. Remove all generic stuff. So you 
have a Java 1.4 version with classic constructor and without generics but the 
code is equivalent to 2.0
 
3. Now you have two branches that are based on the same codeline and 
backporting from 2.0 to 1.4 is easy. Create new features in wicket 2 and 
backport them (just drop the generics and add some type casts) to 1.4.
 
4. You can release current 1.3 as a beta and release it soon as it is.
 
Stefan Lindner
winmail.dat-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] When you have tabs and forms, is it ok to have the tabs all inside one form,

2007-03-14 Thread Jean-Baptiste Quenot

* Jean-Baptiste Quenot:
 We have DojoTabContainer in Wicket Contrib Dojo that is
 client-side only.
 
 See an example at
 http://www.demay-fr.net:8080/Wicket-start/app?wicket:bookmarkablePage=:wicket.contrib.dojo.examples.TabContainerSample

Sorry the right URL (more uptodate) was:

http://www.demay-fr.net:8080/WCD13/app/?wicket:bookmarkablePage=%3Awicket.contrib.dojo.examples.TabContainerSample
-- 
 Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Apache Con Amsterdam: wicket presence

2007-03-14 Thread Jean-Baptiste Quenot

* Martijn Dashorst:

 Who is going to attend  Apache Con in Amsterdam? We are planning
 to host an  evening session, but we would like  to know how many
 would be interested/attend.

Me too.
-- 
 Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

The whole gest of the discussion is to remove the constructor change.
It hasn't been decided yet, but the future for the constructor change
seems grim.

Martijn

On 3/14/07, Stefan Lindner [EMAIL PROTECTED] wrote:
 Al Maw wrote
 I don't want to do any of A, B or C.

 I am not a developer of wicket and it's completely up to yours how you do it, 
 but why not the following way:

 1. Keep Wicket 2 and do the constructor change there. Now you have a java 1.4 
 branch (wicket 1.x) and a java 5 branch (wicket 2.0 or call the thing wicket 
 1.5 or whatever). The very most of Wicket 2 users will not have big trouble 
 to change the constructor. Do the packet name change in 2.0. It's easy to 
 replace wicket with org.apache.wicket...

 2. Create a branch from 2.0 and call it 1.4. Remove all generic stuff. So you 
 have a Java 1.4 version with classic constructor and without generics but the 
 code is equivalent to 2.0

 3. Now you have two branches that are based on the same codeline and 
 backporting from 2.0 to 1.4 is easy. Create new features in wicket 2 and 
 backport them (just drop the generics and add some type casts) to 1.4.

 4. You can release current 1.3 as a beta and release it soon as it is.

 Stefan Lindner

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] Converters

Hi,

I use Wicket 1.2.5 and have been looking at Converters (IConverter  
ITypeConverter).

The problem I want to solve is formatting my BigDecimals correctly.

Can't understand why this should be so complicated. Why have converters 
at all? Java already has java.text.Format with the methods:

Object parseObject(String source)
String format (Object obj)

What more do we need? (Maybe generics...)


How do I get rid of 0E-9 when using Wicket 1.2.5 and Java 1.5? Why 
isn't this - whatever the solution is - the default behavior of Wicket?


/Anders


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] Setting up directories to make CSS available

2007-03-14 Thread Chris Colman

 You can include
 
 wicket:remove
   base href=file:///C:/Docs%20and%20Settings/you/your-
 project/src/webapp/
 /
 /wicket:remove
 
 in your html head.

Ah cool!

Ok, so that will include the CSS at HTML edit time. What do I need to
put in a tag that is the opposite to wicket:remove? ie., not there at
edit time but there a wicket render time?

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Setting up directories to make CSS available

Just:

link href=mystyle.css rel=stylesheet /

Martijn

On 3/14/07, Chris Colman [EMAIL PROTECTED] wrote:
  You can include
 
  wicket:remove
base href=file:///C:/Docs%20and%20Settings/you/your-
  project/src/webapp/
  /
  /wicket:remove
 
  in your html head.

 Ah cool!

 Ok, so that will include the CSS at HTML edit time. What do I need to
 put in a tag that is the opposite to wicket:remove? ie., not there at
 edit time but there a wicket render time?

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

2007-03-14 Thread Jean-Baptiste Quenot

* Al Maw:
 Eelco Hillenius wrote:
  Can I have the opinions of all committers please? Johan is on a skiing
  trip but opts for c).
 
 I don't want to do any of A, B or C.
 
 What I /really/ think we should try to achieve:
 
 1. Have long-term JDK 1.4 and JDK 1.5 branches that are easy to
 sync/backport from. These would therefore ideally have, in order of
 importance:
  - The same constructor/add logic.
  - The same kind of models.
  - The same package namespace.
 
 2. Avoid pushing out a 1.3 beta that's very different from the RC and
 final releases.
 
 Provided we do both of those, I don't really care how we get there. 
 Looking at your options, option C breaks that second point pretty badly.
 
 I still think we should push out 1.3 as-is, do a quick 1.4 with the new 
 models and a package rename from wicket to org.apache.wicket, and create 
 a 1.5 branch as soon as we have a beta/RC of 1.4.

The problem is not the names you  put in front of a released piece
of software.   The problem is how  many branches are you  going to
maintain  at  the  same  time?   At the  beginning  I  liked  your
proposal, but I  think now it's just too optimistic.   We won't be
probably  releasing anything  to  the public  until all  important
features have been backported from trunk.

 Everyone else seems to think that this is a terrible idea, likely to 
 drag on for ages and confuse the users. Given that is therefore a 
 non-flier, I think we should:
   * Push the model change in right now.
   * Let it settle for a week or two to catch the worst bugs.
 (If we need a 1.3 alpha-incubator-moderation or whatever to get
 Apache approval, I'm all for that in the meantime.)
   * Get a 1.3 beta out the door to our users before the end of the month.
 
 I also think that if we're going to be stuck maintaining 1.3 as the JDK 
 1.4 branch for a long time (which looks likely), we should change the 
 package namespace to org.apache.wicket for 1.3 right now, as it'll make 
 life easier.
 
 I guess there's nothing wrong with having a minor release version (like 
 1.3.2 or something) be the first Apache approved non-incubator release.
 
 Hopefully if we push the model change into 1.3, no one will want 
 anything else to go in there and we can finally kick it out the door.

I'm +1 with everything you say in the second part of your mail.
I notice that you changed your mind during writing it, that's
good to see you are open, and not narrow-minded at all ;-)
-- 
 Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

Can anyone vote?

I vote for alternative D.

You asked about reverting the constructor change or not. My
interpretation of the answers you got is: Yes, fine, what ever, but give
us generics (for models at least).

Alternative D is: Revert to working on 1 branch (doesn't matter if it's
called 1.3 or 2.0) and make moving to Java5 (adding Generics) top priority.

/Anders

Eelco Hillenius wrote:
Hi,

It looks like the discussion around reverting the constructor change
that we did for 2.0 has cooled down. This email is not a vote yet, but
a summary of opinions so far[1]. Those of you Wicket committers who
didn't have your say yet (Juergen, Frank, Gwyn, Janne, Jan, Ate), I
consider that an OK for reverting. If not, please reply to the thread.
Juergen, you have been working on 2.0 quite a bit. Can you please
state your opinion, and can you tell us whether there are more
functional differences between 1.3 and 2.0 other than the constructor
change, Java 5 features, the attach/ detach change and improved models
and validators?[2]

I think so far we can safely say reverting is supported broadly. At
least, of the people who reacted, most stated they actually preferred
add over the new constructor, and those who were either neutral or had
a slight preference for the new constructor would still support
reverting as that would keep the momentum for the project going.

So, it looks like this may happen. But we'll vote about that in a few
days. Before we do that, we have to reach consensus on the package
we'll vote on. We have some different - and strong - opinions[3] so we
need to find a way to bridge that. Here are what I think the different
opinions:

a) focus on stabilizing 1.3 first, meanwhile keep supporting 2.0
(though only for bugfixes). 1.4 will be the release with backports of
the currently missing 2.0 features, and 1.5 will be 1.4 + the Java 5
features (including generics).

b) as a) but rather than developing 1.3 up to a final release, freeze
asap (only fix bugs) and start on 1.4

c) put all backports except for the Java 5 features in 1.3 after the
beta1 release (which we agreed upon doing this weekend). 1.4 will be
for the Java 5 features, and the branch should be started as soon as
1.3 is feature complete.

Maybe the most constructive way to gather opinions here is to first
let people plainly state what they prefer before we enter discussion
mode. So, please state what package you think is the best idea (or
introduce d if you want), and why.

Cheers,

Eelco

[1]
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9350505
http://www.nabble.com/Re%3A-IMPORTANT%3A-your-opinion-on-the-constructor-tf3359229.html#a9344068
[2] http://www.nabble.com/State-1.3--features-tf3376983.html
[3]
http://www.nabble.com/VOTE%3A-backporting-wicket-2.0-model-change-to-1.3-tf3364601.html
http://www.nabble.com/roadmap-tf3366743.html

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Build failure

2007-03-14 Thread Gwyn Evans

Double-check the top-level pom.xml? It should have
 modulejdk-1.4/module
 modulejdk-1.5/module
but your log doesn't seem to show it doing the jdk-1.4 module tree for
soem reason...

/Gwyn

On 14/03/07, Frank Bille [EMAIL PROTECTED] wrote:
 I have upgraded to 2.0.5 and also updated to latest svn version of 1.3, and
 I now get a different error:

 http://www.nabble.com/Al%27s-repository-restructure-tf3386729.html#a9469179

 Frank



 On 3/13/07, John Patterson [EMAIL PROTECTED] wrote:
  Strange, I just deleted the entire
 .m2/repository/org/apache/wicket/
  directory and checked out a fresh copy of http://svn.apache.org/repos/
  asf/incubator/wicket/branches/wicket- 1.x into a new
 directory,
  updated mvn to 2.0.5 (using darwin ports) and ran:
 
  mvn -Dmaven.test.skip=true  install
 
  But got the exact same error as before:
 
  Loading source file
 /Users/John/Development/wicket/current/wicket- 1.x/
 
 jdk-1.4/wicket-extensions/src/main/java/wicket/extensions/wizard/
  WizardModel.java...
  Loading source file
 /Users/John/Development/wicket/current/wicket-1.x/
 
 jdk-1.4/wicket-extensions/src/main/java/wicket/extensions/wizard/
  WizardStep.java...
  1 error
  [INFO]
 
 
  [ERROR] BUILD ERROR
  [INFO]
 
 
  [INFO] An error has occurred in JavaDocs report generation.
 
  Embedded error: Exit code: 1 - error: error reading /Users/John/
 
 Development/wicket/current/wicket-1.x/jdk-1.4/wicket/target/
  wicket-1.3.0-incubating-SNAPSHOT.jar ; invalid header
 field
 
  could it be a different javadoc binary that causes the different
  behaviour?
 
  My Mac OS X java version is reported as:
 
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164 )
 
  On 13 Mar 2007, at 14:40, Martijn Dashorst wrote:
 
   I just did a clean checkout of our 1.x branch, removed my local
   repository, and it 'just worked'.
  
   I do use maven 2.0.5 , perhaps that is the deciding factor?
  
   Martijn
  
   On 3/13/07, John Patterson [EMAIL PROTECTED] wrote:
   On 13 Mar 2007, at 12:31, Frank Bille wrote:
  
   I get the same error and have tried to remove local jar files. I'll
   look into it tonight (can't get workspace setup using new al
   structure)
  
  
   Great, cheers.  Until then I have checked out the last revision
   before the restructuring.
  
  
 -
   
   Take Surveys. Earn Cash. Influence the Future of IT
   Join SourceForge.net's Techsay panel and you'll get the chance to
   share your
   opinions on IT  business topics through brief surveys-and earn cash
   http://www.techsay.com/default.php?
   page=join.phpp=sourceforgeCID=DEVDEV
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
   --
   Learn Wicket at ApacheCon Europe: http://apachecon.com
   Join the wicket community at irc.freenode.net : ##wicket
   Wicket 1.2.5 will keep your server alive. Download Wicket now!
   http://wicketframework.org
  
  
 --
   ---
   Take Surveys. Earn Cash. Influence the Future of IT
   Join SourceForge.net's Techsay panel and you'll get the chance to
   share your
   opinions on IT  business topics through brief surveys-and earn cash
   http://www.techsay.com/default.php?
   page=join.phpp=sourceforgeCID=DEVDEV
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
  opinions on IT  business topics through brief surveys-and earn cash
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-- 
Download Wicket 1.2.5 now! - http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future

[Wicket-user] Setting up directories to make CSS available

2007-03-14 Thread Chris Colman

Ar! On closer reading I just realized that you were using the
wicket:remove to set a base whereas I had assumed (without reading too
carefully) that you were using it to include the CSS and consequently I
was concerned that the CSS would be included twice by the HTML editor -
but not do! It all makes sense now.
 
 Just:
 
 link href=mystyle.css rel=stylesheet /
 
 Martijn
 
 On 3/14/07, Chris Colman [EMAIL PROTECTED] wrote:
   You can include
  
   wicket:remove
 base href=file:///C:/Docs%20and%20Settings/you/your-
   project/src/webapp/
   /
   /wicket:remove
  
   in your html head.
 
  Ah cool!
 
  Ok, so that will include the CSS at HTML edit time. What do I need
to
  put in a tag that is the opposite to wicket:remove? ie., not there
at
  edit time but there a wicket render time?
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] find a cousin Component


This feels like something someone would have asked before, but I couldn't
find any relevant answers.

I have a usecase where my page/components have role-based security;
ENABLE/RENDER actions are dynamic as opposed to static based upon the
user/data on the page.  When data on the page changes that could affect
another field, I want to refresh the other field so that it's ENABLE/RENDER
function can be re-evaluated.

In my specific example, a field in one Panel is enabled ONLY when you are in
the List of Responsible Individuals (a field on a different Panel).  If that
list of RIs change, I want to immediately refresh (via AJAX) the other
(dependent) field.

I am working towards a Listerner(?) pattern whereby a Component registers
itself with another Component to be refreshed.  In order for that to work, I
need to geta handle to the other Component and the only way I know to do
that is by calling get from a common parent.  Other ways?

Given this hierarchy, I want to register OtherMdays to be refreshed when
ResponsibleIndividuals changes (ResponsibleIndividuals panel is responsible
for knowing when to refresh it's listeners).

content (Panel)
  + form
+ headerSection (Panel)
  + collapsibleBody (WebMarkupContainer)
+ sections (RepeatingView)
  + header (Panel)
+ responsibleIndividuals (Panel)
(other textfields, etc)
+ romEvents (RepeatingView)
  + baseEvent (Panel)
+ collapsibleBody (WebMarkupContainer)
  + sections (RepeatingView)
+ event (Panel)
  + rates (Panel)
OtherMdays (TextField)
(other textfields, etc)
  + signatures (Panel)

So, the name of the RI Panel (relative to form) is
headerSection:collapsibleBody:sections:header:responsibleIndividuals.

Therefore, I can do
form.get(headerSection:collapsibleBody:sections:header:responsibleIndividuals)
to return that Component.  But that means that everywhere that I want to get
a handle to the RI Panel, I need to use that string.  Is that really the
only/best way to do it?  I suppose I could extract that string into a
constant at the Page level so that at least I am not propagating a raw
string, but it is still just a plain old string, then why not store a ref to
the component at the page level?  There could be many such refreshers that
listener Components register with.

Chuck
-- 
View this message in context: 
http://www.nabble.com/find-a-%22cousin%22-Component-tf3401959.html#a9473809
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] find a cousin Component


you could keep component instances as fields so you can reference them
directly instead of getting them via their path

-igor


On 3/14/07, ChuckDeal [EMAIL PROTECTED] wrote:



This feels like something someone would have asked before, but I couldn't
find any relevant answers.

I have a usecase where my page/components have role-based security;
ENABLE/RENDER actions are dynamic as opposed to static based upon the
user/data on the page.  When data on the page changes that could affect
another field, I want to refresh the other field so that it's
ENABLE/RENDER
function can be re-evaluated.

In my specific example, a field in one Panel is enabled ONLY when you are
in
the List of Responsible Individuals (a field on a different Panel).  If
that
list of RIs change, I want to immediately refresh (via AJAX) the other
(dependent) field.

I am working towards a Listerner(?) pattern whereby a Component registers
itself with another Component to be refreshed.  In order for that to work,
I
need to geta handle to the other Component and the only way I know to do
that is by calling get from a common parent.  Other ways?

Given this hierarchy, I want to register OtherMdays to be refreshed when
ResponsibleIndividuals changes (ResponsibleIndividuals panel is
responsible
for knowing when to refresh it's listeners).

content (Panel)
  + form
+ headerSection (Panel)
  + collapsibleBody (WebMarkupContainer)
+ sections (RepeatingView)
  + header (Panel)
+ responsibleIndividuals (Panel)
(other textfields, etc)
+ romEvents (RepeatingView)
  + baseEvent (Panel)
+ collapsibleBody (WebMarkupContainer)
  + sections (RepeatingView)
+ event (Panel)
  + rates (Panel)
OtherMdays (TextField)
(other textfields, etc)
  + signatures (Panel)

So, the name of the RI Panel (relative to form) is
headerSection:collapsibleBody:sections:header:responsibleIndividuals.

Therefore, I can do
form.get
(headerSection:collapsibleBody:sections:header:responsibleIndividuals)
to return that Component.  But that means that everywhere that I want to
get
a handle to the RI Panel, I need to use that string.  Is that really the
only/best way to do it?  I suppose I could extract that string into a
constant at the Page level so that at least I am not propagating a raw
string, but it is still just a plain old string, then why not store a ref
to
the component at the page level?  There could be many such refreshers
that
listener Components register with.

Chuck
--
View this message in context:
http://www.nabble.com/find-a-%22cousin%22-Component-tf3401959.html#a9473809
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0


C as wel.


On 3/10/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


 a) focus on stabilizing 1.3 first, meanwhile keep supporting 2.0
 (though only for bugfixes). 1.4 will be the release with backports of
 the currently missing 2.0 features, and 1.5 will be 1.4 + the Java 5
 features (including generics).

 b) as a) but rather than developing 1.3 up to a final release, freeze
 asap (only fix bugs) and start on 1.4

 c) put all backports except for the Java 5 features in 1.3 after the
 beta1 release (which we agreed upon doing this weekend). 1.4 will be
 for the Java 5 features, and the branch should be started as soon as
 1.3 is feature complete.

I feel very strongly about choosing c).

Imo, a) takes too long for the people currently working on 2.0
(including myself for Wicket In Action). We basically tell them to
hold their breath until we are ready for it, which in fact punishes
them twice for being early adaptors (who I think we should value
especially giving the type of framework Wicket is).

I think b) would be good if it worked. However, I don't believe it
will. We have been annoyingly slow in putting out releases this year.
Sure there have been lots of reasons for it, but the fact remains that
even though we plan to move fast with releases, we never actually
do[1]. And with all the best intentions, I have absolutely not doubt
that if we follow b), it'll be months up to a year before we reach
1.5.

So for me c) is the best package. We'll have the pain (of which I
doubt the intensity for most people, but let's play with Johan's
branch for that) now, which probably sucks, but it is the quickest way
to get things really stable. We will have implemented all the API
changes we have been thinking about the last 1.5 years, and 1.3 will
be a release that'll be good for a long time. We'll have a separate
branch for Java 5 stuff with 1.4, but as long as we want to support
Java 1.4, we'll have that anyway. The code should be largely the same
except for the generified components and models and some 1.5
constructs. Compared to maintaining the current 2.0 and 1.3, that
should be a piece of cake. A final argument for c) is that it just
pushes us to get it over with.

My 2c,

Eelco


[1]
http://www.nabble.com/remove-add%28%29-and-pass-parent-in-constructor--tf929620.html
The interesting thing there is that even back then there was
discussion on whether to break early or not. I think in hind-sight we
can say that it was a bad decision we didn't do it right away, which
makes my opinion about c) even stronger. We might have been 'stuck'
with the new constructor forever you may argue, but otoh, we might
have found out it wasn't gonna work earlier.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

1.4 will be java5 (when C is done first)
That we can do pretty quickly.
(not direclty releasing it but usable for people who want 1.3 + java5)

johan

On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:

Can anyone vote?

I vote for alternative D.

You asked about reverting the constructor change or not. My
interpretation of the answers you got is: Yes, fine, what ever, but give
us generics (for models at least).

Alternative D is: Revert to working on 1 branch (doesn't matter if it's
called 1.3 or 2.0) and make moving to Java5 (adding Generics) top
priority.

/Anders

Eelco Hillenius wrote:
Hi,

b) as a) but rather than developing 1.3 up to a final release, freeze
asap (only fix bugs) and start on 1.4

Cheers,

Eelco

[1]
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9350505

http://www.nabble.com/Re%3A-IMPORTANT%3A-your-opinion-on-the-constructor-tf3359229.html#a9344068
[2] http://www.nabble.com/State-1.3--features-tf3376983.html
[3]
http://www.nabble.com/VOTE%3A-backporting-wicket-2.0-model-change-to-1.3-tf3364601.html
http://www.nabble.com/roadmap-tf3366743.html

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] AbstractBehavior or AjaxFormSubmitBehavior exception handling

2007-03-14 Thread Apaar Trivedi

Hey guys, 

 

When I have an exception (in this case a NullPointerException) occur
during the onSubmit of an AjaxFormSubmitBehavior, neither onException or
onError is being called.  Why is that?  I thought these methods existed
specifically to catch these types of problems?

 

Thanks

Par

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] How to attach thread

2007-03-14 Thread Thomas Küchenthal

Dear all,

within my Wicket application I'm using a self build process framework. I
klick on a wicket button and a process starts running in an own thread.
I want the process thread to take over the control of the wicket thread
to e.g. build the gui, or change the current model of a component etc...
(Actually I'm using the wizard component and want to combine/synchronize
my own process steps with the wizard steps)

But for now I receive this error message:

caused by: wicket.WicketRuntimeException: there is no session attached
to current thread Thread-51
at wicket.Session.get(Session.java:210)
at wicket.Page.dirty(Page.java:338)
at wicket.Page.componentStateChanging(Page.java:956)
at wicket.Component.addStateChange(Component.java:2347)



How can I attach the process thread to the wicket thread?

Thanks in advance

/thomas

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Converters


please look at the converters that are now in 1.3. those are much simpler
and you should be able to do what you want pretty quickly

in 1.2.x it is also possible. But it is a bit harder
Because if you want BigDecimals support for both ways you have to make 2
and then register one for String-BigDecimals (in the StringConverter i
believe)
and BigDecimals-String

johan


On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:


Hi,

I use Wicket 1.2.5 and have been looking at Converters (IConverter 
ITypeConverter).

The problem I want to solve is formatting my BigDecimals correctly.

Can't understand why this should be so complicated. Why have converters
at all? Java already has java.text.Format with the methods:

Object parseObject(String source)
String format (Object obj)

What more do we need? (Maybe generics...)


How do I get rid of 0E-9 when using Wicket 1.2.5 and Java 1.5? Why
isn't this - whatever the solution is - the default behavior of Wicket?


/Anders


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] How to attach thread


First of all you shouldn't really access the session in another thread.
Because that is not really supported by a webcontainer, especially in
clustering or persistent storage..

So if you want to spawn to a thread you should only really do backend logic,
not gui logic things.

If you really want then you could look at Session.set/get and
Application.set/get

johan


On 3/14/07, Thomas Küchenthal [EMAIL PROTECTED] wrote:


Dear all,

within my Wicket application I'm using a self build process framework. I
klick on a wicket button and a process starts running in an own thread.
I want the process thread to take over the control of the wicket thread
to e.g. build the gui, or change the current model of a component etc...
(Actually I'm using the wizard component and want to combine/synchronize
my own process steps with the wizard steps)

But for now I receive this error message:

caused by: wicket.WicketRuntimeException: there is no session attached
to current thread Thread-51
at wicket.Session.get(Session.java:210)
at wicket.Page.dirty(Page.java:338)
at wicket.Page.componentStateChanging(Page.java:956)
at wicket.Component.addStateChange(Component.java:2347)



How can I attach the process thread to the wicket thread?

Thanks in advance

/thomas

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] AbstractBehavior or AjaxFormSubmitBehavior exception handling


onexception where? onerror is called when a form validation error occurs.

-igor


On 3/14/07, Apaar Trivedi [EMAIL PROTECTED] wrote:


 Hey guys,



When I have an exception (in this case a NullPointerException) occur
during the onSubmit of an AjaxFormSubmitBehavior, neither onException or
onError is being called.  Why is that?  I thought these methods existed
specifically to catch these types of problems?



Thanks

Par



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Apache Con Amsterdam: wicket presence


Me Too.

Can we organize a BOF?

johan


On 3/14/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:


* Martijn Dashorst:

 Who is going to attend  Apache Con in Amsterdam? We are planning
 to host an  evening session, but we would like  to know how many
 would be interested/attend.

Me too.
--
 Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Apache Con Amsterdam: wicket presence

On 3/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
 Me Too.

 Can we organize a BOF?

That is the idea, or just go and drink ourselves a hangover!

Martijn

 On 3/14/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
  * Martijn Dashorst:
 
   Who is going to attend  Apache Con in Amsterdam? We are planning
   to host an  evening session, but we would like  to know how many
   would be interested/attend.
 
  Me too.
  --
   Jean-Baptiste Quenot
  aka  John Banana   Qwerty
  http://caraldi.com/jbq/
 
 
 -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
  opinions on IT  business topics through brief surveys-and earn cash
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Apache Con Amsterdam: wicket presence

2007-03-14 Thread Alexandru Popescu

On 3/14/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
 On 3/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
  Me Too.
 
  Can we organize a BOF?

 That is the idea, or just go and drink ourselves a hangover!


As always I am in for this last proposal ;-).

./alex
--
.w( the_mindstorm )p.

 Martijn

  On 3/14/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
   * Martijn Dashorst:
  
Who is going to attend  Apache Con in Amsterdam? We are planning
to host an  evening session, but we would like  to know how many
would be interested/attend.
  
   Me too.
   --
Jean-Baptiste Quenot
   aka  John Banana   Qwerty
   http://caraldi.com/jbq/
  
  
  -
   Take Surveys. Earn Cash. Influence the Future of IT
   Join SourceForge.net's Techsay panel and you'll get the chance to share
  your
   opinions on IT  business topics through brief surveys-and earn cash
  
  http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
 
 
  -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share your
  opinions on IT  business topics through brief surveys-and earn cash
  http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 


 --
 Learn Wicket at ApacheCon Europe: http://apachecon.com
 Join the wicket community at irc.freenode.net: ##wicket
 Wicket 1.2.5 will keep your server alive. Download Wicket now!
 http://wicketframework.org

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] AbstractBehavior or AjaxFormSubmitBehaviorexception handling

2007-03-14 Thread Apaar Trivedi

Something like the following code:

 

Button searchButton = new Button(searchButton, new
StringResourceModel(searchButton, this, null));

searchButton.add(new MyAjaxFormSubmitBehaviorWithIndicator(form,
onclick) {

 

protected void onError(AjaxRequestTarget arg0) {

super.onError(arg0);

}



public void onException(Component target, RuntimeException
e) {  -- Does not get called

super.onException(target, e);

}

 

protected void onSubmit(AjaxRequestTarget target) {


Collection ldapUsers = getUsersOrGroupsFromLdap() --
causes a null pointer exception 

target.addComponent(this);

}

}

 

So in the following code, AbstractBehavior.onException does not get
called, and it is also not being handled by
RequestCycle.onRuntimException, since I have overridden that to catch
run time exceptions already, I know it is not being called.  This is
making it rather difficult to implement ajax error handling for this
situation.

 

Alternatively, I have a similar piece of code where I explicitly do a
'throw new MyRuntimeException()', and this DOES get handled by
RequestCycle.onRuntimeException.

 

Any ideas?

 

Thanks

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Igor
Vaynberg
Sent: Wednesday, March 14, 2007 11:05 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] AbstractBehavior or
AjaxFormSubmitBehaviorexception handling

 

onexception where? onerror is called when a form validation error
occurs.

-igor



On 3/14/07, Apaar Trivedi  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]  wrote:

Hey guys, 

 

When I have an exception (in this case a NullPointerException) occur
during the onSubmit of an AjaxFormSubmitBehavior, neither onException or
onError is being called.  Why is that?  I thought these methods existed
specifically to catch these types of problems?

 

Thanks

Par

 



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your 
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user 

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

Is the feature set for 1.3 set? I vote to remove everything that may
delay the release of that version.

With alternative C; when would you estimate 1.4 (Java5) could be released?

/Anders

Johan Compagner wrote:
1.4 will be java5 (when C is done first)
That we can do pretty quickly.
(not direclty releasing it but usable for people who want 1.3 + java5)

johan

On 3/14/07, * Anders Peterson* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:

Can anyone vote?

I vote for alternative D.

You asked about reverting the constructor change or not. My
interpretation of the answers you got is: Yes, fine, what ever, but give
us generics (for models at least).

Alternative D is: Revert to working on 1 branch (doesn't matter if it's
called 1.3 or 2.0) and make moving to Java5 (adding Generics) top
priority.

/Anders

Eelco Hillenius wrote:
Hi,

It looks like the discussion around reverting the constructor change
that we did for 2.0 has cooled down. This email is not a vote
yet, but
a summary of opinions so far[1]. Those of you Wicket committers who
didn't have your say yet (Juergen, Frank, Gwyn, Janne, Jan, Ate), I
consider that an OK for reverting. If not, please reply to the
thread.
Juergen, you have been working on 2.0 quite a bit. Can you please
state your opinion, and can you tell us whether there are more
functional differences between 1.3 and 2.0 other than the constructor
change, Java 5 features, the attach/ detach change and improved
models
and validators?[2]

I think so far we can safely say reverting is supported broadly. At
least, of the people who reacted, most stated they actually preferred
add over the new constructor, and those who were either neutral
or had
a slight preference for the new constructor would still support
reverting as that would keep the momentum for the project going.

So, it looks like this may happen. But we'll vote about that in a
few
days. Before we do that, we have to reach consensus on the package
we'll vote on. We have some different - and strong - opinions[3]
so we
need to find a way to bridge that. Here are what I think the
different
opinions:

b) as a) but rather than developing 1.3 up to a final release, freeze
asap (only fix bugs) and start on 1.4

Cheers,

Eelco

[1]

http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9350505

http://www.nabble.com/Re%3A-IMPORTANT%3A-your-opinion-on-the-constructor-tf3359229.html#a9344068
[2] http://www.nabble.com/State-1.3--features-tf3376983.html
[3]

http://www.nabble.com/VOTE%3A-backporting-wicket-2.0-model-change-to-1.3-tf3364601.html
http://www.nabble.com/roadmap-tf3366743.html

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list

Re: [Wicket-user] AbstractBehavior or AjaxFormSubmitBehaviorexception handling


ok

onexception is for exceptions that occur during form processing. in
onsubmit() you are responsible to process your own exceptions since that is
your own handler code

-igor


On 3/14/07, Apaar Trivedi [EMAIL PROTECTED] wrote:


 Something like the following code:



Button searchButton = *new* Button(searchButton, 
*new*StringResourceModel(
searchButton, *this*, *null*));

searchButton.add(*new* MyAjaxFormSubmitBehaviorWithIndicator(form,
onclick) {



*protected* *void* onError(AjaxRequestTarget arg0) {

*super*.onError(arg0);

}



*public* *void* onException(Component target, RuntimeException
e) {  ß Does not get called

*super*.onException(target, e);

}



*protected* *void* onSubmit(AjaxRequestTarget target)
{

Collection ldapUsers = getUsersOrGroupsFromLdap() ß causes
a null pointer exception

target.addComponent(*this*);

}

}



So in the following code, AbstractBehavior.onException does not get
called, and it is also not being handled by RequestCycle.onRuntimException,
since I have overridden that to catch run time exceptions already, I know it
is not being called.  This is making it rather difficult to implement ajax
error handling for this situation.



Alternatively, I have a similar piece of code where I explicitly do a
'throw new MyRuntimeException()', and this DOES get handled by
RequestCycle.onRuntimeException.



Any ideas?



Thanks


 --

*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Igor Vaynberg
*Sent:* Wednesday, March 14, 2007 11:05 AM
*To:* wicket-user@lists.sourceforge.net
*Subject:* Re: [Wicket-user] AbstractBehavior or
AjaxFormSubmitBehaviorexception handling



onexception where? onerror is called when a form validation error occurs.

-igor

 On 3/14/07, *Apaar Trivedi*  [EMAIL PROTECTED] wrote:

Hey guys,



When I have an exception (in this case a NullPointerException) occur
during the onSubmit of an AjaxFormSubmitBehavior, neither onException or
onError is being called.  Why is that?  I thought these methods existed
specifically to catch these types of problems?



Thanks

Par




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

no there is a discussion about that.

1.3 feature set would be a merge between 2.0 and 1.3 when we drop 2.0

And no releasing it quickly will not mean that we will release a java5
version quickly
because that will mean we will again have multiply branches to support.

johan

On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:

Is the feature set for 1.3 set? I vote to remove everything that may
delay the release of that version.

With alternative C; when would you estimate 1.4 (Java5) could be released?

/Anders

Johan Compagner wrote:
1.4 will be java5 (when C is done first)
That we can do pretty quickly.
(not direclty releasing it but usable for people who want 1.3 + java5)

johan

On 3/14/07, * Anders Peterson* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:

Can anyone vote?

I vote for alternative D.

You asked about reverting the constructor change or not. My
interpretation of the answers you got is: Yes, fine, what ever, but
give
us generics (for models at least).

Alternative D is: Revert to working on 1 branch (doesn't matter if
it's
called 1.3 or 2.0) and make moving to Java5 (adding Generics) top
priority.

/Anders

Eelco Hillenius wrote:
Hi,

It looks like the discussion around reverting the constructor
change
that we did for 2.0 has cooled down. This email is not a vote
yet, but
a summary of opinions so far[1]. Those of you Wicket committers
who
didn't have your say yet (Juergen, Frank, Gwyn, Janne, Jan, Ate),
I
consider that an OK for reverting. If not, please reply to the
thread.
Juergen, you have been working on 2.0 quite a bit. Can you please
state your opinion, and can you tell us whether there are more
functional differences between 1.3 and 2.0 other than the
constructor
change, Java 5 features, the attach/ detach change and improved
models
and validators?[2]

I think so far we can safely say reverting is supported broadly.
At
least, of the people who reacted, most stated they actually
preferred
add over the new constructor, and those who were either neutral
or had
a slight preference for the new constructor would still support
reverting as that would keep the momentum for the project going.

So, it looks like this may happen. But we'll vote about that in a
few
days. Before we do that, we have to reach consensus on the
package
we'll vote on. We have some different - and strong - opinions[3]
so we
need to find a way to bridge that. Here are what I think the
different
opinions:

a) focus on stabilizing 1.3 first, meanwhile keep supporting 2.0
(though only for bugfixes). 1.4 will be the release with
backports of
the currently missing 2.0 features, and 1.5 will be 1.4 + the
Java 5
features (including generics).

b) as a) but rather than developing 1.3 up to a final release,
freeze
asap (only fix bugs) and start on 1.4

c) put all backports except for the Java 5 features in 1.3 after
the
beta1 release (which we agreed upon doing this weekend). 1.4 will
be
for the Java 5 features, and the branch should be started as soon
as
1.3 is feature complete.

Maybe the most constructive way to gather opinions here is to
first
let people plainly state what they prefer before we enter
discussion
mode. So, please state what package you think is the best idea
(or
introduce d if you want), and why.

Cheers,

Eelco

[1]

http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9350505

http://www.nabble.com/Re%3A-IMPORTANT%3A-your-opinion-on-the-constructor-tf3359229.html#a9344068
[2] http://www.nabble.com/State-1.3--features-tf3376983.html
[3]

http://www.nabble.com/VOTE%3A-backporting-wicket-2.0-model-change-to-1.3-tf3364601.html
http://www.nabble.com/roadmap-tf3366743.html

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys-and earn
cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief

Re: [Wicket-user] AbstractBehavior or AjaxFormSubmitBehavior exception handling

2007-03-14 Thread Nathan Hamblen

Is it this?

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

Apaar Trivedi wrote:
 Hey guys,
 
  
 
 When I have an exception (in this case a NullPointerException) occur 
 during the onSubmit of an AjaxFormSubmitBehavior, neither onException or 
 onError is being called.  Why is that?  I thought these methods existed 
 specifically to catch these types of problems?
 
  
 
 Thanks
 
 Par
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Converters

 Why have converters at all?

Because dates and numbers and possibly other things should
transparently be presented and parsed in a locale aware fashion.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] find a cousin Component


Yeah, that's what I thought you were going to say.

What I ended up doing was to make two complimentary methods

// keep a registry of Components that are event sources (stored as Map on
the Page)
registerAsEventSource(String sourceName, Component source)  

// keep a registry of event targets (stored in the source Component
MetaData)
registerAsRefreshTarget(Component target, Component source)  
registerAsRefreshTarget(Component target, String sourceName)  // lookup
source from eventRegistry

Then, I can either reference the Component itself or the sourceName in the
eventRegistry.  The Page acts as the middleman in that case.

Chuck


igor.vaynberg wrote:
 
 you could keep component instances as fields so you can reference them
 directly instead of getting them via their path
 
 -igor
 
 
 On 3/14/07, ChuckDeal [EMAIL PROTECTED] wrote:


 This feels like something someone would have asked before, but I couldn't
 find any relevant answers.

 I have a usecase where my page/components have role-based security;
 ENABLE/RENDER actions are dynamic as opposed to static based upon the
 user/data on the page.  When data on the page changes that could affect
 another field, I want to refresh the other field so that it's
 ENABLE/RENDER
 function can be re-evaluated.

 In my specific example, a field in one Panel is enabled ONLY when you are
 in
 the List of Responsible Individuals (a field on a different Panel).  If
 that
 list of RIs change, I want to immediately refresh (via AJAX) the other
 (dependent) field.

 I am working towards a Listerner(?) pattern whereby a Component registers
 itself with another Component to be refreshed.  In order for that to
 work,
 I
 need to geta handle to the other Component and the only way I know to do
 that is by calling get from a common parent.  Other ways?

 Given this hierarchy, I want to register OtherMdays to be refreshed when
 ResponsibleIndividuals changes (ResponsibleIndividuals panel is
 responsible
 for knowing when to refresh it's listeners).

 content (Panel)
   + form
 + headerSection (Panel)
   + collapsibleBody (WebMarkupContainer)
 + sections (RepeatingView)
   + header (Panel)
 + responsibleIndividuals (Panel)
 (other textfields, etc)
 + romEvents (RepeatingView)
   + baseEvent (Panel)
 + collapsibleBody (WebMarkupContainer)
   + sections (RepeatingView)
 + event (Panel)
   + rates (Panel)
 OtherMdays (TextField)
 (other textfields, etc)
   + signatures (Panel)

 So, the name of the RI Panel (relative to form) is
 headerSection:collapsibleBody:sections:header:responsibleIndividuals.

 Therefore, I can do
 form.get
 (headerSection:collapsibleBody:sections:header:responsibleIndividuals)
 to return that Component.  But that means that everywhere that I want to
 get
 a handle to the RI Panel, I need to use that string.  Is that really the
 only/best way to do it?  I suppose I could extract that string into a
 constant at the Page level so that at least I am not propagating a raw
 string, but it is still just a plain old string, then why not store a ref
 to
 the component at the page level?  There could be many such refreshers
 that
 listener Components register with.

 Chuck
 --
 View this message in context:
 http://www.nabble.com/find-a-%22cousin%22-Component-tf3401959.html#a9473809
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user

 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

-- 
View this message in context: 
http://www.nabble.com/find-a-%22cousin%22-Component-tf3401959.html#a9478053
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash

Re: [Wicket-user] Reverting the constructor change of 2.0

 1.3 feature set would be a merge between 2.0 and 1.3 when we drop 2.0

 And no releasing it quickly will not mean that we will release a java5
 version quickly
 because that will mean we will again have multiply branches to support.

It would be my idea to follow up with a Java 5 version asap though.
Which is the reason why I'm arguing for folding in the 'missing' ports
in 1.3 soon, so that we would at least have that out of the way and
only have two branches which are pretty close to each other. But as
long as we plan to support JDK 1.4, we have to have two branches I'm
afraid.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] AbstractBehavior or AjaxFormSubmitBehaviorexception handling

2007-03-14 Thread dukejansen


I can understand why onException might only be used for internal exceptions
in processing, but shouldn't the exception at least escalate back up to
RequestCycle.onRuntimeException and be handled there?

Otherwise, are we expected to always catch any possible Throwable in our
onSubmit if we want to be able to handle it server side? Seems a bit wonky
to not be able to rely on standard exception handling for this sort of
thing


igor.vaynberg wrote:
 
 ok
 
 onexception is for exceptions that occur during form processing. in
 onsubmit() you are responsible to process your own exceptions since that
 is
 your own handler code
 
 -igor
 
 
 On 3/14/07, Apaar Trivedi [EMAIL PROTECTED] wrote:

  Something like the following code:



 Button searchButton = *new* Button(searchButton,
 *new*StringResourceModel(
 searchButton, *this*, *null*));

 searchButton.add(*new*
 MyAjaxFormSubmitBehaviorWithIndicator(form,
 onclick) {



 *protected* *void* onError(AjaxRequestTarget arg0) {

 *super*.onError(arg0);

 }



 *public* *void* onException(Component target,
 RuntimeException
 e) {  ß Does not get called

 *super*.onException(target, e);

 }



 *protected* *void* onSubmit(AjaxRequestTarget target)
 {

 Collection ldapUsers = getUsersOrGroupsFromLdap() ß
 causes
 a null pointer exception

 target.addComponent(*this*);

 }

 }



 So in the following code, AbstractBehavior.onException does not get
 called, and it is also not being handled by
 RequestCycle.onRuntimException,
 since I have overridden that to catch run time exceptions already, I know
 it
 is not being called.  This is making it rather difficult to implement
 ajax
 error handling for this situation.



 Alternatively, I have a similar piece of code where I explicitly do a
 'throw new MyRuntimeException()', and this DOES get handled by
 RequestCycle.onRuntimeException.



 Any ideas?



 Thanks


  --

 *From:* [EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED] *On Behalf Of *Igor Vaynberg
 *Sent:* Wednesday, March 14, 2007 11:05 AM
 *To:* wicket-user@lists.sourceforge.net
 *Subject:* Re: [Wicket-user] AbstractBehavior or
 AjaxFormSubmitBehaviorexception handling



 onexception where? onerror is called when a form validation error occurs.

 -igor

  On 3/14/07, *Apaar Trivedi*  [EMAIL PROTECTED] wrote:

 Hey guys,



 When I have an exception (in this case a NullPointerException) occur
 during the onSubmit of an AjaxFormSubmitBehavior, neither onException or
 onError is being called.  Why is that?  I thought these methods existed
 specifically to catch these types of problems?



 Thanks

 Par




 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

-- 
View this message in context: 
http://www.nabble.com/AbstractBehavior-or-AjaxFormSubmitBehavior-exception-handling-tf3402992.html#a9478323
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net

Re: [Wicket-user] Converters

 From reading old posts I know that the converters have been improved 
for 1.3/2.0 but I'm doing my best to stay away from beta versions.

I have built two new ITypeConverters, a new IConverter and a new 
IConverterFactory and ... it kind of works. Strangely I don't see the 
correct format everywhere.

One of my questions remain: Why does Wicket need converters at all? Java 
already has java.text.Format with two-way conversion between String and 
some other class.

/Anders

Johan Compagner wrote:
 please look at the converters that are now in 1.3. those are much simpler
 and you should be able to do what you want pretty quickly
 
 in 1.2.x it is also possible. But it is a bit harder
 Because if you want BigDecimals support for both ways you have to make 2
 and then register one for String-BigDecimals (in the StringConverter i 
 believe)
 and BigDecimals-String
 
 johan
 
 
 On 3/14/07, *Anders Peterson * [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:
 
 Hi,
 
 I use Wicket 1.2.5 and have been looking at Converters (IConverter 
 ITypeConverter).
 
 The problem I want to solve is formatting my BigDecimals correctly.
 
 Can't understand why this should be so complicated. Why have converters
 at all? Java already has java.text.Format with the methods:
 
 Object parseObject(String source)
 String format (Object obj)
 
 What more do we need? (Maybe generics...)
 
 
 How do I get rid of 0E-9 when using Wicket 1.2.5 and Java 1.5? Why
 isn't this - whatever the solution is - the default behavior of Wicket?
 
 
 /Anders
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
 share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Converters

On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
 One of my questions remain: Why does Wicket need converters at all? Java
 already has java.text.Format with two-way conversion between String and
 some other class.

But they assume the VM's locale, not the locale of the request/session/user.

Martijn

-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

Do you plan to still release new features for old Java after you've 
released a Java5 version? That seems crazy.

Make one last release for JDK 1.4 and after that it's bug fixing only. 
All new development should target Java5. Wicket should have moved to 
Java5 at least one year ago!

/Anders

Eelco Hillenius wrote:
 1.3 feature set would be a merge between 2.0 and 1.3 when we drop 2.0

 And no releasing it quickly will not mean that we will release a java5
 version quickly
 because that will mean we will again have multiply branches to support.
 
 It would be my idea to follow up with a Java 5 version asap though.
 Which is the reason why I'm arguing for folding in the 'missing' ports
 in 1.3 soon, so that we would at least have that out of the way and
 only have two branches which are pretty close to each other. But as
 long as we plan to support JDK 1.4, we have to have two branches I'm
 afraid.
 
 Eelco
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
 Do you plan to still release new features for old Java after you've
 released a Java5 version? That seems crazy.

 Make one last release for JDK 1.4 and after that it's bug fixing only.
 All new development should target Java5. Wicket should have moved to
 Java5 at least one year ago!

We did actually with Wicket 2.0 which started over a year ago. But we
haven't gotten around to releasing for many reasons.

As for dropping  JDK 1.5 support: I think the committers would love
that, but it would bring a bunch of users in trouble I'm afraid. Maybe
we should have a poll about that.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Converters

No. You create them specifying which Locale to use. Look at the static 
factory methods in NumbverFormat.

http://java.sun.com/j2se/1.5.0/docs/api/java/text/NumberFormat.html

All Wicket would needs is a FormatFactory that reads the Locale from the 
request/session/user and instantiates correct Format instances.

/Anders

Martijn Dashorst wrote:
 On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
 One of my questions remain: Why does Wicket need converters at all? Java
 already has java.text.Format with two-way conversion between String and
 some other class.
 
 But they assume the VM's locale, not the locale of the request/session/user.
 
 Martijn
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Converters


and does that api support registering your own converters?

-igor


On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:


No. You create them specifying which Locale to use. Look at the static
factory methods in NumbverFormat.

http://java.sun.com/j2se/1.5.0/docs/api/java/text/NumberFormat.html

All Wicket would needs is a FormatFactory that reads the Locale from the
request/session/user and instantiates correct Format instances.

/Anders

Martijn Dashorst wrote:
 On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
 One of my questions remain: Why does Wicket need converters at all?
Java
 already has java.text.Format with two-way conversion between String and
 some other class.

 But they assume the VM's locale, not the locale of the
request/session/user.

 Martijn



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
 On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
  Make one last release for JDK 1.4 and after that it's bug fixing only.
  All new development should target Java5. Wicket should have moved to
  Java5 at least one year ago!

I beg to differ. Though I only use Java 1.5 on our internal projects,
I know several companies that require the use of Java 1.4, at least
for now. I would not have liked it when we lost those companies.

 As for dropping  JDK 1.5 support: I think the committers would love
 that, but it would bring a bunch of users in trouble I'm afraid. Maybe
 we should have a poll about that.

I think that is a good idea. I would welcome Wicket 1.3 to be the last
JDK 1.4 version. It is pretty much a vast improvement over 1.2 and
contains enough features to make 1.4 people happy for a long time I
think.

Maintaining Wicket 1.3 should be for bug fixes, not new features. But
that doesn't prevent new components to be developed, or backported by
our community if there is a need for JDK 1.4 components. And if you
really have a need, then you can always use retrotranslator/weaver to
backport 1.5 for your own pleasure.

Martijn
-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Converters

On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
 No. You create them specifying which Locale to use. Look at the static
 factory methods in NumbverFormat.

 http://java.sun.com/j2se/1.5.0/docs/api/java/text/NumberFormat.html

 All Wicket would needs is a FormatFactory that reads the Locale from the
 request/session/user and instantiates correct Format instances.

Conversions currently are transparent for components. Formatfactories
would either be too case specific, or they would grow into something
that converters are today.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

 Maintaining Wicket 1.3 should be for bug fixes, not new features. But
 that doesn't prevent new components to be developed, or backported by
 our community if there is a need for JDK 1.4 components. And if you
 really have a need, then you can always use retrotranslator/weaver to
 backport 1.5 for your own pleasure.

If that would be the consensus, we could consider skipping backporting
those last 2.0 features and just put them in 1.4 together with the JDK
5 features.

Who wants to write the poll?

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

1) I think you're overestimating the trouble that would cause. The only 
thing they're not getting is new features after the next release. In 
terms of new (major) releases no one has gotten anything for almost a year.

2) You also lose something by not moving to Java5... Wicket can be 
better with Java5. The fact that Wicket has not yet adopted Java5 means 
it is not as good as it could be.

Java5 is not just a minor upgrade. If anything ever should have been 
called Java2 it's Java 1.5/5.0 ;-)

/Anders

Eelco Hillenius wrote:
 On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
 Do you plan to still release new features for old Java after you've
 released a Java5 version? That seems crazy.

 Make one last release for JDK 1.4 and after that it's bug fixing only.
 All new development should target Java5. Wicket should have moved to
 Java5 at least one year ago!
 
 We did actually with Wicket 2.0 which started over a year ago. But we
 haven't gotten around to releasing for many reasons.
 
 As for dropping  JDK 1.5 support: I think the committers would love
 that, but it would bring a bunch of users in trouble I'm afraid. Maybe
 we should have a poll about that.
 
 Eelco
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0


isnt this thread a poll? how many polls of the same thing do we need? omfg
ponies!

-igor


On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


 Maintaining Wicket 1.3 should be for bug fixes, not new features. But
 that doesn't prevent new components to be developed, or backported by
 our community if there is a need for JDK 1.4 components. And if you
 really have a need, then you can always use retrotranslator/weaver to
 backport 1.5 for your own pleasure.

If that would be the consensus, we could consider skipping backporting
those last 2.0 features and just put them in 1.4 together with the JDK
5 features.

Who wants to write the poll?

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

This thread is about 'Reverting the constructor change of 2.0', not
about 'Stop supporting  JDK 1.5  after 1.3'.

Eelco

On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 isnt this thread a poll? how many polls of the same thing do we need? omfg
 ponies!

 -igor


 On 3/14/07, Eelco Hillenius  [EMAIL PROTECTED] wrote:
 
   Maintaining Wicket 1.3 should be for bug fixes, not new features. But
   that doesn't prevent new components to be developed, or backported by
   our community if there is a need for JDK 1.4 components. And if you
   really have a need, then you can always use retrotranslator/weaver to
   backport 1.5 for your own pleasure.
 
  If that would be the consensus, we could consider skipping backporting
  those last 2.0 features and just put them in 1.4 together with the JDK
  5 features.
 
  Who wants to write the poll?
 
  Eelco
 
 
 -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
  opinions on IT  business topics through brief surveys-and earn cash
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Converters

Not sure what you mean, but if you control the factory you control the 
formatters. /Anders

Igor Vaynberg wrote:
 and does that api support registering your own converters?
 
 -igor
 
 
 On 3/14/07, *Anders Peterson* [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:
 
 No. You create them specifying which Locale to use. Look at the static
 factory methods in NumbverFormat.
 
 http://java.sun.com/j2se/1.5.0/docs/api/java/text/NumberFormat.html
 
 All Wicket would needs is a FormatFactory that reads the Locale from
 the
 request/session/user and instantiates correct Format instances.
 
 /Anders
 
 Martijn Dashorst wrote:
   On 3/14/07, Anders Peterson [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
   One of my questions remain: Why does Wicket need converters at
 all? Java
   already has java.text.Format with two-way conversion between
 String and
   some other class.
  
   But they assume the VM's locale, not the locale of the
 request/session/user.
  
   Martijn
  
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
 share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0


well obviously we cannot poll for that until we have decided what 1.3 will
be. so first you need a poll on that, then you need a poll that depends on
that poll so we can decide when to drop support for 1.5. and then another
poll on the what to do next, but that poll has to depend on the previous two
polls. and while all these polls are going on no one is doing anything
because nothing is certain. do i commit to 2.0? naah, maybe into 1.3. but
wait i dont know if i can put this into 1.3 because a poll on that is still
going on. blah blah blah blah.

create a few variations of the roadmap. put them into a single poll. lets
poll, and vote on that and restore some sanity.

-igor


On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


This thread is about 'Reverting the constructor change of 2.0', not
about 'Stop supporting  JDK 1.5  after 1.3'.

Eelco

On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 isnt this thread a poll? how many polls of the same thing do we need?
omfg
 ponies!

 -igor


 On 3/14/07, Eelco Hillenius  [EMAIL PROTECTED] wrote:
 
   Maintaining Wicket 1.3 should be for bug fixes, not new features.
But
   that doesn't prevent new components to be developed, or backported
by
   our community if there is a need for JDK 1.4 components. And if you
   really have a need, then you can always use retrotranslator/weaver
to
   backport 1.5 for your own pleasure.
 
  If that would be the consensus, we could consider skipping backporting
  those last 2.0 features and just put them in 1.4 together with the JDK
  5 features.
 
  Who wants to write the poll?
 
  Eelco
 
 

-
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to
share
 your
  opinions on IT  business topics through brief surveys-and earn cash
 

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 



-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
your
 opinions on IT  business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] wicket-ajax.js


wicket-ajax.js (revision 518211) appears to have a problem.

I think lines 296-299 should be
var e = element.childNodes[i];
if (e.tagName != null) {
result += Wicket.Form.serialize(e);
}

but right now they are
var e = element.childNodes[i] {
if (e.tagName != null) {
result += Wicket.Form.serialize(e);
}
}

Chuck
-- 
View this message in context: 
http://www.nabble.com/wicket-ajax.js-tf3403817.html#a9479916
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

Don't poll too much - just decide on something. The core development 
team is relatively small isn't it... /Anders

Igor Vaynberg wrote:
 well obviously we cannot poll for that until we have decided what 1.3 
 will be. so first you need a poll on that, then you need a poll that 
 depends on that poll so we can decide when to drop support for 1.5. and 
 then another poll on the what to do next, but that poll has to depend on 
 the previous two polls. and while all these polls are going on no one is 
 doing anything because nothing is certain. do i commit to 2.0? naah, 
 maybe into 1.3. but wait i dont know if i can put this into 1.3 because 
 a poll on that is still going on. blah blah blah blah.
 
 create a few variations of the roadmap. put them into a single poll. 
 lets poll, and vote on that and restore some sanity.
 
 -igor
 
 
 On 3/14/07, *Eelco Hillenius* [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:
 
 This thread is about 'Reverting the constructor change of 2.0', not
 about 'Stop supporting  JDK 1.5  after 1.3'.
 
 Eelco
 
 On 3/14/07, Igor Vaynberg  [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
   isnt this thread a poll? how many polls of the same thing do we
 need? omfg
   ponies!
  
   -igor
  
  
   On 3/14/07, Eelco Hillenius  [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
   
 Maintaining Wicket 1.3 should be for bug fixes, not new
 features. But
 that doesn't prevent new components to be developed, or
 backported by
 our community if there is a need for JDK 1.4 components. And
 if you
 really have a need, then you can always use
 retrotranslator/weaver to
 backport 1.5 for your own pleasure.
   
If that would be the consensus, we could consider skipping
 backporting
those last 2.0 features and just put them in 1.4 together with
 the JDK
5 features.
   
Who wants to write the poll?
   
Eelco
   
   
  
 -
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance
 to share
   your
opinions on IT  business topics through brief surveys-and earn
 cash
   
  
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
  
  
  
 -
 
   Take Surveys. Earn Cash. Influence the Future of IT
   Join SourceForge.net's Techsay panel and you'll get the chance to
 share your
   opinions on IT  business topics through brief surveys-and earn cash
  
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
 https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
 share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash

Re: [Wicket-user] Reverting the constructor change of 2.0

On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 well obviously we cannot poll for that until we have decided what 1.3 will
 be. so first you need a poll on that, then you need a poll that depends on
 that poll so we can decide when to drop support for 1.5. and then another
 poll on the what to do next, but that poll has to depend on the previous two
 polls. and while all these polls are going on no one is doing anything
 because nothing is certain. do i commit to 2.0? naah, maybe into 1.3. but
 wait i dont know if i can put this into 1.3 because a poll on that is still
 going on. blah blah blah blah.

We are looking for consensus, and as we're doing that on the mailing
list, yes there will be a couple of bounces back and forth.

But I think we pretty much know all the options now. I've been
sticking my neck out with polls and proposals a couple of times now,
so Igor, why don't you write that next ultimate all-compassing vote
where we can decide on ditching the constructor refactor and when and
how?

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
 Don't poll too much - just decide on something. The core development
 team is relatively small isn't it... /Anders

But the user base isn't anymore.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0


i guess sacrasm and frustration dont transfer well over email :|

-igor


On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 well obviously we cannot poll for that until we have decided what 1.3will
 be. so first you need a poll on that, then you need a poll that depends
on
 that poll so we can decide when to drop support for 1.5. and then
another
 poll on the what to do next, but that poll has to depend on the previous
two
 polls. and while all these polls are going on no one is doing anything
 because nothing is certain. do i commit to 2.0? naah, maybe into 1.3.
but
 wait i dont know if i can put this into 1.3 because a poll on that is
still
 going on. blah blah blah blah.

We are looking for consensus, and as we're doing that on the mailing
list, yes there will be a couple of bounces back and forth.

But I think we pretty much know all the options now. I've been
sticking my neck out with polls and proposals a couple of times now,
so Igor, why don't you write that next ultimate all-compassing vote
where we can decide on ditching the constructor refactor and when and
how?

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

2007-03-14 Thread Marc-Andre Houle


From a user base standpoint, I am just waiting for core developer to decide

something...

On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
 Don't poll too much - just decide on something. The core development
 team is relatively small isn't it... /Anders

But the user base isn't anymore.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

I didn't mean that bad. I would just prefer someone else to do the next vote.

Eelco


On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 i guess sacrasm and frustration dont transfer well over email :|

 -igor


 On 3/14/07, Eelco Hillenius  [EMAIL PROTECTED] wrote:
 
  On 3/14/07, Igor Vaynberg  [EMAIL PROTECTED] wrote:
   well obviously we cannot poll for that until we have decided what 1.3
 will
   be. so first you need a poll on that, then you need a poll that depends
 on
   that poll so we can decide when to drop support for 1.5. and then
 another
   poll on the what to do next, but that poll has to depend on the previous
 two
   polls. and while all these polls are going on no one is doing anything
   because nothing is certain. do i commit to 2.0? naah, maybe into 1.3.
 but
   wait i dont know if i can put this into 1.3 because a poll on that is
 still
   going on. blah blah blah blah.
 
  We are looking for consensus, and as we're doing that on the mailing
  list, yes there will be a couple of bounces back and forth.
 
  But I think we pretty much know all the options now. I've been
  sticking my neck out with polls and proposals a couple of times now,
  so Igor, why don't you write that next ultimate all-compassing vote
  where we can decide on ditching the constructor refactor and when and
  how?
 
  Eelco
 
 
 -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
  opinions on IT  business topics through brief surveys-and earn cash
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] wicket-ajax.js

2007-03-14 Thread Matej Knopp

Actually, it should be fixed already. Can you please check if it works
as it should?

-Matej

On 3/14/07, Vincent Demay [EMAIL PROTECTED] wrote:
 Hi

 I do not see difference between you two ;) samples

 but maybe you was talking about that :
 https://issues.apache.org/jira/browse/WICKET-387.

 I think, it will be fixed soon.

 cheers

 --
 Vincent
 http://www.demay-fr.net/blog/

 ChuckDeal a écrit :
  wicket-ajax.js (revision 518211) appears to have a problem.
 
  I think lines 296-299 should be
  var e = element.childNodes[i];
  if (e.tagName != null) {
result += Wicket.Form.serialize(e);
  }
 
  but right now they are
  var e = element.childNodes[i] {
if (e.tagName != null) {
result += Wicket.Form.serialize(e);
}
  }
 
  Chuck
 


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

2007-03-14 Thread Harald Gruber


hi,

i came over from another framework to wicket because i didnt like the 
api change with every release there and liked the way wicket does things.

first i was not sure which version of wicket to use and read the mailing 
list and found out, that 2.0 suits best to me. after starting 2 bigger 
projects with 2.0 which have deadline in a few weeks, i would appreciate 
any (fast ;-)) decision of you regarding the future of 2.0 as for me it 
doesn't make sense to ride a dying horse and probably have to backport 
my 2.0 components to 1.3 (coz of the missing generics support and 
constructor change) and later in a few weeks port them to new 1.5 (or 
1.6/1.7...) to be up to date and use them in my next projects.

just my personal opinion,
cheers
h.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] When you have tabs and forms, is it ok to have the tabs all inside one form,

2007-03-14 Thread Thomas R. Corbin

On Tuesday, 13 March 2007 03:31 pm, Jean-Baptiste Quenot escreveu:
 * Igor Vaynberg:
  a better  option for these  situations imho is  to not to  use a
  serverside  tabpanel,  but  a  clientside  one.  that  way  your
  entire  form  is  written  out and  the  submit  button  submits
  the  entire  thing.  a  js  lib  like  this  makes  it  trivial:
  http://www.stilbuero.de/jquery/tabs/

 We have DojoTabContainer in Wicket Contrib Dojo that is
 client-side only.

 See an example at
 http://www.demay-fr.net:8080/Wicket-start/app?wicket:bookmarkablePage=:wick
et.contrib.dojo.examples.TabContainerSample

Wow - way cool!

Thanks!

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] wicket-ajax.js


Sorry, I should have been explicit about what I was pointing out.  The last
char of the first line (var e ...) should be a semicolon, not an open brace
as it is in the second snippet.

And yes, the reason why I even was looking was because of WICKET-387.  I
patched my code to fix it and will check tomorrow for an update from svn.

Chuck


Vincent Demay wrote:
 
 Hi
 
 I do not see difference between you two ;) samples
 
 but maybe you was talking about that : 
 https://issues.apache.org/jira/browse/WICKET-387.
 
 I think, it will be fixed soon.
 
 cheers
 
 --
 Vincent
 http://www.demay-fr.net/blog/
 
 ChuckDeal a écrit :
 wicket-ajax.js (revision 518211) appears to have a problem.

 I think lines 296-299 should be
 var e = element.childNodes[i];
 if (e.tagName != null) {
  result += Wicket.Form.serialize(e);
 }

 but right now they are
 var e = element.childNodes[i] {
  if (e.tagName != null) {
  result += Wicket.Form.serialize(e);
  }
 }

 Chuck
   
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
 your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

-- 
View this message in context: 
http://www.nabble.com/wicket-ajax.js-tf3403817.html#a9480665
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Reverting the constructor change of 2.0

 i came over from another framework to wicket because i didnt like the
 api change with every release there and liked the way wicket does things.

 first i was not sure which version of wicket to use and read the mailing
 list and found out, that 2.0 suits best to me. after starting 2 bigger
 projects with 2.0 which have deadline in a few weeks, i would appreciate
 any (fast ;-)) decision of you regarding the future of 2.0 as for me it
 doesn't make sense to ride a dying horse and probably have to backport
 my 2.0 components to 1.3 (coz of the missing generics support and
 constructor change) and later in a few weeks port them to new 1.5 (or
 1.6/1.7...) to be up to date and use them in my next projects.

As far as I am concerned, we could make a decision this week, and I
can reserve this weekend to work on porting and preparing and - though
it may take a while before we have actual releases - I hope we'll be
able to get something workable in SVN soon (like by next week).

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] wicket-ajax.js

2007-03-14 Thread Matej Knopp

heh, of course. sorry for that. i wonder how could i have missed that,
as i have tested script.

-Matej

On 3/14/07, ChuckDeal [EMAIL PROTECTED] wrote:

 Sorry, I should have been explicit about what I was pointing out.  The last
 char of the first line (var e ...) should be a semicolon, not an open brace
 as it is in the second snippet.

 And yes, the reason why I even was looking was because of WICKET-387.  I
 patched my code to fix it and will check tomorrow for an update from svn.

 Chuck


 Vincent Demay wrote:
 
  Hi
 
  I do not see difference between you two ;) samples
 
  but maybe you was talking about that :
  https://issues.apache.org/jira/browse/WICKET-387.
 
  I think, it will be fixed soon.
 
  cheers
 
  --
  Vincent
  http://www.demay-fr.net/blog/
 
  ChuckDeal a écrit :
  wicket-ajax.js (revision 518211) appears to have a problem.
 
  I think lines 296-299 should be
  var e = element.childNodes[i];
  if (e.tagName != null) {
   result += Wicket.Form.serialize(e);
  }
 
  but right now they are
  var e = element.childNodes[i] {
   if (e.tagName != null) {
   result += Wicket.Form.serialize(e);
   }
  }
 
  Chuck
 
 
 
  -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share
  your
  opinions on IT  business topics through brief surveys-and earn cash
  http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

 --
 View this message in context: 
 http://www.nabble.com/wicket-ajax.js-tf3403817.html#a9480665
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Build failure

2007-03-14 Thread Frank Bille


I finally got it!! Ok, two things:

First the pom file error. I'll commit a fix for the root pom without the
jdk15 profile. This was the one which caused problems with the second error.

The first error was because of some old versions of maven plugins. I didn't
find out what it exactly was (though I suspect maven-jar to be the sinner),
but a rm -rf ~/.m2/repository/org/apache took care of it.

So John there your solution.

Frank


On 3/14/07, Gwyn Evans  [EMAIL PROTECTED] wrote:


Double-check the top-level pom.xml? It should have
modulejdk-1.4/module
modulejdk-1.5/module
but your log doesn't seem to show it doing the jdk-1.4 module tree for
soem reason...

/Gwyn

On 14/03/07, Frank Bille  [EMAIL PROTECTED] wrote:
 I have upgraded to 2.0.5 and also updated to latest svn version of 1.3,
and
 I now get a different error:


http://www.nabble.com/Al%27s-repository-restructure-tf3386729.html#a9469179

 Frank



 On 3/13/07, John Patterson [EMAIL PROTECTED]  wrote:
  Strange, I just deleted the entire
 .m2/repository/org/apache/wicket/
  directory and checked out a fresh copy of http://svn.apache.org/repos/

  asf/incubator/wicket/branches/wicket- 1.x into a new
 directory,
  updated mvn to 2.0.5 (using darwin ports) and ran:
 
  mvn -Dmaven.test.skip=true  install
 
  But got the exact same error as before:
 
  Loading source file
 /Users/John/Development/wicket/current/wicket- 1.x/
 
 jdk-1.4/wicket-extensions/src/main/java/wicket/extensions/wizard/
  WizardModel.java...
  Loading source file
 /Users/John/Development/wicket/current/wicket-1.x/
 
 jdk-1.4/wicket-extensions/src/main/java/wicket/extensions/wizard/
  WizardStep.java...
  1 error
  [INFO]
 
 
  [ERROR] BUILD ERROR
  [INFO]
 
 
  [INFO] An error has occurred in JavaDocs report generation.
 
  Embedded error: Exit code: 1 - error: error reading /Users/John/
 
 Development/wicket/current/wicket-1.x/jdk-1.4/wicket/target/
  wicket-1.3.0-incubating-SNAPSHOT.jar ; invalid header
 field
 
  could it be a different javadoc binary that causes the different
  behaviour?
 
  My Mac OS X java version is reported as:
 
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164 )
 
  On 13 Mar 2007, at 14:40, Martijn Dashorst wrote:
 
   I just did a clean checkout of our 1.x branch, removed my local
   repository, and it 'just worked'.
  
   I do use maven 2.0.5 , perhaps that is the deciding factor?
  
   Martijn
  
   On 3/13/07, John Patterson [EMAIL PROTECTED] wrote:
   On 13 Mar 2007, at 12:31, Frank Bille wrote:
  
   I get the same error and have tried to remove local jar files.
I'll
   look into it tonight (can't get workspace setup using new al
   structure)
  
  
   Great, cheers.  Until then I have checked out the last revision
   before the restructuring.
  
  
 -
   
   Take Surveys. Earn Cash. Influence the Future of IT
   Join SourceForge.net's Techsay panel and you'll get the chance to
   share your
   opinions on IT  business topics through brief surveys-and earn
cash
   http://www.techsay.com/default.php?
   page=join.phpp=sourceforgeCID=DEVDEV
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
   --
   Learn Wicket at ApacheCon Europe: http://apachecon.com
   Join the wicket community at irc.freenode.net : ##wicket
   Wicket 1.2.5 will keep your server alive. Download Wicket now!
   http://wicketframework.org
  
  
 --
   ---
   Take Surveys. Earn Cash. Influence the Future of IT
   Join SourceForge.net's Techsay panel and you'll get the chance to
   share your
   opinions on IT  business topics through brief surveys-and earn cash

   http://www.techsay.com/default.php?
   page=join.phpp=sourceforgeCID=DEVDEV
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 

-
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to
share
 your
  opinions on IT  business topics through brief surveys-and earn cash
 

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 



-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
your

Re: [Wicket-user] Build failure


umm, we already found a solution for that

mvn eclipse:eclipse -U

which tells maven to update its dependencies

woops :)

-igor


On 3/14/07, Frank Bille [EMAIL PROTECTED] wrote:


I finally got it!! Ok, two things:

First the pom file error. I'll commit a fix for the root pom without the
jdk15 profile. This was the one which caused problems with the second error.

The first error was because of some old versions of maven plugins. I
didn't find out what it exactly was (though I suspect maven-jar to be the
sinner), but a rm -rf ~/.m2/repository/org/apache took care of it.

So John there your solution.

Frank


On 3/14/07, Gwyn Evans  [EMAIL PROTECTED] wrote:

 Double-check the top-level pom.xml? It should have
 modulejdk-1.4/module
 modulejdk-1.5/module
 but your log doesn't seem to show it doing the jdk-1.4 module tree for
 soem reason...

 /Gwyn

 On 14/03/07, Frank Bille  [EMAIL PROTECTED] wrote:
  I have upgraded to 2.0.5 and also updated to latest svn version of 1.3,
 and
  I now get a different error:
 
 
 http://www.nabble.com/Al%27s-repository-restructure-tf3386729.html#a9469179
 
  Frank
 
 
 
  On 3/13/07, John Patterson  [EMAIL PROTECTED]  wrote:
   Strange, I just deleted the entire
  .m2/repository/org/apache/wicket/
   directory and checked out a fresh copy of http://svn.apache.org/repos/

   asf/incubator/wicket/branches/wicket- 1.x into a new
  directory,
   updated mvn to 2.0.5 (using darwin ports) and ran:
  
   mvn -Dmaven.test.skip=true  install
  
   But got the exact same error as before:
  
   Loading source file
  /Users/John/Development/wicket/current/wicket- 1.x/
  
  jdk-1.4/wicket-extensions/src/main/java/wicket/extensions/wizard/
   WizardModel.java...
   Loading source file
  /Users/John/Development/wicket/current/wicket-1.x/
  
  jdk-1.4/wicket-extensions/src/main/java/wicket/extensions/wizard/
   WizardStep.java...
   1 error
   [INFO]
  
 
 
   [ERROR] BUILD ERROR
   [INFO]
  
 
 
   [INFO] An error has occurred in JavaDocs report generation.
  
   Embedded error: Exit code: 1 - error: error reading /Users/John/
  
  Development/wicket/current/wicket-1.x/jdk-1.4/wicket/target/
   wicket-1.3.0-incubating-SNAPSHOT.jar ; invalid header
  field
  
   could it be a different javadoc binary that causes the different
   behaviour?
  
   My Mac OS X java version is reported as:
  
   Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
  
   On 13 Mar 2007, at 14:40, Martijn Dashorst wrote:
  
I just did a clean checkout of our 1.x branch, removed my local
repository, and it 'just worked'.
   
I do use maven 2.0.5 , perhaps that is the deciding factor?
   
Martijn
   
On 3/13/07, John Patterson [EMAIL PROTECTED]  wrote:
On 13 Mar 2007, at 12:31, Frank Bille wrote:
   
I get the same error and have tried to remove local jar files.
 I'll
look into it tonight (can't get workspace setup using new al
structure)
   
   
Great, cheers.  Until then I have checked out the last revision
before the restructuring.
   
   
  -

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT  business topics through brief surveys-and earn
 cash
http://www.techsay.com/default.php?
page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
  https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net : ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
   
   
  --

---
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT  business topics through brief surveys-and earn
 cash
http://www.techsay.com/default.php?
page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
  https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
 
 -
   Take Surveys. Earn Cash. Influence the Future of IT
   Join SourceForge.net's Techsay panel and you'll get the chance to
 share
  your
   opinions on IT  business topics through brief surveys-and earn cash
  
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
   ___
   Wicket-user

Re: [Wicket-user] Build failure

2007-03-14 Thread Frank Bille


And why didn't anyone tell me that? We can't all be maven experts ;)

Frank

On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:


umm, we already found a solution for that

mvn eclipse:eclipse -U

which tells maven to update its dependencies

woops :)

-igor


On 3/14/07, Frank Bille [EMAIL PROTECTED] wrote:

 I finally got it!! Ok, two things:

 First the pom file error. I'll commit a fix for the root pom without the
 jdk15 profile. This was the one which caused problems with the second error.

 The first error was because of some old versions of maven plugins. I
 didn't find out what it exactly was (though I suspect maven-jar to be the
 sinner), but a rm -rf ~/.m2/repository/org/apache took care of it.

 So John there your solution.

 Frank


 On 3/14/07, Gwyn Evans  [EMAIL PROTECTED] wrote:
 
  Double-check the top-level pom.xml? It should have
  modulejdk-1.4/module
  modulejdk-1.5/module
  but your log doesn't seem to show it doing the jdk-1.4 module tree for
  soem reason...
 
  /Gwyn
 
  On 14/03/07, Frank Bille  [EMAIL PROTECTED] wrote:
   I have upgraded to 2.0.5 and also updated to latest svn version of
  1.3, and
   I now get a different error:
  
  
  http://www.nabble.com/Al%27s-repository-restructure-tf3386729.html#a9469179
  
   Frank
  
  
  
   On 3/13/07, John Patterson  [EMAIL PROTECTED]  wrote:
Strange, I just deleted the entire
   .m2/repository/org/apache/wicket/
directory and checked out a fresh copy of http://svn.apache.org/repos/
 
asf/incubator/wicket/branches/wicket- 1.x into a new
   directory,
updated mvn to 2.0.5 (using darwin ports) and ran:
   
mvn -Dmaven.test.skip=true  install
   
But got the exact same error as before:
   
Loading source file
   /Users/John/Development/wicket/current/wicket- 1.x/
   
   jdk-1.4/wicket-extensions/src/main/java/wicket/extensions/wizard/
WizardModel.java...
Loading source file
   /Users/John/Development/wicket/current/wicket-1.x/
   
   jdk-1.4/wicket-extensions/src/main/java/wicket/extensions/wizard/
WizardStep.java...
1 error
[INFO]
   
  
  
[ERROR] BUILD ERROR
[INFO]
   
  
  
[INFO] An error has occurred in JavaDocs report generation.
   
Embedded error: Exit code: 1 - error: error reading /Users/John/
   
   Development/wicket/current/wicket-1.x/jdk-1.4/wicket/target/
wicket-1.3.0-incubating-SNAPSHOT.jar ; invalid header
   field
   
could it be a different javadoc binary that causes the different
behaviour?
   
My Mac OS X java version is reported as:
   
Java(TM) 2 Runtime Environment, Standard Edition (build
  1.5.0_07-164 )
   
On 13 Mar 2007, at 14:40, Martijn Dashorst wrote:
   
 I just did a clean checkout of our 1.x branch, removed my local
 repository, and it 'just worked'.

 I do use maven 2.0.5 , perhaps that is the deciding factor?

 Martijn

 On 3/13/07, John Patterson [EMAIL PROTECTED]  wrote:
 On 13 Mar 2007, at 12:31, Frank Bille wrote:

 I get the same error and have tried to remove local jar files.
  I'll
 look into it tonight (can't get workspace setup using new al
 
 structure)


 Great, cheers.  Until then I have checked out the last revision
 before the restructuring.


  
  -
 
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance
  to
 share your
 opinions on IT  business topics through brief surveys-and earn
  cash
 http://www.techsay.com/default.php?
 page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net

   https://lists.sourceforge.net/lists/listinfo/wicket-user



 --
 Learn Wicket at ApacheCon Europe: http://apachecon.com
 Join the wicket community at irc.freenode.net : ##wicket
 Wicket 1.2.5 will keep your server alive. Download Wicket now!
 http://wicketframework.org


  
  --
 ---
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance
  to
 share your
 opinions on IT  business topics through brief surveys-and earn
  cash
 http://www.techsay.com/default.php?
 page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net

   https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
  
  -
Take Surveys. Earn Cash. Influence the Future of IT
Join

Re: [Wicket-user] Apache Con Amsterdam: wicket presence

2007-03-14 Thread Erik van Oosten

If you are off into the city, I'll join you.  Perhaps I can show you one 
or two locations as well.

 Erik.


Alexandru Popescu schreef:
 On 3/14/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
   
 That is the idea, or just go and drink ourselves a hangover!
 

 As always I am in for this last proposal ;-).


   

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


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Wicket's questions

2007-03-14 Thread Jonathan Locke



Serial version UID exists to prevent problems deserializing persistent 
serialized data, and since serialization is not being used for long-term
persistent storage in Wicket (unless you have some unusual project going,
sessions should not be persistent across class changes), I cannot see 
a need to generate serialversionuids for Wicket components.  I personally
just supress the warning.


ZedroS Schwart wrote:
 
 * serialVersionUID and anonymous inner classes
 
 Quite often in my code, I've got some warning due to non define
 serialVersionUID.
 
 I usually tell Eclipse to generate them for me.
 
 However, for the anonymous inner classes, which are quite commun, I'm
 not sure it's ok. Is it ?
 
 Furthermore, I'm wondering which risk I would take by using the
 @SuppressWarnings(serial) annotation. Do you have a clue ?
 

-- 
View this message in context: 
http://www.nabble.com/Wicket%27s-questions-tf3396173.html#a9484189
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Wicket's questions

I think some containers complain in certain cases if you don't have
them. Johan, what was the problem with not having those UIDs again?

Eelco

 Serial version UID exists to prevent problems deserializing persistent
 serialized data, and since serialization is not being used for long-term
 persistent storage in Wicket (unless you have some unusual project going,
 sessions should not be persistent across class changes), I cannot see
 a need to generate serialversionuids for Wicket components.  I personally
 just supress the warning.


 ZedroS Schwart wrote:
 
  * serialVersionUID and anonymous inner classes
 
  Quite often in my code, I've got some warning due to non define
  serialVersionUID.
 
  I usually tell Eclipse to generate them for me.
 
  However, for the anonymous inner classes, which are quite commun, I'm
  not sure it's ok. Is it ?
 
  Furthermore, I'm wondering which risk I would take by using the
  @SuppressWarnings(serial) annotation. Do you have a clue ?
 

 --
 View this message in context: 
 http://www.nabble.com/Wicket%27s-questions-tf3396173.html#a9484189
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Hibernate/Spring and Wicket architecture request for validation (was Wicket's questions)

2007-03-14 Thread ZedroS Schwart

Hi all

Among the questions I had, one of the core questions is the following
one : is the architecture I plan to use appropriate ? Just to give a
bit of insight, I'm new to Hibernate/Spring and Wicket (ouch !). lol
But I'm really motivated :) I would like to be sure I don't do huge
mistake in my architecture... since I'm not an expert it could be the
case :(

I took it mainly from a Spring book (not an english one though). For
Wicket I user Pro Wicket.

So, my architecture is the following :
For each domains of my application, I've a manager, like the
UserManager. The managers contain the access to the DAO Interfaces
(which are properly injected by Spring) and render  pure Pojo Model
for my databased data (like an User object for the user info).

Behind all t his stuff, the transaction manager is
org.springframework.orm.hibernate3.HibernateTransactionManager and the
sessionFactory is
org.springframework.orm.hibernate3.LocalSessionFactoryBean.


Using injection, I've put an instance of my userManager in my BasePage.

From it, where needed, I access the user info. For example, on login,
I call it to retrieve an user and put in my session.

For my pages, I use CompoundPropertyModel with the Pojo retrieve from
my managers (which are injected on demand excepted for the usermanager
which is always available as told before).

When I have to change an object on the OnSubmit, I use the update
methods from my managers. What I fear here is to update some data
which have already been updated in between.

Overall, I'm wondering whether my implentation is good enough and
how to avoid data collision.

What do you think of it ?

Thanks in advance
ZedroS

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Hibernate/Spring and Wicket architecture request for validation (was Wicket's questions)