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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to