> I went through all that not only for your benefit :), but also because I > have a question. Currently, when I mark a component as protected, I add the > Component to a List on the Page (protectedComponents) so that onBeforeRender > doesn't have to go to every child Compoennt of the page (which could end up > being a pretty deep, dense tree) looking for protected components. Is > storing a List of Components bad? How expensive is it to traverse through > all children looking for a MetaDataKey? > > On a related note, how expensive is it to look for a specifc type of Parent > of a Component?
I wouldn't be too worried about that. You can get your profiler out of the shed (YourKit is an excellent one that is very affordable) and see how much it will cost you, but in general I wouldn't be too worried about the CPU expenses of such operations. Something that should always be in the back of your mind when you work with Wicket is the memory consumption. Though the fact that Wicket depends on session memory for it's workings is nothing to panic about, you have to consider that this is a deliberate tradeoff: 'memory for a better programming model'. So, in this case, keeping that list does increase that load somehow. Probably nothing serious, but I'd rather focus on that cost instead of the CPU cost. > Thanks, I know that was a lot to read, but I LOVE working with Wicket versus > the home-made solution that we currently use, but I need to build this kind > of stuff into the framewrok before I can unleash the rest of my team on it > and your help and insight are invaluable! Always good to hear that people like what we're all working on here. Concerning your case, I would still do it a bit differently. It's the old push vs pull thing. You decided to push the info you need by overriding onBeforeRender (also consider onAttach btw), visiting the children and push any state in them that will be accessed again when rendering. Why not turn that around? When the components are being rendered (which works as visiting in itself btw), you should have the same information available as with your visit action. Why not, instead of having that visit method interpret the authorization, convert it to the proper meta data, which is then interpreted by the auth strategy, just let the auth strategy interpret directly? The advantages of that is that it keeps everything more simple (you don't need the meta data), cheap in CPU and memory, and you'll only evaluate the components that are actually rendered (otherwise, your visit should filter on visible and enabled). Just my 2c, Eelco ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
