I've recently started using zend framework 3 for work; and was asked about the possibility of using the same library files within another application, or project.
The application folder 'manufactoring' contains all expected folders within a zf3 structure, such as modules, library, etc.
The question is: can you refer to the library files within 'manufactoring' within another application/project?
This would reduce code duplication.
I have tried answers to other questions on Stack Overflow; however they related to files within the same project.
I was able to link and execute using include or require, which allowed variables to be defined, or functions to be called from a source outside the application/project; however for my use I needed to define a new class, and this method did not work for that purpose.
Any insight would be greatly appreciated.
EDIT: I found this answer from another stackoverflow question: https://stackoverflow.com/a/3272684/10647325 which suggests a solution I am aiming for. This example has a common folder at the same level as the application folders, which contains libraries which can be linked to application folders.
EDIT: I've also tried changing the library path on composer.json. This worked after running composer dump-autoload for migration.
Modules are autoloaded from vendor as well as module, so you'd split the module with code you want to share out into its own repository and then install it using composer in both applications in the same way as you would any other PHP library.
Related
I am using this code: https://github.com/pradeepramakrishna/Lightning-Experience/tree/master/aura-components to compile on my org.
I have got one components as eventLib.lib and interactive.js in eventLib folder. I have put this folder in c:MyDevOrg\force-app\main\default\aura folder in the local machine and tried to deploy in the org using VSCode but it didn't work.
I tried creating folder in the Files tab and added the interactive.js in the folder but that is also not seeming to work with the Aura components.
How can I deploy this lib into the org as it is being used in some Aura components.
We don't know what you're trying to achieve. You asked a very technical question to which the answer is "you're probably doing it wrong". Instead try to write what business functionality you are trying to achieve and you might get better answers.
You shouldn't have to import ui:eventLib. It's supposed to be part of core Salesforce's Aura components framework. But.
You've referenced a repo that wasn't updated in a while, no promises this still compiles / is best way to do X.
This repo seems to rely on open source Aura framework which is well... dead in the water.
You might be able to reuse something from this repo in your app using SF's built-in tags - but whole ui: library has been deprecated. Announced in Winter'20 = almost 2 years ago, finally dead in May 2021.
I don't think eventLib was ever exposed, might be something needed just in open source version which complicates the matter more. The answer would be to not work with the really "decompiled" tags but with their higher abstracted versions like ui:inputDate.
So, back to my question. What exactly are you trying to achieve.
You want to build something on pure SF platform (use pure Aura/LWC).
Want to have an app written in Angular, React etc, pure JS, connecting to SF data via API? (build it, upload as static resourcethen import using lightning:container)
want to prettify an existing Java/PHP/.NET app, make it look more Lightning-ish and embed it as iframe? (look into https://www.lightningdesignsystem.com/ and connected apps + "canvas")
want to expose piece of SF as reusable element that can be embedded in another website but could even be an Outlook plugin? (search for "lightning out")
want to look at modern equivalent of that old open source Aura repo and decide what to do next? Check https://lwc.dev/ out.
I'm currently working on a contract job where I've been asked to help integrate a 3rd party SDK with an existing React Native app. The SDK only comes in Android and iOS specific flavors, meaning that it has to be added on the platform-specific side of things (in my case, the iOS side with Xcode).
For the app, the client has created a react native module which gets built into a Library in Xcode, represented by a separate nested Xcode project in Libraries/MyLibrary.xcodeproj from the root of the base Xcode workspace project. This library has several method stubs defined in React Native which will need to be implemented in Swift (and likewise in Android), as this is in these methods that the 3rd party platform-specific SDK is utilized.
The issue I'm having has to do with accessing the 3rd party SDK framework in the library's existing bridging header file. I have followed every tutorial under the sun for how to integrate external frameworks with an existing Xcode project. This includes steps about adding the framework to the project, adding it under the Embedded Binaries and Linked Frameworks and Libraries sections of the project target, adding it under the Build Phases/Link Binary With Libraries section of both the project target and the library target, and adding the framework path under Project Settings/Framework Search Paths. From here, I add the appropriate import statement to my library's Library-Bridging-Header.h file with #import <MyFramework/MyFramework.h> so I can then access the framework in Swift. (This import statement is copied directly from the bridging header file of the sample project included with the SDK, so I know it is correct and should not be given in a different format such as quotes instead of angle brackets).
Regardless of following all of these steps multiple times over and in various combinations, I still get this error at build time: MyFramework/MyFramework.h file not found.
To clarify, MyFramework is just an alias for the actual 3rd party framework I'm attempting to integrate, and MyLibrary is an alias for the existing library with nothing but method stubs given to me by the client to implement in Swift.
Again, I have read every tutorial and forum under the sun, but none seem to address this very specific issue of integrating a 3rd party framework in a xcodeproj Library within the iOS version of a react native app. I would appreciate any new insights or suggestions anyone might have to offer! And please, please don't just post a link to or copy the steps from existing forum posts about a similar-sounding issue, as I've probably already read it 😉. Understand that I think that there is something subtly unique about my specific circumstances which are causing these same steps from the 10+ articles that come up on the first page of Google and StackOverflow NOT to work.
Figured it out! I'll post my solution here in case anybody out there ever runs into the same issue as me.
TLDR - You must add the 3rd party framework in the root of the xcodeproj Library (NOT the top level project) AND ensure that the files were actually copied into that directory, not just referenced from the directory you copied the framework from (be sure to double-check in Finder, since checking the 'Copy if needed' box doesn't always work for some reason). Then, you must add $(PROJECT_DIR) to your xcodeproj Library's Build Settings/Framework Search Paths, and also drag and drop the framework from the root of your xcodeproj Library into the Library's Build Phases/Link Binary With Libraries panel.
I'll address some of the issues with other tutorials/forums that I found, with hopes that it might help someone else that finds themselves as frustrated as I was in this position.
Most only address adding the framework to the base level project, not the obscure case of a project within a project. Therefore, when you start following the steps, it can be confusing to know whether you should be changing the settings of the top-level project or the sub-project. Again, as I discovered, all changes should ONLY be made to the sub-project.
There are a few tutorials that do seem to address this situation regarding a project within a project, but the steps describe adding the framework to the top-level project under Embedded Binaries and Linked Frameworks and Libraries, but I believe the situation described in these tutorials are somehow subtly different than this situation here. Again, only mess with the sub-project.
There's a lot of discussion out there about "umbrella frameworks", but that doesn't really apply to this situation, and again, the terminology similarities can make it seem like it's a similar issue. As I understand it, "umbrella frameworks" are discouraged by Apple, but again, this situation is not the same.
Sorry for the long-winded explanation, but I'm hoping to provide the kind of detail I would have liked to have found when I was searching for solutions for this weirdly obscure problem.
Cheers!
Currently I have an iPhone app that is just one large project. It has hundreds of code files. I have one folder called "Helper" that includes all of my classes that I have created. I'm going to be making a second app that also needs to use the exact same code that is in the "Helper" folder.
What is the proper way to share that "Helper" code between two projects/apps? Should I put it in its own project file and then add both the main app + "Helper" to a common workspace? I'm not interested in making static libraries or anything... I just want the code segregated somehow.
I've already tried making a second "blank" project file and dragging the code into it, but when I try to build Xcode just thinks I am missing header files now... for some reason it's not seeing the code in the other project.
It would be ideal if there were a clean distinction between the shared code and the code unique to your current app. If there isn't yet, try to make sure everything that will be shared is not dependent on anything from the code unique to the project.
One way you could accomplish this is by using a Git Repo and then making the shared code its own repo project. Then, in the repo for both projects, include the helper code as a submodule.
I've worked with projects that use submodules, though I haven't set up the submodule aspect myself as of yet. The benefit here is that any changes you make to "helper" can be pulled into the both projects, so the changes are synchronized.
If you aren't familiar with Git yet, I recommend getting familiar. Setting up a Git repo on your computer, even if you aren't collaborating with others, is pretty useful. XCode currently offers the option of setting up a repo when you create your project. If you haven't done that, or aren't sure though, you can still create a repo after the fact.
I use source tree to manage my repositories. Creating a repo is pretty straightforward and easy from there SourceTree. However, you can use GitHub's own desktop client, or any other client if you wish - depending on how you set up your project.
Some information about setting up a submodule in git: Setting up a submodule
So, to recap:
Make sure your "helper" code can stand on its own
Put the helper code into its own repo
Include the helper repo as a submodule to any project you want the code in.
Hope that helps!
It sounds to me the situation you have described is exactly what a framework is designed to solve. What you would likely end up doing is creating another project with all of your shared code within it and creating a framework which your applications could link against.
I would suggest reading Apple's Framework Programming Guide. From the introduction to the guide:
Mac OS X makes extensive use of frameworks to distribute shared code and resources, such as the interfaces to the system itself. You can create frameworks of your own to provide shared code and resources to one or more of your company’s applications. You can also create frameworks containing class libraries or add-on modules with the intention of distributing them to other developers.
You can put the shared code in a separate folder and then add it to the both projects.
But don't forget to add the path of the folder to the User Header Search Paths in Build Settings > Search Paths.
I'm not interested in making static libraries or anything...
Yet, for iOS, a static library target is exactly what you'd use.
No workspace required, just a separate Xcode project with that shared static library, which both apps reference.
I completed my very first project in zend framework!! Thanks to stackoverflow community!!
While uploading files, i didn't know how to include zend library so i uploaded the whole library in the /library folder of my project base.
Is there a way to determine which library is used and which in not (like compilation that automatically copies dependent files to library folder incase webhost does not provide zend library ..)? i would be awfully bad to manually add each file and test weather the particular library is added or not.
This answer essentially says don't worry about including the whole library. I usually put the whole library in the project library folder, just like you did.
But if it is truly problematic to include the whole library, you could take a look at Jani Hartikainen's Packageizer which, at least in a previous form that I played with, allowed you to specify the components you needed and it would chase the dependencies and wrap them in a neat little package.
Disk space is cheap. Just have the entire ./Zend library directory (and maybe ./ZendX, if you are using that) into your own library directory where it will used. With autoloading, nothing that isn't being used will take up any significant memory. taking even 5 minutes trying to figure out is time (and therefore money) that is more usefully spent writing code.
I wonder if it would be worthwhile/reliable to subclass the autoloader for this and have it optionally log each class it loads during site operation (sort of how Zend_Translate can log untranslated strings).
You could have it turned off normally but in your testing environment you would turn it on (via your application.ini), and have it build your dependency list while your unit tests are running.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Wether you call it Addons, Plugins or extra peices of code that is connected with the original software later, it really doesn't matter. I would love to understand how they work, there has to be a simple explanation of how to design a Plugin System. Unfortunately, I never understood it, and there remains a lot of open question in my mind. For example, how does the program find a plugin? how does it interface with it? when is it preferable for a software to have Plugin System?
Thanks for all helpful answers. It seems I asked too open question, fortunately I got keywords to look for. I liked David answer though I am not a Java guy, but his talk made sense to me :)
Plug-ins work by conforming to well-known interfaces that the main application expects to work with.
There are several ways in which a plug-in architecture actually works, but in general, these are the steps:
Plug-ins are designed to match an interface that the application expects. For example, a simple application might require that plug-ins implement a IPlugin interface.
Plug-ins are loaded by the application, usually when the app is starting up
Plug-ins are often provided access to much of the data that the application manages. For example, Firefox plug-ins can access the current web page, and Eclipse plug-ins can access the open files.
Here are two ways (out of several) in which an application can find plug-ins:
The plug-ins are known to exist in a particular folder, and the application knows to load plug-ins from that folder
Each plug-in runs as a service, and the services are designed to work together (this is how an OSGi-based application works)
When plug-ins are found, they are loaded by the application (sometimes the job of a Class Loader).
A software architect might design a plug-in architecture when they expect that either the software provider or the user community will implement new features that were not originally part of the system. Two great examples are Eclipse and Firefox; other applications include Adobe Photoshop (for artistic techniques and graphical tools) and Winamp (for visualizations).
Create an interface that all plugins of a particular type will implement
Write the code that will 'consume' the plugin against the interface only.
Have a dynamic way to load a DLL containing the plugin type that implements your interface (for instance, have a configurable folder location to test whether any DLLs in that folder contain any types that implement your interface, and dynamically load any that do. In .NET this might use Assembly.LoadFile())
If you want to have a look at some source code, Paint.NET is free and open source, and has a plugin architecture.
A program typically has to be designed to look for a plug-in, and the plug-in has to have a standard access point to accept control from the main program. Every application or website does it a little differently.
The simplest type of plug-in is accessed something like this:
if (a plug-in exists/is configured)
call predefined plug-in code
In this case, the main program is coded to only handle a specific set of plug-ins (many php-based wordpress templates are like this). A slightly more advanced plug-in
perform application specific logic
if any plug-in exists that exposes the run_after_app_specific_logic function
call plug-in code
This second case can handle ridiculously complex plug-ins ... the plug-in would just need to implement more functions called by the master program.
Eclipse in an example of a application-framework which is entirely plugin-based, meaning that all functionality is implemented as plugins. There is a thin layer at the bottom for startup/shutdown and plugin-management, but everything else is implemented as plugins on top of that. This results in a framework which can be used for just about everything. More info about Eclipse plugin architecture can be found here: http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html.
It's very language dependent.
In an interpreted language it simply involves calling a file that follows a pattern.
In C it's pretty hard to do without help. In C+windows a "DLL" can be a plug-in and are often used that way.
In an OO language with reflection, you might create an object that implements an interface and load it reflectively. After it's loaded, you can ignore the fact that it was a plug-in because it's treated as any other object in your code.
.net has a plugin architecture (is it COM?) Well anyway COM can be used as (is?) a plugin system.
Your question is probably too open-ended because of all the possibilities. There is no single answer.
I've never written a plugin system. But this is how I imagine it in my head:
Your program has a subdirectory for plugins (e.g. "C:\Program Files\My Program Name\plugins").
You create plugins as DLL files and place them in the plugins folder.
These DLLs would export functions with predefined names.
When you run your program, it looks through all the DLLs in your plugins folder. In each one it would look for an exported function with a certain name (e.g. "Load") and call that function. The plugin could then do any setup that it needed to do.
The program would then call an exported function on the plugin with a name like "GetPluginName". The plugin would return it's name and the program could then use that name when it displays a list of plugins to the user.
When it comes time to invoke the plugin, the program would call another exported function (maybe "Activate") and probably pass the plugin a pointer to the data that the plugin is going to work on. The program would then do its work on the data.
The plugin might also export another function that the program would call to show a setup dialog where you could change the plugin options.
A plugin system can be implemented in many ways, but the common way for a lot of C/C++ applications is a DLL-based plugin SDK.
The DLL will expose various automated function calls which may allow the plugin to "set itself up" in the running application such as adding menu items, new functionality or extra options for systems (like 3D rendering implementations).
More ofthen there's no need for any special discovery - the plugin mechanizm is generally dumb: Here's a code signature I understand, and here's a call(s) I can make. I have no clue how the thing I'm calling will do the job, but I expect result to be in certain format. And that is pretty much a contract. Now - the plugin will implement the contract and make itself available. In Java, for example "make available" simply means that implementing classes are loaded into memory. JDBC driver for a particular database would be a good example.