Jon, I didn't understand 100% what you meant in the first part
of your discussion. What do you mean by "this then adds them to the
wrong container"? The problem, as I see it, is that any components
nested into <wicket:component> will not have a parent and you only
discover the parent at render time -- nor will the <wicket:component>
have a parent until its parent is rendered too). This sound similar to
what you are saying but somewhat different... can you please explain
what you meant a bit differently?
Thanks,
Gili
On Wed, 02 Feb 2005 09:07:42 -0800, Jonathan Locke wrote:
>
>i made some comments on this problem back on 12/30... the problem isn't
>too simple and we
>need to solve it carefully. it could be that we need to create some
>reparenting code to solve
>the problem. basically, as gili points out, wicket components should
>not know anything about
>their container. they just call "add". this then adds them to the
>wrong container during Page
>construction. then at render time, we encounter the wicket:component
>tag and insert the border
>container. each immediate child encountered during rendering gets
>reparented as a child of the
>border. this has to be done recursively (maintain a stack of
>wicket:component tags) though
>since borders of this type can nest! the other option is to solve the
>problem by making the
>component "render-time-only" (see comments on 12/30). i'm not sure this
>is a good idea
>though as it's an unusual special case. probably better to reparent the
>children during rendering,
>essentially inserting the border in the middle.
>
>Gili wrote:
>
>> Ok.... this strikes me as nonsense. Think about it for a
>>second....... I'm a Border component. I don't know, nor do I care, what
>>components are within me because I only define the look on the outside,
>>not inside. I think that Border, unlike conventional Wicket components,
>>is more presentation than model oriented.
>>
>> From the discussion below (constructor time versus render time)
>>it seems pretty clear to me that you'd like <wicket:component> to be
>>added during Page construction time so that you could add its children
>>there so that people can navigate through the model (including them in
>>the hierarchy) before rendering time. So the solution seems pretty
>>clear to me: just scan the Page for <wicket:component> and add() them
>>at construction time... can't we do that?
>>
>>Gili
>>
>>On Wed, 2 Feb 2005 10:56:36 +0100, Juergen Donnerstag wrote:
>>
>>
>>
>>>I was thinking about the "automatically add children" sentence I
>>>wrote. That is probably nonsense, because I don't no how we should
>>>make it taking into account at which time (constructor) the component
>>>tree is build and which time rendering (afterwards) takes place.
>>>Because it probably not clear what I mean:
>>>
>>>time sequence:
>>>1) page constructor:
>>> create the component tree; note: the <wicket:component> will not
>>>yet be available, hence you can not access it (get("myBox").add(xxx))
>>>and add your own component. And the <wicket:component> is not yet
>>>avaiable you can not add children to it during construct.
>>>
>>>2) page.handleRender()
>>> get the markup stream and render the component. Only at this point
>>>in time, the <wicket:component> gets created and automatically added
>>>to the component tree.
>>>
>>>This seems to be not the right way. What about adding the children in
>>>the <wicket:component>'s constructor? I need to think about that one.
>>>
>>>Juergen
>>>
>>>
>>>On Tue, 01 Feb 2005 19:12:22 -0500, Gili <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> I understand now. First, I'm +1 on automatically adding
>>>>children into components created using <wicket:component>. Please let
>>>>me know when you've added it (send me updated a snapshot build via
>>>>email). I'm itching to complete RoundCornerBorder already.
>>>>
>>>> Second, I guess you've clarified my question: Are nested tags
>>>>add()ed into the surrounding Page or surrounding components? The wicket
>>>>approach is rather intuitive from a OO point of view but totally
>>>>unintuitive if you've got any JSP background (you'd expect to add()
>>>>into the Page). I think this is something we should explicitly address
>>>>in our user documentation.
>>>>
>>>> What would really clarify this is to add a Border example to
>>>>the examples package. I'd want to see a Page, a component within and a
>>>>component within that.
>>>>
>>>>Gili
>>>>
>>>>On Tue, 1 Feb 2005 23:52:10 +0100, Juergen Donnerstag wrote:
>>>>
>>>>
>>>>
>>>>>just my 2c note. From a logical point of view that is correct because
>>>>>hellomessage is contained (XML) within myBox. That is how all wicket
>>>>>components work. But I wonder one can add a compoment (helloworld) to
>>>>>the container (myBox). myBox is automatically created (you do not need
>>>>>any java code). Thus, and that is probably the bug, children should
>>>>>automatically be added to the container. I'm fairly sure, we don't do
>>>>>it by now. Not doing it keeps <wicket:component> however almost
>>>>>useless. I'll try to into it as soon as possible.
>>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>On Tue, 01 Feb 2005 14:56:31 -0500, Gili <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>
>>>>>> I've modified the HelloWorld example to contain the following
>>>>>>HTML sniplet:
>>>>>>
>>>>>> <wicket:component name="myBox"
>>>>>>class="wicket.markup.html.border.RoundCornerBorder" width="100%">
>>>>>> <span id="wicket-hellomessage">Here comes the hello world
>>>>>>message...</span>
>>>>>> </wicket:component>
>>>>>>
>>>>>> and I get this error when I run it:
>>>>>>
>>>>>>wicket.markup.MarkupException: Unable to find component named
>>>>>>'hellomessage' in [path = 0.myBox, children = {width=[path =
>>>>>>0.myBox.width]}]
>>>>>>[markup =
>>>>>>file:/C:/Program%20Files/wicket-examples-0.9.17-beta/src/Netbeans4/build
>>>>>>/web/WEB-INF/classes/wicket/examples/helloworld/HelloWorld.html, index
>>>>>>= 5, current = '<span id="wicket-hellomessage">' (line 10, colum
>>>>>>7)]
>>>>>> wicket.markup.MarkupStream.throwMarkupException(MarkupStream.jav
>>>>>>a:247)
>>>>>> wicket.Container.renderNext(Container.java:909)
>>>>>> wicket.Container.renderBody(Container.java:606)
>>>>>> wicket.markup.html.border.Border.resolveComponent(Border.java:15
>>>>>>5)
>>>>>>[snip]
>>>>>>
>>>>>> I'm expecting wicket-hellomessage to resolve within the scope
>>>>>>of HelloWorld (the Page) but it's trying to resolve it within my
>>>>>>Border. Any idea why?
>>>>>>
>>>>>>Gili
>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>>>>>Tool for open source databases. Create drag-&-drop reports. Save time
>>>>>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>>>>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>>>>_______________________________________________
>>>>>>Wicket-user mailing list
>>>>>>[email protected]
>>>>>>https://lists.sourceforge.net/lists/listinfo/wicket-user
>>>>>>
>>>>>>
>>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>>>>Tool for open source databases. Create drag-&-drop reports. Save time
>>>>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>>>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>>>_______________________________________________
>>>>>Wicket-user mailing list
>>>>>[email protected]
>>>>>https://lists.sourceforge.net/lists/listinfo/wicket-user
>>>>>
>>>>>
>>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>>>Tool for open source databases. Create drag-&-drop reports. Save time
>>>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>>_______________________________________________
>>>>Wicket-user mailing list
>>>>[email protected]
>>>>https://lists.sourceforge.net/lists/listinfo/wicket-user
>>>>
>>>>
>>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>>Tool for open source databases. Create drag-&-drop reports. Save time
>>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>>_______________________________________________
>>>Wicket-user mailing list
>>>[email protected]
>>>https://lists.sourceforge.net/lists/listinfo/wicket-user
>>>
>>>
>>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>Tool for open source databases. Create drag-&-drop reports. Save time
>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>_______________________________________________
>>Wicket-user mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/wicket-user
>>
>>
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Wicket-user mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
