You're right, I didn't notice a record was being passed into the
constructor, just that the id was not longer being passed in.
For create, we would inject everything into the constructor and pass
0L to super.
For create, injection is still possible because we pass in an newly
created record to super.
For edit, we still can't inject. Our concrete constructor for edit
would have to look like
@Inject
public ConcreteRecordEditActivity(ConcreteRecordEditView view, R
record, RequestFactory requests, PlaceController placeController) {
super(view, record, requests.getClass(record), false,
requests,placeController);
...
The problem still being the "record" variable here. Even if
assistance was available from GIN, I would still prefer to be able to
set the "creation" flag in the ctor and set the record after I've been
able to pass in the place information to the activity.
On Sun, Aug 15, 2010 at 7:25 PM, Thomas Broyer <t.bro...@gmail.com> wrote:
>
>
> On 15 août, 19:47, Patrick Julien <pjul...@gmail.com> wrote:
>> On Sun, Aug 15, 2010 at 11:04 AM, Thomas Broyer <t.bro...@gmail.com> wrote:
>>
>> > On 15 août, 03:38, Patrick Julien <pjul...@gmail.com> wrote:
>> >> I would like to point out that this patch addresses the following issues
>>
>> >>http://code.google.com/p/google-web-toolkit/issues/detail?id=5106
>> >>http://code.google.com/p/google-web-toolkit/issues/detail?id=5115
>>
>> > It sure addresses issue 5106, but I don't think it changes anything as
>> > far as issue 5115 is concerned (i.e. you still need GIN's
>> > AssistedInject or some kind of parameterized factory –which is what we
>> > currently do, as we use GIN 1.0 which doesn't have AssistedInject–)
>>
>> Gin 1.0 doesn't have AssistedInject. If you inherit from the abstract
>> edit activity that in this patch, you longer need any assistance to
>> inject the concrete type
>
> I'm afraid I don't understand: you cannot "auto-inject" (i.e. with
> GIN) the record into the activity, as that would mean that either you
> always create new records or always edit the same record (depending on
> whether you'd use @Singleton scope of not).
> You *have* to construct the activity with the record (ID currently, or
> instance with the patch) to be edited; it's not a dependency, and you
> therefore cannot depend on GIN (or whatever) to inject it.
> Just in case we're not talking about the same thing, I'm refering to
> this line:
> http://gwt-code-reviews.appspot.com/717801/diff/53001/54040#pair-58
>
> FYI, our own factory looks like (GWT 2.1.0.M2):
> public static class Factory { // defined as a nested class in our
> record edit activities
> �...@inject Provider<FooRecordEditView> view; // let's use the concrete
> type to avoid an explicit bind from RecordEditView<FooRecord> to
> FooRecordEditView; the (private) constructor still takes a
> RecordEditView<FooRecord>
> �...@inject Provider<MyRequestFactory> requests; // we use providers for
> lazy-init
> �...@inject Provider<PlaceController> placeController; // some other
> dependency
>
> public FooRecordEditActivity create(String id) {
> return new FooRecordEditActivity(view.get(), id, requests.get(),
> placeController.get());
> }
> }
> I'm expecting to replace it with AssistedInject when GIN will release
> a new version.
>
> Our ActivityMapper is injected such a Factory and calls create() with
> the record ID extracted from the Place.
>
> (and we created a RecordPlace very similar to the ProxyPlace proposed
> in the patch; except it holds a Class<? extends Record> and the record
> ID, instead of a record instance)
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
