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
-~----------~----~----~----~------~----~------~--~---