I am looking at the Orchard source and am looking for where the IOchardServices gets its concrete injected. I realize that all one has to do is specify the IOchardServices as a param in a controller constructor and it'll get injected, but I want to know where Autofac actually does it. I was looking at '/Orchard/Environment/OrchardStarter.cs' and there are many builder..... calls and so it looks like injection is occurring there; did a search in that file for IOchardServices and didn't find it.
The reason I'm interested in this is, I need to do property injection on aspx pages' codebehind since our team will only be able to slowly migrate over to Orchard CMS and we'll need to keep our existing pages as is, well without too much modification. I also assume that when we have our own custom interfaces we'll want to inject and will need to know the best place to do this.
The actual injection is done within Autofac itself, not in the Orchard code. The autofac-configuration is done by several autofac-modules within Orchard-modules.
When you want to migrate to Orchard, you can just start by first using Autofac without Orchard. Define logical interfaces and put the Autofac-configuration in application_start in your global.asax. See here and here for examples.
Related
I look more tutorial about MVC. But I didn't understand, people are using "BaseController" for what? In one project someone use it forcommunication between all controller. In other project someone use for get logs. Can you explain to me completely?
It is a very common practice for some developers to create a "BaseController" or really, a BaseAnything class to use for common functionality, and then derive other things from that BaseWhatever in order to reuse that functionality. This is just basic Object Oriented Programming techniques, and have nothing specific to do with MVC (other than the fact we're talking specifically about a BaseController in this instance).
There are some, and I happen to be among them, who believe that explicit Base classes are often a code smell, and are often severely abused as "catch alls". All too often, people put all kinds of stuff in these base classes for convenience, because it's easier than creating some other mechanism to share code or data in a better way.
I avoid Base classes unless absolutely necessary. I tend to prefer other methods to achieve the functionality that is often achieved this way (I call it lazy reuse). Examples of alternatives are:
Extension Methods
Html.Action methods
Attribute Frameworks, such as AOP
Dependency Injection
and many more..
You may create a base class with the best of intentions, and claim it will only be used for a very limited function... but before you know it, others that are developing in your project are stuffing all kinds of stuff in there.
My rules is, Just don't do it. Avoid creating a base class at all costs, unless there really is no other good way to do it.
*NOTE: I'm referring to concrete base classes used for the sole purpose of sharing implementation/data. Generic and abstract base classes are a bit of a different story, as are base classes used for Taxonomy (ie is-a relationships) and hierarchical purposes. In general, if you have called something FooBase or BaseFoo, it's probably of this type.
There are also other exceptions to this rule, such as when wrapping an untestable class for testing purposes, you often create a base class for this purpose, or in frameworks you sometimes deliberately build a base class that is intended to be inherited, but isn't generic or abstract. It's there to provide functionality to fit within the framework. But, these are not things you often have control over when using those frameworks.
this is not compulsory to use basecontroller in application but its like same you using master page for your all pages in application where you can keep your common functionality for your pages same applying here. while calling action method from each controller you require different common functionality like
exception handling
master page level settings
common custom authorization.
common custom caching
common model on master page level
so everytime if you call for different controller and its action, you need to regenerate same and this you can rebuild or handle through basecontroller.
Hope this will help to resolve your question.
I'm new to Symfony2 and would like to know the proper place to put my universal helper class. The helper class contains things like removeCurseWords, uplodFile, resizeImage, watermarkImage, convertDateToServerTime, doStuffHere and other things used by many but belong to none. I want this class to be accessible to all the bundles in my app so where do I place it to make it available to all.
Group those methods and put them in services (see http://symfony.com/doc/current/book/service_container.html). That way you can use them cross-bundle via the service container. You could have one service for all image operations and one for the rest which doesn't fit elsewhere.
If you have your php Library i suggest you to write a bundle that wrap it for symfony2 usage for, as example, expose the functionality as services container, manage the initialization, implement for type and so on for enable your library in yhe symfony2 way, then you can share via composer in other projects.
See this for further details.
Hope this help
I always create a folder called "Utils" at the same level as Controllers, Repositories, etc Found several people doing it that way too.
How I can inject an array of services from config.yml giving class names (with namespaces) to a controller? I need to run a function from each of this services in the controller. At the moment I use $this->get('service'); in the controller, but I need to make controller independent from services. Is there a way to do this?
Edit
I don't know names and how many services will be injected, though all of them implement an Interface.
Edit2
Well, probably I did not express correctly my thoughts. I have a bundle named Widgets. It has an array of widget names, display widget holders for each widget and with AJAX I get the content and display it. At the moment I have in the Widget controller hardcoded some widget deffinitions (title and id for Ajax) and some are retrieved by calling getWidgetList from some controllers from another bundle. Well I need that the list of the widgets wont be hardcoded itself in the widget bundle. I need a way to pass this list from the config.yml. Any ideas?
Injecting an array of services is, generally speaking, not the right approach (even if there was a way to do it, which I don't think there is)
The whole reason you don't want to write container-dependent code is to keep your codebase flexible, lithe, and testable. A variable array of services is, in practice, just a mini container, so if you implemented that you'd just be shrinking the scope of the problem, not eliminating it. You'd still be making your code dependent on an arbitrary bucket of services.
I strongly recommend explicitly defining each service your controllers need (as outlined by the links in the comments from Rufinus and Cerad) or look into using something like the jms/di-extra-bundle.
Update
Maybe you need to do more research on the configuration options available?
How to Create Friendly Configuration for a Bundle
The Config Component
http://symfony.com/doc/current/cookbook/bundles/configuration.html
A site I'm working on has two different pages, and each one is attempting to do the same thing. One of the pages, though still in use, has not been updated and so the code is no longer doing everything it is meant to do.
Rather than continue this wet solution and copy the missing code, I would like to make use of the code that has been updated. Ideally I would copy the function into a helper class or make a base class to provide this functionality, but the one function calls many private functions, and each of the private function mixes business logic with the presentation logic.
I have no documentation and a short time scale, so to do this would not be feasible. So my question is, what are the disadvantages of calling the function on page1.aspx from page2.aspx? It is a shared function so I'm hoping it will be OK but advice would be appreciated.
Sounds like a bloody mess to me. You are not to descript but without really seeing whats going on it is hard to say. If this code is touching dom elements and hitting page cycle events it will probably be a pain. I would say.. take the actual business logic and put it in another class outside of the page and then reference the business logic that way but for dom elements directly webforms is already over complicated I would try staying away from making it worse. Perhaps you can pull these dom elements into a user control and reuse it on both pages? Either way sounds like you have plenty of fun a head of you :)
It would be best if you showed some of the code, but I have to say that if the two methods are Shared, then you're probably ok.
However, such Shared code doesn't belong on either page. It belongs in some other class that can be accessed by both pages.
I have an ASP.NET web site dedicated to reporting on PBX extension stats. It comprises many report pages, with HTML generated almost purely by code-behind (setting a Label control's Text property instead of using Response.Write), using un-parameterised string literal SQL queries that populate By Reference DataTable parameters.
Maintenance pages at least comprise DataGrids and detail forms, but use the same DAL, on e thing for which can be said is that it supports multiple DB servers, with sub-classes each overriding these access methods with their own string literal queries.
What do I need to consider cleaning up this mess? I've already made an almost obvious decision to use a third party reporting solution, and move the queries to stored procs in their respective DB languages, narrowing the diversity of the different DAL classes, and to separate CSS out to shared files, as lots of it is very hidden in C# files!
For your back-end design, I suggest having a class to represent each main table of your database (i.e. a Report class and a User class, for example). Anything that's not an event handler should go in the back-end class files / namespace.
For your GUI, looks like you're on the right track using ASP.NET controls instead of just streaming your data out to the user. However, you may consider objectifying the areas of the page. For example, one of my favorite tricks is to open semitransparent "popup" panels when requiring user input or a something like the Information Bar when displaying a short message.
Consider AJAX and the AJAX Control Toolkit. It's easy to implement (especially in the case of a rewrite) and provides great flexibility. Specifically, I've found Accordions - sometimes even nested within other Accordions - are excellent at organizing overabundances of information.
Edit:
Note that if you were to use AJAX, you basically can't even consider using response.write anymore.
As far as having too much content on the screen, remember Panels have a "Scrollbar" property and DIVs don't without some heavy changes.
Also, I tend to separate my code files by Namespace; but the popular trend is to do so by Class. This is a better option if you have many Developers or if it's likely several classes within a namespace will be checked out or simultaneously modified by different people.
I would consider ditching any custom written DAL and use one of:
iBATIS.NET
NHibernate
SubSonic
You might even end up dropping sprocs entirely.
If you're daring you could try the redesign using Microsoft's MVC implementation.
Whatever approach you take, make sure you write unit tests prior to refactoring any code, verify the tests pass before and after refactoring.