You can do this by binding List<MenuElement> references annotated with a particular marker annotation to a specific implementation of List<MenuElement>, which preloads itself with the required elements.
e.g. Set up annotations called @FileMenu, @EditMenu ... and Guice can look for these and bind to the right preloaded list. This also allows you to mock the real lists out with dummy ones for testing, if necessary. Bit brief cos I'm sending this from my phone, but I can add code examples later if it helps. I can't guarantee that the gurus consider this to be the right approach though :-) Andrew. On 23 Dec 2008, at 09:30, Luis <[email protected]> wrote: > > Dhanji, when you say: > > "I would go so far as to say it's an abuse to ask the dependency > injector to build your GUI for you. " > > I agree... it was a bad example. But again I am sure there are other > cases where this makes more sense. > > From the "philosophic" point of view I think the answer is now clear > to me. But I am still not sure about how does Guice handle this kind > of situations: > > class MenuTree extends MenuElement { > @Inject List<MenuElement> items; > } > > I assume that all that Guice can do is to inject an empty list for > you, right? > > Thank you for your response, > > Luis. > > On Dec 23, 9:35 am, "Dhanji R. Prasanna" <[email protected]> wrote: >> On Tue, Dec 23, 2008 at 7:22 PM, Luis <[email protected]> wrote: >> >>> Thank you Brian and Brian (what a coincidence, I got two replies >>> from >>> two different Brians). >> >>> The GUI example was just that, an example... and maybe not the best >>> one. Here is another one: >> >>> Let's say I want to build a menu composed of menu items and >>> submenus. >>> Each menu item has a label and an associated action, etc. If you >>> externalize that information in YAML, this is how it could look >>> like: >> >>> items: >>> - label: Menu item 1 >>> activity: activity 1 >>> - label: submenu A >>> items: >>> - label: subitem a1 >>> activity: activity a1 >>> - label: subitem a2 >>> activity: activity a2 >>> - label: Menu item 2 >>> activity: activity 2 >> >>> As I said before I am not an expert on Spring but I think that this >>> could be easily expressed as a Spring-based XML bean definition, and >>> this menu tree structure could then be instantiated on runtime >>> through >>> a single line of code. >> >>> Is there an equivalent way to do this with Guice? (and yes, I know >>> Guice does not read XML but that is supposed to be an advantage, >>> not a >>> limitation). In that respect, it seems to me that other DI >>> frameworks >>> can also be used as flexible builders in order to instantiate >>> arbitrary object trees, whereas Guice is only able to create object >>> trees that explicitly match the Java code structure, so a given Java >>> class can only generate a single object tree which will always look >>> the same, except maybe for constant values for basic object types >>> such >>> as int or String. >> >>> To put it another way, how can you use Guice to build something like >>> this? >> >>> class MenuElement { >>> @Inject String label; >>> } >> >>> class MenuItem extends menuElement { >>> @Inject Action action; >>> } >> >>> class MenuTree extends MenuElement { >>> @Inject List<MenuElement> items; >>> } >> >>> And then I want it to instantiate an arbitrary menu structure for my >>> application, for example the above YAML structure. >> >>> As far as I can tell Guice is not enough, and some builder has to be >>> developed around it. For example I could create a builder that >>> receives a Guice Injector instance and uses it to create the object >>> trees/graphs by reading a file or even by using an EDSL. >> >>> Please correct me if I am wrong... notice that reading from an >>> external file is not a requirement: the way Guice avoids XML is >>> nice, >>> and I wonder if it can be useful for this example too. >> >> Yes this is essentially right. This is sometimes called the robot >> legs >> problem. I think you are much better served using a builder than any >> framework driven system. It is idiomatic, flexible and type safe in >> the Guice way. You can inject the builder itself with whatever you >> need in normal Guice fashion. >> >> I would go so far as to say it's an abuse to ask the dependency >> injector to build your GUI for you. >> >> Dhanji. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
