I would like to use a common class file for all the modules. I like to keep all the common variables and arrays in that file.
I had created a folder 'Common' as like as 'Zend' library folder.
And created a class Common.php in that folder.
Afterwards, I initialized use Common/Common in controller;
Created an Object
$common = new Common();
It shown an error.
'Class not found Common\Common'.
How can I do this in ZF2?
It is really suggested you step out of monolithic thoughts with Zend Framework 2. Make modules independent and self-contained. This also means you shouldn't let big all-of-a-kind classes floating around in your application.
If you want to have for example a shared logger instance, make a log module your other modules depend on. Same holds for caching, database connections etc. With me will several others really trying to convince people not to use these kind of strategies.
When you give more insights in why you need a "common" class, perhaps more detailed answers can help you with the architectural decision. Personally I would suggest you to look first at your modular architecture instead of trying to solve this specific problem.
PS. Real answer: probably you have an autoloading issue...
Related
I have a couple third-party libraries (not using cocoapods) in my iOS project, and when I dug into the files of each, I discovered that 4 of these libraries had their own versions of the UIImage+ImageEffects category. So I was about to merge them into one single file, but that got kind of messy:
For instance, one of the libraries, SCLAlertView, has a custom method inside its version of UIImage+ImageEffects which refers back to one of SCLAlertView's classes to access a variable. So if I import that class into the merged file, It would make the new UIImage+ImageEffects dependent on SCLAlertView. I dont feel comfortable about that, and its not pretty. So I need your guys thoughts on this :
What is the best approach to go about this? Should I just go ahead and merge them or keep them as separate files in their respective libraries?
Does having multiple, slightly different, versions of the same category in a project really matter? does it give rise to any issues/conflicts?
i often see this :
Class _NSZombie_OS_dispatch_group is implemented in both ?? and ?? ...
in my console. is this by any chance caused by the above thing?
Thanks in advance.
Note: I didnt give the question a generalized name like "multiple versions of same category in one project" because UIImage+ImageEffects is used by lots of libraries for blur effects and has the most chance of ending up as multiple slightly different versions in your project
Answering 2 will drive the answer to 1 (and 3 sounds like a bug in the system, you should file it :) ):
Does having multiple, slightly different, versions of the same category in a project really matter? does it give rise to any issues/conflicts?
As long as all method names are unique, there isn't a problem outside of the issue that categories on system classes are awful for the long term maintainability of a codebase.
If, however, the categories all have methods of the same name -- which they likely do -- then only one of them will be used and which one is indeterminate.
Thus, yes, you'll need to merge them. Or, better yet, eliminate them entirely by refactoring them into a helper class or something (then file a bug against the original codebase and have 'em pull the changes).
If you build and integrate your 3rd party libs as static libraries, every lib is isolated and uses its own version of the category, and things should work fine. In this case, you should keep the categories internal to the libs and avoid exposing them by means of #include in public headers. EDIT: As pointed out by bbum, category methods are not isolated inside their containing static lib; wrapping the libraries as static libs would not solve the OP's problem.
If you just have one build target and integrate the libs by source, things will work OK as long as the duplicate method implementations don't differ (even though this might result in lots of linker warnings).
Issue will arise if the category implementations differ, because the resulting behavior (i.e. which category method is used at runtime) is undefined (see this post). In this case, I don't know a good solution for the problem; a not good (but working) solution would be to rename (prefix) the methods in each lib's category and use the renamed method in the respective lib. E.g. in lib A, you would rename imageByApplyingLightEffectToImage: to a_imageByApplyingLightEffectToImage: and change all calls to that method inside A accordingly. As I said, I would use this approach as a last resort only.
I am a (very) novice iOS/Swift programmer with a basic question about moving reusable software objects to their own ... something.
I am developing three iPhone apps that present information from three distinct data sets. Those data sets contain unique information but are structurally similar. As such, the apps share some Swift classes that are identical, specifically the classes that model the data. As I continually refactor the code, I find that when I tweak a class in one app's project, I have to remember to go to the other two projects and make the same tweaks to the same classes for those apps. It's getting to be a big headache.
What I would like to do is have one class definition in its own ... something that I can share, link, import, or attach to/from each app's project. From my online research, I suspect that the ... something is a library? or maybe it's a framework? or a module? I have found all three terms are used, but I am not sure how they relate to each other.
Given that all of the software I am writing is in Swift, does Xcode support what I am trying to do? Thank you!
It seems you have the issue of needing the same Swift class in multiple projects. You could build a Framework (aka Module) for this class then copy it in to each project. This is probably the formally correct approach but it is a bit of overkill for just a single class.
Instead, you could just make the file in the Navigator panel a reference in each project to the one actual file.
You could also make a Workspace and then put each project into the workspace and just have the file at the top level (but this may introduce some build complexity).
Im currently working on a iOS project where we now want to add some feature for the Apple Watch. Since the extension for Apple Watch is a different target I naturally can't access the code written for the App. I have searched here on stackoverflow and have found two different ways to solve this problem.
Create a dynamic frameworks. This would definitely be the best approach but unfortunately the app must support down to iOS 6, and what I have found this solution will only work on iOS 8+.
Link the files in either Build Phases -> Compile Sources or through Target Membership in File Inspector. The main problem here is that the two classes we want to use have many dependencies to many other classes, which also have other dependencies and so on. From what I understand I need to include all these other files as well if I want to make use of the classes I intend to use in the extension.
So my question is if there is any other better way for me to accomplish this. If I choose #2, first of all I need to include all files, and after that, from a maintenance point of view, if I make changes to there files, for example importing an other class, I need to include that one as well in Compile Sources / Target Membership. Would really appreciate any ideas or advice regarding this! Thank you!
I don't know how "deep" is your coupling regarding point 2. However if you can use interfaces(protocols) instead of direct class referencing you can separate just the classes you need.
Moreover you could re-think whether specific class really need some other class to operate(probably not) or just some methods from it. Those methods could be moved to protocol and your dependant class to implement it(now this class do not need to be part of AppWatch target).
This will be heavy work though if your project is really big and your classes are tightly coupled. I would advice you to read this article about Dependency Injection and especially 'Dependency is bigger than Testing part' :)
I have written a few razor helpers and these helpers use functions that include the extension methods generated by T4MVC.
I now want to move these to a control library so that they can be used across multiple mvc applications.
The initial idea that I have used is that I can put a copy of the template into the control library, and this works, the downside is that the template used in the application then regenerates the same extension methods in the same namespace.
Because I am using some of the extension that require the interface for the ActionResult I do need that the namespace remains the same.
What I am wondering is, is there a known way to use the extensions in a control library as well as an application that references the library, or is a change to the template required such that the static extension methods can be either generated or not via a flag in the settings file?
I am also wondering if the static extensions could be included in a separate cs file that lives along side the template. So that we have 2 classes T4Extensions and DynamicT4Extensions?
This might force the use of the interface IT4MVCActionResult though,
This is similar but not quite the same as http://forums.asp.net/p/1510753/3603100.aspx.
I wonder if the solution might be to add a new switch in the settings file that would turn off the generation of those static methods. So if you know you're already getting them from some referenced assembly, you'd turn them off in the app.
Though that might still blow up if you have multiple unrelated libraries that each need to use the methods, as the app would then get an ambiguous reference.
Note that we can't make the methods internal, since some of them need to be called from views, which live in different assemblies.
And ideally, I'd prefer to avoid having those in yet a separate file, as some users may start complaining that T4MVC brings in too many files.
Sorry, not really a clear answer, but more thinking through possibilities. :)
I'm adding some non-trivial functionality in my rails application and it needs to be in a module and not one of the auto generated models. I'd like a few suggestions on where the file containing the module should go (currently I've added a 'code' directory on the same level as 'models' and 'views' - but I don't know that that's a strong choice).
Most people add this type of code in lib
If it's related to the controller/view layer, consider putting the functionality in a helper. If not, lib is a good general storage directory for util classes and the like. If at all possible, think about making extra code like this a plugin, as it helps keep the codebase clean and reusable functionality available to other projects.