Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

U4-11427 : Remove property injection #2690

Merged

Conversation

lars-erik
Copy link
Contributor

@lars-erik lars-erik commented Jun 13, 2018

(Full discussion on tracker under ID from this PR's title)
(see original issue)

HttpModules able to get injection for now. Will continue to see about controllers etc.

…ed) gets dependencies injected through ContainerUmbracoModule.
@ghost ghost assigned lars-erik Jun 13, 2018
@ghost ghost added the review label Jun 13, 2018
Copy link
Contributor

@Shazwazza Shazwazza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple comments but the gist is that the removal of property injection should also mean there are no setters for those properties since they are set only in the ctor. I think any fixme remove ctor's for our built in controllers should be removed indeed. And for the empty protected ctor's, don't we want to call base or this and populate the dependencies based on Current?

I know this is a WIP so things are in flux :) looks great so far!

@@ -36,37 +35,31 @@ public abstract class PluginController : Controller, IDiscoverable
/// <summary>
/// Gets or sets the Umbraco context.
/// </summary>
[Inject]
public virtual UmbracoContext UmbracoContext { get; set; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should not have setters

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Missed it.

@@ -10,5 +16,13 @@
[UmbracoAuthorize]
[DisableBrowserCache]
public abstract class UmbracoAuthorizedController : UmbracoController
{ }
{
protected UmbracoAuthorizedController()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we want to call : base(....) and use Current to populate the dependencies?

Copy link
Contributor Author

@lars-erik lars-erik Jun 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will automagically call the one in UmbracoController. 😋

@lars-erik
Copy link
Contributor Author

\o/

I manage to squeeze in an hour here and there.

@@ -305,7 +305,8 @@ public TFileSystem GetFileSystemProvider<TFileSystem>(Func<IFileSystem> fallback

// fixme - switch to using container. where are these registered?

var fs = (IFileSystem) Activator.CreateInstance(typeof(TFileSystem), shadowWrapper);
//var fs = (IFileSystem) Activator.CreateInstance(typeof(TFileSystem), shadowWrapper);
var fs = Current.Container.GetInstance<TFileSystem>((IFileSystem)shadowWrapper);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Shazwazza seems like you've done something like this before: seesharper/LightInject#237

Got any idea why it complains it can't resolve the dependency? We get this down, we've basically got all tight couplings solved.

See ContainerAdapter.cs line 48 for concrete impl. Basic forwarding of object array to concrete container. (No extension usage)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm, got the hang of it.

lars-erik and others added 3 commits June 26, 2018 00:26
A bit messy, and probably leaves quite a bit of dead / useless code around that should be deleted.
Needs some manual testing.
@@ -44,6 +44,9 @@ public override void Compose(Composition composition)
composition.Container.Register<DatabaseBuilder>();

// register filesystems

composition.Container.Register<IFileSystem, MediaFileSystem>((f, wrappedFileSystem) => new MediaFileSystem(wrappedFileSystem, f.GetInstance<IContentSection>(), f.GetInstance<ILogger>()));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is most likely not covered by any tests. :/
Should look into testing/verifying all composition builders etc. later.

@lars-erik
Copy link
Contributor Author

Getting there. The MediaFileSystem should now be resolved from the container, but get the ShadowWrapper thingy as a runtime argument. A few concrete IO tests fail, most likely due to less stubbed dependency needs.

Otherwise, just MembershipHelper to go. :)

Also took the liberty of adding a "Slow" category to a bunch of integrated tests. Makes it quicker to run "most". (8 vs 16 min on my older box)

…pletely Broken (tm). Need to review whole lifetime & registration of it.
(But OMG! there's nearly no test coverage of Umbraco.Web :O )
@lars-erik
Copy link
Contributor Author

Boom! Done!

At least I hope so. Seems like all the tests are passing, but the Umbraco.Web assembly is sadly lacking in coverage. Guess the MembershipHelper dependencies has to be tested somewhat manually sooner or later.

There's so much more to do, but at least the first task can be ticked off. :)
It's a mouthful, but I hope you can find the time to look over it. Maybe @zpqrtbnk should have a look as well?

I'd really like to get on with abstracting all the registrations as well. Should I make it another PR based off this? Could probably rebase and force push the first one.

@abjerner
Copy link
Contributor

@lars-erik I may not understand all of this PR, but seriously, great job 👍

57f3099a7a77cf5c

@zpqrtbnk
Copy link
Contributor

Going to review all this asap. Excellent!

@lars-erik
Copy link
Contributor Author

\o/

It's interesting to notice the faintly fresher smells of the now huge constructors and weird registration cases. They probably reek a bit of feature envy and possibly SRP breaches (and more). I guess it's worth investigating when through the immediate bits.

On a sidenote - some of the scope and IO tests seem to be failing intermittently. Dunno if that's from these changes or if it's still a bit unstable?

@zpqrtbnk
Copy link
Contributor

FWIW some merge conflicts need to be fixed - have done it locally - now going to test and review code

@zpqrtbnk zpqrtbnk merged commit f6cd134 into umbraco:temp8 Jan 4, 2019
@JimBobSquarePants
Copy link
Contributor

Yay!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants