I've been searching and trying to learn for ages but it just doesn't stick. There seems to be only 1 tutorial on Zend 2, and it's not very smart. Here we have a sample structure (and the tutorial proceeds with this application) http://framework.zend.com/manual/2.0/en/user-guide/modules.html :
zf2-tutorial/
/module
/Album
/config
/src
/Album
/Controller
/Form
/Model
/view
/album
/album
That's not cool - how do I know which album is which? In Zend 1 it made a lot of sense - you have modules, then you have controllers, and those controllers have actions.
Now I have a module called Album. is the src/Album/... a "single controller"? Would:
zend1application/modules/album/albumcontroller.php map to zend2application/modules/album/src/album/controller/albumcontroller.php? In that case, why are there 3 albums now? Like what happens if I change albumcontroller.php to indexcontroller.php? (I have been testing but there are so many changes it never sticks - I finally thought I should ask someone and if I know why I'll remember.
If I look at it a different way it seems the Album in module/Album and module/Album/src/Album should be the same - then why would we have it twice? Doesn't that just make room for error? Like why have a src/album folder? Why not put Controller, Form, and Model under module/Album?
Why is there a folder called Controller? There used to be a folder called controllers (plural, why singular now?) in a module before, that makes sense. But why is/are controller(s) inside a src/Album folder now?
Thank you for your time. I have tried to research but I think it's just too big absorb when (in my opinion) it seems so sparsely documented. Or, if someone could point me to a book like http://survivethedeepend.com/ but for ZF2, it'd be greatly apprecated.
Zend Framework 2 follows PHPfigs PSR-0 Standards. This means that the directory structure directly relates to the classname. But before i come close to that, let me explain the basic architecture.
First you have the ModuleNAME. Since the Module name needs to be unique, it only makes sense to map the Modulename to the Namespace of your model.
Inside the modules folder you have three sub-folders. One folder for configuration items named config. One folder for source-code files named src and one additional folder for the view files view
This separation is simply for overview. You separate configuration, view and sourcecode from another. It makes no sense to bunch them together and i guess you'd agree. This pretty much has been the same for ZF1, too.
The interesting part is the source-folder src. Earlier i mentioned about the PSR-0 Standard. And this is the place where it comes into effect. By default the source-files for each module will be looked upon from the source-folder src. So whenever you have a class, it will be using PSR-0 Standards based off of the source-folder. Mewning: My\Funky\Class would be found within src\My\Funky\Class.php
And that's basically all there is to it. Controllers usually have a FQCN like Mymodule\Controller\SomeController so you will find this class inside src\Mymodule\Controller\SomeController.php
The main question arising could be: Why are the folders sometimes all lowercase and sometimes ucfirst. The answer, once again, is PSR-Standards. Classnames and/or Namespaces are supposed to begin with an upperchar character. And since path-names are case-sensitive, the folders need to match the classnames exactly!
EDIT Another nice read i've just stumbled upon is Rob Allens latest blogpost: Thoughts on module directory structure. He explains how you can change the default setup quite easily to your likings.
Related
I am trying to add a few translations to the frontend of our module. When the translations are in the .tpl files they do get rendered. However no translation fields get shown in the backend my code for the .tpl files is:
{l s="Text" mod="myModule"}
I also do need to do some translating in the FrontControllers (mainly Error handling and feedback for serverside validation).
In the AdminController I simply use $this->l('Text'); which works. However, in the FrontController this is not available. I've checked the ControllerCore and FrontControllerCore, l() is not defined in those and only available in AdminController.
Can anyone give me a detailed explanation of what I need doing? All my research on the web always points to $this->l() being the thing to use...
When using translations in tpl files you need to use single quotes not double quotes.
{l s='Text' mod='myModule'}
As for front controllers... well if you're using custom module controllers as in controllers that extend ModuleFrontController you can use
$this->module->l('Text');
And if you're not using those controllers then... start using them.
Some things might be different since thirtybees is a fork of PrestaShop but I guess translation mechanism is the same.
I'm working on prestashop and I'm Trying to override "order detail page" in front (customer's details orders).
This is how I did :
I copied file \controllers\front\OrderDetailController.php into folder \override\controllers\front\OrderDetailController.php
I copied also default template file order-detail.tpl into folder override/customtemplate/order-detail.tpl
And In OrderDetailController.php I have specified template directory like that
$this->setTemplate(_PS_OVERRIDE_DIR_ . '/themes/parfum_evo/order-detail.tpl');
I tried, it works fine except translations. Even watching the documentation, no test solution seems to work.
Could anyone help me? Thank you in advance :'(
The php override sits in the correct place. As for the other, you specified the path the override/customtemplate/order-detail.tpl but then placed it in override/themes/parfum_evo/order-detail.tpl. I take it as customtemplate is farfum_evo really, but you need to add another one named themes, after override, using that structure. I think. Because there is a hook named
DisplayOverrideTemplate
Which should take care of this, while I believe setTemplate for controllers will always grab from the main theme folder
In the zf2 database and models tutorial a path such as this leads to a directory containing my model classes:
module/Album/src/Album/Model
I have created two more classes at:
module/Album/src/Album/Model/AlbumRelatedClass.php
module/Album/src/Album/Model/AlbumRelatedTable.php
I would like to put these classes at
module/Album/src/AlbumRelated/Model/
I have created duplicates of the model classes there for the purposes of this test, unfortunately, my module config for Album tells me that it cannot find the classes at the AlbumRelated location. I have tried changing the namespaces in the AlbumRelated location to AlbumRelated\Model and directly referring to the class location (\Album\Model\AlbumRelated()) without success.
Does anyone know how I can do this? If I shouldn't be doing this, can somebody explain why? I'm also interested to know why the folder structure is Album/Model/Album (it seems redundant, and I wasn't clear on the explanation in the tutorial).
Any help given would be great, thanks :)
The short answer is that it can't find the class because you probably didn't set up the autoloader config to know about a new "AlbumRelated" namespace. Look at what happens in \Album\Module::getAutoloaderConfig(). You probably want to add a key/value pair to namespaces like 'AlbumRelated' => __DIR__ . '/src/AlbumRelated'. That will tell the autoloader where to look for classes under the AlbumRelated namespace.
That said,
If I shouldn't be doing this, can somebody explain why?
You probably shouldn't be doing it that way. You've got a top-level namespace called \Album. Then you have \Album\Model namespace under it. Any models related to Albums ought to live there. Imagine you had an entity in your system for Record Labels, so you could associate an Album with the label that released it. The ZF2 expectation is that you'd create a class called \Album\Model\RecordLabel that lived in module/Album/src/Album/Model/RecordLabel.php. As long as we assume that RecordLabels are primarily related to albums, that all makes perfect sense.
Of course, you could stick RecordLabel in it's own module as well, if you had a lot of workflow around managing them.
I'm also interested to know why the folder structure is Album/Model/Album
I assume you mean Album/src/Album. That redundancy is to keep a nice clean PSR-0 setup. So, the first Album is identifying the module, and the second is the top-level of the Album namespace. This provides maximum flexibility, but isn't a hard and fast rule. See Rob Allen's recent blog post about alternative module layouts in zf2 for an exploration.
I have one companion script file for a Rails model, that uses code I've broken down into a hierarchy of over a dozen classes, for things like jQuery/Bootstrap UI code, factoring out similarities between different types of dialog, and so on. Let's say I'm working with articles.js.coffee as the "main page script" here.
I can define Coffeescript classes, namespace them as something like window.ourproject.OurUIDialog, and save them in separate, per-class source files such as app/assets/javascripts/OurUIDialog.js.coffee. Restart the Rails server, and that class can be subclassed, e.g., window.ourproject.PostInfoDialog extends window.ourproject.OurUIDialog. As long as PostInfoDialog is in articles.js.coffee (where the instantiation of the PostInfoDialog is), all is well.
But, if I move the subclass (PostInfoDialog) out into a separate file, e.g., PostInfoDialog.js.coffee, then attempting to do anything at all with it within the main articles script produces
Uncaught TypeError: Cannot read property 'prototype' of undefined
Again:
This revolves around a Rails model's companion script file, here called articles.js.coffee;
window.ourproject.OurUIDialog gets picked up whether it's in its own file or in articles.js.coffee
window.ourproject.PostInfoDialog (which extends OurUIDialog) can only be used if it's not in a separate file, even though viewing the generated HTML shows PostInfoDialog being included with all the other script files.
I'm tearing my hair out trying to figure this out, and I didn't have much left to begin with. Any ideas?
Pretty sure that Trevor Burnham answered my question when he answered this one; I just didn't see it the first dozen times I searched. :-P
Thanks to both of you for reading this one, though. :-)
in my project i have about 20 html forms with many different <input>'s. This <input>'s are unique in every form and they don't repeated between them. For each form there is a script which get data from form, generate specific file, and push it to the browser. and that's it. no databases, admin, logins/passwords and other usual web-app stuff.
so for example in php, project structure can be something like this:
forms/
------->form1/
--------------->index.html
--------------->script/
----------------------->index.php
------->form2/
--------------->index.html
--------------->script/
----------------------->index.php
and so on. It's quite clear and it makes pretty urls like:
www.website.com/forms/form1
but in Ruby-on-Rails there is a MVC pattern. And i have no idea how to organize structure with project like that. How to make it right? I should not to make 20 different controllers after all, right?
Yes you do make 20 controllers. In much the same way as you have 20 script/index.php files in your PHP structure. The rails structure would look something like this.
app/
controllers/
form1s_controller
form2s_controller
.....
formns_controller
view/
form1/
new.html.erb
form2/
new.html.erb
......
formn/
new.html.erb
layouts/
application.html.erb
Where the controllers have a method for each action that you want to perform e.g. new, edit etc
The layouts/application.html.erb file will contain all of the markup that is consistent across all of your pages.
Finally, don't try and fight the structure. It is there to enable minimal code because of convention, if you try and create your own structures you will create a world of pain.
Since there is no database backend for the forms, i would create one FormsController, with 20 methods (form1, form2, form3, ...).
Your urls would then look almost the same \forms\form1, \forms\form2 ...
Even if you would use 20 controllers, there are many ways in ruby to remove duplicate code. So even in a normal MVC, i have had applications with 140 models, and likewise as many controllers, most of these controllers had only one line and the views were completely generic.
Just because a certain solution seemed simple in PHP, it doesn't mean better solutions don't exist. Like for instance MVC. It might seem to induce more code, more files, more work, but the structure is there for good reason, it seperates the concerns cleanly, and each file in itself becomes more clear and easier to understand.