I want to have a bunch of settings in my module, and they should be writable from the App. Since they're application settings, I thought a table for it would be not very efficient (it would only have one row).
I found the Zend module Zend\Config, which seems to be able to to write config files, which can in turn be used by Zend.
It is advisable to write into the module.config.php? Or into a different file? Can I still load it into the standard module config?
I am pretty new to Zend and this fully modular approach, so I'd like some clarification on that.
You should never write into the module directory itself. Instead, have a data directory, e.g. at the root of your application, and put written configuration files in there.
Related
Essentially, I'm looking to have a PHP development workflow that needs to be modular, but using a Single Page Application technology.
I understand it is recommended to separate the back-end from the front-end. Develop them separately. But is there a way to group all related code into one module (or folder), meaning all backend code with its own views presentation inside the same folder?
It's like MVC, but the "V" contains fragments of vuejs (or angular) files, which extends from a master file somewhere in your project.
For example
Assume we are building a modular CMS, where you can upload "plugins" (really, PHP modules), extending the CMS' functionality:
-project[root-folder]
----core[folder] # contains all infrastracture code, api routes, master view file, magic, etc.
----modules[folder] # uploadable modules goes here
--------User[folder] # sample module; follows the MVC pattern
------------Controllers[folder] # contains files, e.g. UserController.php
------------Models[folder] # contains User.php
------------views[folder] # where vue components is housed
----------------users/index.php # contains vue code
----------------users/create.php # etc...
----------------users/js/user.js
----------------users/css/user.css
--------Blog[folder] # another module
----index.php # the master view or just the bootstrap file
----gulpfile.js
Then inside the core/ folder, there is a master layout that binds all views together.
Will a folder structure like this be viable?
Obvious problem there is you can't use .vue files (as that would mean, every time you upload a new module, you need to run gulp or re-compile).
Hoping for your feedback. Thanks.
This question will strike a lot of folk as bizarre and twisted. That's the reaction I got when I asked it in the context of .net mvc. I'm with you 100%.
I'm too new to js frontend development (and too ignorant of PHP) to have much advice. It's going to be tricky. Ajax calls to PHP code will need to go to paths below the src directory. But then you want to stop your frontend resources being served from these same paths. Both PHP and gulp will want to use file paths for urls, but at least for Gulp this can be controlled.
I'll follow this with interest. My ambition is to keep in the same folder things you're likely to want to delete together, and for those things to be able to call each other with short, relative paths. The ideal would be to be able to specify the module route independently of the path on disk, and to have this route work for both frontend bundled resources and services. Good luck !
I came across this question whilst searching for an approach for exactly the same problem. I'm building a "platform" rather than an application with a plugin system along the lines of Wordpress. I have the additional issue of the platform itself being a 'multitenancy' environment, too - so any plugins cannot interfere with the core "Dashboard" that holds these things together.
So; posting for a few reasons, two years on...
Did you get anywhere and would you care to share any thoughts?
I came across a quite extensive article for PHP Phalcon that has certainly given me a few ideas. Sharing incase it helps you/others:
https://blog.antsand.com/singlepost/index/5619/How-to-integrate-php-(Phalcon)-and-Vue.js-components
There's a line buried in the series that says "As a rule of thumb. Structure your code, based on the application and NOT on the programming language and frameworks." I'm not sure how wise or not this is, but it certainly gave me something to crack on with.
So right now, I have a module folder a bit like:
/mymodule
/Controller
/Model/
/Template
thing.vue
/Assets
/js
/css
MyModule.php
Assets are handled via a framework route (i.e, /assets/{path:.*} )
Templates are handled via the (PHP) module install script to make sure webpack knows where they live.
Still at proof-of-concept stage but rightly or wrongly, it seems to work well enough!
I wish to use codeigniter NOT as a framework for building a site, but simply as a backend to handle some php stuff (eg. db in/out, image manipulation, file writing to the server).
In the default download of CodeIgniter3, there are 3 primary directories (application, system, and user_guide). Most of application is roughly empty, other than application/config; and user_guide is surely unnecessary.
So what parts of CodeIgniter3 are needed such that it is functionally complete?
TL;DR: All of it
If you want to use just a set of a framework's components, CodeIgniter is not the right pick.
Long answer:
In theory: it should be just system/core/
But most of that code assumes that you have constants defined in index.php, that you do have an "application" directory (containing "config/" and "views/errors/" subdirectories).
A lot of it also depends on language translations, for which the defaults are in system/language/, so you need that too.
Some badly written parts may also depend on a particular system/libraries/ or system/helpers/ component.
So while we started with just system/core/, you now need all of system/ and at least some of application/ (though that can be renamed to something else).
CodeIgniter has a monolithic architecture; it is simply not built in a way to allow you to do what you're asking for.
And those are only a few kylobytes of files anyway - it's not 1980 and that's not a problem; unless you actually load the extra components that you don't use, they wouldn't get in the way.
It is generally adviced to store module assets inside the module's directory, inside moduleName/public (or whatever you want to name the asset's directory).
Zend Framework 2 unfortunately doesn't support asset publishing for module assets by default. According to MWOP, there was nothing planned ~1 month ago and I guess there still is no real plan (they had probably a lot of work to get the stable version ready). (But, some day, they are going to address this issue.)
As my ZF2 app is growing and growing, I reached the point where I need to have module-specific assets. At the moment, I maintain them inside the module directories and copy them to the application's public directory. You can imagine that this method is error-prone and exhausting.
How do you handle this problem? Is there maybe a simple solution to this issue with little coding effort? My project plan doesn't allow me to create a complex asset handling on my own. Is there a recommendable, lightweight asset framework compatible to ZF2? I've already considered creating symlinks but I don't think this would be the best solution because it would require some additional web server configuration (FollowSymlinks) and additional maintenance work (the app is developed locally and deployed on a remote server).
Thanks in advance.
This has been discussed before in many places and it comes down to three ways to manage this.
Copy and Paste the assets into the public/ directory
Use symlinks
Use an asset loading module like assetic
A simple solution would be to make the copying of assets part of you build process.
Another question was already asked How to merge Zend Framework 2 module public directories for info.
I know this is pretty old, but I wanted to add this information for other readers.
Now there's also a module for this, which has been fully tested and is being used (and even depended on) by many modules.
Check it out here: https://github.com/RWOverdijk/AssetManager
Hope this helps.
There is also fourth option. Use a directory Alias in VirtualHost configuration.
I am creating a custom magento module and cant decide the best place to store some config files i require with the module?
Anyone out there suggest the best place for this? Should it be in the root of the module or in with the helpers maybe?
Edit:
Along the same lines as this question: is it acceptable to have a folder in the root of the namespace for the modules for includes that will be shared amongst the modules?
If these files are for configuration, they belong in etc. Think of the etc folder the same way you would a unix/linux/bsd system's etc folder. It's where you put configuration information. Convention is that you should use an XML file to hold your config data, and then load it with
Mage::getConfig()->loadModulesConfiguration('your-xml-name-here.xml')
When you use the loadModulesConfiguration method to load your configuration values, Magento combines XML files for ALL modules in the system into one big tree. This allows other modules you'll write (or others would write) to share the configuration information.
You don't need to do this, but etc is definitely the defined place for any configuration files you want to include with your module. Also, whatever method you're choosing, I'd pick a unique file name (packagename_modulename.xml, packagename_modulename.inc, etc.) to ensure against the slim possibility that someone at Magento might pick your name to use in a future version.
Along the same lines as this question: is it acceptable to have a folder in the root of the namespace for the modules for includes that will be shared amongst the modules?
No, that would not be acceptable. If you want a shared configuration, use the method I mentioned above. If modules need to share other information with each other, they should either do so directly (one module instantiates another module's model) or you should define a central "broker" module that handles all inter-module communication. If you're interested more in the topic, I'd recommend the first few chapters of Meyer's Object-oriented Software Construction. If you can get past the whole "how to implement low level data structures" aspected of old programming books, its a great introduction to what CS people when they say "module".
(it's also worth mentioning that if there are simple configuration values, learning how to use the Magento System Config Admin section is worth it.)
You could probably get away with this, but you're purposely avoiding Magento to do so. Inside a module, make a directory called etc and put an XML config file in it called config.xml. That file will be read and included in the Magento configuration, which means you won't have to try to escape the framework to grab your configuration data. Take a look at the existing files for some examples.
The other benefit to this approach is that the conversion from config XML files to user configuration options (in the admin panel) isn't too difficult (requires minor refactoring), so you can later change your configuration method with ease.
Hope that helps!
Thanks,
Joe
Coming from a .net background so bear with me!
Does php have anything like a web.config or a global.asax file or is it simply dropping the application in the file system and boom it is running on the web server? (obviously dropping the files mapped in apache for the domain etc).
Specifically thinking of setting up wordpress.
PHP is a parser itself. It is not a framework. In ASP.NET, it is a Framework and thus it has its own config files.
As for PHP, we have php.ini - the PHP configuration that sets how PHP behaves and so on.
However for application level, you can create your own configuration file. Normally if you use a PHP framework, they will have an application level configuration file (eg. "config.php") which will decide how the framework will work and so on.
Wordpress installation is quite simple.
Just drop the files ;-)
Of course, you'll need to have created the database (and db user), set up the Apache's VirtualHost, and you'll have to configure the application itself...
... But there is no notion of "application server" in PHP+Apache.
About wordpress, there should be some file explaining how to install, btw ; but it's not harder than dropping the files, maybe creating the configuration one, and a couple of "next" screens ;-)