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.
Related
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' :)
My objective is developing several apps using the same core (code) just have different UI (color, asset's, etc.).
I don't know if I can compare to MVC but I want to reuse the Model and Controller having several Views
Important:
Can be only one project?
For example creating different target or other configuration project..
If I discover a bug I want resolve just once.
Generating separated build's.
The bundle have only the resources that I want (new target right?)
I saw several apps using this (theoretically) like sports apps (soccer, etc).
Thanks
**Edit**** More detail
I think you would like to use this : http://www.raywenderlich.com/41377/creating-a-static-library-in-ios-tutorial
The Core can be a project, in which you're going to define the common classes. These common classes may be controllers and views. From MVC point of view, in your app these will be the Model.
I suggest you to prefer Cocoa (Touch) Framework classes.
I create many apps from a single workspace. I have created separate schemes/targets for each apps. I have separate resources/xib/plist/prefix/build files for each targets. In some places, particular target should execute a specific set of code. For this, I have added unique macros in the target'e prefix files.
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...
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. :)