Can WICKET-2150 please be fixed in 1.5-SNAPSHOT
Hi guys,
Can someone of the committers please implement the fix to Wicket-2150 in
the trunk. It was postponed from 1.4 to 1.5 and I really need this, but
it is not yet in the 1.5 codebase (as far as I can see). The code that
needs to be changed is the delegateSubmit-method in the Form and it
should read something like this:
protected void delegateSubmit(IFormSubmittingComponent
submittingComponent)
{
/* WICKET-2150: execute the onSubmit's from most general to most
specific */
// when the given submitting component is not null, it means
that it was the
// submitting component
Form? formToProcess = this;
if (submittingComponent != null)
{
// use the form which the submittingComponent has submitted
for further processing
formToProcess = submittingComponent.getForm();
}
// Model was successfully updated with valid data
formToProcess.onSubmit();
// call onSubmit on nested forms
formToProcess.visitChildren(Form.class, new IVisitorForm?()
{
public Object component(Form? component)
{
Form? form = component;
if (form.isEnabledInHierarchy()
form.isVisibleInHierarchy())
{
form.onSubmit();
return IVisitor.CONTINUE_TRAVERSAL;
}
return IVisitor.CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER;
}
});
// most specific
if (submittingComponent != null)
{
submittingComponent.onSubmit();
}
}
Thanks very much,
Dave
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Can WICKET-2150 please be fixed in 1.5-SNAPSHOT
I don't know about the tests, but in the snapshot repository there are
1.5-SNAPSHOT binaries. My application is not yet in production, so I
(think I) can manage the rough edges of working with a development
release. On top of that, I want to make sure it is in 1.5.
What would be a reason not to put it in the trunk yet?
Martin Grigorov wrote:
How the fix in 1.5-SNAPSHOT will help you ?
Currently 1.5-SNAPSHOT is not even buildable (at least the tests), so it
is not quite ready for use.
On Fri, 2010-01-15 at 09:07 +0100, Dave Schoorl wrote:
Hi guys,
Can someone of the committers please implement the fix to Wicket-2150 in
the trunk. It was postponed from 1.4 to 1.5 and I really need this, but
it is not yet in the 1.5 codebase (as far as I can see). The code that
needs to be changed is the delegateSubmit-method in the Form and it
should read something like this:
protected void delegateSubmit(IFormSubmittingComponent
submittingComponent)
{
/* WICKET-2150: execute the onSubmit's from most general to most
specific */
// when the given submitting component is not null, it means
that it was the
// submitting component
Form? formToProcess = this;
if (submittingComponent != null)
{
// use the form which the submittingComponent has submitted
for further processing
formToProcess = submittingComponent.getForm();
}
// Model was successfully updated with valid data
formToProcess.onSubmit();
// call onSubmit on nested forms
formToProcess.visitChildren(Form.class, new IVisitorForm?()
{
public Object component(Form? component)
{
Form? form = component;
if (form.isEnabledInHierarchy()
form.isVisibleInHierarchy())
{
form.onSubmit();
return IVisitor.CONTINUE_TRAVERSAL;
}
return IVisitor.CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER;
}
});
// most specific
if (submittingComponent != null)
{
submittingComponent.onSubmit();
}
}
Thanks very much,
Dave
-
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: Localizing thru database lookup
Damn, you're right (thanks). An oversight on my part. I guess I have to do some work on the Localizer as well, so that localizations pulled from the database are not cached by the Localizer as well. Regards, Dave Uwe Schäfer wrote: Dave Schoorl schrieb: updates the cached value. Of course, when you use an ORM-tool, you can alternatively use it's second level cache. i recently look in that corner, and iirc you don´t have to cache them at all, because wicket does in a layer above (when running in prod). cu uwe - 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: Localizing thru database lookup
I get my localized data from the database. I do that by creating a class that subclasses org.apache.wicket.resource.loader.ComponentStringResourceLoader. My subclass interacts with the database through a dao. Then in the init-method of my Application, I register my implementation through a call to: getResourceSettings().addStringResourceLoader(new MySubclassOfComponentStringResourceLoader()); //Dave Mathias Nilsson wrote: I have used .properties and .xml files in all of my Wicket projects and it has worked great. However, quite often someone in the translation team wants to changes some text, image or something else that is localized in the properties files. Has anyone moved propeties to database with success? Something like component // The wicket component language // the language country // the country variant // the variant key // the key value // the actual value This could allow text to be changed thrue a web form. If the text was changed a callback to the resource loader to refresh the value. Can anyone lead me to the right path of implementing this. What classes should I look at? Has someone used something like this and is the .properties, .xml preferred over the database? It would be nice to not have to redeploy the whole application if just a text should be altered. // Mathias - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Nested forms not working in wizard.
Could this be related to this issue:
https://issues.apache.org/jira/browse/WICKET-2150 ?
Ned Collyer wrote:
The nesting is -
The outer form is inside the wizard, then I have an inner form inside
one of the steps.
Sorry, I cant show you the output of the html - I scrapped the impl I
had am implementing a less wizardy wizard.
On Mon, Jul 6, 2009 at 8:36 PM, nino martinez
waelnino.martinez.w...@gmail.com wrote:
Is the form nested in the other form in html. I remember vaguely
something about it needs to be nested, wicket then rewrites it or
something like that.. How does the resulting html look like?
2009/7/6 Ned Collyer ned.coll...@gmail.com:
I am currently running wicket 1.4-rc2
I have nested forms setup in the wizard. One of my steps is as follows.
code
public class MyStep1 extends WizardStep {
public MyStep1(final CompoundPropertyModelCampaign campaignModel) {
super(Step 1, Wow bananas);
add(new Form(form) {
@Override
protected void onSubmit() {
super.onSubmit(); --- never fired
}
});
}
}
/code
The wizard successfully navigates between steps, and validation occurs
against any fields in the nested forms.
The onSubmit of the inner form is never fired - this is ... pretty annoying :)
Any ideas?
-
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
Component lifecycle question
Hi list, I want to create the UI of a MarkupContainer after it has been added to the component hierarchy, because I need to get to the Page for information needed in constructing the UI. MarkupContainer.onBeforeRender() just doesn't smell right and passing the Page as an argument in the construction of the MarkupContainer is too bloated. What is the suggested best way to accomplish what I want? Thanks in advance, Dave - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
Maybe Eric Evans Book 'Domain-Driven Design'? Kaspar Fischer wrote: James, Eduardo, Jeremy, thank you very much for your input! I follow your discussions with great interest. Can you recommend a book on this sort of questions? I have read books on Spring and Hibernate but not from this high-level point of view. Cheers, Kaspar On 24.03.2009, at 17:38, Eduardo Nunes wrote: Ok I got it. One question, consider that you have this model: Person 1xN Address You have a screen that list a detailed view of a person, including a list of addresses. What approach do you use to implement it? - A service method that returns a Person entity with eager load of the list of Addresses? (if you don't need always the addresses this doesn't make sense) - A service method that returns a Person entity with lazy load of the list of Addresses? (it could be a problem in a JEE environment) - Two service methods, one to return the Person entity and another one to return the of addresses? Thanks, Eduardo S. Nunes On Tue, Mar 24, 2009 at 1:11 PM, Jeremy Thomerson jer...@wickettraining.com wrote: Agree again. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 24, 2009 at 11:11 AM, James Carman jcar...@carmanconsulting.com wrote: On Tue, Mar 24, 2009 at 12:08 PM, Eduardo Nunes esnu...@gmail.com wrote: Yes, I understand you too. What do you do when you have to send a set of entities and a calculation for each entity? you encapsulate it inside another class? A domain-driven design advocate would say that the entity knows how to calculate what you need and you can ask it for the calculated value. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: how to build lastest 1.3.x jar
On the wicket site they mention a SNAPSHOT repository at
repositories
repository
idorg.wicketstuff/id
nameWicket Stuff Repository/name
urlhttp://wicketstuff.org/maven/repository/url
/repository
/repositories
When you look with your webbrowser, you can see that at this moment the latest
snapshot is from March 3: wicket-1.3-20090303.231013-289.jar.
HTH
NHSoft.YHW wrote:
I can not found where to get lastest 1.3.x jar file, so I build from source,
but there always has error.
check out lastest code from
http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.x;, then build
with mvn installl, but build failure because some test case run error. so
I build with mvn -Dmaven.test.skip=true install as wicket site said, but
there has some error, detail information
INFO] [bundle:manifest {execution: bundle-manifest}]
[WARNING] Warning in manifest for
org.apache.wicket:wicket-extensions:jar:1.3-SN
APSHOT : Superfluous export-package instructions: [org, org.apache,
org.apache.w
icket, org.apache.wicket.extensions.ajax,
org.apache.wicket.extensions.ajax.mark
up, org.apache.wicket.extensions.ajax.markup.html.form,
org.apache.wicket.extens
ions.ajax.markup.html.repeater,
org.apache.wicket.extensions.ajax.markup.html.re
peater.data, org.apache.wicket.extensions.markup,
org.apache.wicket.extensions.m
arkup.html, org.apache.wicket.extensions.markup.html.image,
org.apache.wicket.ex
tensions.markup.html.repeater,
org.apache.wicket.extensions.markup.html.repeater
.data, org.apache.wicket.extensions.util,
org.apache.wicket.extensions.validatio
n]
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.wicket:wicket:jar:tests:1.3-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.wicket
-DartifactId=wicket -
Dversion=1.3-SNAPSHOT -Dclassifier=tests -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=org.apache.wicket -DartifactId=wicket
-Dv
ersion=1.3-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file
-Dur
l=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.wicket:wicket-extensions:jar:1.3-SNAPSHOT
2) org.apache.wicket:wicket:jar:tests:1.3-SNAPSHOT
--
1 required artifact is missing.
for artifact:
org.apache.wicket:wicket-extensions:jar:1.3-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
anyone could help me how to build, or where to get lastest build jar files,
thanks.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wizard and onSubmit of nested form
I created the following Jira issue for this:
https://issues.apache.org/jira/browse/WICKET-2150
Dave Schoorl wrote:
Thanks. But I've dug a little deeper and it turns out that the panel
switching is done in the onSubmit() of the Wizard's NextButton. The
Form's onSubmit() is executed after that, so that will execute the
onSubmit() of the replaced (read: next) nested Form.
I don't think that is correct, so I will be preparing a Jira issue
later today.
But I am still looking for a work around (or maybe a permanent
solution that can be submitted as a patch).
Regards,
Dave
rmattler wrote:
Show us your code and I'll see if I can help.
Dave Schoorl wrote:
Hi Robert, thanks for your quick reply.
I am not sure if I understand what you mean. How is form validation
helping with the trigger of onSubmit() on the correct form?
But I gave it a try and the problem remains: the onSubmit of the
next step is called instead of the current step. I think that first
the panel of the current step is replaced with the panel of the next
step and then the onSubmit is executed.
Hope someone can help me.
Regards,
Dave
rmattler wrote:
Use public void validate(Form form)
See example below. Hope it helps.
private final class Step2 extends WizardStep {
public Step2() {
setTitleModel(new Model(Add pictures));
add(new AbstractFormValidator() {
public FormComponent[] getDependentFormComponents() {
return null;
}
public void validate(Form form) {
String dir = Constants.ADD_PROJECT_FILE_PIC_PATH +
getProjects().getTblId();
File filesDir = new File(dir);
if (filesDir.canRead() || filesDir.isDirectory()) {
String[] fileNames = filesDir.list();
if (fileNames.length 0) {
getProjects().setNumPhotos(fileNames.length);
} else {
form.error(Please upload some photos);
}
} else {
form.error(Please upload some photos);
}
}
});
}
}
Dave Schoorl wrote:
Hi all,
I am building my first Wizard with the wizard from
wicket-extensions version 1.3.5. Every step contains a panel with
it's own form, so I have a nested form in the wizards form. I was
expecting that when I click next, the onSubmit of my current form
is called, but it's not. Instead the onSubmit of the form in the
next step is called.
This seems to be related:
http://markmail.org/message/ktpvzvslq5tupo6x
Am I doing something wrong?
Regards,
Dave
-
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
Wizard and onSubmit of nested form
Hi all, I am building my first Wizard with the wizard from wicket-extensions version 1.3.5. Every step contains a panel with it's own form, so I have a nested form in the wizards form. I was expecting that when I click next, the onSubmit of my current form is called, but it's not. Instead the onSubmit of the form in the next step is called. This seems to be related: http://markmail.org/message/ktpvzvslq5tupo6x Am I doing something wrong? Regards, Dave - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wizard and onSubmit of nested form
Hi Robert, thanks for your quick reply.
I am not sure if I understand what you mean. How is form validation
helping with the trigger of onSubmit() on the correct form?
But I gave it a try and the problem remains: the onSubmit of the next
step is called instead of the current step. I think that first the panel
of the current step is replaced with the panel of the next step and then
the onSubmit is executed.
Hope someone can help me.
Regards,
Dave
rmattler wrote:
Use public void validate(Form form)
See example below. Hope it helps.
private final class Step2 extends WizardStep {
public Step2() {
setTitleModel(new Model(Add pictures));
add(new AbstractFormValidator() {
public FormComponent[]
getDependentFormComponents() {
return null;
}
public void validate(Form form) {
String dir =
Constants.ADD_PROJECT_FILE_PIC_PATH +
getProjects().getTblId();
File filesDir = new File(dir);
if (filesDir.canRead() ||
filesDir.isDirectory()) {
String[] fileNames =
filesDir.list();
if (fileNames.length 0) {
getProjects().setNumPhotos(fileNames.length);
} else {
form.error(Please upload
some photos);
}
} else {
form.error(Please upload some
photos);
}
}
});
}
}
Dave Schoorl wrote:
Hi all,
I am building my first Wizard with the wizard from wicket-extensions
version 1.3.5. Every step contains a panel with it's own form, so I have
a nested form in the wizards form. I was expecting that when I click
next, the onSubmit of my current form is called, but it's not. Instead
the onSubmit of the form in the next step is called.
This seems to be related: http://markmail.org/message/ktpvzvslq5tupo6x
Am I doing something wrong?
Regards,
Dave
-
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: Uppercasing inputs
LOL! That sounds scalable!
Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
you can create a convertermodel that takes an instance of iconverter
and uses that to convert the values, then you can subclass textfield,
override initmodel() and wrap any model the textfield had with this
one.
that way everyone is happy!
-igor
On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
LOL! Nah - I would just change all the setters on every domain object to
be:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
Or, maybe I'd use AOP and build an aspect that could automatically intercept
calls to com.mydomain setters that take a single string argument and do the
upper-casing there!
It's makes me smile to think of how many ways a single thing can be done.
Leszek - you should now definitely have plenty of choices. Pick which feels
best / most comfortable for you!
On Wed, Mar 4, 2009 at 5:22 PM, jWeekend jweekend_for...@cabouge.comwrote:
Igor,
Nope, not for me (this time).
Here's the Javadoc for updateModel:
* Updates this components model from the request, it expects that
the
object is already
* converted through the convertInput() call that is called by the
validate() method when a form
* is being processed.
Regards - Cemal
http://jWeekend.com jWeekend
igor.vaynberg wrote:
pft, you guys!
i would go with the simplest!
class uppercasetextfield extends textfieldstring {
public void updatemodel()
{
final String str=getconvertedinput();
setdefaultmodelobject((str==null)?null:str.touppercase());
}
}
done!
-igor
On Wed, Mar 4, 2009 at 3:07 PM, jWeekend jweekend_for...@cabouge.com
wrote:
Jeremy,
I sensed you were uncomfortable with my most Wicket-way suggestion
when
I
read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
previous post on this thread stating that the model doing the
transformation work was on the right track; it is not unusual that
more
than one design can satisfy a given requirement.
Do you like the idea of a model being responsible for conversion of
users'
textual input?
Your article illustrates the use of nested models nicely but on this
occasion I would probably go with
http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's
idea
for a client side, instant gratification, solution, and a custom text
field
with a converter if the conversion can happen later, on the server.
Regards - Cemal
http://jWeekend.com jWeekend
Jeremy Thomerson-5 wrote:
Cemal,
I think I have to respectfully disagree with you here. I describe
what
I
feel is a better solution, and a little bit of why in this blog post
from
a
few months ago:
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
Basically, doing it the way you suggested isn't reusable across many
components - you have to create overridden variants of each type of
input.
Also, a converter (or more specifically, an implementation of
IConverter)
is
supposed to be for transforming a type of object to a string usable in
the
browser / form post / etc, as it's javadoc mentions.
Anyway, as the saying goes there are many ways to skin a cat -
although
the saying isn't that great, I think it applies - there are multiple
ways
of
accomplishing the same thing.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Mar 4, 2009 at 12:04 PM, jWeekend
jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its
convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
Re: a bit of topic but i couldnt resist ....
If I change every MyObject in a String, everything is fine. Perhaps the
MyObject is not obeying the necessary contracts?
See adjusted code below:
import java.util.ArrayList;
import java.util.Collection;
import java.util.Comparator;
import java.util.HashSet;
import java.util.Iterator;
import java.util.TreeSet;
public class TestWithStrings
{
public static void main(String[] args)
{
TreeSetString set1 = getCleanSet();
HashSetString set2 = new HashSetString();
set2.add(johan);
set1.removeAll(set2);
System.err.println(this works: + set1.size() + == 1, and
remaining object is + set1.iterator().next() + == rob);
// add removed back in
set1 = getCleanSet();
// increase the size of set2 with some other random others
set2.add(random1);
set2.add(random2);
// now size is bigger then set1, call removeall again:
set1.removeAll(set2);
System.err.println(this doesnt work: + set1.size() + != 1,
so now both objects stil remain! This is because +
removeAll isnt overwritten by TreeSet and AbstractSet
walks over the smallest set but then compare fails);
// same for retainAll that also compares wrong.
set1 = getCleanSet();
set1.retainAll(set2);
System.err.println(set1 is now completely empty, but it should
have 1 left: + set1);
// so both methods should always iterator through the colleciton
they get and do the compare on its self
set1 = getCleanFixedSet();
set1.removeAll(set2);
System.err.println(now this works: + set1.size() + == 1,
and remainng object is + set1.iterator().next() + == rob);
// add removed back in
set1 = getCleanFixedSet();
set1.retainAll(set2);
System.err.println(set1 is now correct, it has 1 left: + set1);
}
public static TreeSetString getCleanSet() {
TreeSetString set1 = new TreeSetString(new ComparatorString(){
public int compare(String o1, String o2)
{
return o1.compareToIgnoreCase(o2);
}
});
set1.add(johan);
set1.add(rob);
return set1;
}
public static TreeSetString getCleanFixedSet() {
TreeSetString set1 = new MyFixedTreeSetString(new
ComparatorString(){
public int compare(String o1, String o2)
{
return o1.compareToIgnoreCase(o2);
}
});
set1.add(johan);
set1.add(rob);
return set1;
}
public static class MyFixedTreeSetE extends TreeSetE
{
public MyFixedTreeSet(Comparator? super E comparator)
{
super(comparator);
}
@Override
public boolean retainAll(Collection? c)
{
ArrayListE list = new ArrayListE();
Iterator? e = c.iterator();
while (e.hasNext()) {
Object next = e.next();
if (contains(next)) {
list.add((E)next);
}
}
boolean modified = list.size() size();
if (modified)
{
clear();
for (E item : list)
{
add(item);
}
}
return modified;
}
@Override
public boolean removeAll(Collection? c)
{
boolean modified = false;
for (Iterator? i = c.iterator(); i.hasNext(); )
modified |= remove(i.next());
return modified;
}
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: a bit of topic but i couldnt resist ....
I think it is a bug in the Eclipse plugin. Thankfully, it's Eclipse and
not Sun, so this bug can be solved very fast ;)
Dave Schoorl wrote:
I do understand your point. However you are dealing with multiple
contracts and not all of them are satisfied. And sometimes contracts
are conflicting and it is impossible to meet all contracts, but I
believe this is not the case in your scenario.
A TreeSet is an implementation of a Set and must obey the Set
contract. Adding order to the Set should not break the Set contract,
because if I have a Set, I should not be concerned with the
implementation details (is it a TreeSet or a HashSet or whatever). I
believe the Set contract takes precedence over the Comparator
contract, but in your case, by providing an equals method to MyObject
that is in line with the Comparator, there still is no problem. See
the code below, where MyObject implements the equals method with by
comparing case insensitive:
import java.util.ArrayList;
import java.util.Collection;
import java.util.Comparator;
import java.util.HashSet;
import java.util.Iterator;
import java.util.TreeSet;
public class CorrectedMyObjectTest {
public static class MyObject {
private final String aString;
MyObject(String str) {
aString = str;
}
@Override
public String toString() {
return aString;
}
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((aString == null) ? 0 :
aString.toLowerCase().hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (!(obj instanceof MyObject))
return false;
MyObject other = (MyObject) obj;
if (aString == null) {
if (other.aString != null) {
return false;
}
} else if (other.aString == null) {
return false;
}
return aString.compareToIgnoreCase(other.aString) == 0;
}
}
public static void main(String[] args) {
TreeSetMyObject set1 = getCleanSet();
HashSetMyObject set2 = new HashSetMyObject();
set2.add(new MyObject(johan));
set1.removeAll(set2);
System.err.println(this works: + set1.size() + == 1, and
remaining object is + set1.iterator().next() + == rob);
// add removed back in
set1 = getCleanSet();
// increase the size of set2 with some other random others
set2.add(new MyObject(random1));
set2.add(new MyObject(random2));
// now size is bigger then set1, call removeall again:
set1.removeAll(set2);
System.err.println(this doesnt work: + set1.size() + != 1,
so now both objects stil remain! This is because
+ removeAll isnt overwritten by TreeSet and
AbstractSet walks over the smallest set but then compare fails);
// same for retainAll that also compares wrong.
set1 = getCleanSet();
set1.retainAll(set2);
System.err.println(set1 is now completely empty, but it should
have 1 left: + set1);
// so both methods should always iterator through the
colleciton they get and do the compare on its self
set1 = getCleanFixedSet();
set1.removeAll(set2);
System.err
.println(now this works: + set1.size() + == 1, and
remainng object is + set1.iterator().next() + == rob);
// add removed back in
set1 = getCleanFixedSet();
set1.retainAll(set2);
System.err.println(set1 is now correct, it has 1 left: + set1);
}
public static TreeSetMyObject getCleanSet() {
TreeSetMyObject set1 = new TreeSetMyObject(new
ComparatorMyObject() {
public int compare(MyObject o1, MyObject o2) {
return o1.aString.compareToIgnoreCase(o2.aString);
}
});
set1.add(new MyObject(johan));
set1.add(new MyObject(rob));
return set1;
}
public static TreeSetMyObject getCleanFixedSet() {
TreeSetMyObject set1 = new MyFixedTreeSetMyObject(new
ComparatorMyObject() {
public int compare(MyObject o1, MyObject o2) {
return o1.aString.compareToIgnoreCase(o2.aString);
}
});
set1.add(new MyObject(johan));
set1.add(new MyObject(rob));
return set1;
}
public static class MyFixedTreeSetE extends TreeSetE {
public MyFixedTreeSet(Comparator? super E comparator) {
super(comparator);
}
@Override
public boolean retainAll(Collection? c) {
ArrayListE list = new ArrayListE();
Iterator? e = c.iterator();
while (e.hasNext()) {
Object next = e.next
Re: a bit of topic but i couldnt resist ....
Sorry Pointbreak, I did not change the Comparators. They are identical to Johan's example. All I did was to add the equals() and hascode() methods, aligning the equals with the Comparator, as described by the specs. Indeed, maybe I am missing Johan's point. But early in this thread Johan described his point as we have to know the implementations and illustrated that with the Set-example. My point is that you don't have to know the implementations when all contracts are fulfilled correctly. And I tried to point out in his example, that the contracts are not fulfilled correctly. But now I think Johan tries to make the point that the TreeSet is useless given the contracts, because the Comparator and equals() method must be compatible. Or he tries to make the point that the TreeSet implementation is broken and the specification must be changed. I'm not sure. I can sympathize with both. But I am glad he pointed out the problems with TreeSet, because I wasn't aware of them. Pointbreak wrote: Dave, you are missing the point completely. The issue raised by Johan is that if you call TreeSet.removeAll(otherSet), then in some cases the comperator/equals contract of otherSet is used, in other cases the comperator/equals contract of the treeset. Which is a bit strange, and even by Sun considered a bug (although low priority). You are just making both comperators the same, which of course will not demonstrate this problem. Make the comperator of the TreeSet use str.compareTo instead of compareToIgnoreCase, while keeping your implementation of MyObject the same, and you will have the same problem that Johan illustrated. On Thu, 05 Mar 2009 16:51 +0100, Dave Schoorl mailli...@cyber-d.com wrote: I do understand your point. However you are dealing with multiple contracts and not all of them are satisfied. And sometimes contracts are conflicting and it is impossible to meet all contracts, but I believe this is not the case in your scenario. A TreeSet is an implementation of a Set and must obey the Set contract. Adding order to the Set should not break the Set contract, because if I have a Set, I should not be concerned with the implementation details (is it a TreeSet or a HashSet or whatever). I believe the Set contract takes precedence over the Comparator contract, but in your case, by providing an equals method to MyObject that is in line with the Comparator, there still is no problem. See the code below, where MyObject implements the equals method with by comparing case insensitive: - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: a bit of topic but i couldnt resist ....
Yes, I understand your point. It is also eloquently formulated in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4730113.
Maybe try to submit a patch via http://openjdk.java.net/ ?
Regards,
Dave
Johan Compagner wrote:
But now you are completely breaking My contact
My object is an database object
MyObject
{
id
name
}
MyObject is only equals if the id is the same
But now i want a TreeSet that orders by name (sometimes case is
important,sometimes not)
Those things are not the same!
I cant make my object equals on name.. That would break everything else!
And that is just not true
I know TreeSet is a special case, but thats the whole point it should always
just use the comparator with everything.
Then it is jus always clear.
if we revert it
HashSet.removeAll(TreeSet)
now suddenly the comparator of the TreeSet is used to remove things from the
HashSet
That is just plain weird and stupid.
johan
On Thu, Mar 5, 2009 at 18:41, Dave Schoorl mailli...@cyber-d.com wrote:
Sorry Pointbreak, I did not change the Comparators. They are identical to
Johan's example. All I did was to add the equals() and hascode() methods,
aligning the equals with the Comparator, as described by the specs.
Indeed, maybe I am missing Johan's point. But early in this thread Johan
described his point as we have to know the implementations and illustrated
that with the Set-example. My point is that you don't have to know the
implementations when all contracts are fulfilled correctly. And I tried to
point out in his example, that the contracts are not fulfilled correctly.
But now I think Johan tries to make the point that the TreeSet is useless
given the contracts, because the Comparator and equals() method must be
compatible. Or he tries to make the point that the TreeSet implementation is
broken and the specification must be changed. I'm not sure. I can sympathize
with both. But I am glad he pointed out the problems with TreeSet, because I
wasn't aware of them.
Pointbreak wrote:
Dave, you are missing the point completely. The issue raised by Johan is
that if you call TreeSet.removeAll(otherSet), then in some cases the
comperator/equals contract of otherSet is used, in other cases the
comperator/equals contract of the treeset. Which is a bit strange, and
even by Sun considered a bug (although low priority). You are just
making both comperators the same, which of course will not demonstrate
this problem. Make the comperator of the TreeSet use str.compareTo
instead of compareToIgnoreCase, while keeping your implementation of
MyObject the same, and you will have the same problem that Johan
illustrated.
On Thu, 05 Mar 2009 16:51 +0100, Dave Schoorl mailli...@cyber-d.com
wrote:
I do understand your point. However you are dealing with multiple
contracts and not all of them are satisfied. And sometimes contracts are
conflicting and it is impossible to meet all contracts, but I believe this
is not the case in your scenario.
A TreeSet is an implementation of a Set and must obey the Set contract.
Adding order to the Set should not break the Set contract, because if I have
a Set, I should not be concerned with the implementation details (is it a
TreeSet or a HashSet or whatever). I believe the Set contract takes
precedence over the Comparator contract, but in your case, by providing an
equals method to MyObject that is in line with the Comparator, there still
is no problem. See the code below, where MyObject implements the equals
method with by comparing case insensitive:
-
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: a bit of topic but i couldnt resist ....
If col1 and col2 both have the (equally) same 5 objects in common with
set 1 and 2, I would expect set1.equals(set2) to return true, otherwise,
I would expect them only to be of the same size.
I think it is not so much about interfaces, but more about contracts.
Not everything about a contract can always be expressed in interfaces.
Johan Compagner wrote:
they are not the same (and yes talking about java)
And yes removeAll() and remove() are just working and implemented
More stranger thing is
Set set1 = aSetWithSize10;
Set set1 = aSetWithSize10; // different instance, same kind of set same
values
Collection col1 = aCollectionWithSize5;
Collection col2 = aCollectionWithSize15;
col1 and col2 both have 5 objects that are also in the set1,2, and the rest
is just random other stuff
now
set1.removeAll(col1)
set2.removeAll(col2)
now is set1.equals(set2) ?? (or are the sizes the same)
johan
On Wed, Mar 4, 2009 at 02:41, jWeekend jweekend_for...@cabouge.com wrote:
Johan,
The question is phrased in such an ambiguous way that it's not even clear
if
you're using Java!
If your col1 and set1 refer to the same object then your foreach is not
going to get very far (concurrent modification) so I'll assume thatcol1
!= set1 .
From a non-functional perspective (acceptable performance, for instance), a
smart implementation of removeAll may loop around the smaller of the two
collections, unlike your foreach. Now that may seem irrelevant, but if
col1 is a hashed (and well hashed) the removeAll may finish in an
acceptable
timeframe if it is an optimised implementation whereas your for loop code
could go on for longer (potentially, unacceptably long).
Functionally, the first problem you face is that both remove and removeAll
are optional, so either one, or even both of your snippets may just throw
an exception at you. If they both throw the same exception, I suppose you
may even argue that your 2 snippets are functionally the same for those
implementations of the two collections! If only one throws an
UnsupportedOperationException then they are not equivalent.
The question of the Set being sorted or not is also interesting, but may be
a red herring if remove and removeAll are implemented consistently (but
they
may not be). If the elements of your collections are Comparables, then it
is recommended but not strictly required that (x.compareTo(y)==0) ==
(x.equals(y)). Comparator's compare method contract is similarly loose.
Put this in your test case:
public void testComparingEquals(){
BigDecimal onePointOh = new BigDecimal(1.0);
BigDecimal onePointOhOh = new BigDecimal(1.00);
assertEquals(0, onePointOh.compareTo(onePointOhOh));
assertFalse(onePointOh.equals(onePointOhOh));
}
... yes, it passes!
That means that you could have elements of the same type in both your
collections and still get a different result from each of your two snippets
depending on the Comparator passed in to a sorted collection referred to by
set1.
I think there may be more stuff that can go wrong here, but let's see where
this thread heads off to!
Regards - Cemal
http://jWeekend.com jWeekend
Johan Compagner wrote:
Is this the same?
Set set1 = xxx
Collection col1 = xxx;
foreach (col in col1)
set1.remove(col)
or
set1.removeAll(col1);
???
--
View this message in context:
http://www.nabble.com/a-bit-of-topic-but-i-couldnt-resist--tp22319709p22321977.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: What does Page Expired mean?
This normally happens when your HttpSession expires. I'm not sure what could be the reason in your case. Edwin Ansicodd wrote: I see in the Page maps documentation: http://cwiki.apache.org/WICKET/page-maps.html that Page Exoured will be shown if the id and version for a page doesn't exist. But I can't see how the id and version of the page would not exist anymore. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
In my current project I do just that and it works fine. I must add that it is a highly interactive application, so I work with long conversations (managed hibernate sessions), where the transaction is committed only after a number of request/response cycles after the user clicks on 'save'. During the conversation my business objects are in persistent state (never detached), and I wrap every business object in a LDM, except I do not load from database, but from EhCache. The only thing that I had to do, is move all validation, even simple syntax checking, like field lengths, required fields etc., out of the business objects, because I create a domain object with a default (no-arg) constructor and add it to the Hibernate session. At that moment, the object has invalid state (required fields have no data etc.) So I have to trust on form validation and/or guide each object through a validator before it is saved to the database or actually used in the domain layer. Maintaining the objects validity combined with the separation of layers is, I think, the only 'pitfall' I encountered that I have not yet found a completely satisfactory answer for. Hope this helps. Stephen Swinsburg wrote: Hi all, I'm after your thoughts on the following method. Suppose there is a wicket form with some fields that can map directly to a simple Hibernate object, and hence a db table. Is it safe to simply wrap this object in a CompoundPropertyModel and use it as the backing model for the form? Then in the onSubmit method, calling a method to get the object from the form's model and saving it via Hibernate. This does work fine, I'm just after any pitfalls that might happen down the track. Very simple form here. thanks. S - 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: Uppercasing inputs
A slightly different approach: I would talk with the customer again,
because this is a really stupid (excusez le mot) requirement. I hope you
understand their motivation, possibly some legacy system that depends on
uppercase information? Maybe the problem can be shifted to that legacy
system that uppercases all data read from the database?
Regards,
Dave
Leszek Gawron wrote:
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased before being written to the model?
my regards
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: HTML creation tool
I have never used DreamWeaver or extensively used any other wysiwyg html/css tool, but I have looked at Amaya (http://www.w3.org/Amaya/) once, and in that whole hour I tried it, it looked interesting. So far I have managed to let other people do the dirty (read: design) work. Edwin Ansicodd wrote: Thank you for your post! Yes, I would imagine a WYSIWYG editor would be best. Are there any open source or freeware tools you like? christian.helmbold wrote: Any css based HTML creation tool recommended by Wicket users? Are you looking for a so called WYSIWYG editor? Adobe Dreamweaver is my favorite. Regards, Christian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket at ApacheCon EU'09 in Amsterdam
I am not sure what you would like to standardize. Given your JPA example, I would guess that you want to push a JSR for a web framework or something. But there is already something like that: JSF. Just let Wicket be Wicket and instead of changing Wicket (and it's community) in the wrong way, let's try to change the views of corporate managers in the right way. As Thomas said earlier What we need is less talks titled 'why wicket is cool' and more 'cut your development costs in two with Wicket' . And I do not think that the lack of support for pushing a JSR has anything to do with a lack of open-mindedness... Hoover, William wrote: I hear the arguments and I completely agree with the notion that innovation usually happens elsewhere and a JSR/JCP would slow that process down. I just want to objectively view the other side of the spectrum :o) From a developers point-of-view standardization can often be a thorn in our side, but for management it can offer a vendor-independent/implementation-independent solution. Maintaining/upgrading infrastructure is difficult, expensive and time consuming. From the point-of-view of management a standard can often minimize the risk of vender lock-in. Another thing to consider is that a broader multi-community involvement could also bread innovation. There may be other innovators from other communities that may have valuable input that could improve Wicket in ways that may have not been previously considered. IMHO, the biggest argument for JSR/JCP is that there is often a broader involvement in the process. Hibernate, for instance, was in a similar position a few years back when they introduced a new persistence concept. They have since become heavily involved in the JPA specification process. When I first worked with Hibernate, like many, I was very impressed (similar to the first time I worked with Wicket :o), but looking back at how Hiberante initially did things to how they do them now there are some huge improvements due to the JPA specification. My hope is that the Wicket community can be as open-minded to this notion as they are to the open source code they represent :o) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket at ApacheCon EU'09 in Amsterdam
I do think that pushing a JSR for Wicket will have a negative influence on the spirit of Wicket and it's community due to the politics involved with a JSR. Politics are so not the Wicket way. This is what I mean with the wrong way and yes, that is mighty subjective. I also expect there will not be enough support from other parties to participate in a JSR (again, highly subjective), because there is nothing for them to gain. Which I believe is one of your main arguments: there will not be a broader input base. But I think Wicket receives enough input since the Wicket developers see what is happening in other projects around them and they take that with them. And without enough support, the JSR will be dropped and I think that in the corporate eye, Wicket will turn into 'that project that didn't make the JSR', and wide adoption will be even further away. But again, without a concrete proposal, I have no idea what the specification request would describe and what the scope of such a JSR would be. Could you elaborate on that? Maybe that clears things up for me. BTW, I think not that Hibernate has grown as a result of the JPA-standard, but that the Java EE standard has grown a a result of the emerging of ORM-tools (like Hibernate, Toplink etc.) and other popular application stacks, like Spring etc. The quality of Hibernate would have increased without the JPA-spec anyway (and ofcourse, there was - and there still is - enough opportunity to improve). Hoover, William wrote: I agree that we need to change the views of corporate managers in the right way by illustrating the cost savings achieved though a reduction in development time. At the same time, I don't believe that this will change the Wicket community in the wrong way (which is a highly subjective statement). I'm only presenting the alternative viewpoint. It is possible that a standard could potentially inhibit progression due to contrasting viewpoints within the community, but it is also equally possible that it could lead to a value-added aspect by introducing a broader input base to the Wicket community that could speed progression (Hibernate/JPA is an example of this). There is always a possibility that progress can be slowed as the number of members increase because there are more viewpoints to be examined/debated. I think that there is a higher probability that the community will grow if such a standard were to be adopted. Just because there is already a specification for a web framework (JSF) that does not constitute abandoning a standard approach. Look at JAX-WS vs JAX-RS. They accomplish many of the same objectives, but they both are part of the proposed profile stack (http://www.theserverside.com/tt/articles/article.tss?l=JavaEE6Overview) . A Wicket implementation could orchestrate a refreshing alternative approach to JSF in the same manner that it does today. When I referred to open-mindedness I was referring to being open-minded to the ideas behind the push... I didn't necessary intended to imply that anyone would not be open-minded if they did not support a JSR :o) -Original Message- From: Dave Schoorl [mailto:mailli...@cyber-d.com] Sent: Friday, February 13, 2009 9:21 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I am not sure what you would like to standardize. Given your JPA example, I would guess that you want to push a JSR for a web framework or something. But there is already something like that: JSF. Just let Wicket be Wicket and instead of changing Wicket (and it's community) in the wrong way, let's try to change the views of corporate managers in the right way. As Thomas said earlier What we need is less talks titled 'why wicket is cool' and more 'cut your development costs in two with Wicket' . And I do not think that the lack of support for pushing a JSR has anything to do with a lack of open-mindedness... Hoover, William wrote: I hear the arguments and I completely agree with the notion that innovation usually happens elsewhere and a JSR/JCP would slow that process down. I just want to objectively view the other side of the spectrum :o) From a developers point-of-view standardization can often be a thorn in our side, but for management it can offer a vendor-independent/implementation-independent solution. Maintaining/upgrading infrastructure is difficult, expensive and time consuming. From the point-of-view of management a standard can often minimize the risk of vender lock-in. Another thing to consider is that a broader multi-community involvement could also bread innovation. There may be other innovators from other communities that may have valuable input that could improve Wicket in ways that may have not been previously considered. IMHO, the biggest argument for JSR/JCP is that there is often a broader involvement in the process. Hibernate, for instance, was in a similar position a few years back when they introduced a new
