I'm currently working on a project with symfony 1.4 and Doctrine 1.2. I'm looking for a proper way to do logging from the model layer.
In some model classes I use the record hook postSave() to create a ZIP file using exec() (since PHP zip doesn't provide for storage method 'Stored'). To be sure that everythings works fine I check the return code and log an error if something goes wrong. My first naive approach was to do it like this:
if ($returnCode != 0) {
sfContext::getInstance()->getLogger()->debug(...);
}
As you know, this doesn't work so well because sfContext belongs to the controller layer and shouldn't be used from the model layer. My next try was to use the model's constructor to pass in an sfLogger instance, but this doesn't work due to Doctrine 1.2 reserving the constructor for internal use (Doctrine 1.2 Documentation).
I'm looking forward for your suggestions!
You can add a setLogger() method to your function, that gets a logger instance in a parameter, and sets it to an internal variable, like $this->logger. Later, when you need to log something, do it like if ($this->logger) { $this->logger->debug(...); }.
Related
In the implementation of repositories, you inject the PersistenceManager interface using #InjectPersistenceManager(). For testing, the docs mention to use RunWithDrivine, and to import Drivine (through the AppModule) into the createTestingModule call. This allows the PersistenceManager to be injected in the repository to be used.
I create a temporary Docker container with a new Neo4j database for the tests to use (using a package called testcontainers). This database needs some data to be used. In the test setup, it is possible to get the PersistenceManager by retrieving it from the testing module using a string which normally the decorator provides: app.get("PersistenceManager:default") as PersistenceManager and while this works, it does not seem like the correct way to do it.
How would I get the PersistenceManager to set up the data (and do other things) properly?
app.get("PersistenceManager:default") as PersistenceManager
This is actually probably what you're looking to do, but need to add { strict: false } as a second parameter to the get method. Seeing as #InjectPersistenceManager() is just #Inject('PersistenceManager:database') and database is default by default, you have the correct token, so you probably just need to tell Nest to dig deeper than the top module, hence the{ strict: false } option
What is the best approach to write validation in service layer and pass error to controller? I have found that tutorial: http://www.asp.net/mvc/tutorials/older-versions/models-%28data%29/validating-with-a-service-layer-cs
In this tutorial we pass ModelState to own class called ModelStateWrapper and in service method we pass error to ModelStateWrapper. What do you think about this solution?
The solution you linked is decent.
Basically what's happening is you want to decouple your service layer from your controllers.
So in order to do that you cannot use ModelState. So in this tutorial they create an abstraction around the ModelState and use that instead.
Then in your controller's constructor you would just pass the populated ModelStateWrapper like in the tutorial
_service = new ProductService(new ModelStateWrapper(this.ModelState), new ProductRepository());
I think this is a fine way to do it, another way to do it would just use something like a Dictionary<string,string> for your errors (instead of creating another type and wrapper), and have a utility method somewhere in a base controller or something that would convert this to your ModelState.
Advantage to using just a dictionary is everyone knows what it is, testing it is trivial, and you don't have to keep jumping back to your wrapper class to see how to use it properly, less abstractions ect.
I think either solution is fine.
Please be gentle, I'm a newb to this IoC/MVC thing but I am trying. I understand the value of DI for testing purposes and how IoC resolves dependencies at run-time and have been through several examples that make sense for your standard CRUD operations...
I'm starting a new project and cannot come up with a clean way to accomplish user permissions. My website is mostly secured with any pages with functionality (except signup, FAQ, about us, etc) behind a login. I have a custom identity that has several extra properties which control access to data... So....
Using Ninject, I've bound a concrete type* to a method (Bind<MyIdentity>().ToMethod(c => MyIdentity.GetIdentity()); so that when I add MyIdentity to a constructor, it is injected based on the results of the method call.
That all works well. Is it appropriate to (from the GetIdentity() method) directly query the request cookies object (via FormsAuthentication)? In testing the controllers, I can pass in an identity, but the GetIdentity() method will be essentially untestable...
Also, in the GetIdentity() method, I will query the database. Should I manually create a concrete instance of a repository?
Or is there a better way all together?
I think you are reasonably on the right track, since you abstracted away database communication and ASP.NET dependencies from your unit tests. Don't worry that you can't test everything in your tests. There will always be lines of code in your application that are untestable. The GetIdentity is a good example. Somewhere in your application you need to communicate with framework specific API and this code can not be covered by your unit tests.
There might still be room for improvement though. While an untested GetIdentity isn't a problem, the fact that it is actually callable by the application. It just hangs there, waiting for someone to accidentally call it. So why not abstract the creation of identities. For instance, create an abstract factory that knows how to get the right identity for the current context. You can inject this factory, instead of injecting the identity itself. This allows you to have an implementation defined near the application's composition root and outside reach of the rest of the application. Besides that, the code communicates more clearly what is happening. Nobody has to ask "which identity do I actually get?", because it will be clear by the method on the factory they call.
Here's an example:
public interface IIdentityProvider
{
// Bit verbose, but veeeery clear,
// but pick another name if you like,
MyIdentity GetIdentityForCurrentUser();
}
In your composition root you can have an implementation of this:
private sealed class AspNetIdentityProvider : IIdentityProvider
{
public MyIdentity GetIdentityForCurrentUser()
{
// here the code of the MyIdentity.GetIdentity() method.
}
}
As a trick I sometimes have my test objects implement both the factory and product, just for convenience during unit tesing. For instance:
private sealed class FakeMyIdentity
: FakeMyIdentity, IIdentityProvider
{
public MyIdentity GetIdentityForCurrentUser()
{
// just returning itself.
return this;
}
}
This way you can just inject a FakeMyIdentity in a constructor that expects an IIdentityProvider. I found out that this doesn’t sacrifice readability of the tests (which is important).
Of course you want to have as little code as possible in the AspNetIdentityProvider, because you can't test it (automatically). Also make sure that your MyIdentity class doesn't have any dependency on any framework specific parts. If so you need to abstract that as well.
I hope this makes sense.
There are two things I'd kinda do differently here...
I'd use a custom IPrincipal object with all the properties required for your authentication needs. Then I'd use that in conjunction with custom cookie creation and the AuthenticateRequest event to avoid database calls on every request.
If my IPrincipal / Identity was required inside another class, I'd pass it as a method parameter rather than have it as a dependency on the class it's self.
When going down this route I use custom model binders so they are then parameters to my actions rather than magically appearing inside my action methods.
NOTE: This is just the way I've been doing things, so take with a grain of salt.
Sorry, this probably throws up more questions than answers. Feel free to ask more questions about my approach.
I am trying to make a taglib to represent an object (to read and display at the UI). When creating an object (save method in the controller), I see the domain class and association are created by the auto assignment of parameter
def Book = new Book(params)
It also maps complex types (for eg: joda time). I wonder about the naming convention necessary to facilitate this mapping. Out of curiosity, can someone also point where in the grails source code I could see how grails handles this mapping. I'm still learning Spring and probably this would be a good exercise.
Thanks,
Babu.
AFAIK the naming conventions are rather straightforward. If there's a field params.foo and the object you are binding to has a field foo, it will bind the value, assuming the type conversion works properly. If there's a params.bar.id set with an Long value and your object has a complex property of type Bar, it will lookup this instance and inject it.
If you need more control over the binding process, you might want to use bindData.
If you are interested into the details of the binding process, have a look at Java's PropertyEditor as this is what is being used in the background. I wrote a blog post on how to create and register PropertyEditors a while ago, maybe it helps you getting started with that stuff.
im calling an actionscript class from my main mxml file. the actionscript class is responsible for calling a web service and handling the response, however im having trouble and keep getting the following error; (im new to flex btw)
Error #1009: Cannot access a property or method of a null object reference.
my code goes as follows;
public function getSites(argWsdl:String):void{
ws = new WebService();
ws.loadWSDL(argWsdl);
ws.getSites.addEventListener(ResultEvent.RESULT,echoResultHandler);
ws.getSites();
}
public function echoResultHandler(event:ResultEvent):void {
var siteField:ArrayCollection = event.result as ArrayCollection;
Application.application.setSiteField(siteField);
}
when i run the debugger the code never reaches the result hanlder and i see the #1009 error in the variable list.
any ideas?
looks like you have it sorted, but just to add more information in case someone else comes along to this question, you generally see this error when you are trying to use something that hasn't been created yet. A lot of the time you will see it when trying to access UI components that have not yet been created (its good to rely on the creationComplete event for these sort of things), but in this case it looks like you are using the webservice before it is completely ready (the wsdl hasnt been loaded yet).
Just so you know, you can also define your webservices in mxml (mx:webservice) and specify the wsdl there or you can also load the wsdl later on from a configuration file afterwards just by referencing the ID.
sorted it out,
i needed to created a loadEvent and loadhandler. Once loadWsdl is called the loadhandler specifies the laodHandler to use, inside the loadHandler i call the method name as seen in the wsdl
thanks Ryan,
the main reason im using a seperate actionscript class is so i can reuse the same web service calls across my components without having to retype the same code. I couldnt think of a better way to do this - maybe a could have done the same with a custom component