RE: thanks you all for giving proper suggestions

2011-04-01 Thread Chris Colman
We haven't felt the need to use GWT with Wicket. Wicket has handled all
of our client side code very powerfully and efficiently- and we can do
all development and debugging in standard Java IDE's which means there's
none of the GWT object marshalling to write, debug and maintain.

What kind of client side stuff do you need GWT for that you can't do
with Wicket alone?

>-Original Message-
>From: hariharansrc [mailto:hariharan...@gmail.com]
>Sent: Saturday, 2 April 2011 4:17 PM
>To: users@wicket.apache.org
>Subject: Re:thanks you all for giving proper suggestions
>
>i want to know whether i can use gwt along with wicket
>so i can quite manage both server and client  side coding efficiently
>are there any tutorials to integrate gwt with wicket
>
>thank you in advance
>
>--
>View this message in context: http://apache-
>wicket.1842946.n4.nabble.com/how-to-call-javascript-function-on-form-
>submission-tp3408147p3421644.html
>Sent from the Users forum mailing list archive at Nabble.com.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


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



Re:thanks you all for giving proper suggestions

2011-04-01 Thread hariharansrc
i want to know whether i can use gwt along with wicket
so i can quite manage both server and client  side coding efficiently
are there any tutorials to integrate gwt with wicket

thank you in advance

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/how-to-call-javascript-function-on-form-submission-tp3408147p3421644.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread gnul
>> On 02 Apr 2011, at 00:13, Bruno Borges wrote:
>>
>> [    ] Please, check this box if you agree with EULA
>> [ x ] Please, uncheck this box if you don't want to receive notifications
>>
>>
>> In this case, I would set the first checkbox as required, and leave the
>> later as optional.
>>
>> Vote for (1) +1

>On Fri, Apr 1, 2011 at 5:01 PM, Maarten Billemont  wrote:
>
> Please don't pretend a checkbox is a Radio component.  This is irrelevant to 
> this discussion.
>

I don't see how radio choices could represent these options as
elegantly as checkboxes. It seems you would need four radio choices,
two for each selection, possibly each pair in a radio group.

With respect to the larger discussion, I don't think it matters. If
you wish to setRequired(true) on a checkbox, it means it must be
checked. If we're not allowed to setRequired(), then a validator can
require checked.

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



RE: [ANNOUNCE] Wicketopia 0.9 Released...

2011-04-01 Thread Chris Colman
>PersistenceProvider is an interface and the implementation class
>doesn't depend on Spring at all.  It's a pure hibernate DAO,
>essentially.  The example application is pieced together with Spring,
>since that's what I'm familiar with and it allows me to put something
>together with little effort by copy/pasting stuff from other projects
>that I know work.

We created and maintain the open source persistence abstraction framework 
called exPOJO (expojo.com) than can support any persistence technology under 
the hood upon which your application (or indeed other framework) can with be 
written with no direct reference to any specific framework (Hibernate, JDO, 
JPA). Currently JDO and Hibernate plugins are implementated but JPA could be 
easily accommodated via the same interface. It allows you to write applications 
where the UI and model need have no direct reference to any specific framework 
- keeping your app "persistence framework agnostic". Following Chris 
Richardon's 'Exposed domain model' pattern it works with repositories and 
service classes. It is only the repositories (collections of query methods) 
that need to be written in a specific persistence framework's query language. 
The rest of the app can remain blissfully independent and portable and usable 
by developers of any ORM persuasion.

The coincidence here is that we also have a class called PersistenceProvider 
which is the abstract interface that you write your app (or framework) to. 

>We get it, you don't like Spring. :)

He's not the only one!

In addition to 'abstracting' the persistence framework exPOJO provides an 
optional dependency injection mechanism which provides virtually automatic 
OpenSessionInView/OpenPersistenceManagerInView without needing the 
multimegabyte bloatware that Swing has become.

exPOJO is uber lightweight: a 35k jar, 30 minute learning curve etc., that is 
completely XML free and typesafe.

>
>> Also, does wicketopia depend on Spring?  That would be a really *really*
>big downside.  I don't need any frontend library telling me what
>persistence framework to use, and Spring is about much more than just
>persistence.  Abstract that stuff.
>>
>
>Again, no.  Take a look at the pom.xml files:
>
>https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/pom.xml
>https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/persistence
>/pom.xml
>https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/hibernate/p
>om.xml
>https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/jpa/pom.xml
>
>There are modules that depend on Spring (spring-security and
>domdrides), but you don't have to use them.
>
>> Perhaps when I can understand what Wicketopia is without having to UTSL,
>I'll consider giving it a try.  Assuming I don't also need to suffocate my
>code under the weight of Spring.
>>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


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



Re: Apache Wicket Cookbook Published!

2011-04-01 Thread shetc
Yippee! My book has arrived.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-Cookbook-Published-tp3406012p3421473.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: [Vote] New Wicket Version Numbering

2011-04-01 Thread Bruno Borges
Of course it is the best. It has no software error-prone... :-)

No GC problems, no heap calculations.

=)

Bruno Borges
www.brunoborges.com.br
+55 21 76727099

"The glory of great men should always be
measured by the means they have used to
acquire it."
 - Francois de La Rochefoucauld



On Fri, Apr 1, 2011 at 9:47 PM, Chris Colman
wrote:

> I poon you all with my Atari 7800!
>
> Ok, so it doesn't have a keyboard, let alone a JVM, but the version
> number is so much bigger - it just has to be the best!
>
> >-Original Message-
> >From: msj121 [mailto:msj...@gmail.com]
> >Sent: Saturday, 2 April 2011 8:56 AM
> >To: users@wicket.apache.org
> >Subject: Re: [Vote] New Wicket Version Numbering
> >
> >I mean XP is letters... That is pretty amazing, there isn't even a
> number,
> >and even roman numerals, is there a 'P' in roman numerals?
> >
> >--
> >View this message in context: http://apache-
> >wicket.1842946.n4.nabble.com/Vote-New-Wicket-Version-Numbering-
> >tp3420887p3421249.html
> >Sent from the Users forum mailing list archive at Nabble.com.
> >
> >-
> >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >For additional commands, e-mail: users-h...@wicket.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


RE: [Vote] New Wicket Version Numbering

2011-04-01 Thread Chris Colman
I poon you all with my Atari 7800!

Ok, so it doesn't have a keyboard, let alone a JVM, but the version
number is so much bigger - it just has to be the best!

>-Original Message-
>From: msj121 [mailto:msj...@gmail.com]
>Sent: Saturday, 2 April 2011 8:56 AM
>To: users@wicket.apache.org
>Subject: Re: [Vote] New Wicket Version Numbering
>
>I mean XP is letters... That is pretty amazing, there isn't even a
number,
>and even roman numerals, is there a 'P' in roman numerals?
>
>--
>View this message in context: http://apache-
>wicket.1842946.n4.nabble.com/Vote-New-Wicket-Version-Numbering-
>tp3420887p3421249.html
>Sent from the Users forum mailing list archive at Nabble.com.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Marek Šabo
I agree with Maarten, +1 for the second behaviour (2) and let validators 
do the rest.


--
Marek

On 04/01/2011 11:23 PM, Maarten Billemont wrote:

On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:


I would stick with 1 (required to be checked).

The main reason would be not to break compatibility with old versions.

Lame reason.  "Don't fix bugged behavior because old code relies on it."
All that got us is a renders-well-in-IE 6.0 web, which we only barely are 
struggling out of with the advent of Mozilla et al. who decided to do the right 
thing for a change.


I actually used .setRequired(true) on legal checkboxes (disclaimers) in one of our 
applications because if I have a "required checkbox" I expect it to be needed 
to be checked.

Get the context right.  "You are required to provide a value" is not the same as "You are 
required to provide this specific value".  The context of the term "required" in the 
setRequired method refers to the former, not the latter.  As Igor pointed out, the latter is accomplished 
with a validator.  setRequired has no business looking at what your value is, just whether or not one exists.

Changing that context for one component for whatever reason breaks the 
consistency and reliability of the API.


Although I will change that in our project now that I know such a change is 
being discussed, I wouldn't expect others to be that observant of the issue and 
have unit tests that prevent anything from breaking on a future upgrade.

I hope people test their web apps before they deploy a new release to 
production.  I'm sure they'll notice the change if they do.

I vote (2) +1, if it doesn't make sense to apply setRequired to a certain type 
of component because the HTML model simply does not permit it, giving 
setRequired a different meaning is not an acceptable alternative.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



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



Re: Anyone using wicket-velocity 1.4.16 on java 1.5?

2011-04-01 Thread Emmanouil Batsis




Quoting James Carman :


Quickstart?


Bear with me; are you asking for a minimal testcase based on the  
archetype or whether i'm actually using it (or something else)?


Cheers,

Manos

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



Re: Anyone using wicket-velocity 1.4.16 on java 1.5?

2011-04-01 Thread James Carman
Quickstart?
On Apr 1, 2011 7:57 PM, "Emmanouil Batsis"  wrote:
> Stuck on a win machine, but checked out my classpath, even deleted my
> maven repo .m2/repository/org/apache/wicket to verify what i'm seeing
> in my pom but no dice.
>
> I'm using 1.4.16 or wicket-xx including velocity. This code:
>
> // START SNIPPET, next line is 51
> VelocityPanel panel = new VelocityPanel("templatePanel", templateContext)
{
>
> @Override
> protected IStringResourceStream getTemplateResource() {
> return template;
> }
>
> @Override
> protected boolean parseGeneratedMarkup() {
> return true;
> }
> };
>
> // ENDSNIPPET
>
>
> results in the following error, although
> VelocityPanel.getMarkupResourceStream is supposed to be public and
> final:
>
>
> \src\main\java\foo\wicket\velocity\VelocityPage.java:[51,76]
> .wicket.velo
> city.VelocityPage$1> is not abstract and does not override abstract
> method
> getMarkupResourceStream(org.apache.wicket.MarkupContainer,java.lang.Class)
> in org.apache.wicket.markup.IMarkupResourceStreamProvider
>
> Any ideas?
>
> Manos
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>


Anyone using wicket-velocity 1.4.16 on java 1.5?

2011-04-01 Thread Emmanouil Batsis
Stuck on a win machine, but checked out my classpath, even deleted my  
maven repo .m2/repository/org/apache/wicket to verify what i'm seeing  
in my pom but no dice.


I'm using 1.4.16 or wicket-xx including velocity. This code:

// START SNIPPET, next line is 51
VelocityPanel panel = new VelocityPanel("templatePanel", templateContext) {

@Override
protected IStringResourceStream getTemplateResource() {
return template;
}

@Override
protected boolean parseGeneratedMarkup() {
return true;
}
};

// ENDSNIPPET


results in the following error, although  
VelocityPanel.getMarkupResourceStream is supposed to be public and  
final:



\src\main\java\foo\wicket\velocity\VelocityPage.java:[51,76]  
.wicket.velo
city.VelocityPage$1> is not abstract and does not override abstract  
method  
getMarkupResourceStream(org.apache.wicket.MarkupContainer,java.lang.Class)

 in org.apache.wicket.markup.IMarkupResourceStreamProvider

Any ideas?

Manos





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



Re: changing image on locale change

2011-04-01 Thread hrbaer
Thanks Igor.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/changing-image-on-locale-change-tp3421291p3421371.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: changing image on locale change

2011-04-01 Thread Igor Vaynberg
There is a locale pub example in wicket-examples that shows how to do it.

-igor
On Apr 1, 2011 3:21 PM, "hrbaer"  wrote:
> Hi all,
>
> is there any chance to change an image once the user choose another
> language?
> With a text it's very easy because the only thing you have to provide are
> the different language property files.
>
> Let's assume there is a dropdown with different languages. I've added
> DropDownChoices and implemented the onSelectionChanged method. If the user
> choose another option the only thing I have to do is to set the Locale to
> the choosen language.
>
> Is there a similar functionality for images?
>
> At the moment I've tried a little bit with this:
> --
> Image imageGerman = new Image( "someImage", new ResourceReference(
> Home.class, "images/logo.png" ) );
> Image imageUK = new Image( "someImage", new ResourceReference( Home.class,
> "images/logo2.png" ) );
> add( isLocaleGerman() ? imageGerman : imageUK );
> --
> But this is only working if the page constructor is called.
>
> Any ideas?
> Thanks in advance.
>
> --
> View this message in context:
http://apache-wicket.1842946.n4.nabble.com/changing-image-on-locale-change-tp3421291p3421291.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>


Re: ModalWindow detach/serialize crashes wicket app

2011-04-01 Thread Clint Checketts
Do you have a propetymodel with the session as its object?

On Friday, April 1, 2011, Pedro Santos  wrote:
> looks like your page is referencing session or pagemap somehow
>
> On Fri, Apr 1, 2011 at 4:15 PM, Russell Morrisey <
> russell.morri...@missionse.com> wrote:
>
>> Guys,
>>
>> I'm having an intermittent issue in development where use of a ModalWindow
>> on a page completely crashes wicket.
>>
>> I don't know of the ModalWindow is the root cause. I am hoping that someone
>> with intimate knowledge of wicket's page store can help me narrow it down.
>> Hints appreciated. =)
>>
>> The "X" button and other ajax controls within the ModalWindow's content
>> page stop responding to user input. When I try to hit the same bookmarkable
>> URL again for the containing page, wicket seems to have stopped running
>> entirely, and I get a Tomcat HTTP 404 error.
>>
>> The JVM outputs a StackOverflowError which looks like it happens during
>> page serialization.
>> Apr 1, 2011 2:53:14 PM org.apache.catalina.core.StandardWrapperValve invoke
>> SEVERE: Servlet.service() for servlet default threw exception
>> java.lang.StackOverflowError
>> The two blocks below occur multiple times, each, within a single trace:
>> ...
>>       at
>> org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121)
>>       at
>> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322)
>>       at
>> org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1130)
>>       at
>> org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:203)
>>       at
>> org.apache.wicket.protocol.http.pagestore.DiskPageStore.prepareForSerialization(DiskPageStore.java:1190)
>>       at
>> org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.writeObject(SecondLevelCacheSessionStore.java:386)
>> ...
>>       at
>> org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121)
>>       at
>> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322)
>>       at
>> org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1130)
>>       at
>> org.apache.wicket.protocol.http.pagestore.AbstractPageStore$PageSerializer.getPageReplacementObject(AbstractPageStore.java:288)
>>       at org.apache.wicket.Page.writeReplace(Page.java:1383)
>>
>> In our application's init() method, we have this setting:
>>
>> Objects.setObjectStreamFactory(null); // jdk serialization
>>
>> I have tried to reproduce the problem in a quickstart; but, I have not had
>> much luck, so far.
>>
>> We don't really have any custom code in our app that deals with object
>> serialization. Any help would be appreciated. We are currently using wicket
>> 1.4.9; if you guys think this might be fixed in a later version, we'd be
>> happy to upgrade. I searched briefly through the JIRA, and nothing popped
>> out at me.
>>
>> 
>>
>> RUSSELL E. MORRISEY
>> Programmer Analyst Professional
>> Mission Solutions Engineering, LLC
>>
>> | russell.morri...@missionse.com | www.missionse.com<
>> http://www.missionse.com/>
>> 304 West Route 38, Moorestown, NJ 08057-3212
>>
>>
>> 
>> This is a PRIVATE message. If you are not the intended recipient, please
>> delete without copying and kindly advise us by e-mail of the mistake in
>> delivery.
>> NOTE: Regardless of content, this e-mail shall not operate to bind MSE to
>> any order or other contract unless pursuant to explicit written agreement or
>> government initiative expressly permitting the use of e-mail for such
>> purpose.
>>
>
>
>
> --
> Pedro Henrique Oliveira dos Santos
>

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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Maarten Billemont

On 02 Apr 2011, at 00:13, Bruno Borges wrote:

> [] Please, check this box if you agree with EULA
> [ x ] Please, uncheck this box if you don't want to receive notifications
> 
> 
> In this case, I would set the first checkbox as required, and leave the
> later as optional.
> 
> Vote for (1) +1

Please don't pretend a checkbox is a Radio component.  This is irrelevant to 
this discussion.

> 
> Best regards,
> 
> Bruno Borges
> www.brunoborges.com.br
> +55 21 76727099
> 
> "The glory of great men should always be
> measured by the means they have used to
> acquire it."
> - Francois de La Rochefoucauld
> 
> 
> 
> On Fri, Apr 1, 2011 at 6:46 PM, Maarten Billemont  wrote:
> 
>> 
>> On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:
>> 
>>> BTW an empty string (that's not null) is a string nevertheless. Following
>> the argument that an unchecked (false) checkbox should be regarded as valid
>> if it is required, an empty string should be accepted as a valid input as
>> well.
>> 
>> I don't see why you would think that.  setRequired(true) means, "You must
>> provide a value for this component's model".  An empty String and a null
>> String mean the same thing (since you cannot input a null String); in both
>> instances, it's the user saying: "I have no value for this".  Hence, it
>> makes perfect sense that the setRequired(true) fails validation on an empty
>> text field.
>> 
>> Contrary to a text field, an unchecked checkbox does not mean: "no value".
>> It means: "Off".  As though I'd write "false" in my text field.
>> 
>> If the web application asks me whether I want to gift-wrap my purchase,
>> leaving the box unchecked does not mean I can't or don't want to make up my
>> mind.  It means I do not want it gift wrapped.  It's me saying: "No."
>> 
>>> I've just tested it with Wicket 1.4 and actually both of the following
>> TextFields validate to a failed state:
>>> 
>>>   TextField tf1 = new TextField("text1", new PropertyModel(this,
>> "test1"));
>>>   tf1.setRequired(true);
>>>   tf1.setConvertEmptyInputStringToNull(false);
>>>   form.add(tf1);
>>> 
>>>   TextField tf2 = new TextField("text2", new PropertyModel(this,
>> "test2"));
>>>   tf2.setRequired(true);
>>>   tf2.setConvertEmptyInputStringToNull(true);
>>>   form.add(tf2);
>>> 
>> 
>> Regardless, setConvertEmptyInputStringToNull is not relevant during
>> checkRequired.  It is only used by the developer to say, if the user doesn't
>> enter any characters, make my model object null instead of an empty string.
>> checkRequired checks Strings.isEmpty(), which is perfectly sensible (ref.
>> the first paragraph of this email).
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>> 


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



changing image on locale change

2011-04-01 Thread hrbaer
Hi all,

is there any chance to change an image once the user choose another
language?
With a text it's very easy because the only thing you have to provide are
the different language property files.

Let's assume there is a dropdown with different languages. I've added
DropDownChoices and implemented the onSelectionChanged method. If the user
choose another option the only thing I have to do is to set the Locale to
the choosen language.

Is there a similar functionality for images?

At the moment I've tried a little bit with this:
--
Image imageGerman = new Image( "someImage", new ResourceReference(
Home.class, "images/logo.png" ) );
Image imageUK = new Image( "someImage", new ResourceReference( Home.class,
"images/logo2.png" ) );
add( isLocaleGerman() ? imageGerman : imageUK );
--
But this is only working if the page constructor is called.

Any ideas?
Thanks in advance.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/changing-image-on-locale-change-tp3421291p3421291.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Bruno Borges
[] Please, check this box if you agree with EULA
[ x ] Please, uncheck this box if you don't want to receive notifications


In this case, I would set the first checkbox as required, and leave the
later as optional.

Vote for (1) +1

Best regards,

Bruno Borges
www.brunoborges.com.br
+55 21 76727099

"The glory of great men should always be
measured by the means they have used to
acquire it."
 - Francois de La Rochefoucauld



On Fri, Apr 1, 2011 at 6:46 PM, Maarten Billemont  wrote:

>
> On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:
>
> > BTW an empty string (that's not null) is a string nevertheless. Following
> the argument that an unchecked (false) checkbox should be regarded as valid
> if it is required, an empty string should be accepted as a valid input as
> well.
>
> I don't see why you would think that.  setRequired(true) means, "You must
> provide a value for this component's model".  An empty String and a null
> String mean the same thing (since you cannot input a null String); in both
> instances, it's the user saying: "I have no value for this".  Hence, it
> makes perfect sense that the setRequired(true) fails validation on an empty
> text field.
>
> Contrary to a text field, an unchecked checkbox does not mean: "no value".
>  It means: "Off".  As though I'd write "false" in my text field.
>
> If the web application asks me whether I want to gift-wrap my purchase,
> leaving the box unchecked does not mean I can't or don't want to make up my
> mind.  It means I do not want it gift wrapped.  It's me saying: "No."
>
> > I've just tested it with Wicket 1.4 and actually both of the following
> TextFields validate to a failed state:
> >
> >TextField tf1 = new TextField("text1", new PropertyModel(this,
> "test1"));
> >tf1.setRequired(true);
> >tf1.setConvertEmptyInputStringToNull(false);
> >form.add(tf1);
> >
> >TextField tf2 = new TextField("text2", new PropertyModel(this,
> "test2"));
> >tf2.setRequired(true);
> >tf2.setConvertEmptyInputStringToNull(true);
> >form.add(tf2);
> >
>
> Regardless, setConvertEmptyInputStringToNull is not relevant during
> checkRequired.  It is only used by the developer to say, if the user doesn't
> enter any characters, make my model object null instead of an empty string.
>  checkRequired checks Strings.isEmpty(), which is perfectly sensible (ref.
> the first paragraph of this email).
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: problems with spring integration

2011-04-01 Thread hrbaer
This works like a charm - thanks.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/problems-with-spring-integration-tp3416484p3421269.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: [Vote] New Wicket Version Numbering

2011-04-01 Thread msj121
I mean XP is letters... That is pretty amazing, there isn't even a number,
and even roman numerals, is there a 'P' in roman numerals?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Vote-New-Wicket-Version-Numbering-tp3420887p3421249.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Maarten Billemont

On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:

> BTW an empty string (that's not null) is a string nevertheless. Following the 
> argument that an unchecked (false) checkbox should be regarded as valid if it 
> is required, an empty string should be accepted as a valid input as well.

I don't see why you would think that.  setRequired(true) means, "You must 
provide a value for this component's model".  An empty String and a null String 
mean the same thing (since you cannot input a null String); in both instances, 
it's the user saying: "I have no value for this".  Hence, it makes perfect 
sense that the setRequired(true) fails validation on an empty text field.

Contrary to a text field, an unchecked checkbox does not mean: "no value".  It 
means: "Off".  As though I'd write "false" in my text field.

If the web application asks me whether I want to gift-wrap my purchase, leaving 
the box unchecked does not mean I can't or don't want to make up my mind.  It 
means I do not want it gift wrapped.  It's me saying: "No."

> I've just tested it with Wicket 1.4 and actually both of the following 
> TextFields validate to a failed state:
> 
>TextField tf1 = new TextField("text1", new PropertyModel(this, 
> "test1"));
>tf1.setRequired(true);
>tf1.setConvertEmptyInputStringToNull(false);
>form.add(tf1);
> 
>TextField tf2 = new TextField("text2", new PropertyModel(this, 
> "test2"));
>tf2.setRequired(true);
>tf2.setConvertEmptyInputStringToNull(true);
>form.add(tf2);
> 

Regardless, setConvertEmptyInputStringToNull is not relevant during 
checkRequired.  It is only used by the developer to say, if the user doesn't 
enter any characters, make my model object null instead of an empty string.  
checkRequired checks Strings.isEmpty(), which is perfectly sensible (ref. the 
first paragraph of this email).
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Igor Vaynberg
to clarify, this kind of change is off the table for 1.4, but may be
implemented in 1.5

-igor

On Fri, Apr 1, 2011 at 2:23 PM, Maarten Billemont  wrote:
>
> On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:
>
>> I would stick with 1 (required to be checked).
>>
>> The main reason would be not to break compatibility with old versions.
>
> Lame reason.  "Don't fix bugged behavior because old code relies on it."
> All that got us is a renders-well-in-IE 6.0 web, which we only barely are 
> struggling out of with the advent of Mozilla et al. who decided to do the 
> right thing for a change.
>
>> I actually used .setRequired(true) on legal checkboxes (disclaimers) in one 
>> of our applications because if I have a "required checkbox" I expect it to 
>> be needed to be checked.
>
> Get the context right.  "You are required to provide a value" is not the same 
> as "You are required to provide this specific value".  The context of the 
> term "required" in the setRequired method refers to the former, not the 
> latter.  As Igor pointed out, the latter is accomplished with a validator.  
> setRequired has no business looking at what your value is, just whether or 
> not one exists.
>
> Changing that context for one component for whatever reason breaks the 
> consistency and reliability of the API.
>
>> Although I will change that in our project now that I know such a change is 
>> being discussed, I wouldn't expect others to be that observant of the issue 
>> and have unit tests that prevent anything from breaking on a future upgrade.
>
> I hope people test their web apps before they deploy a new release to 
> production.  I'm sure they'll notice the change if they do.
>
> I vote (2) +1, if it doesn't make sense to apply setRequired to a certain 
> type of component because the HTML model simply does not permit it, giving 
> setRequired a different meaning is not an acceptable alternative.
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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



Re: [Vote] New Wicket Version Numbering

2011-04-01 Thread Korbinian Bachl - whiskyworld
OMG?!? ARE YOU SERIOUS??? Here we are already using WINDOWS 2000 with 
OFFICE 2010 ;)


(Note: never ever believe any mails, blogs, newspapers on april 1st *g*)



Am 01.04.11 20:14, schrieb nino martinez wael:

Gotta be a aprils fools thing..

Who would decide what framework to be used based on version number?
Why not take a look at architecture instead... Ooh lets chose windows
95 instead of windows 7, it has a higher number so it gotta be better
.

2011/4/1 Igor Vaynberg:

where do i apply for a job there? sounds like fun!

-igor

On Fri, Apr 1, 2011 at 10:56 AM, Jim Pinkham  wrote:

I've had a hard time lately trying to get corporate acceptance of the Wicket
framework.

In fact, our company looked at this comparison of java frameworks:

http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

  *Project* *Current Stable Version*  Apache Click  2.2.0   Apache Cocoon
2.2.0   Apache Struts  2.2.1.1   Apache Tapestry  5.2.4   Apache Wicket
1.4.15   AppFuse  2.0.2   Aranea  1.0.10   Eclipse RAP  1.2.0   FormEngine
1.7.1   Google Web Toolkit  2.2.0   Hamlets  1.6  IceFaces  2  ItsNat
1  JavaServer
Faces  2  JBoss Seam  2.2.0 GA   Jspx-bay  1.1.0   JVx WebUI  0.8  ManyDesigns
Portofino  3.1.10   OpenLaszlo  4.1  OpenXava  4.0.1   Oracle ADF  11.1.1.4
Play  1.1.1   RIFE  1.6.2   Shale  1.0.4   Sling  5  SmartClient  8  Spring
3.0.5   Stripes  1.5.4   Telosys  1.1.1   ThinWire  1.2  Vaadin(IT Mill
Toolkit)  6.5.1   Wavemaker  6.1.10   WebObjects  5.4.3   WebWork  2.2.6
ZK  5.0.5   ztemplates  0.9.9.6

The powers that be decided to pick Smart Client over Apache Wicket because
they have the highest version number.

So, I think the time is right to move straight to the front of the pack and
release version 10.0.

Who's with me?

-- Jim

Spinal Tap Industries, Inc.



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




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



--

  whiskyworld e.K.
  http://www.whiskyworld.de
  Ziegelfeld 6
  94481 Grafenau/ Haus im Wald
  Tel. 08555/ 406 320
  Fax. 08555/ 406 319

  Amtsgericht Passau: HRA 11760
  Geschäftsführer: Ulrike Bachl
  UstID: DE260619452
  

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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Maarten Billemont

On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote:

> I would stick with 1 (required to be checked).
> 
> The main reason would be not to break compatibility with old versions.

Lame reason.  "Don't fix bugged behavior because old code relies on it."
All that got us is a renders-well-in-IE 6.0 web, which we only barely are 
struggling out of with the advent of Mozilla et al. who decided to do the right 
thing for a change.

> I actually used .setRequired(true) on legal checkboxes (disclaimers) in one 
> of our applications because if I have a "required checkbox" I expect it to be 
> needed to be checked.

Get the context right.  "You are required to provide a value" is not the same 
as "You are required to provide this specific value".  The context of the term 
"required" in the setRequired method refers to the former, not the latter.  As 
Igor pointed out, the latter is accomplished with a validator.  setRequired has 
no business looking at what your value is, just whether or not one exists.

Changing that context for one component for whatever reason breaks the 
consistency and reliability of the API.

> Although I will change that in our project now that I know such a change is 
> being discussed, I wouldn't expect others to be that observant of the issue 
> and have unit tests that prevent anything from breaking on a future upgrade.

I hope people test their web apps before they deploy a new release to 
production.  I'm sure they'll notice the change if they do.

I vote (2) +1, if it doesn't make sense to apply setRequired to a certain type 
of component because the HTML model simply does not permit it, giving 
setRequired a different meaning is not an acceptable alternative.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread MZemeck
I second Daniel's comments.

+1 for option 1




From:   Daniel Neugebauer 
To: users@wicket.apache.org
Date:   04/01/2011 02:56 PM
Subject:Re: [VOTE] Behavior of CheckBox With Respect to 
setRequired(true)



I would stick with 1 (required to be checked).

The main reason would be not to break compatibility with old versions. I 
actually used .setRequired(true) on legal checkboxes (disclaimers) in 
one of our applications because if I have a "required checkbox" I expect 
it to be needed to be checked. Although I will change that in our 
project now that I know such a change is being discussed, I wouldn't 
expect others to be that observant of the issue and have unit tests that 
prevent anything from breaking on a future upgrade.

BTW an empty string (that's not null) is a string nevertheless. 
Following the argument that an unchecked (false) checkbox should be 
regarded as valid if it is required, an empty string should be accepted 
as a valid input as well. I've just tested it with Wicket 1.4 and 
actually both of the following TextFields validate to a failed state:

 TextField tf1 = new TextField("text1", new 
PropertyModel(this, "test1"));
 tf1.setRequired(true);
 tf1.setConvertEmptyInputStringToNull(false);
 form.add(tf1);

 TextField tf2 = new TextField("text2", new 
PropertyModel(this, "test2"));
 tf2.setRequired(true);
 tf2.setConvertEmptyInputStringToNull(true);
 form.add(tf2);

So, TextField.setRequired doesn't validate the syntactic meaning as 
well, instead it validates the semantic meaning, just as 
CheckBox.setRequired does. If that's consistently used throughout 
Wicket, I would expect CheckBox.setRequired to validate false unless the 
CheckBox is actually checked.

Just my 2 cents,
Daniel

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






Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread James Carman
On Fri, Apr 1, 2011 at 2:33 PM, Matthew Pennington
 wrote:
>
> (1)
>
> I can't think of any useful benefit to (2) but I *can* think of a very
> useful benefit for (1) The classic "tick this box to indicate that you have
> read and agreed to sell us your soul EULA  would be the obvious time to use
> a checkbox and setRequired(true) if it worked as per (1).
>

The way I found it was that Wicketopia automatically marks every
primitive property as required, since primitive fields can't be null.
When you use a checkbox as the "editor", it messes up, because the
user is required to check those checkboxes.  I have worked around it,
but it just seems inconsistent with the way everything else works in
Wicket.

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



Re: ModalWindow detach/serialize crashes wicket app

2011-04-01 Thread Pedro Santos
looks like your page is referencing session or pagemap somehow

On Fri, Apr 1, 2011 at 4:15 PM, Russell Morrisey <
russell.morri...@missionse.com> wrote:

> Guys,
>
> I'm having an intermittent issue in development where use of a ModalWindow
> on a page completely crashes wicket.
>
> I don't know of the ModalWindow is the root cause. I am hoping that someone
> with intimate knowledge of wicket's page store can help me narrow it down.
> Hints appreciated. =)
>
> The "X" button and other ajax controls within the ModalWindow's content
> page stop responding to user input. When I try to hit the same bookmarkable
> URL again for the containing page, wicket seems to have stopped running
> entirely, and I get a Tomcat HTTP 404 error.
>
> The JVM outputs a StackOverflowError which looks like it happens during
> page serialization.
> Apr 1, 2011 2:53:14 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet default threw exception
> java.lang.StackOverflowError
> The two blocks below occur multiple times, each, within a single trace:
> ...
>   at
> org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121)
>   at
> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322)
>   at
> org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1130)
>   at
> org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:203)
>   at
> org.apache.wicket.protocol.http.pagestore.DiskPageStore.prepareForSerialization(DiskPageStore.java:1190)
>   at
> org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.writeObject(SecondLevelCacheSessionStore.java:386)
> ...
>   at
> org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121)
>   at
> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322)
>   at
> org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1130)
>   at
> org.apache.wicket.protocol.http.pagestore.AbstractPageStore$PageSerializer.getPageReplacementObject(AbstractPageStore.java:288)
>   at org.apache.wicket.Page.writeReplace(Page.java:1383)
>
> In our application's init() method, we have this setting:
>
> Objects.setObjectStreamFactory(null); // jdk serialization
>
> I have tried to reproduce the problem in a quickstart; but, I have not had
> much luck, so far.
>
> We don't really have any custom code in our app that deals with object
> serialization. Any help would be appreciated. We are currently using wicket
> 1.4.9; if you guys think this might be fixed in a later version, we'd be
> happy to upgrade. I searched briefly through the JIRA, and nothing popped
> out at me.
>
> 
>
> RUSSELL E. MORRISEY
> Programmer Analyst Professional
> Mission Solutions Engineering, LLC
>
> | russell.morri...@missionse.com | www.missionse.com<
> http://www.missionse.com/>
> 304 West Route 38, Moorestown, NJ 08057-3212
>
>
> 
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind MSE to
> any order or other contract unless pursuant to explicit written agreement or
> government initiative expressly permitting the use of e-mail for such
> purpose.
>



-- 
Pedro Henrique Oliveira dos Santos


ModalWindow detach/serialize crashes wicket app

2011-04-01 Thread Russell Morrisey
Guys,

I'm having an intermittent issue in development where use of a ModalWindow on a 
page completely crashes wicket.

I don't know of the ModalWindow is the root cause. I am hoping that someone 
with intimate knowledge of wicket's page store can help me narrow it down. 
Hints appreciated. =)

The "X" button and other ajax controls within the ModalWindow's content page 
stop responding to user input. When I try to hit the same bookmarkable URL 
again for the containing page, wicket seems to have stopped running entirely, 
and I get a Tomcat HTTP 404 error.

The JVM outputs a StackOverflowError which looks like it happens during page 
serialization.
Apr 1, 2011 2:53:14 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet default threw exception
java.lang.StackOverflowError
The two blocks below occur multiple times, each, within a single trace:
...
   at 
org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322)
   at 
org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1130)
   at 
org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:203)
   at 
org.apache.wicket.protocol.http.pagestore.DiskPageStore.prepareForSerialization(DiskPageStore.java:1190)
   at 
org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.writeObject(SecondLevelCacheSessionStore.java:386)
...
   at 
org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322)
   at 
org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1130)
   at 
org.apache.wicket.protocol.http.pagestore.AbstractPageStore$PageSerializer.getPageReplacementObject(AbstractPageStore.java:288)
   at org.apache.wicket.Page.writeReplace(Page.java:1383)

In our application's init() method, we have this setting:

Objects.setObjectStreamFactory(null); // jdk serialization

I have tried to reproduce the problem in a quickstart; but, I have not had much 
luck, so far.

We don't really have any custom code in our app that deals with object 
serialization. Any help would be appreciated. We are currently using wicket 
1.4.9; if you guys think this might be fixed in a later version, we'd be happy 
to upgrade. I searched briefly through the JIRA, and nothing popped out at me.



RUSSELL E. MORRISEY
Programmer Analyst Professional
Mission Solutions Engineering, LLC

| russell.morri...@missionse.com | www.missionse.com
304 West Route 38, Moorestown, NJ 08057-3212



This is a PRIVATE message. If you are not the intended recipient, please delete 
without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any 
order or other contract unless pursuant to explicit written agreement or 
government initiative expressly permitting the use of e-mail for such purpose.


Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Igor Vaynberg
no, validators do not typically handle "null" values. those are
controlled by the required flag. the reason checkboxes are unique is
that they have no "null" value, a null in the checkbox means "false"

-igor


On Fri, Apr 1, 2011 at 11:57 AM, Matthew Pennington
 wrote:
> On 01/04/2011 19:34, Igor Vaynberg wrote:
>>
>> that can be accomplished using a validator.
>
> Is that not true of all form components?
>
> Matt
>>
>> -igor
>>
>>
>> On Fri, Apr 1, 2011 at 11:33 AM, Matthew Pennington
>>   wrote:

 1.  The current approach is correct, requiring a checkbox means
 requiring that it be checked.

 2.  A checkbox shouldn't be able to be required.  You can't *not*
 provide a value (it's binary) for a checkbox, so therefore it always
 should satisfy the required requirement.
>>>
>>> (1)
>>>
>>> I can't think of any useful benefit to (2) but I *can* think of a very
>>> useful benefit for (1) The classic "tick this box to indicate that you
>>> have
>>> read and agreed to sell us your soul EULA  would be the obvious time to
>>> use
>>> a checkbox and setRequired(true) if it worked as per (1).
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Matthew Pennington

On 01/04/2011 19:34, Igor Vaynberg wrote:

that can be accomplished using a validator.

Is that not true of all form components?

Matt

-igor


On Fri, Apr 1, 2011 at 11:33 AM, Matthew Pennington
  wrote:

1.  The current approach is correct, requiring a checkbox means
requiring that it be checked.

2.  A checkbox shouldn't be able to be required.  You can't *not*
provide a value (it's binary) for a checkbox, so therefore it always
should satisfy the required requirement.

(1)

I can't think of any useful benefit to (2) but I *can* think of a very
useful benefit for (1) The classic "tick this box to indicate that you have
read and agreed to sell us your soul EULA  would be the obvious time to use
a checkbox and setRequired(true) if it worked as per (1).


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



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






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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Daniel Neugebauer

I would stick with 1 (required to be checked).

The main reason would be not to break compatibility with old versions. I 
actually used .setRequired(true) on legal checkboxes (disclaimers) in 
one of our applications because if I have a "required checkbox" I expect 
it to be needed to be checked. Although I will change that in our 
project now that I know such a change is being discussed, I wouldn't 
expect others to be that observant of the issue and have unit tests that 
prevent anything from breaking on a future upgrade.


BTW an empty string (that's not null) is a string nevertheless. 
Following the argument that an unchecked (false) checkbox should be 
regarded as valid if it is required, an empty string should be accepted 
as a valid input as well. I've just tested it with Wicket 1.4 and 
actually both of the following TextFields validate to a failed state:


TextField tf1 = new TextField("text1", new 
PropertyModel(this, "test1"));

tf1.setRequired(true);
tf1.setConvertEmptyInputStringToNull(false);
form.add(tf1);

TextField tf2 = new TextField("text2", new 
PropertyModel(this, "test2"));

tf2.setRequired(true);
tf2.setConvertEmptyInputStringToNull(true);
form.add(tf2);

So, TextField.setRequired doesn't validate the syntactic meaning as 
well, instead it validates the semantic meaning, just as 
CheckBox.setRequired does. If that's consistently used throughout 
Wicket, I would expect CheckBox.setRequired to validate false unless the 
CheckBox is actually checked.


Just my 2 cents,
Daniel

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



Re: [Vote] New Wicket Version Numbering

2011-04-01 Thread nino martinez wael
hah some of our servers are 2008 r2 :)
However im considering doing a nix distribution called "HAL 9000" as
it probably will attract a lot of users based on the high number...

2011/4/1 Igor Vaynberg :
> im running win 2000, you guys are too far behind.
>
> -igor
>
>
> 2011/4/1 Rafał Krupiński :
>> W dniu 01.04.2011 20:14, nino martinez wael pisze:
>>>
>>> Gotta be a aprils fools thing..
>>>
>>> Who would decide what framework to be used based on version number?
>>> Why not take a look at architecture instead... Ooh lets chose windows
>>> 95 instead of windows 7, it has a higher number so it gotta be better
>>
>> You have a valid point there, it's time to switch back to Win95
>>
>> Rafał Krupiński
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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



Re: [Vote] New Wicket Version Numbering

2011-04-01 Thread Igor Vaynberg
im running win 2000, you guys are too far behind.

-igor


2011/4/1 Rafał Krupiński :
> W dniu 01.04.2011 20:14, nino martinez wael pisze:
>>
>> Gotta be a aprils fools thing..
>>
>> Who would decide what framework to be used based on version number?
>> Why not take a look at architecture instead... Ooh lets chose windows
>> 95 instead of windows 7, it has a higher number so it gotta be better
>
> You have a valid point there, it's time to switch back to Win95
>
> Rafał Krupiński
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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



Re: Detach on ldm?

2011-04-01 Thread nino martinez wael
in a button this seemed to have a impact on deciding to reloading the :

cancelButton.setDefaultFormProcessing(false);

Not sure why it has, no matter what I detached the cpm and I guess it
should be reloaded.. However it's working as I want now..

have a great weekend, ha en go weekend or saludos!

2011/4/1 Pedro Santos :
> yep
>
> On Fri, Apr 1, 2011 at 2:02 PM, nino martinez wael <
> nino.martinez.w...@gmail.com> wrote:
>
>> Shouldnt a call to detach on a cpm targeting a ldm chain detach so that it
>> will reload?
>>
>
>
>
> --
> Pedro Henrique Oliveira dos Santos
>

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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Igor Vaynberg
that can be accomplished using a validator.

-igor


On Fri, Apr 1, 2011 at 11:33 AM, Matthew Pennington
 wrote:
>
>> 1.  The current approach is correct, requiring a checkbox means
>> requiring that it be checked.
>>
>> 2.  A checkbox shouldn't be able to be required.  You can't *not*
>> provide a value (it's binary) for a checkbox, so therefore it always
>> should satisfy the required requirement.
>
> (1)
>
> I can't think of any useful benefit to (2) but I *can* think of a very
> useful benefit for (1) The classic "tick this box to indicate that you have
> read and agreed to sell us your soul EULA  would be the obvious time to use
> a checkbox and setRequired(true) if it worked as per (1).
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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



Re: [Vote] New Wicket Version Numbering

2011-04-01 Thread Rafał Krupiński

W dniu 01.04.2011 20:14, nino martinez wael pisze:

Gotta be a aprils fools thing..

Who would decide what framework to be used based on version number?
Why not take a look at architecture instead... Ooh lets chose windows
95 instead of windows 7, it has a higher number so it gotta be better


You have a valid point there, it's time to switch back to Win95

Rafał Krupiński

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



Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Matthew Pennington



1.  The current approach is correct, requiring a checkbox means
requiring that it be checked.

2.  A checkbox shouldn't be able to be required.  You can't *not*
provide a value (it's binary) for a checkbox, so therefore it always
should satisfy the required requirement.

(1)

I can't think of any useful benefit to (2) but I *can* think of a very 
useful benefit for (1) The classic "tick this box to indicate that you 
have read and agreed to sell us your soul EULA  would be the obvious 
time to use a checkbox and setRequired(true) if it worked as per (1).



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



Re: [Vote] New Wicket Version Numbering

2011-04-01 Thread nino martinez wael
Gotta be a aprils fools thing..

Who would decide what framework to be used based on version number?
Why not take a look at architecture instead... Ooh lets chose windows
95 instead of windows 7, it has a higher number so it gotta be better
.

2011/4/1 Igor Vaynberg :
> where do i apply for a job there? sounds like fun!
>
> -igor
>
> On Fri, Apr 1, 2011 at 10:56 AM, Jim Pinkham  wrote:
>> I've had a hard time lately trying to get corporate acceptance of the Wicket
>> framework.
>>
>> In fact, our company looked at this comparison of java frameworks:
>>
>> http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
>>
>>  *Project* *Current Stable Version*  Apache Click  2.2.0   Apache Cocoon
>> 2.2.0   Apache Struts  2.2.1.1   Apache Tapestry  5.2.4   Apache Wicket
>> 1.4.15   AppFuse  2.0.2   Aranea  1.0.10   Eclipse RAP  1.2.0   FormEngine
>> 1.7.1   Google Web Toolkit  2.2.0   Hamlets  1.6  IceFaces  2  ItsNat
>> 1  JavaServer
>> Faces  2  JBoss Seam  2.2.0 GA   Jspx-bay  1.1.0   JVx WebUI  0.8  
>> ManyDesigns
>> Portofino  3.1.10   OpenLaszlo  4.1  OpenXava  4.0.1   Oracle ADF  11.1.1.4
>> Play  1.1.1   RIFE  1.6.2   Shale  1.0.4   Sling  5  SmartClient  8  Spring
>> 3.0.5   Stripes  1.5.4   Telosys  1.1.1   ThinWire  1.2  Vaadin(IT Mill
>> Toolkit)  6.5.1   Wavemaker  6.1.10   WebObjects  5.4.3   WebWork  2.2.6
>> ZK  5.0.5   ztemplates  0.9.9.6
>>
>> The powers that be decided to pick Smart Client over Apache Wicket because
>> they have the highest version number.
>>
>> So, I think the time is right to move straight to the front of the pack and
>> release version 10.0.
>>
>> Who's with me?
>>
>> -- Jim
>>
>> Spinal Tap Industries, Inc.
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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



Re: [Vote] New Wicket Version Numbering

2011-04-01 Thread Igor Vaynberg
where do i apply for a job there? sounds like fun!

-igor

On Fri, Apr 1, 2011 at 10:56 AM, Jim Pinkham  wrote:
> I've had a hard time lately trying to get corporate acceptance of the Wicket
> framework.
>
> In fact, our company looked at this comparison of java frameworks:
>
> http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
>
>  *Project* *Current Stable Version*  Apache Click  2.2.0   Apache Cocoon
> 2.2.0   Apache Struts  2.2.1.1   Apache Tapestry  5.2.4   Apache Wicket
> 1.4.15   AppFuse  2.0.2   Aranea  1.0.10   Eclipse RAP  1.2.0   FormEngine
> 1.7.1   Google Web Toolkit  2.2.0   Hamlets  1.6  IceFaces  2  ItsNat
> 1  JavaServer
> Faces  2  JBoss Seam  2.2.0 GA   Jspx-bay  1.1.0   JVx WebUI  0.8  ManyDesigns
> Portofino  3.1.10   OpenLaszlo  4.1  OpenXava  4.0.1   Oracle ADF  11.1.1.4
> Play  1.1.1   RIFE  1.6.2   Shale  1.0.4   Sling  5  SmartClient  8  Spring
> 3.0.5   Stripes  1.5.4   Telosys  1.1.1   ThinWire  1.2  Vaadin(IT Mill
> Toolkit)  6.5.1   Wavemaker  6.1.10   WebObjects  5.4.3   WebWork  2.2.6
> ZK  5.0.5   ztemplates  0.9.9.6
>
> The powers that be decided to pick Smart Client over Apache Wicket because
> they have the highest version number.
>
> So, I think the time is right to move straight to the front of the pack and
> release version 10.0.
>
> Who's with me?
>
> -- Jim
>
> Spinal Tap Industries, Inc.
>

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



[Vote] New Wicket Version Numbering

2011-04-01 Thread Jim Pinkham
I've had a hard time lately trying to get corporate acceptance of the Wicket
framework.

In fact, our company looked at this comparison of java frameworks:

http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

  *Project* *Current Stable Version*  Apache Click  2.2.0   Apache Cocoon
2.2.0   Apache Struts  2.2.1.1   Apache Tapestry  5.2.4   Apache Wicket
1.4.15   AppFuse  2.0.2   Aranea  1.0.10   Eclipse RAP  1.2.0   FormEngine
1.7.1   Google Web Toolkit  2.2.0   Hamlets  1.6  IceFaces  2  ItsNat
1  JavaServer
Faces  2  JBoss Seam  2.2.0 GA   Jspx-bay  1.1.0   JVx WebUI  0.8  ManyDesigns
Portofino  3.1.10   OpenLaszlo  4.1  OpenXava  4.0.1   Oracle ADF  11.1.1.4
Play  1.1.1   RIFE  1.6.2   Shale  1.0.4   Sling  5  SmartClient  8  Spring
3.0.5   Stripes  1.5.4   Telosys  1.1.1   ThinWire  1.2  Vaadin(IT Mill
Toolkit)  6.5.1   Wavemaker  6.1.10   WebObjects  5.4.3   WebWork  2.2.6
ZK  5.0.5   ztemplates  0.9.9.6

The powers that be decided to pick Smart Client over Apache Wicket because
they have the highest version number.

So, I think the time is right to move straight to the front of the pack and
release version 10.0.

Who's with me?

-- Jim

Spinal Tap Industries, Inc.


Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread Pedro Santos
I vote for 2, checkbox needs always to satisfy the required requirement. As
pointed, there are no parameter in the HTTP request reader for false inputs,
we can't distinguish 'false' from 'null', so we can't consider that user
isn't meeting the required condition.

On Fri, Apr 1, 2011 at 2:34 PM, James Carman wrote:

> This has been discussed before
> (https://issues.apache.org/jira/browse/WICKET-1221), but I can't find
> the old vote thread to see what folks think.  The problem is that a
> checkbox is a weird bird when it comes to HTTP.  If it's unchecked, it
> doesn't send a value which makes Wicket think you haven't provided a
> value for that input field.  Right now, if you call setRequired(true)
> on a CheckBox, it's going to require the user to actually check the
> box.  What do folks think the desired behavior should be?
>
> 1.  The current approach is correct, requiring a checkbox means
> requiring that it be checked.
>
> 2.  A checkbox shouldn't be able to be required.  You can't *not*
> provide a value (it's binary) for a checkbox, so therefore it always
> should satisfy the required requirement.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Pedro Henrique Oliveira dos Santos


[VOTE] Behavior of CheckBox With Respect to setRequired(true)

2011-04-01 Thread James Carman
This has been discussed before
(https://issues.apache.org/jira/browse/WICKET-1221), but I can't find
the old vote thread to see what folks think.  The problem is that a
checkbox is a weird bird when it comes to HTTP.  If it's unchecked, it
doesn't send a value which makes Wicket think you haven't provided a
value for that input field.  Right now, if you call setRequired(true)
on a CheckBox, it's going to require the user to actually check the
box.  What do folks think the desired behavior should be?

1.  The current approach is correct, requiring a checkbox means
requiring that it be checked.

2.  A checkbox shouldn't be able to be required.  You can't *not*
provide a value (it's binary) for a checkbox, so therefore it always
should satisfy the required requirement.

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



Re: Detach on ldm?

2011-04-01 Thread Pedro Santos
yep

On Fri, Apr 1, 2011 at 2:02 PM, nino martinez wael <
nino.martinez.w...@gmail.com> wrote:

> Shouldnt a call to detach on a cpm targeting a ldm chain detach so that it
> will reload?
>



-- 
Pedro Henrique Oliveira dos Santos


Detach on ldm?

2011-04-01 Thread nino martinez wael
Shouldnt a call to detach on a cpm targeting a ldm chain detach so that it
will reload?


Re: [ANNOUNCE] Wicketopia 0.9 Released...

2011-04-01 Thread James Carman
On Fri, Apr 1, 2011 at 11:20 AM, Emmanouil Batsis  wrote:
>
> I have to agree with Maarten on points; without more documentation,
> prospective users will just dismiss this shortly after visitinga couple of
> webpages. Some questions:
>

I appreciate you guys taking the time to give feedback.  Please keep
in mind, though, that this has been a one man show and this one man
has three kids and a full-time job. :)  I'm definitely planning on
improving the documentation, but my priority is to add features that
help me in my day-to-day work.  This project is very young as far as
being out there in front of folks, but it's been something that I've
been working on for quite some time in my very limited spare time.

>  - Does this offer static scaffolding (e.g. build time) or runtime? Are
> templating mechanisms available?
>

The built-in scaffolding (which I wrote in one evening the other
night) is all runtime-generated.  Right now, there is no capability
for generating source code.

>  - What are the tier tyes covered? Wicket is in there, but how about
> business and persistance components (e.g. EJB)
>

Wicketopia's primary focus is on generating viewers/editors for
objects.  So, it doesn't really care how you get those objects or how
(or if) you save them.  There is currently a Hibernate integration
module.  There is also a Spring Security integration (written last
night in about 30 minutes) which allows you to hide/show (or require
or disable) properties based on user roles.

>  - Is there a howto for what appears to be a sample app? What does the
> sample app include?
>

Right now the sample app only includes a scaffolding example.  The
information on the site came from the example.

> I did md4j [1] about five years ago; it was a similar concept, only for
> Struts1/JSP2/EJB2/Hibernate. It saved man-months in my teams, but people
> outside those never got it since we never made it easy documentation-wise.
> Eventually we left it behind and never got the chance to write something
> similar using more current components. Wicketopia could be usefull, maybe
> even to the point of us making contributions, but you really need more
> documentation!
>

Thank you for the advice and any contributions would be welcomed.
There is plenty of room for improvement and I'll just continue along
improving it based on my current needs.

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



Re: Set default coding strategy

2011-04-01 Thread Loren Cole
Awesome.  We are already using wicketstuff-annotation, annotating the base
class is the (now obvious) solution we were looking for.

Thanks,
Loren

On Fri, Apr 1, 2011 at 4:10 AM, Mike Mander  wrote:

> Am 31.03.2011 17:39, schrieb Loren Cole:
>
>  We're using annotations to mount our pages, and would like to set things
>> up
>> so they use HybridUrlCodingStrategy by default.  Does anyone know of a way
>> to do this?
>>
>> Thanks,
>> Loren
>>
>>  Maybe you can write your own mount method "mountHybrid" and overload it.
> Then you can call
> this methods. Overwriting "mount methods" in application seems to be
> forbidden (final) and
> in these methods there is no "entry point" for startegy instanciation.
>
> Another (realy great) tool for mounting pages is in wicketstuff-annotation
> project. There you can set strategy
> to use in every page itself and if you derive all your pages from a base
> class you can annotate this class
> with a HybridUrlCodingStrategy.
>
> Hth
> Mike
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: [ANNOUNCE] Wicketopia 0.9 Released...

2011-04-01 Thread Emmanouil Batsis


I have to agree with Maarten on points; without more documentation,  
prospective users will just dismiss this shortly after visitinga  
couple of webpages. Some questions:


 - Does this offer static scaffolding (e.g. build time) or runtime?  
Are templating mechanisms available?


 - What are the tier tyes covered? Wicket is in there, but how about  
business and persistance components (e.g. EJB)


 - Is there a howto for what appears to be a sample app? What does  
the sample app include?


I did md4j [1] about five years ago; it was a similar concept, only  
for Struts1/JSP2/EJB2/Hibernate. It saved man-months in my teams, but  
people outside those never got it since we never made it easy  
documentation-wise. Eventually we left it behind and never got the  
chance to write something similar using more current components.  
Wicketopia could be usefull, maybe even to the point of us making  
contributions, but you really need more documentation!


[1] http://dev.abiss.gr/md4j/

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



Re: [ANNOUNCE] Wicketopia 0.9 Released...

2011-04-01 Thread James Carman
By the way, the example is available for download from here:

http://repo2.maven.org/maven2/org/wicketopia/wicketopia-example/0.9.1/wicketopia-example-0.9.1.war

It should work in any container (crossing fingers), but the classpath
scanning might get messed up in some more strict environments.


On Fri, Apr 1, 2011 at 7:01 AM, James Carman  wrote:
> On Fri, Apr 1, 2011 at 3:02 AM, nino martinez wael
>  wrote:
>> very nice with the scaffold component!!
>>
>> Any examples of it?
>
> The example application includes an example:
>
> https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/example/src/main/java/org/wicketopia/example/web/page/HomePage.java
>
> I added the authentication stuff last night to show off the new Spring
> Security module, but the only line in the constructor used to be:
>
> add(new Scaffold("scaffold", Person.class, persistenceProvider));
>
> Take a look at the generated scaffold stuff.  It looks a lot like
> Grails.  I spent an entire evening "borrowing" from them to see if I
> could replicate the look and feel.
>

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



Re: [ANNOUNCE] Wicketopia 0.9 Released...

2011-04-01 Thread James Carman
On Fri, Apr 1, 2011 at 3:02 AM, nino martinez wael
 wrote:
> very nice with the scaffold component!!
>
> Any examples of it?

The example application includes an example:

https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/example/src/main/java/org/wicketopia/example/web/page/HomePage.java

I added the authentication stuff last night to show off the new Spring
Security module, but the only line in the constructor used to be:

add(new Scaffold("scaffold", Person.class, persistenceProvider));

Take a look at the generated scaffold stuff.  It looks a lot like
Grails.  I spent an entire evening "borrowing" from them to see if I
could replicate the look and feel.

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



Re: [ANNOUNCE] Wicketopia 0.9 Released...

2011-04-01 Thread James Carman
On Fri, Apr 1, 2011 at 4:45 AM, Maarten Billemont  wrote:
> Without knowing what RAD or Scaffolding is about, the examples on your site 
> really make very little sense to me.
>

The scaffolding term is borrowed from the Rails/Grails folks.
Basically, it automatically generates a view that will show you a list
of beans, allow you to view, create, edit, and delete them all
individually.

> You show a method, getDescription, with a bunch of annotations on them.  You 
> don't show what this method is a part of, or how that actually ties in with 
> your actual wicket code underneath.
>

I'm still working on the documentation.  I want to provide a more
tutorial-ish version soon.

> The wicket Java code example shows a wicketopia Scaffold component that takes 
> a wicketopia Widget class and a Spring persistence provider.  How could this 
> possibly be useful to me?  What does it do?  How does it tie in with my 
> insanely annotated getDescription method?
>

PersistenceProvider is an interface and the implementation class
doesn't depend on Spring at all.  It's a pure hibernate DAO,
essentially.  The example application is pieced together with Spring,
since that's what I'm familiar with and it allows me to put something
together with little effort by copy/pasting stuff from other projects
that I know work.

> Also, does wicketopia depend on Spring?  That would be a really *really* big 
> downside.  I don't need any frontend library telling me what persistence 
> framework to use, and Spring is about much more than just persistence.  
> Abstract that stuff.
>

Again, no.  Take a look at the pom.xml files:

https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/pom.xml
https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/persistence/pom.xml
https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/hibernate/pom.xml
https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/jpa/pom.xml

There are modules that depend on Spring (spring-security and
domdrides), but you don't have to use them.

> Perhaps when I can understand what Wicketopia is without having to UTSL, I'll 
> consider giving it a try.  Assuming I don't also need to suffocate my code 
> under the weight of Spring.
>

We get it, you don't like Spring. :)

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



Re: Set default coding strategy

2011-04-01 Thread Mike Mander

Am 31.03.2011 17:39, schrieb Loren Cole:

We're using annotations to mount our pages, and would like to set things up
so they use HybridUrlCodingStrategy by default.  Does anyone know of a way
to do this?

Thanks,
Loren

Maybe you can write your own mount method "mountHybrid" and overload it. 
Then you can call
this methods. Overwriting "mount methods" in application seems to be 
forbidden (final) and

in these methods there is no "entry point" for startegy instanciation.

Another (realy great) tool for mounting pages is in 
wicketstuff-annotation project. There you can set strategy
to use in every page itself and if you derive all your pages from a base 
class you can annotate this class

with a HybridUrlCodingStrategy.

Hth
Mike

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



Re: ReloadingWicketFilter does not work on Wicket 1.5-rc2

2011-04-01 Thread Martin Grigorov
Hi Hideyuki,

I think the idea is that if the Application class is modified then you'll
need to restart the whole web application.
Even if we use the ReloadingClassLoader it will reload the class but it wont
be re-init()-ed, so it will not be clear whether the changes are loaded and
taken into account or not.

What exactly is the problem you experience ?

On Fri, Apr 1, 2011 at 11:46 AM, Hideyuki TAKEUCHI wrote:

> Hi Martin,
> Thanks for your reply.
>
> Yes, Please see in WicketFilter.init(boolean, FilterConfig).
>
> public void init(final boolean isServlet,
>final FilterConfig filterConfig) throws ServletException {
>  this.filterConfig = filterConfig;
>
>  applicationFactory = getApplicationFactory();
>  application = applicationFactory.createApplication(this);
>  application.setName(filterConfig.getFilterName());
>  application.setWicketFilter(this);
>
> ... after that ...
>
>  final ClassLoader previousClassLoader =
>Thread.currentThread().getContextClassLoader();
>  final ClassLoader newClassLoader = getClassLoader();
>
>  ThreadContext.setApplication(application);
>  try
>  {
>if (previousClassLoader != newClassLoader)
>{
>  Thread.currentThread().setContextClassLoader(newClassLoader);
>}
>
> --
> Hideyuki TAKEUCHI
>
>
> (11/04/01 16:55), Martin Grigorov wrote:
>
>> Are you sure ?
>> See WicketFilter's code and the usage
>> of org.apache.wicket.protocol.http.WicketFilter.getClassLoader()
>> ReloadingWicketFilter overrides this method so the reloading class loader
>> should be used in init() and doFilter().
>>
>> 2011/4/1 Hideyuki TAKEUCHI
>>
>>  Hi all,
>>>
>>>  From Wicket 1.5, ReloadingWicketFilter does not work.
>>> It seems a classloader from WicketFilter.getClassLoader()
>>> isn't used on instancing WebApplication (WicketFilter.java:281).
>>>
>>> The below code works correctly, but ad-hoc.
>>>
>>> public class MyWicketFilter extends ReloadingWicketFilter {
>>>  static {
>>>ReloadingClassLoader.includePattern("myapplication.web.**");
>>>  }
>>>
>>>  @Override
>>>  public void init(boolean isServlet, FilterConfig filterConfig)
>>>  throws ServletException {
>>>// force it to use ReloadingClassLoader
>>>Thread.currentThread().setContextClassLoader(getClassLoader());
>>>
>>>super.init(isServlet, filterConfig);
>>>  }
>>> }
>>>
>>>
>>> Anyone has an idea how to fix this?
>>>
>>> --
>>> Hideyuki TAKEUCHI
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com 


Re: ReloadingWicketFilter does not work on Wicket 1.5-rc2

2011-04-01 Thread Hideyuki TAKEUCHI

Hi Martin,
Thanks for your reply.

Yes, Please see in WicketFilter.init(boolean, FilterConfig).

public void init(final boolean isServlet,
final FilterConfig filterConfig) throws ServletException {
  this.filterConfig = filterConfig;

  applicationFactory = getApplicationFactory();
  application = applicationFactory.createApplication(this);
  application.setName(filterConfig.getFilterName());
  application.setWicketFilter(this);

... after that ...

  final ClassLoader previousClassLoader =
Thread.currentThread().getContextClassLoader();
  final ClassLoader newClassLoader = getClassLoader();

  ThreadContext.setApplication(application);
  try
  {
if (previousClassLoader != newClassLoader)
{
  Thread.currentThread().setContextClassLoader(newClassLoader);
}

--
Hideyuki TAKEUCHI

(11/04/01 16:55), Martin Grigorov wrote:

Are you sure ?
See WicketFilter's code and the usage
of org.apache.wicket.protocol.http.WicketFilter.getClassLoader()
ReloadingWicketFilter overrides this method so the reloading class loader
should be used in init() and doFilter().

2011/4/1 Hideyuki TAKEUCHI


Hi all,

 From Wicket 1.5, ReloadingWicketFilter does not work.
It seems a classloader from WicketFilter.getClassLoader()
isn't used on instancing WebApplication (WicketFilter.java:281).

The below code works correctly, but ad-hoc.

public class MyWicketFilter extends ReloadingWicketFilter {
  static {
ReloadingClassLoader.includePattern("myapplication.web.**");
  }

  @Override
  public void init(boolean isServlet, FilterConfig filterConfig)
  throws ServletException {
// force it to use ReloadingClassLoader
Thread.currentThread().setContextClassLoader(getClassLoader());

super.init(isServlet, filterConfig);
  }
}


Anyone has an idea how to fix this?

--
Hideyuki TAKEUCHI

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







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



Re: [ANNOUNCE] Wicketopia 0.9 Released...

2011-04-01 Thread Maarten Billemont
Without knowing what RAD or Scaffolding is about, the examples on your site 
really make very little sense to me.

You show a method, getDescription, with a bunch of annotations on them.  You 
don't show what this method is a part of, or how that actually ties in with 
your actual wicket code underneath.

The wicket Java code example shows a wicketopia Scaffold component that takes a 
wicketopia Widget class and a Spring persistence provider.  How could this 
possibly be useful to me?  What does it do?  How does it tie in with my 
insanely annotated getDescription method?

Also, does wicketopia depend on Spring?  That would be a really *really* big 
downside.  I don't need any frontend library telling me what persistence 
framework to use, and Spring is about much more than just persistence.  
Abstract that stuff.

Perhaps when I can understand what Wicketopia is without having to UTSL, I'll 
consider giving it a try.  Assuming I don't also need to suffocate my code 
under the weight of Spring.

On 31 Mar 2011, at 19:34, James Carman wrote:

> Wicketopia is a Rapid Application Development (RAD) library for
> Wicket.  There is some documentation available at:
> 
> http://wicketopia.sourceforge.net
> 
> The official release will be available in the main maven repository
> shortly, but you can download it via SVN (and run the example
> application) by doing:
> 
> svn co 
> http://wicketopia.svn.sourceforge.net/svnroot/wicketopia/tags/wicketopia-parent-0.9/
> wicketopia
> 
> I am trying to clean up the code a bit and tie up some loose ends, but
> I got the Scaffold component working, so I thought that at least
> deserved a release.  Plus, I wanted to make sure my release process
> was all ironed out before 1.0.
> 
> Thanks,
> 
> James
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


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



Re: ReloadingWicketFilter does not work on Wicket 1.5-rc2

2011-04-01 Thread Martin Grigorov
Are you sure ?
See WicketFilter's code and the usage
of org.apache.wicket.protocol.http.WicketFilter.getClassLoader()
ReloadingWicketFilter overrides this method so the reloading class loader
should be used in init() and doFilter().

2011/4/1 Hideyuki TAKEUCHI 

> Hi all,
>
> From Wicket 1.5, ReloadingWicketFilter does not work.
> It seems a classloader from WicketFilter.getClassLoader()
> isn't used on instancing WebApplication (WicketFilter.java:281).
>
> The below code works correctly, but ad-hoc.
>
> public class MyWicketFilter extends ReloadingWicketFilter {
>  static {
>ReloadingClassLoader.includePattern("myapplication.web.**");
>  }
>
>  @Override
>  public void init(boolean isServlet, FilterConfig filterConfig)
>  throws ServletException {
>// force it to use ReloadingClassLoader
>Thread.currentThread().setContextClassLoader(getClassLoader());
>
>super.init(isServlet, filterConfig);
>  }
> }
>
>
> Anyone has an idea how to fix this?
>
> --
> Hideyuki TAKEUCHI
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com 


ReloadingWicketFilter does not work on Wicket 1.5-rc2

2011-04-01 Thread Hideyuki TAKEUCHI
Hi all,

>From Wicket 1.5, ReloadingWicketFilter does not work.
It seems a classloader from WicketFilter.getClassLoader()
isn't used on instancing WebApplication (WicketFilter.java:281).

The below code works correctly, but ad-hoc.

public class MyWicketFilter extends ReloadingWicketFilter {
  static {
ReloadingClassLoader.includePattern("myapplication.web.**");
  }

  @Override
  public void init(boolean isServlet, FilterConfig filterConfig)
  throws ServletException {
// force it to use ReloadingClassLoader
Thread.currentThread().setContextClassLoader(getClassLoader());

super.init(isServlet, filterConfig);
  }
}


Anyone has an idea how to fix this?

--
Hideyuki TAKEUCHI

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



Re: [ANNOUNCE] Wicketopia 0.9 Released...

2011-04-01 Thread julien roche AKA indiana_jules
That seems very cool !!

Many thanks for your great job

Julien Roche

On Fri, Apr 1, 2011 at 9:02 AM, nino martinez wael <
nino.martinez.w...@gmail.com> wrote:

> very nice with the scaffold component!!
>
> Any examples of it?
>
> 2011/3/31 James Carman :
> > Wicketopia is a Rapid Application Development (RAD) library for
> > Wicket.  There is some documentation available at:
> >
> > http://wicketopia.sourceforge.net
> >
> > The official release will be available in the main maven repository
> > shortly, but you can download it via SVN (and run the example
> > application) by doing:
> >
> > svn co
> http://wicketopia.svn.sourceforge.net/svnroot/wicketopia/tags/wicketopia-parent-0.9/
> > wicketopia
> >
> > I am trying to clean up the code a bit and tie up some loose ends, but
> > I got the Scaffold component working, so I thought that at least
> > deserved a release.  Plus, I wanted to make sure my release process
> > was all ironed out before 1.0.
> >
> > Thanks,
> >
> > James
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: [ANNOUNCE] Wicketopia 0.9 Released...

2011-04-01 Thread nino martinez wael
very nice with the scaffold component!!

Any examples of it?

2011/3/31 James Carman :
> Wicketopia is a Rapid Application Development (RAD) library for
> Wicket.  There is some documentation available at:
>
> http://wicketopia.sourceforge.net
>
> The official release will be available in the main maven repository
> shortly, but you can download it via SVN (and run the example
> application) by doing:
>
> svn co 
> http://wicketopia.svn.sourceforge.net/svnroot/wicketopia/tags/wicketopia-parent-0.9/
> wicketopia
>
> I am trying to clean up the code a bit and tie up some loose ends, but
> I got the Scaffold component working, so I thought that at least
> deserved a release.  Plus, I wanted to make sure my release process
> was all ironed out before 1.0.
>
> Thanks,
>
> James
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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