I've been out for one day. I come back and see a thread with 38
messages. That's crazy !:)
jWeekend wrote:
Leszek,
Thank you asking such a deep question ;-)
We may not all agree, but in the end, at least you have been offered around
87 well-intentioned solutions you can ask your customer to choose from; that
will teach them to request such complex features and fuctionality!
I was really blown by the amount of approaches you all presented. Thank
you for all of them.
Some answers:
1. Dave wrote:
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?
I thought so too but actually it's not that stupid after all. The
customer has to enter A LOT of names, addresses etc. It speeds things up
not to have to think about Proper Word Capitalization. Anything you type
in always looks good.
2. I wanted to go with most non invasive way to do it. That is why I like:
public class UpperCaseBehavior extends AttributeAppender
{
private static final long serialVersionUID = 1L;
public UpperCaseBehavior()
{
super("style", new Model<String>("text-transform: uppercase"), ";");
}
@Override
public void bind(Component component)
{
super.bind(component);
component.add(new AttributeAppender(
"onkeyup", new Model<String>("this.value = this.value.toUpperCase()"),
";"));
}
}
especially used with some nasty logic that would apply the behavior to
every string field.
This is why I find this:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
really ugly. Remember that I have to apply this for 99% of my domain model.
3. Igor, will this work:
class uppercasetextfield extends textfield<string> {
public void updatemodel()
{
final String str=getconvertedinput();
setdefaultmodelobject((str==null)?null:str.touppercase());
}
}
If the form model is a loadable detachable model?
The solution I chose:
@UpperCased
@Entity
@Table(name = "usr")
@Inheritance(strategy = InheritanceType.JOINED)
public class User extends Persistent {
private boolean active = true;
private String code;
@NormalCased
private String username;
@NormalCased
private String password;
private String firstName;
private String lastName;
private Set<Role> roles = new HashSet<Role>();
private String mobilePhone;
private String workPhone;
private String colour;
> }
and:
public aspect Uppercaser {
pointcut setString( String value ) : ( ( set(String (@UpperCased *).* )
&& set(!...@normalcased String *.* ) )
|| set(@UpperCased String *.* ) )
&& args( value );
void around( String value ) : setString( value ) {
proceed( StringUtils.upperCase( value ) );
}
}
because:
1. I decided that the uppercasing should available for junit
tests/command line tools etc.
2. It introduces the least changes into existing code.
3. It allows me to get rid of uppercasing just by recompiling the domain
model library without the aspect (if ever my customer came back to
"sanity").
It feels like I'm introducing way too complicated tool to solve an easy
task (maybe judging by the number of the posts - not that easy after
all), but what the hell...
Thank you for all posts. You are by no means one of the most helpful and
vigorous OS community there is.
PS. I laughed almost to tears reading some posts. Very refreshing :)
--
Leszek Gawron 3.14159265358979323846264338327950288419716939937510
58209749445923078164062862089986280348253421170679
82148086513282306647093844609550582231725359408128
48111745028410270193852110555964462294895493038196
44288109756659334461284756482337867831652712019091
45648566923460348610454326648213393607260249141273
72458700660631558817488152092096282925409171536436
78925903600113305305488204665213841469519415116094
33057270365759591953092186117381932611793105118548
07446237996274956735188575272489122793818301194912
98336733624406566430860213949463952247371907021798
60943702770539217176293176752384674818467669405132
00056812714526356082778577134275778960917363717872
14684409012249534301465495853710507922796892589235
42019956112129021960864034418159813629774771309960
51870721134999999837297804995105973173281609631859
50244594553469083026425223082533446850352619311881
71010003137838752886587533208381420617177669147303
59825349042875546873115956286388235378759375195778
18577805321712268066130019278766111959092164201989
38095257201065485863278865936153381827968230301952
03530185296899577362259941389124972177528347913151
55748572424541506959508295331168617278558890750983
81754637464939319255060400927701671139009848824012
85836160356370766010471018194295559619894676783744
94482553797747268471040475346462080466842590694912
93313677028989152104752162056966024058038150193511
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
