Re: Simple TextField Override and A SubmitLink Question
I have figured out issue #2. My form had a method='get' on it and I
have a very large grid with checkboxes in it, so I suspect that I was
overflowing the request size. Stupid mistake, but the behavior in no
way pointed me towards this. On the observation I made that it seemed
to work when I removed the readOnly logic, I don't know why that made
it succeed in some tests. I can only guess that when testing that
part I chose a record that had fewer detail records to load in the
grid. *shrug*.
However, I am still very eager to get feedback on the first issue
below concerning the onRender.
On 4/21/10, Brian Mulholland blmulholl...@gmail.com wrote:
I am a Wicket n00b. Just learning and writing a demo app to evaluate
Wicket vs a few other MVC solutions which are having demos written by
other developers in the group. I am having two issues.
Issue 1 involves me trying to write a custom TextField to demo the
idea of overriding a control and outputting custom HTML to support it.
The plan was to override the onRender and write out plain text when
the control is disabled instead of writing out a textbox with the
enabled flag set to false (which is the default behavior).
So I wrote a TextField with the following onRender:
@Override
public void onRender(MarkupStream stream)
{
if(this.isEnabled())
super.onRender(stream);
else
{
getResponse().write(getModelValue());
this.renderNext(stream);
}
}
I read about the renderNext on nabble, which resolved one exception I
got, but now it throws exceptions saying that it cannot find the
component as if I declared it in html, but did not add it to the
hierarchy. I know the code outside this render is fine because if I
change the code to keep the super.onRender() call, but merely surround
the super with a span tag with display:none, it works fine.
But I really wanted this style to work as a proof of concept of
overriding the onRender to output whatever HTML we need. Customizing
components to put our custom HTML seems to be Wicket's greatest
feature. But clearly there is some aspect of the onRender contract
that I am missing. The super must be taking care of something that I
am not aware that I am required to take care of. Any Ideas?
Issue 2: Same page. When the page is in readOnly mode, I set a
readOnly flag, set all my controls to disabled, and change what links
show. I am using SubmitLinks. When the page loads the first time one
set of actions is enabled (such as a Modify link) and upon hitting
modify, I set the controls to enabled, and display Save and Cancel
links while hiding the others. But upon getting to the modifiable
mode, none of the SubmitLinks work. I even tried showing all the
links all the time and once I have run a request through the app, none
of the links respond anymore.
However, I found that if I eliminate the code that iterates through my
controls, the links work. I wrote a simple setEnabled method that
uses the IVisitor interface like so:
@Override
public Object component(Component comp)
{
MyBasePage page = (MyBasePage) comp.getPage();
if(FormComponent.class.isAssignableFrom(comp.getClass()))
comp.setEnabled(!page.isReadOnly());
return IVisitor.CONTINUE_TRAVERSAL;
}
Thus each page will inherit from MyBasePage and just change the
readOnly flag. I don't want to disable every Component since I want
some of the links and other things to work. I may have to make this
method smarter in the future, but for now this is pretty close to what
I want...except for the small detail of not actually working. I know
that the links are never getting disabled by this code because I
debugged through it, and also echoed out the isVisible and isEnabled
after the fact. However, when I don't do this, my links refuse to
respond on the 2nd request. Further, the request they stop working on
is when I am ENABLING the controls.
So why if the links are not disabled, might they not be responding
when I click on them. The onSubmit() method of the form never gets
control. I've tried to provide all the information I know. Anyone
have ideas? Even if you don't know what might be wrong, if you can
suggest an avenue of investigation that would be helpful.
Also, what resources do you suggest for a Wicket noob? I've been
looking at the javadoc and the Wicket wiki and the examples on the
apache site. But they all seem fairly light. The javadoc often has
insufficient detail (see the onRender issue), the wiki has large
important sections simply labelled TODO, and the examples seem
mostly slanted toward things that don't really show off the good
stuff. Are there other good resources that I should be using?
Brian Mulholland
--
Brian Mulholland
One of the greatest delusions in the world is the hope that the evils
in this world are to be cured by legislation.
--Thomas B. Reed (1886)
-
To
Re: Simple TextField Override and A SubmitLink Question
Thanks for the response. I have two thoughts.
1) So you would say that expected Wicket best practice would be what?
My control is effectively a TextField. Would I extend
AbstractTextComponent (which I see has almost every property TextField
has) and then add() a TextField and a Label to it, and simple
oscillate their visibility based on my enabled flag? I could see
doing that for this situation.
2) However, I wasn't just curious about this situation, but also the
more general principle. Perhaps there is a better way to skin this
particular cat, but writing components (new or extended from existing
ones) that modify the HTML rendered seems like a sensible and powerful
use of Wicket's component architecture (indeed, it seems to me to be
Wicket's primary advantage). But if the onRender has implicit
undocumented rules, then I will bump into them later on when I am
writing my HTML.
For example, let's say I wanted to write a rich DHTML control out of
divs and spans that effectively is a specialized Grid (or whatever).
I would want to make a custom control that extends the ListView (since
we have alot of properties in common) but render the output HTML my
own custom way. I would assume that overriding the onRender would be
a big part of that, but I need to know the rules for doing so, and I
don't see where they are documented.
I would call this the equivalent of writing my own custom taglibs to
support my application's needs. Wicket's all-java approach has me
drooling of the potential for re-usable bits, but I need to feel
confident that the framework will support that before I sell the
notion to my teammates.
On 4/22/10, Igor Vaynberg igor.vaynb...@gmail.com wrote:
in wicket you would not override the textfield and make it render as a
label, thats what the label component does. you would create a
component that would either add a textfield or a label based on some
condition.
-igor
On Thu, Apr 22, 2010 at 9:42 AM, Brian Mulholland
blmulholl...@gmail.com wrote:
I have figured out issue #2. My form had a method='get' on it and I
have a very large grid with checkboxes in it, so I suspect that I was
overflowing the request size. Stupid mistake, but the behavior in no
way pointed me towards this. On the observation I made that it seemed
to work when I removed the readOnly logic, I don't know why that made
it succeed in some tests. I can only guess that when testing that
part I chose a record that had fewer detail records to load in the
grid. *shrug*.
However, I am still very eager to get feedback on the first issue
below concerning the onRender.
On 4/21/10, Brian Mulholland blmulholl...@gmail.com wrote:
I am a Wicket n00b. Just learning and writing a demo app to evaluate
Wicket vs a few other MVC solutions which are having demos written by
other developers in the group. I am having two issues.
Issue 1 involves me trying to write a custom TextField to demo the
idea of overriding a control and outputting custom HTML to support it.
The plan was to override the onRender and write out plain text when
the control is disabled instead of writing out a textbox with the
enabled flag set to false (which is the default behavior).
So I wrote a TextField with the following onRender:
@Override
public void onRender(MarkupStream stream)
{
if(this.isEnabled())
super.onRender(stream);
else
{
getResponse().write(getModelValue());
this.renderNext(stream);
}
}
I read about the renderNext on nabble, which resolved one exception I
got, but now it throws exceptions saying that it cannot find the
component as if I declared it in html, but did not add it to the
hierarchy. I know the code outside this render is fine because if I
change the code to keep the super.onRender() call, but merely surround
the super with a span tag with display:none, it works fine.
But I really wanted this style to work as a proof of concept of
overriding the onRender to output whatever HTML we need. Customizing
components to put our custom HTML seems to be Wicket's greatest
feature. But clearly there is some aspect of the onRender contract
that I am missing. The super must be taking care of something that I
am not aware that I am required to take care of. Any Ideas?
Issue 2: Same page. When the page is in readOnly mode, I set a
readOnly flag, set all my controls to disabled, and change what links
show. I am using SubmitLinks. When the page loads the first time one
set of actions is enabled (such as a Modify link) and upon hitting
modify, I set the controls to enabled, and display Save and Cancel
links while hiding the others. But upon getting to the modifiable
mode, none of the SubmitLinks work. I even tried showing all the
links all the time and once I have run a request through the app, none
of the links respond anymore.
However, I found that if I eliminate the code that iterates through my
controls, the links work. I wrote a simple setEnabled
Re: Simple TextField Override and A SubmitLink Question
i have written a lot of listviews and repeaters and never had to
override onrender to render html, this is now how wicket is intended
to work. in wicket you attach components to html elements, and the
only contract is that certain components expect to be attached to
certain elements. for example a textfield component is expecting to be
attached to input type=text, while a label has no such expectations.
perhaps you should look at examples we provide or get the wicket in
action book, but i dont think you are thinking about wicket in a
correct way.
maybe think about it this way:
if you were building this using a desktop framework you would not
override onrender to change the behavior and render your own buttons,
instead you would swap in the appropriate pre-built low-level
component.
-igor
On Thu, Apr 22, 2010 at 10:58 AM, Brian Mulholland
blmulholl...@gmail.com wrote:
Thanks for the response. I have two thoughts.
1) So you would say that expected Wicket best practice would be what?
My control is effectively a TextField. Would I extend
AbstractTextComponent (which I see has almost every property TextField
has) and then add() a TextField and a Label to it, and simple
oscillate their visibility based on my enabled flag? I could see
doing that for this situation.
2) However, I wasn't just curious about this situation, but also the
more general principle. Perhaps there is a better way to skin this
particular cat, but writing components (new or extended from existing
ones) that modify the HTML rendered seems like a sensible and powerful
use of Wicket's component architecture (indeed, it seems to me to be
Wicket's primary advantage). But if the onRender has implicit
undocumented rules, then I will bump into them later on when I am
writing my HTML.
For example, let's say I wanted to write a rich DHTML control out of
divs and spans that effectively is a specialized Grid (or whatever).
I would want to make a custom control that extends the ListView (since
we have alot of properties in common) but render the output HTML my
own custom way. I would assume that overriding the onRender would be
a big part of that, but I need to know the rules for doing so, and I
don't see where they are documented.
I would call this the equivalent of writing my own custom taglibs to
support my application's needs. Wicket's all-java approach has me
drooling of the potential for re-usable bits, but I need to feel
confident that the framework will support that before I sell the
notion to my teammates.
On 4/22/10, Igor Vaynberg igor.vaynb...@gmail.com wrote:
in wicket you would not override the textfield and make it render as a
label, thats what the label component does. you would create a
component that would either add a textfield or a label based on some
condition.
-igor
On Thu, Apr 22, 2010 at 9:42 AM, Brian Mulholland
blmulholl...@gmail.com wrote:
I have figured out issue #2. My form had a method='get' on it and I
have a very large grid with checkboxes in it, so I suspect that I was
overflowing the request size. Stupid mistake, but the behavior in no
way pointed me towards this. On the observation I made that it seemed
to work when I removed the readOnly logic, I don't know why that made
it succeed in some tests. I can only guess that when testing that
part I chose a record that had fewer detail records to load in the
grid. *shrug*.
However, I am still very eager to get feedback on the first issue
below concerning the onRender.
On 4/21/10, Brian Mulholland blmulholl...@gmail.com wrote:
I am a Wicket n00b. Just learning and writing a demo app to evaluate
Wicket vs a few other MVC solutions which are having demos written by
other developers in the group. I am having two issues.
Issue 1 involves me trying to write a custom TextField to demo the
idea of overriding a control and outputting custom HTML to support it.
The plan was to override the onRender and write out plain text when
the control is disabled instead of writing out a textbox with the
enabled flag set to false (which is the default behavior).
So I wrote a TextField with the following onRender:
@Override
public void onRender(MarkupStream stream)
{
if(this.isEnabled())
super.onRender(stream);
else
{
getResponse().write(getModelValue());
this.renderNext(stream);
}
}
I read about the renderNext on nabble, which resolved one exception I
got, but now it throws exceptions saying that it cannot find the
component as if I declared it in html, but did not add it to the
hierarchy. I know the code outside this render is fine because if I
change the code to keep the super.onRender() call, but merely surround
the super with a span tag with display:none, it works fine.
But I really wanted this style to work as a proof of concept of
overriding the onRender to output whatever HTML we need. Customizing
components to put our custom HTML seems to be Wicket's greatest
