about structure. We can do what you want and put all functionality
into Component and focus on memory footprint but I'm more into
smaller, easily testable, separated etc modules may be at the cost of
a little bit more memory. I think it is worth it. Remember, it is only
the reference to Markup which I want to keep. I don't want to copy the
markup.
i am all for footprint. Component is our base class. Anything we add to that
hits us very very hard in memory consumption.
I don't think we are talkng about different things except that I would
add (not replace or change) additional requirements. E.g. the Markup
is required for the render phase later on as well. If there were a
possibility to search (remember we'll need resolvers for different
user needs to find the markup fragment which we would need to call at
least twice than) the associated markup only once (at constructor
time) than that be better.
thats fine by me. Thats why i said maybe the component could have
getMarkup() or getMarkupFragment() or what ever you want to call it.
And it wouldn't cause any issues if the markup file is changed in
between the constructor and the render phase. You load it at
constructor time, you keep a reference, and as there will not be
anymore request for the markup, if won't be reloaded and not causing
any problem because they are out of sync.
hmm this is a good point.
What if the markup did change for an existing page.
Then for example the markup attributes when a copy is made to make them
mutable for the component wouldn't reflect that.
Maybe we should then really make igors remark happen and only store what
the developer change inside the component and always keep the rest from the markup
That would be better in this situation.. yes. Only size() and entrySet() or values() must then
be carefully looked at if you have a "combined" map that is really 2 maps.
This is true but it is not the point I'm trying to make. IMO keeping a
(lazy) copy of the tag attributes with the Component is not the best
solution. We should rather keep a MarkupFragement (which is not a copy
of the whole Markup as discribed).
That is just what getMarkup() call does what i describe
get the immutable MarkupFragement. But then still we need inside the component
something that is mutable for all the mutable things we want. And for developers
this is just the tags attributes
at render time we have even more things that change like the name of the tag (disabled links)
But i don't think we need that as a mutable thing at construct time.
But can you tell me in some pseude code what you then want to store in the component?
And which part is then component specific? (so the mutable attributes and where are those then stored?)
johan
_______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
