i'm trying to dynamically add the class attribute to the body tag, and i came across this class. but i can't seem to understand how to use this class. i have something like this in my page class (or panel class, as i tried with that too):
add(new BodyTagAttributeModifier("class", "homepage", this));
this doesn't even compile, saying there's something wrong with the 2nd parameter. but i think String is automatically considered a Model in wicket, like the Label class. am i missing something here?
What if you just add an wicket:id to the body attribute and use the AttributeAppender class? Or, if the body attribute already has an id, can't you just use this class?
http://wicket.sourceforge.net/apidocs/wicket/behavior/AttributeAppender.html
Some Wicket Components have this String-to-model-shortcut (like Label), but it's not a general feature. You have to convert your String into a Model manually:
add(new BodyTagAttributeModifier("class", Model.of("homepage"), this));
Related
How do I override a widget in order to provide some custom modifications to one of its property.
For example: Let's say I want to create my own Text widget which will convert whole text to uppercase. I'll do something like:
class MyOwnText extends Text {
MyOwnText(String data) : super(data.toUpperCase());
}
But with this approach, I can't use other properties of Text in my own widget, style, for example. For that, I'll have to add style property in my class constructor like this:
MyOwnText(String data, {TextStyle style}) : super(data.toUpperCase(), style: style);
But Text has got around 12-13 properties, and just to override one, I need to define all of those properties and then their assertion. I'm sure I may not be doing something right. Can anyone please help?
Note: Neither I want to use extension methods nor some client side code. MyOwnText should be a Text.
I get what you wanted to achieve, but I do not recommend to do this.
Why?? - Because most of the class has private variable and they have their separate getter and setter which are expose to the outer front of the class.
Again, If you wanted to for design and func. then you should not extend the widget. Instead you can directly use those in your build method
Why?? - You can't inherit more than one class(Mixin is other way around here)
So ultimately you need to assign properties directly or you could use spread operator
I am creating a custom widget, say "CustomWid" in UiBinder.
And in CustomWid.java file I am writing two constructors
one with zero args like
CustomWid(){....}
another with some args like
CustomWid(String a,String b){......}
So,Now I am using my custom widget in another .ui.xml file,in that .ui.xml file
it is working fine when we give
<my:CustomWid/> alone,
and also fine when we give like
<my:CustomWid a="srt1" b="str2"/> alone
But "MY PROBLEM" is whenever I am trying to give both the tags in the one .ui.xml as
<my:CustomWid/>
<my:CustomWid a="str1" b="str2"/>
Now it is throwing error when i am using both types of tags in a single .ui.xml
I mean How to use my custom widget tag like a prdefined tag?
I am using #uiConstructor, but it showing error
Please developers... I need answer as early as possible
UiBinder will only ever use a single constructor for a given widget: either its zero-arg constructor, or a #UiConstructor (I'm surprised that you say it works when using either one or the other call but not both: one should fail in every case, and one should succeed in every case; if you haven't annotated a constructor with #UiConstructor, then <my:CustomWid/> should always work and <my:CustomWid a="str1" b="str2"/> should always fail)
There are two solutions here:
use setters for the a and b attributes (void setA(String a) and void setB(String b))), and possibly check later (say, in onLoad or onAttach) that you have either none or both of A and B, but not one without the other (if that's your rule).
use #UiField(provided = true) when you need to use the other constructor (if you choose to have UiBinder use the zero-arg constructor –i.e. no #UiConstructor–, then that means you'll have to move the a="str1" b="str2" from the XML to the Java code: #UiField(provided = true) CustomWid myCustomWid = new CustomWid("str1", "str2")).
The first option has my preference.
It Will not show any errors...'
#UiConstructor
public Component(String displayText,String heading)
{
initWidget(uiBinder.createAndBindUi(this));
this.displayText.setText(displayText);
this.heading.setText(heading);
}`
now use another constructor with default parameters also it will work
public Component()
{
initWidget(uiBinder.createAndBindUi(this));
}
now if you add with xml parameters component and without parameters also works in the same page.
I have the following situation. There are two combos on my UI form, one shows the list of vegetables and another one shows a list of fruits.
In my supporting view class I'd like to declare such methods:
#UiFactory
SimpleComboBox<Vegetable> createVegetablesCombo() {
return vegetables;
}
#UiFactory
SimpleComboBox<Fruit> createFruitsCombo() {
return fruits;
}
But it seems that GWT does not recognize parameterized returned types... Every time I get an error:
ERROR: Duplicate factory in class VegetablesAndFruitsView for type SimpleComboBox.
Is it possible to handle this case? Is there a good example of multiple comboboxes on one UI form?
From the perspective of Java (not GWT, not UiBinder, but the Java language itself) at runtime there isn't a difference between SimpleComboBox<Vegetable> and SimpleComboBox<Fruit>. That said, this error is coming from UiBinder's code generation, which is looking for all #UiConstructor methods, and using them to build things.
So what does UiBinder have to work with? From the UiBinder XML, there is no generics. The only way UiBinder could get this right is if you happen to have included a #UiField entry in your class with the proper generics. This then would require #UiField annotations any time there might be ambiguity like this, something GWT doesn't presently do.
What are you trying to achieve in this? You are returning a field (either vegetables or fruits) - why isn't that field just tagged as #UiField(provided=true)? Then, whatever wiring you are doing to assign those fields can be used from UiBinder without the need for the #UiConstructor methods at all.
#UiField(provided=true)
SimpleComboBox<Fruit> fruits;
//...
public MyWidget() {
fruits = new SimpleComboBox<Fruit>(...);
binder.createAndBind(this);
}
...
<form:SimpleComboBox ui:field="fruits" />
If this is just an over-simplification, and you actually plan on creating new objects in those methods, then consider passing an argument in, something like String type, and returning a different SimpleComboBox<?> based on the value. From your UiBinder xml, you could create the right thing like this:
<field:SimpleComboBox type="fruit" />
Is it possible to use a variable inside the error message referring to the label of the form element? It's possible to map custom variables like %hostname% (in email validator) and the %value% is also available, but I'd like to have the form label as well.
I could't find it in the ZF codebase, but the use case is for example that the Zend_Validate_NotEmpty can return a message like:
"The field %label% is required and can't be empty"
Instead of:
"Value is required and can't be empty"
I think it's not possible without subclassing the validators. The Zend_Validate classes are not intended to be used with Zend_Form_Element only. Having a %label% in the message would introduce a coupling between both components.
A possible solution could be to create custom validators by extending Zend_Validate_NotEmpty (or whatever validators you are using) and pass the label to the constructor. This way, you could compose the appropriate message every time you instantiate it.
EDIT:
If you follow the method above, you could even define your own %label% "magic variable" and attach it to a member of the class. See the $_messageVariables member in the Example #2 in the Zend Framework documentation: Writing validators
Hope that helps...
I finally went with the decorator. The solution of dinopmi is possible, however you need to inject the label all the times. My error decorator for the form element replaces now the %label% to the real label.
This may sound very weird, but let's start with an example:
<my:MagicWidget ui:field="someFieldName" fieldName="someFieldName"/>
It's pretty much asured that we'll always want to have the same value in ui:field and in fieldName. Clearly there is some duplucation in this code, I'd like to avoid it and make the fieldName optional.
So, this is what I have in the widget's code:
#UiConstructor
public MagicWidget(String fieldName) {
this.fieldName = fieldName;
}
But I'd like, if possible to allow this constructor to be optional, and provide an default constructor that would "by magic" find out it's ui:field value:
#UiConstructor
public MagicWidget() {
this.fieldName = /*some magic to get ui:field's value*/;
}
I was wondering if there is a way to get the value of "ui:field" inside my MagickWidget? (The widget extends Composite). I fear this might not be possible, because most of the time it's not so useful, but if anyone has an idea - feel free to share!
PS: I'm using GWT 2.1.0.RC1.
As you may know, the ui:field is there so you can interact with a UI Object in Java code after you've declared it with UiBinder. So, for example, if you add a MagicWidget in a UiBinder template, you can write
#UiField MagicWidget someWidget
in order to be able to interact with it programatically. Having your magic widget aware of the name of the reference that is pointing to it might not be all that helpful (or possible), as you can pass the reference to that specific MagicWidget back and forth between different parts of your application. A single MagicWidget could easily have several references with different names pointing at is simultaneously. That's why it's difficult to pick it out "by magic" at runtime. I realize this isn't much of an issue if you only want this value when the object is constructed, but keep in mind that you're not required to include a ui:field when you add a widget using UiBinder.
Why is it important that the Widget know its field name? Knowing that might make it easier to provide suggestions about other ways to accomplish what you are looking to do.