Note that the prototype does not make a difference between AJAX per component render and Page render. With Wicket there is currently a significant difference. Default page render iterates over the markup and searches (resolves) the component. With the current AJAX implementation you need to first search the markup tag for the component and while rendering you do the reverse (iterate the markup and find the component). We should do just have one.
Juergen On 6/9/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > 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
