The easiest way would be to create an application-specific classes
that wraps each kind of window in your application:
class MyNameDialog (
private final Window window;
@Inject
MyNameDialog(Provider<Window> windowSource,
Provider<Label> labelSource,
Provider<InputField> inputFieldSource,
Provider<Button> buttonSource) {
window = windowSource.get();
Label label = labelSource.get();
label.setText("Name: ");
window.add(label);
window.add(inputFieldSource.get());
Button button = buttonSource.get();
button.setText("OK");
window.add(button);
button = buttonSource.get();
button.setText("Cancel");
window.add(button);
}
...
}
This allows you to plug in different sources for basic UI elements
(perhaps to allow themes). Your other classes could take a
MyNameDialog as a parameter to get an instance of it from Guice.
(This code is a bit awkward because the Provider interface takes no
arguments and can only replace a no-arg constructor. AssistedInject
could be used to fix that.)
Creating wrapper classes for your Windows gives you a convenient place
to put other methods, but if you really don't want it, an alternative
is to implement Provider<Window> yourself and use the @Named
annotation to distinguish the providers of different different
windows:
bind(Window.class).named("myDialog").toProvider(MyDialogProvider.class);
Provider methods will make that easier in Guice 2.0.
- Brian
On Sat, Dec 20, 2008 at 5:09 PM, Luis <[email protected]> wrote:
>
> Sorry if I am asking something too basic but I am totally new to
> Guice.
>
> What stops me for thinking that this is a great framework is that all
> the examples I have seen use objects with a very fixed and predefined
> object graphs. For example object A always contains objects B and C,
> and so forth. But often one needs to create more complex structures,
> where a given object contains a list of other objects, and this list
> varies for each instance. A typical example is for GUIs: using an
> imaginary windowing framework,
>
> Window win = new Window();
> win.add(new Label("Name: ");
> win.add(new InputField());
> win.add(new Button("OK));
> win.add(new Button("Cancel");
> // etc...
>
> So even if I say:
>
> class Window {
> @Inject public void add(Component c) {
> // blabla...
> }
> }
>
> I don't see how can I use Guice to build the above "win" instance...
> and later use it to create another Window instance containing other
> stuff, possibly nesting components such as tabbed panes or whatever.
>
> Is that beyond the capabilities of Guice? I haven't used Spring
> either, but from reading its documentation, it seems to accept
> building beans containing lists, maps, and other arbitrary graphs.
> If Guice does not intend to implement a full Builder Pattern, how do
> you recommend to extend it or combine it with other framework?
>
> Thanks in advance,
>
> Luis.
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
