Juergen Donnerstag wrote:
this isn't actually a problem since getAssociatedMarkup() will not read the markupthinking out loud
in order make sure the associated markup is read just once, I'd
probably read the markup in the constructor not add().
more than once. it will be loaded only the first time and then found in the markupCache
on subsequent calls. in fact, as it is, markup will only be loaded from disk once /ever/.
the only way it will ever be re-loaded is if the change detection code finds that the file's
timestamp changed.
compent names nested inside a wicket:component still need to be
unique, because wicket:components are "anonymous". Except you do
get("myBox").add(new Label("helloworld"...). correct?
well, no, i was thinking you just say add(new Label("helloworld", ...))then add would be smart enough to figure out that there is an intervening wicket:component
that needs to be added first.
this would be the most intuitive way for it to work. whether we can make that happen is
another matter...
if we're going to force people to name wicket:component nodes and then use that name in
the java code, we might as well abandon the idea altogether since the point of wicket:component
is to enable seamless presentation-only components so that designers can just insert borders
as they see fit without requiring any code changes. i think that goal is worthy if we can figure
out how to accomplish it elegantly.
Constructor will not read the markup, it will also add
<wicket:component>s which are immediate children (not nested
children).
the constructor can always call getAssociatedMarkup() at negligible expense.
it could add the wicket:component children... but until add() is called, it won't be clear
which border to add the children to anyway, so it makes sense for all this logic to be in add()
container.add() checks against the Markup that the component nameyes. this can be very tricky though... the simple case works as you suggest. but in more
exists. Else throw an error.
complex containers like pages, you can have out-of-order container construction where
a deeply nested structure is composed from the bottom up using java local variables to
hold the intermediate container hierarchy results. in this case, checking cannot be done
until the nested structure is finally added to the container because the nesting is being
defined by java local variables until add() is called. make sense?
i'm thinking, btw, that there is some elegant solution to this problem... i just haven't quite figured
it out yet...
container.add() will also add <wicket:component>s which are immediateyes, but the component being added may itself be a container with children already added to it
children (not nested children) of the component just added (nested
components).
thanks again to java out-of-order construction (relative to the markup).
container would keep a transient ref to the Markup for the render process.
container already transient refs the markup:
/** The markup stream for this container. */ private transient MarkupStream markupStream;
Though add() is available to valid that a component with the giventhat is true now, yes. i'm not sure if add() can stay simple and solve this problem in the way we'd
name is required, only render() (some method after constructor) is
able to validate that all components have been added.
like to solve it...
Juergen
------------------------------------------------------- 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
