a prototype is in wicket-sandbox/users/ivaynberg On 6/9/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > 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 > > >
_______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
