this discussion is really going nowhere, and part of the reason is that we're trying to do 10 other things at the same time as this really sticky problem.
i think as a stopgap measure we ought to go ahead and allow <wicket:component/> (with no nested stuff) but throw a WicketRuntimeException on <wicket:component> (open tag, with potentially nested components).
this would disallow border presentation components FOR NOW and would allow us to defer the problem until we can think it through.
gili, i think your component should be written exactly like any other border component. when we figre out how to support <wicket:component> syntax, your border will start to work that way.
this allows us to wrap things up for 1.0. if we have time, we can address the problem, but there are still a lot of other open issues and there is an easy workaround for this problem (doing the containers in java)
again, we're NOT giving up on this. just closing it temporarily so we can try to get done with the framework as a whole. i'm sure there is a good solution which will occur to us eventually.
Gili wrote:
I never fully understood the whole reparenting version. What actually goes on until the hood? If I have:
M contains V contains M where M = model, V = view
then who is responsible for adding who and what is going on under the hood. Also, what about my "M only add() and see M" and "V only see V" proposal a few days back. Never got a real discussion about it...?
Gili
On Fri, 4 Feb 2005 15:18:07 +0100, Juergen Donnerstag wrote:
I've just committed a re-parenting version. Actually it was very easy once I knew the right solution. Only some small changes to WicketTagComponentResolver were necessary.
I've added a test case and tested it with helloworld.
Juergen
On Wed, 02 Feb 2005 22:39:49 -0500, Gili <[EMAIL PROTECTED]> wrote:
What were your thoughts on this last idea?
Gili
==================BEGIN FORWARDED MESSAGE================== On Wed, 02 Feb 2005 13:01:20 -0800, Jonathan Locke wrote:
i'm not sure. it appears to be a rather complicated problem. how to match up the markup with java components that are potentially constructed and added out of order seems pretty hard to me right now. but maybe i just haven't thought of the right approach.
our fallback for 1.0 would be to remove the wicket:component syntax
altogether.
I think we're thinking too hard here. Bottom line here is that we introduced <wicket:component> because we didn't want to have to construct or interact with visual components on the Java end. In that spirit:
1) Let M denote Model components. Let V denote Visual components. 2) If we have: M contains M, M, V then the parent M has to add() only its two child Ms. The V is ignored. 3) If we have: M contains V contains M, then the parent M has to add the child M. The V is totally ignored by the hierarchy.
V live in their own world and have no concept of the model hierarchy (which is the model, when you think about it). And if you think about it, the M also has no concept of the Vs.
In summary: View components interact with other View components and Model components interact with other Model components -- but no direct interaction with one another. What do you think?
Gili ===================END FORWARDED MESSAGE===================
------------------------------------------------------- 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-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- 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-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
