I am new to yii and using version 2. I developed a project which uses a library (I coded) for parsing a CAD model file, extract vertexes, edges, faces etc, finally combine those entities to display the model and then extract features. It displays the model using the three.js library. A user has to be signed-in in order to upload the model file and do all this stuff. I would like to refactor the app into version 2 using the yii 2 framework. So I would like to know how I can merge the feature recognition library into the yii app, should I create a Components, Extension or Module or use other means?
The library is coded in plain OOP. I access it by requiring an init.php file which requires about 20 library class files. If I create a module for the library the view will draw the model but where do the parser and feature extractor go in the model or controller files?
Thanks in advance.
In Yii 2 basically everything is a component.
Extension is the term usually used for the vendored components (or modules) available at packagist.org (or similar) so if you are not planning to release it outside you don't have to worry about extension-ing it.
Now for the component-module debate - module is a component that allows you to use it's own controllers structure so if you need something like this - use module. In any other case simple component is just fine.
Related
I am writing three applications (with 1 module each) in Zend Framework 2 that eventually come together as a unified portal with same look and feel. I plan to write some common code that can be shared between these three apps.
Ex: Couple of classes to programatically create a datagrid, Couple of classes to programatically create a form, etc..
Can you suggest an ideal location to put all this code, so I can just plug and play in my modules when required?
Thanks
You can create a module with all the common code in the src folder, PortalCommon/src/PortalCommon for instance. You can then let the 3 modules depend on that module:
namespace Module1;
use Zend\ModuleManager\Feature\DependencyIndicatorInterface;
class Module implements DependencyIndicatorInterface
{
public function getModuleDependencies()
{
return array('PortalCommon');
}
...
}
Another option is to create a module for all the common functionality. So in your case you might get a datagrid module and a form module.
You can create a separate module : Jake\Common or Jake\Core in a git repo.
Register this repo on Packagist or on a personnal Satis instance if it is private.
You can then include it as a dependency in your composer.json and it will be downloaded in vendor.
I've been using CodeIgniter for a few months and recently discovered Bonfire, which looks like a great foundation for CI projects, despite the current build using almost outdated resources like Bootstrap 2.
I really love the module system in Bonfire, it seems like a very efficient method for creating completely independent subsystems. However, I wonder how compatible these modules would be with a normal CodeIgniter installation. Obviously you can't just dump the modules folder in, CI wouldn't know what to do with it, but is there any way to restructure a BF module into a third party plugin or something that can be used in CI?
Similarly, would it be possible to extract files from a CI installation and package them as a BF module (obviously with some tweaking)?
I would imagine the answer to those questions would probably be "of course not", so I just want to make my understanding clear; if I decide to develop with Bonfire, I would essentially be stuck using it without being able to revert to vanilla CodeIgniter and I would only be able to share my modules with other Bonfire users. Correct?
Basically the very first difference is that bonfire works on HMVC (Hierarchical model–view–controller) which means every module will contain its own model view and controller.
Yes it can easily be integrate with the vanilla codeIgniter you mentioned because the framework basically following the codeIgniter rules and provided a CMS with great functions.
Some features like:
Built-In Admin Area
Modular Coding
Data Maintenance
For more details check the documentation
Right now I find out that extending modules in CodeIgniter framework using MX HMVC is very bad and not supported by default and I have a custom function in MY_Controller and you need to make a "hack"..the main point is it doesn't work good.
My question is if CodeIgniter didn't offer extending modules with other modules e.g. Drupal way of modules. Where e.g. you have core Views module and than module for extending Views so you can have Slideshow as a view and then another that add something else to the slideshow and every module use something from previous module in hierarchy like:
Views -> Views Slideshow -> Views Slideshow Extended
Which PHP frameworks has this "extending" ability in modular way. I am not looking for extensions of classic MVC controllers/models like:
class Views Slideshow extends Views {...
I need a PHP framework that have in mind extending of modules/bundles/whatever-packages
I have a hard time with CodeIgniter so I am looking for some other framework that is capable of this within a core. Thanks for your help.
Symfony2 definitely have this in mind, as everything is a Bundle. Even the framework is a Bundle.
You can pretty much overload almost everything in Symfony2, given that you use the service container instead of hard dependencies. Be careful that this might introduce some complexity (the price of the overloading feature). Also you can reduce complexity (and learning curve), as using the service container is not mandatory.
Please take a look at the documentation of Symfony2: Architecture, and more specifically the Understanding the bundle system
The challenge:
I want to modularize my library folder in my zend framework app. This is fine, if you want to put everything in the same namespace such "App_." But the problem comes in when you have a dozen packages such as a SignUp package, ACL Package, Navigation Package, Foo Package etc. Now each packages has some view helpers, some controller plugins, some action helpers plus some other base classes. You could add each view helper path individually, but that could junk up your application.ini file/ bootstrap.
So the question is, is anyone aware of 'Plugin Package' loader for ZF?
To clarify, it would be nice to have a resource plugin that you pass the package name, it adds the namespace, registers some default options like helper paths and then you can configure it to add helpers to Action Helper brokers. Each plugin package might have to have its own ini file or an init class that where the programmer could initialize the plugin package. Any thoughts or knowledge of something like this would be appreciated.
Your question is difficult to find a solution to. ZF doesn't seem to be used in the manner you wish.
For example you want the following packages
Navigation
ACL
Sign Up
These are all completely separate and don't all 'plugin' to ZF in a similar manner.
Navigation needs to be stored and built for each request that needs the package, the navigation object then needs to be used in Zend_View objects or perhaps not. What happens when the navigation is referenced in a view but it doesn't exist?
The ACL package is so specific, it integrates into ZF in a lot of different ways, it needs a Zend_Controller_Plugin, it needs a way of meaningful way of storing and building the Zend_Acl object for querying on an application to application basis.
Sign Up needs a controller, an action and a form which is passed to Zend_View and the form needs to be process. This then needs to be plugged into your ACL object, presumably a database and perhaps various other parts of your site it it requires more specific permissions that fall outside of the use for ACL
Its not impossible to do what you want, but there must be a better way. It almost sounds like your trying to build a CMS with optional, plug-able packages?
The ACL issue I have resolved by having a Library of controllers, helpers, models, forms, etc. A Zend_Controller_Plugin runs and attempts to log in the user, this plugin is run for every app I create, it works well uses an ACL object format which I have used for a while.
For Sign Up I have a RegisterController in my Library, if my application requires registration it has its own RegisterController which extends the RegisterController in the Library. If the application doesn't need registration then it doesn't have its own RegisterController.
I hope that helps, I really think that doing this in the abstracted way suggested isn't worth it and will never be so solid and tight you can truly rely on it because each application is specific.
Generally, in this case you should use modules which are already modularized instead of modularizing the library.
modules/
signup/
models/
plugins/
The default module resource autoloader is configured by default to load plugins:
See: http://framework.zend.com/manual/en/zend.loader.autoloader-resource.html:
If you really need to modularize the library, the customized autoloader will be the best solution (there is an easy to extend abstract autoloader).
You may also consider separate library for each module, added to your include path (not recommended, because it will slow down the app):
modules/
signup/
models/
library/
I devlopp web applications with Zend Framework.
For now, I have a huge library, wich contains each an every things, used by a couple of web applications. I am thinking of reorganising it, using the concept of "Module".
But I am not sure about the difference between Module and Package.
What I understand is :
a Module contains a part of a web application (pages, models...)
a Package is a group of class in the library
Am I seeing it right ? And how to know where should go my classes (model of a module, or library) ?
Because for example, I have some classes to do the translations. I have "model" classes, to represent a language, a text and its traductions... And I have kind of an "API" class that is just here to translate a string into a language. I would say that I need a module for the model classes and the web interface to edit the traductions, and the API class would go in the library ? Is that right ? Isn't that weird to have 2 kind of classes, one for the module and one for the library.
I guess that's an open question about API, librairie and application architecture.
Modules, in the ZF sense, group concrete, often standalone, application parts:
Modules allow a developer to group a set of related controllers into a logically organized group. The structure under the modules directory would resemble the structure under the application directory. […] The directory structure for modules should mimic that of the application/ directory in the recommended project structure
A package on the other hand is a set of classes in a code library that conceptually belong together. For instance, ActionHelpers and ControllerPlugins conceptually belong to the Zend_Controller package. All available Validator classes belong to the package Zend_Validate.
When using PHPDocumentor you can annotate your code to belong to packages. If you look at ZF's API Docs, you will see this grouping in effect. Try to find the Zend_Validate_Alpha class.
See
http://framework.zend.com/manual/en/project-structure.project.html
http://framework.zend.com/manual/en/project-structure.filesystem.html
http://framework.zend.com/apidoc/core/
http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.package.pkg.html
packages are namespace areas so that symbols with similar names do not clash with one another. For example, the symbol &main::first is different from symbol &List::Util::first . Packages are name prefixes to sysbols.
A module is a file of code, or a tree of bytecodes. A module could be precompiled (.pmc), uncompiled (.pm) on disk; or pre-loaded in memory as one unit -- assuming no autosplit.
In summary: packages are about namespaces, and modules are about files. They are different things, like apples and boxes -- until the day when you start placing one kind of apple into one kind of box, and people start thinking that apples and boxes are related. And they are! but still, one in fruit and the other is a type of container.
Simple in my view:
Modules are like smarty (a library with a targeted goal templating).
Packages are 2 or more modules that work with each other to offer a more complete solution.
Again my simple point of view.