Is .zfproject.xml a must in a Zend Framework project?
What does it do?
Is it's location absolute?
When using Zend_Tool to manage your Zend Framework project, .zfproject.xml will contain your application structure state. This is required by Zend_Tool (and only by it) to be able to work, e.g. add code to certain parts., generate things, etc.
Quoting ZF Manual on Zend_Tool_Project:
So, for example, if in one command you created a controller, and in the next command you wish to create an action within that controller, Zend_Tool_Project is gonna have to know about the controller file you created so that you can (in the next action), be able to append that action to it.
I am not sure if Zend_Tool can be configured to use a different path to .zfproject.xml. My suggestion would be to leave it untouched. It's a hidden file anyway.
Just to add, the zfproject.xml is not needed if you don't use Zend_Tool.
So it's not a must. Personally, I manage all my zf projects more or less without a command line and it works fine for me.
Basically if your going to use Zend_Tool, stick with it. Zend Tool doesn't like it when you create MVC manually. Its just another layer of abstraction that you can probably live without.
I am using zend framework 1.10. Whenever I create a action using zf tool it re-indents the code in the controller file and removes some function closing brackets. It is kind of buggy, so will not be using it from now on.
Related
Basically I don't know how to start implementing VueJs into my project.
Should I use a CDN or require it via NPM? NPM would make it easier to implement VueJs packages.
I have in (my own framework (for learning)) a path /public/ in which a index.php file is located, along with an assets folder (which leads is followed css/js folders).
So the question is, what would you recommend, and how would you implement routing etc.?
I personally prefer it to be independent and would download the necessary files and integrate it directly.
Download the development version: https://vuejs.org/js/vue.js and the production version: https://vuejs.org/js/vue.min.js
Copy this files into the public/js folder
Add a script tag: <script src="js/vue.min.js"></script>
I don't get what the really point is on your question, but:
In your case I would use a framework like laravel, symfony, zend, ...
This gives you routing and stuff.
If you want to write the framework yourself (for learning, like you've mentioned) the you should take your brain and implement a concept on how you would like to define the routings.
Concerning VueJs: I think there should be no problem using the CDN-Version. It keeps things simple, until you really need to build VueJS on your development-PC (later within your deployment-process).
As said: Do one step after another. First use the simple way. Implement a simple Routing. Use VueJS from CDN. And when things get serious: Extend the code by your needs. Include VueJS via NPM and stuff like that.
I'm starting to familiarize myself with using the module-based architecture for zend framework projects. My real reason behind being interested in the module architecture is to be able to take a module from one project and just drop it into another project. Maybe I'm not getting it right..
But what I'm noticing right off the bat is that controllers within each module cannot have the same name as any other controller in the main application (or in any other module, though I haven't tested this). This leads me to think that modules are not really independent self-contained units, so I wonder how this affects their ease of distribution from one project to another.
The other issue is what if I were to take a module and drop it into another project. Do I have to update the .zfproject.xml manually? and wouldn't that be a bit too cumbersome to be done manually?
Maybe I'm not clear on how modules should be used in zend, so I'd like to know when you decide it's best to use them, and when do you decide not to use them, or do you use them all the time, or do you never use them?
I always used module based architecture so far in my projects, because I like to separate concepts. For example I have always an ADMIN module whose classes and controllers dont mix with the rest of the application. Using modules you can reuse modules for other applications, for example if you create a BLOG module.
The names of your controllers will be something like Admin_IndexController for the admin module even if the file is named IndexController.php.
Another concept that is nice and help you reuse resources is the plugins. Use them for authentication or to check validity of the requests.
You need to setup namespaces for your modules so that they are easily moved into a new project without renaming.
If you are using Zend Tool then you will have to edit the zfproject.xml. I haven't spent a lot of time using this so I'm not sure if there is another way without manually editing.
I wish to use the Translator classes of Zend framework in my app, but I don't want to include the whole framework. I grabbed the:
Locale folder
Translate folder
Exception.php
Loader.php
Locale.php
Registry.php
Translate.php
and copied into a custom folder named zend.translator.
Obviously I had to edit all them to adjust the includes to the new path...
Is this the way to go? I'm worried to have to edit all those files every time
a new version is released.
You could use the Zend_Loader_Autoloader to include only the classes from Zend Framework that you actually use. So you wouldn't have to check all the dependencies yourself. Just put the complete Framework on your include_path and the Autoloader will take care of it.
That way, you don't have to edit all the files. And autoloading can also give you a significant performance boost.
No. That's definitely not the way to go.
First of all, grab the whole framework. It does not add any overhead to your application besides occupying some more diskspace. Should you find out later you want to use some more components, you have everything in place already. ZF will not instantiate anything you don't use, so it won't impact performance to have the whole thing.
Second, don't change the files. ZF uses a naming convention you can easily use with autoloading. You can either use the Zend_Autoloader or roll your own. Basically, you just have to replace underscores in a filename with slashes and add '.php'.
I've read a couple of Related questions by the site, but can't find what I'm looking for.
After having done normal PHP without much extra(by which I mean a templating system) for a year now, I feel like trying Zend. Simply because it's the biggest name. I wanna try CakePHP too later.
I've been looking into the examples, but these are all inline-code examples.
In learning PHP, I've used a template system, in order to keep the PHP and the HTML completely separated. Is this possible with the Zend Framework, or should I use a template system alongside it?
Also, what's the deal with executing several .bat files? Is there really so much work in setting up folder-structures with the correct files in them should you did it manually?
Zend Framework is a quite good solution to use as separate modules or complete package as well. You can use only it's templater system (but it's not so super) or you can put on a whole system using Zend_Application, Zend_Controller, Zend_Db, Zend_View, etc.
The .bat (or .sh) file is for the Zend_Tool. It's an experimental command line tool to build modules and applications easier.
I guess you can use zend's built in template solution that comes with Zend View, roll your own, or even integrate something like Smarty. At the end of day, its your call. Zend is fairly flexible in terms of which of its component you want to use and which you don't.
frankly for me these components do the most of work and i dont think i will need more than
(Zend_view , Zend layout , Zend navigation ,Zend breadcrumb)
it's most likely to keep the PHP and the HTML completely separated
about zend tool : its just tool to make Zend development much easier
I highly recommend you take a look at the online tutorial found here. It's a step by step walk through the framework showing you the basics of how you'd build a small Zend Framework app, and shows you how to integrate things like access control, interface with the database, etc. It's written in really understandable language with great source code included.
As for the batch files, you may want to download a demo copy of Zend Studio. It allows you to create a ZF project and does all of the setup for you without requiring you to mess with the command line.
Good luck!
I highly recommend you must first understand the basic directory tree of Zend Framework including all setup needed and familiarization with bootstrapping and setting configurations with a .ini file.
What is the best way to integrate an external script into the Zend Framework? Let me explain because I may be asking this the wrong way. I have a script that downloads and parses an XML file. This script, which runs as a daily cron job, needs to dump its data into the database.
I am using Zend Framework for the site which uses this script and it seems to me that it would be best to use my subclassed model of Zend_Db_Abstract to do the adding and updating of the database. How does one go about doing this? Does my script go in the library next to the Zend Components (i.e. library/Mine/Xmlparse.php) and thus have access to the various ZF components? Do I simply need to include the correct model files and the Zend DB component in the file itself? What is the best way to handle this sort of integration?
Yes, you should put your own classes that maybe inherit Zend Framework classes or add further classes into your own folder next to the Zend Framework folder in library.
When you have Zend_Loader s auto-loading enabled, the class names will automatically map to the class you created, e.g.:
My_Db_Abstract will map to My/Db/Abstract.php .
In your library directory you should have your own library next to the Zend library folder. Whatever you call it (Mylib, Project, ...) you should include it into the Zend Autoloader and that's done as follows:
require_once 'Zend/Loader/Autoloader.php';
$loader = Zend_Loader_Autoloader::getInstance();
$loader->registerNamespace('Project_');
$loader->setFallbackAutoloader(true);
if ($configSection == 'development')
{
$loader->suppressNotFoundWarnings(false);
}
In order for you library to integrate nicely with ZF and the Autoloader you should stick to the ZF naming conventions. This means two things:
if you extend an existing ZF class, replicate the ZF folder structure so that your file has the same path and name except for the library name. E.g. /library/Zend/Db/Abstract.php => /library/Project/Db/Abstract.php.
if you write your own classes, still stick to the ZF naming conventions for the autoloader to find them.
I just came across something that may be germane to this question. This IBM developerWorks article.
The author recommends simply creating a scripts folder in the ZF hierarchy and the using it as one normally would within ZF (though he does set the ini path and call autoload). Is it that simple? Does simply being in the hierarchy of the framework and including the path and autoloader grant your script access to all of the goodies?
I'm not 100% sure what you're trying to ask but I will try to help. If at any point you add a reference to "/path/to/zend/framework" into your php include path then you have in essence enabled the Zend Framework. From there if you do:
require_once('Zend/Loader.php');
Zend_Loader::registerAutoload();
Then at any point in your script you can pretty much just create new Zend Framework objects and Zend_Loader will handle the rest.
One of the big things about the Zend Framework though is not forcing you to do things a certain way. That's why sometimes there are several ways to accomplish the same thing. So, if you feel you need to make your script use the Zend Framework just for the sake of doing so this is not really necessary. But if you think it may improve your script in some way then go for it.
I usually put custom stuff that I think could be used across projects in a custom folder in the library. So I have a library/Ak33m folder that has scripts that may be outside of the framework.
As a ZF noob myself, I think I understand some of what the OP is trying to figure out. So, I'll just explain a bit of what I understand in the hope that it is helpful either to the OP (or more likely, to a future reader, since the original question is so old and I imagine that OP is now a ZF guru).
I understand that ZF claims to be largely "use at will", so that you need no buy into an entire structure, like the Zend_Application, the Zend_Bootstrap class, the entire MVC approach, etc.
Further, I understand conventions for class naming and file locations that enable easy autoloading. Ex: class App_Model_User resides in a folder App/Model/User.php
I think what can be potentially confusing is that in the script context, where you have not yet
done the .htaccess magic that pushes all request to public/index.php
set your APPLICATION_PATH and include paths in public/index.php
created your Application or Bootstrap object tied to a config file
it can be a little bit unclear how best to avail yourself of most of the ZF goodness we get in that context and want in another context.
I guess my answer to the original question would be that the usual entry point sequence of
http request -> .htaccess -> index.php -> config
sets up much of our environment for us, we would need to duplicate some of that for different entry path.
So, for your script, my first instinct would be to create a common include file that mirrors much of what happens in index.php - set the include paths, the APPLICATION_PATH, instantiates and calls a bootstrap, and then does your script-specific processing.
Even better, it might be desirable to create a single entry point for all your scripts, like we do in the http/web context. Extend Zend_Application for your own script purposes so that $application->run(); no longer starts up the MVC router-controller-dispatch processing, but rather does your own stuff. In that way, this single script entry point would look almost identical to the web entry point, the only difference being which application object gets instantiated. Then pass the name of your desired Application class as a command line parameter to the script.
But here I confess to being less confident and just throwing out ideas.
Hope all this helps someone. It actually helped me to write it all down. Thanks and cheers!
Update 2009-09-29: Just ran across this article: Using Zend Framework from the Command Line
Update 2009-11-20: And another article: Cron jobs in Zend Framework | GS Design
Update 2010-02-25: Easy command line scripts with Zend Application - David Caunt