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 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 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
>
>


-- 
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 unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to