What is Reddit's opinion of
Zend Framework?
From 3.5 billion Reddit comments
➔ Zend Framework website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
It's best practice to expose as little PHP (or any other language) as possible, in case the handler doesn't parse it. In this case someone seems to have borked the php opening tag, but something else that's also likely is a botched software upgrade that results in Apache running without PHP. Now all .php files are served as plain text directly to the browser. This is especially true for low-budget shared hosting servers.
That's the reason why you'll want as little PHP in your publicly accessible directory. My index.php generally only consists of:
<?php
require_once '../application/Application.php';
So if for some reason the PHP file is served as-is, that's the only thing leaking out. The rest of the PHP code is outside of the publicly accessible document root directory.
This is also the layout that Zend Framework encourages.
From reading the manual, setEscape is for one callback. If you want to run output through multiple functions, you'll want to create one function to do all of that work, and then define that one function as the callback. For example, in PHP 5.3:
$this->view->setEscape(function($string){ return htmlentities( strtolower( iconv('UTF-8', 'UTF-8//IGNORE//TRANSLIT', $string) ), ENT_QUOTES, 'UTF-8', false ); });
Further, you probably want to not use stripslashes. Unless you have magic quotes enabled, there is no reason at all to ever call it on any user input ever. If you do have magic quotes enabled, turn it off for the sake of all that is good and holy in this world. And if you can't turn it off because you are on shared hosting, get a competent hosting provider.
I seem to recall Zend Framework having classes for barcodes, and maybe PDFs too.
*googles it*
http://framework.zend.com/manual/en/zend.pdf.introduction.html
http://framework.zend.com/manual/en/zend.barcode.html
I would go with the cURL extension.
Also, I would check out Zend HTTP. It may be too big of a dependancy for you (but then so could requiring a curl or http PHP extension). It allows for connection adapters (curl, sockets) and has support for things like file handling, cookies, etc.
If anything it may be a good starting point you could refactor to fit your needs.
It's actually more proper to NOT use the closing tag in script that is all PHP and not mixed with HTML.
This was the closest thing I could find to support it so far.
> For files that contain only PHP code, the closing tag ("?>") is never permitted. It is not required by PHP, and omitting it´ prevents the accidental injection of trailing white space into the response.
Not sure why you're getting so much push back on this.
This was written because Zend\Crypt was still unavoidably using PKCS1v1.5 padding and phpseclib wasn't simple enough by default.
Obviously libsodium is much better than RSA via OpenSSL, but libsodium still isn't a core PHP extension and must be required via PECL (which is a no-go for most PHP devs).
Did you complete the Quick Start tutorial? That should give you a basic idea of how a typical ZF application fits together.
From there, it's a matter reading up on other Zend libraries as and when you need them.
With the XDebug extension for Apache, both Eclipse and Netbeans work pretty well for interactive debugging. (But "watch" variables can cause segfaults if left sitting around.) Netbeans has Smarty-template and Git support, but Eclipse has better SVN tools.
If I was starting a new project, I'd probably try Zend Framework logging. (It's isn't so much a "framework" as a collection of a-la-carte useful libraries.)
Has the company grown enough that it has a "legal guy"? It may seem like stultifying "TPS Report"-type stuff, but creating some sort of company-standard boilerplate for contributed code might be a good idea.
For example, I had to fax in the Zend Framework CLA to contribute code to them.
> By signing a CLA, the person contributing source code provides a license to Zend to use the source code he submitted in Zend Framework. By doing so, the contributor does not give up his own rights or copyright to his own code, but provides us with a license. In addition, the purpose of the CLA is to clearly define the terms under which intellectual property has been contributed to Zend Framework and to make sure that to the best of the contributor's knowledge he is entitled to make such contribution and is not violating anyone else's intellectual property.
To be fair that seems a case of "bad marketing". You may not care and posts like these http://framework.zend.com/blog/zend-framework-3-update-and-roadmap.html are great but as someone who skipped ZF2 (but loved ZF1) some kind of "ZF3 is here" announcement could be a reminder to reevaluate the framework.
I contribute to a lot of open source software (usually under the namespace of my employer) and even published a few projects to boot. My background is heavily specialized on application security and cryptography, so many of my open source contributions are in the form of a vulnerability disclosure. For example: ZF2015-10 a.k.a. CVE-2015-7503.
In addition to this, I'm also active on Stack Exchange and invest a lot of time into cleaning up old questions with really bad security advice.
Recently I offered a free code review for one community-elected PHP security/crypto project and only ~10 people voted in total. While I'm grateful for the people who took the time to nominate a library they felt was deserving of a free audit, because so few people responded, I feel like I'm failing the community by not making developers more aware of security best practices and the research I've published (which might be very relevant to the code they're developing).
(Aside: The audit has since been completed and should be published as soon as my findings are addressed.)
What are some things I could be doing to make the work I'm doing through PIE more visible to the developer communities?
cough:
- https://github.com/zendframework/zend-escaper/blob/d643a846c4e810aae74220892b6009bf419c52cd/src/Escaper.php
- https://github.com/zendframework-c/zend-escaper/blob/82ee7a7380a9efc04c7fd5edd5de9bcd351a18b9/zend/escaper/escaper.zep
- http://framework.zend.com/manual/current/en/modules/zend.escaper.introduction.html
EDIT: Yes, I know the RFC mentions those, but I'm highly against having userland stuff ported to core just because.
PSR-7 isn't just for making outgoing HTTP requests, it's also to be used for incoming HTTP requests. Have you never had to deal with the request/response cycle and how every framework does it differently?
edit:
Examples:
- Symfony is using PSR-7 in middleware: http://symfony.com/blog/psr-7-support-in-symfony-is-here
- ZF has introduced PSR-7 middleware: http://framework.zend.com/blog/announcing-expressive.html
- This guy has written PSR-7 adapters for a metric ton of request/response manipulation libraries: https://github.com/oscarotero/psr7-middlewares
Guzzle and other outgoing request libraries are the least important of the things PSR-7 impacts.
Look at using a hash for the permissions so you have 1 column instead of N. Then just parse that apart when the user logs in as part of authentication. Downside of doing such is, you can't do SQL reports easily for user permissions(who has what). But it depends on what you are looking for. You gain flexibility of adding privileges on the fly with no DB schema updates which I see as a big plus for the client.
Look at Zend_ACL, you can define roles that have access to certain things. http://framework.zend.com/manual/en/zend.acl.html
I would also look at using Zend_Auth for your login system versus the current one you are using. Reason being, that for security items, while sometimes writing from scratch may be easier, you want some things that have been widely been used/tested. You can hook in your current db schema to the Auth database adapter.
These items could be used standalone, and you don't need to use the whole framework. Just those classes.
Database access is generally the biggest bottleneck to the speed of any application. It is the last place you want to cache things. Caching to file is the first stop and should serve your needs well. If you find that it isn't good enough or you need more features then you will need to look at things like memcache.
I would recommend that you use Zend_Cache because you don't need the rest of the framework in order to use it.
It will also save you a lot of time and a serious headache if you read this before you use Zend_Cache. It's a stupid thing but once you know about it it's easy to fix (1 line) and is the only blemish on an otherwise great cache library.
Except use Apigen rather than phpDocumentor
See the difference:
phpDoc: http://framework.zend.com/apidoc/2.3/namespaces/Zend.html
Apigen: http://apigen.juzna.cz/doc/zendframework/zf2/namespace-Zend.html
There's a reason why the closing tag is expressly forbidden in popular PHP frameworks. No offense to you, but I would hesitate to hire a programmer whose attitude is "Lets see, not adding the closing tag causes zero problems, and doesn't decrease readability. Adding the closing tag could cause problems, and doesn't make the code any more readable. Yep, I'm going to use the closing tags!"
A good programmer is someone who always looks both ways before crossing a one-way street. ~Doug Linder
Looks fine to me. I dunno if I would use $ALL_CAPITAL variable names. Also you're not putting your { and } in the normal PHP locations:
http://framework.zend.com/manual/en/coding-standard.coding-style.html
http://pear.php.net/manual/en/standards.control.php
Personally I prefer the way you've done it, but lots of PHPers don't agree with us ;)
PHP is analogous to ERB in the Ruby sphere. The last time I had to oversee a PHP project, the expert PHP developers in the bunch decided to use Zend Framework.
Its strength in prototyping lies in its simplicity, you can start a new experiment merely by saving <?php ?> in a new file.
The most comprehensive package I think you'll be able to find is Zend_Feed_Reader, part of the Zend Framework (though you should be able to use it separately): http://framework.zend.com/manual/en/zend.feed.reader.html
The official documentation is a decent place to start. The tutorial WarRabbit linked to is pretty much the gold standard ZF intro.
You could use Zend Auth (even though it's part of ZF, the ZF components are designed to be used library-style, not just in a full-stack ZF app). Use phpass instead of md5 for more secure password storage.
"Egyptian"? twitch, old man jargon Nazi mode on
Kids, it's called 1TBS, or K&R style. Zend framework uses them: http://framework.zend.com/manual/en/coding-standard.coding-style.html
I like it, as I came from a C background where it made sense to get more actual lines of code on screen instead of syntatic sugar. One reason why python's indentation appeals to me as well. Similar code density, minus the brackets.
TIL there's a name for same-line brackets.
I originally used them at a place that was pretty strict on the Zend Coding Standard and got very used to it. It comes naturally now.
> populateSelect.php file is invoked through an include in my index.html.
That's the difference. When you include a file it uses the calling file's location for includes.
Just rehashing this in case :
./ means this directory ../ means the directory above the current directory (and it can be repeated ../../ means two directories up)
index.php includes forms/formSelect.php, it's starting from public_html (or whatever your web root directory is). If you requesting a page like forms/postThread.php, it's starting from public_html/forms/. Thus why you need to use ../ in the 2nd file but not in the first.
Far as moving the SQL statement, you will have to move the variables as well or create a function which accepts those variables as parameters.
Overall the structure of your project has a weird directory structure IMO. Not that there's a standardized layout for projects. I believe most use some type of template/ or public/ folder for their CSS/JS/Template images and I use media/ for non-template images. Here's a recommend project directory structure from Zend :
http://framework.zend.com/manual/1.12/en/project-structure.project.html
Here's an older article but it includes a few different example types : https://blog.fedecarg.com/2008/08/11/scalable-and-flexible-directory-structure-for-web-applications/
There's a few different ways but I use a combination of
- ZendPDF for creating PDFs
- GhostScript to merge PDFs, see this StackOverflow answer
I should probably agree with /u/pmjones eg : Creating lazy services is not a unique feature of zend service manger.
I am looking at the example : http://framework.zend.com/manual/current/en/modules/zend.service-manager.lazy-services.html#practical-example .
Eg with Aura.Di .
$di->set('database', $di->lazyNew('Database'));
This will only create a connection to database when the $di->get('database') is called.
I use Livedocx, the webservice. http://www.livedocx.com - and I pull in the Zend implementation, http://framework.zend.com/manual/current/en/modules/zendservice.livedocx.html
It's worked perfect for me, but I'm only using it to convert approx 10 documents per day.
Using something like Drupal can limit you Big Time. Very basic example is, if you want to add something to your project that is not supported by the CMS you will have to dig inside the code, add things or make changes manually. That means you will no longer have needed support when you ran into trouble, you will have problems upgrading to newer versions of the CMS and lot of things like that. No need to write code from scratch. Best way to do it is to use a Framework. Frameworks provide all necessary functionality, you only have to write the logic of your application (project). For sure you will write more code that with CMS, but you will know all “nuts and bolts” of your project. You will have more freedom to change or add functionality. Plus you can upgrade your project to use newer versions of the framework much easier because you don’t need to touch any of its core files. I would suggest to use Symfony or Zend frameworks. In terms of “matching profiles”, you have to use a database with a good structure. For web applications, most commonly used database server is MySQL. I’m not SEO expert, but I can tell based on my experience that you can’t have huge user base immediately. Adding traffic to a project is problematic even for people who spend lot of money on it.
ZF3 is planned to come out later this year. You're already so far behind, it would be a titanic job to move the app to ZF2, why not just move to ZF3.
http://framework.zend.com/blog/announcing-the-zend-framework-3-roadmap.html
Design aside; Your webroot directory is not set up properly
I can access your git folder http://www.haroonghafoori.com/.git along with your bower_components folder. Someone with a bit more malicious intent could easily find database or other credentials if there were any.
Take a look at this. I realize you are not using the zend framework, but as you can see, the /public folder is where all your css/js/images should be. It should also be the top level/webroot directory. All the sensitive/application logic should sit outside of that directory
http://framework.zend.com/manual/1.12/en/coding-standard.coding-style.html > PHP code must always be delimited by the full-form, standard PHP tags: > > <?php > ?> > Short tags are never allowed. For files containing only PHP code, the closing tag must always be omitted
Apart from the Symfony Security component, Zend\Authentication (http://framework.zend.com/manual/2.2/en/modules/zend.authentication.intro.html) is also a good option. Recenlty I have came accross https://github.com/nette/security .
Edit : Onething I feel bad about nette/security is they don't follow PSR standards. tabs / space war.
Thank you.
Laziness' answer is good. This comment is just tiny details.
You mention caching query results to XML ... that's not smart. You'll just have to parse all that XML every time you hit your cache. PHP provides serialize()/unserialize(), which are handy. Writing out plain-old-php (array(array(array(...))) might be more performant, but it's a pain, and there could be security concerns (since by loading from cache you'll be executing PHP).
I'd highly recommend you use some library that has implementation details figured out for you. I've used Zend_Cache with great success (both standalone and as part of ZF-based projects). It provides a nice interface, and handles a bunch of details for you. And when you decide file-based caching is too slow, you just plug in the APC or memcache backend, and now you're caching in memory.
I'm sure other libraries do similar things -- find one and use it, or at least learn from it.
Looks like Laravel is just extending off of ZendDB for it's DB layer. If that's that case, you should just be able to follow the ZendDB Adapter docs for setting it up for Oracle.
That said, it's not officially supported so it might not work at all or work poorly.
Edit: Just checked out the code. It's not actually built off ZendDB but it's using a lot of the same ideas and using the PHP PDO stuff. Since PDO supports Oracle there's a chance making the framework support it wouldn't be terrible.
+1 for Django. Most of the stuff I get to do is with PHP, and I've tried a couple of PHP frameworks (ZF and CI) too. I haven't gone too deep on using ZF but the feeling I have is that it's ages away from Django. Sure... you can probably do the same app with both frameworks, but Django saves you SO MUCH TIME. Building the admin is seriously trivial, and CRUD operations are at least half the code...just take a look at Django models!!! You want a foreign key... you use the god damned ForeignKey field! ZendFramework, on the other hand...
> apparently it's not though: [1] http://framework.zend.com/manual/en/coding-standard.naming-conventions.html#coding-standard.naming-conventions.functions-and-methods
I would say most frameworks are not following those naming conventions. Why? Because those are the guidelines for a single framework, not something that everyone who writes PHP should abide by.
PEAR and PECL are the places to start for libraries. Unfortunately, a lot of them can be pretty shit and many aren't actively maintained. That said, you can occasionally find some that will do what you need and save you a great deal of work. Most frameworks also provide various built-in libraries to do certain common tasks. Unless you want to use the entire framework you're probably better off not using anything. Also, check out Zend Framework
Take for instance the generation of PDFs. You could write all that from scratch but you may find that most of the work has already been done for you
As for the IDE, you can use PHPStorm, Eclipse, Aptana, NetBeans, and probably a handful of others I don't know about. I still use Notepad++ for simple stuff because I used it for so long that it's just comfortable for me.
Also, definitely make sure you look into Subversion/Git/Mercurial because these are easily the most valuable tools in a developers toolkit. If you aren't already aware, they are version control systems. Simply put they allow you to make modifications to existing code without wiping out the history of the old code. They do a hell of a lot more than that but that's probably what you'll need it for most when starting out. Pick whichever one you like but understand that eventually you'll probably need to learn whatever one is used in your job.
BTW, That "may_edit" function is essentially what Zend_Acl Assertions are for. You can hide the complex logic away in an assert class (that implements Zend_Acl_Assert_Interface), and then use the regular ACL isAllowed() call to check whether an actorId (Role) has access to a profileId (Resource). It's easier if you're working with model objects that implement Zend_Acl_Resource_Interface, though, instead of working with scalar database IDs.
I agree there are a few PHP4 era nastyisms still lurking around... Just at a glance, I'd like to see:
- PSR-0. There really is no reason to have require_once statements riddled throughout the library. It's inefficient and just bad in general. Use an autoloader.
- Find some other way of doing this that doesn't involve globals:
Bad:
global $apiClient;
global $apiConfig;
I'd suggest having an ini / xml / something file with configuration options. See Zend_Config for a guidline.
Good:
$config = new Google\Api\Config('/path/to/config.ini'); Google\Registry::set('config', $config);
What's with all the apiClassName stuff? Using namespaces and / or PSR-0 as mentioned earlier should force out those weird-isms.. I'd expect a structure that makes a little more sense like: Google\API\Gmail\Class\Name or Google_API_Gmail_Class_Name if you aren't using namespaces (which it really would make sense to do here).
Make PHP 5.3 a minimum requirement. Let's keep raising the bar.
Ah, understood.
Anyways, just for fun in case you're curious and I happen to be really familiar with it, here's how you'd setup a project in ZF from the command line:
wget http://framework.zend.com/releases/ZendFramework-1.11.10/ZendFramework-1.11.10.tar.gz tar -xzf ZendFramework-1.11.10.tar.gz alias zf=/path/to/ZendFramework-1.11.10/bin/zf.php zf create project myproj zf enable layout zf configure db-adapter "adapter=MySQLi&dbname=zend&username=root&password=12&charset=utf8"
And you're done.
Like I said, zend is really cool, but since it's an entire library as well as a framework, it has already taken them far too long to finish the jump from 5.2 => 5.3. From as far as I can tell, the end still isn't even in sight. At this point, they might as well hold off and wait until 5.4 comes out so they can take advantage of traits, imho.
Good frameworks that aren't libraries (symphony comes to mind) have the luxury of having a vastly smaller codebase, making refactoring less than a colossal task.
First off, you probably want some kind of front controller that handles all of the requests for you. So, for instance, you rewrite all URLs to go to the index.php at the root of your site. That index.php file looks at the URL and decides what the user is trying to access and then calls the appropriate controller for that request.
So if the requested URI is: /contact then the index.php calls a class called ContactController.
Your controller can have a method for each action that can be performed at a particular URI. So you might have "/contact/add", "/contact/edit", "/contact/delete" and your controller class would have 3 matching methods:
ContactController::Add() ContactController::Edit() ContactController::Delete()
You would probably learn the most by looking at other frameworks and seeing how they do it, and why.
Zend Framework Documentation Has an overview of of how they do routing
LightVC is a framework that only includes the views and controllers, and it looks like their documentation does a decent job of explaining the different pieces.
I would say your best bet is to use different frameworks (or at least read through the documentation for them), and get a handle on how they all do it. Then you can try to create something that works specifically how you need it to.
What exactly is your goal in building this? Are you trying to solve a particular problem that you have when not using an MVC architecture?
The FC is not a singleton. ZF chooses to have Zend_Controller_Front also implement the Singleton pattern, for their own reasons. See: http://framework.zend.com/manual/en/zend.controller.front.html
Furthermore, ZF will eliminate the use of the singleton pattern in Zend_Controller_Front with ZF 2.0. See: http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
Zend Framework's Zend_Db component has an adapter that uses the experimental PDO DBlib that Microsoft is working on:
Obviously use at your own risk.
There is no general standard, people tend to follow what they like. E.g
http://codeigniter.com/user_guide/general/styleguide.html#variable_names
http://framework.zend.com/manual/en/coding-standard.coding-style.html
etc; as long as YoU_dONtwriTE like this you should be golden.
Yeah, I think we're getting on the same page now. PHP Frameworks are a dime-a-dozen, so just saying that you're better and giving a few bullet points isn't enough to convince me that I should expend any more resources investigating it.
I agree, I hate marketing too, but it serves a purpose. Perhaps it's merely a side-effect of the environment we're in -- you're developers after all, not designers -- but when I go to the Lithium site, pretty much every page I go to I'm hit with a wall-o'-text that'd make any unix man page proud. That's good for documentation, but as marketing literature it's overwhelming (IMHO). Fewer words (talk less, say more), a few graphics of some key high-level concepts perhaps demonstrating some areas where you differ from conventional frameworks, with a specific emphasis on how your technique is better, etc.
OTOH, the ZF home is much more inviting; prominent links for just about every visitor, from the "what is ZF and why do I care?" to "I heard ZF is cool, tell me more!" to "Yeah, I need some help with ZF, let me see the docs and/or issue tracker". And while Agavi's home page doesn't provide much info at all, their docs provides a great deal of "newbie" info.
No offense, but your home page comes off as if you expect that every visitor has already been following your project since it's inception, and the vibe I get is that you guys are saying you should know why you're here already and you should already know all of this jargon that we're going to throw around (e.g. "Aspect Inspired Filter System"). I admit, you have quite a few very interesting features, many of which I listed in my 1st reply but also things like the custom app integration (for which there is also a lack of info).
p.s. the black bar at the top of the page is very annoying the way it flashes each time that a page loads.
Hey. I went through a similar situation / project. MSSQL is not supported natively by php anymore, so FreeTDS is about the only choice you have if you really want to access from 'nux. ODBC sucks pretty bad so I won't even mention that option. The simplest way I found was to have a php instance on the machine that hosts mssql, and use sqlsrv. Now. This in itself gives you a half-decent api but the icing on the cake was when I discovered Zend_Db. This in conjunction with Zend_Table gives you a consistent db agnostic api that made synchronising MSSQL and MySQL almost a pleasure. It is very easy to transfer the data back to your linux box into MySQL , with a simple cli script using a remote user connection on MySql.
Good-luck, ( You may need it! )
>I just need to ask stuff to get me on my two feet in the beginning.
Zend Framework does indeed have a steep learning curve. However, once you've gotten the hang of how things work, it gets a lot easier for you.
>which up until a couple of days I was doing only with the help of a book which I have now learn (from what other zf users have told me) that sucks.
The best way to learn how to code in Zend Framework in the manner it was intended is to read from the official docs. The reference guide is an excellent source of information. It has plenty of code snippets from which you can learn from.
The quick start has an example project which should give you a rough idea about how the whole thing fits together.
And the API documentation will give you a complete overview over the various classes and their methods, if you need it.
http://framework.zend.com/manual/en/zend.validate.html
I'm not sure how standalone it is, but you don't have to use the other parts of the framework. Just put it in your include path.
You also might look at Zend_Form as well. I use it all of the time on the backend without using the rendering on the frontend.
I always prefer using a framework. For PHP, my choice is usually Zend. With it you can use their Zend Mail functionality. More details about it here.
Out of the 3 or 4 frameworks I've used I find Zend the best, and also having the best documentation.
Sure it's a bit steep on the pickup but what framework isn't.
Check out the quickstart guide http://framework.zend.com/manual/en/learning.quickstart.intro.html
Generally, best practice is to have your configuration not directly executable. There's no reason for it to be: it should just be a big dictionary of keys and values. That's the security mistake here.
But that's not a failing of PHP, it's the failing of the web developer who decided not to build a proper configuration system. They also decided to ignore the vast array of pre-built solutions that would have fit the bill: the Yaml component, the Zend config library, etc.
Oh, and if they'd used any framework out there worth its salt, this error wouldn't have revealed sensitive data regardless of where it occurred (most have a fully PHP front-controller that immediately loads the framework, and from then on, it's all MVC).
It's really a matter of blame the programmer, not the language in this case. I know it's just as easy to screw up .NET from the number of ASP sites I see that have full debug backtraces in production. I don't chalk that up to the language.
Speaking specifically of a sub-component, Zend_Db_Select, instead of writing any actual SQL, you can do something like this
$db->select()->from('table') ->join('table2', 'table1.id = table2.id') ->where('field1 = ?', $value) ->orWhere('field1 = ?', $value2) ->order('field1 ASC') ->query()->fetchAll();
which would translate into this (unless I'm mistaken)
SELECT * FROM table JOIN table2 ON (table1.id = table2.id) WHERE field1 = '$value' OR field1 = '$value2' ORDER BY field1 ASC
For simple queries, it can save the headache of silly syntax errors in your SQL, and as long as you configure Zend_Db to use PDO, it'll do parameter binding for you.
For more complex queries... well, you should just write them yourself. You can't currently do something like this (as far as I know):
SELECT * FROM table WHERE (field1 = 'a' AND field2 = 'b') OR (field3 = 'c')
You can get more details about what it can do here and, more specifically, here.
It works pretty well as an abstraction layer, but if you want to do any ORM, the recommendation I've heard from most people is that you should look into Doctrine (which I have yet to work with, but plan to).
I have done access control like this many times, and there are always edge cases that cause problems in my experience. However, the implementation you provided could be fine depending on the number of your users and the actions they can do.
Recently, we have considered implementing a proper access controller, using something like this: http://framework.zend.com/manual/en/zend.acl.html
This gives you a lot more control for added complexity. For example, using the levels you outlined, you may have a level 4 moderator that can only moderate specific boards/threads, whereas other moderators that can moderate anything. Using ACLs and permission inheritance would make implementing a scenarios like this way easier.
Testability is a huge one. Why do you think that's bogus?
Another is being able to clearly divide objects into individual components and construct components in and out to customize parts of the overall system.
For example, Zend_Log has the a Log object, which has a Writer, a Formatter, and a Filter. Using DI I can swap out either of these components instead of having to extend one monstrous God object. I can also swap out either component for a mock or stub during testing to make sure it's getting called correctly.
If you can't see the benefits that DI provides, you're either confused as to what DI is or you're a shitty programmer.
Try this:
$db->select()->from('advertisercontest') ->joinLeft('advertiseraccount', 'advertiseraccount.loginid = advertisercontest.loginid', array('avertiserid', 'companyname')) ->where('advertisercontest.golive is not NULL');
You can see the Zend_Db_Select JOIN examples starting around Example #11 here.
I wouldn't say ZF2 is a bust, they are still in the design/decision making/planning process.
The way I see it, Symfony2 is doing every fabpot's way (which im not saying is a bad thing, other frameworks such as Django also operate this way). If all design decisions are made by the same person then less time is spent talking and more time is spend coding. Zend Framework2 has no BDFL, they ask the community for submissions on how to implement certain features. These are then discussed, voted on and implemented.
ZF2's way of doing things certainly takes longer, but it is well thought out and every major decision in it is justified (so you can read why they did X instead of Y).
Considering you mention Zend, and based on some of the config fields, you might want to look into Zend\Ldap
Ok here are some options, after you tried experimenting doing it by hand: http://doctrine-orm.readthedocs.org/projects/doctrine-dbal/en/latest/reference/query-builder.html http://framework.zend.com/manual/current/en/modules/zend.db.sql.html
Usually when dealing with an object it's easier to add some where statements or optional joins in your logic then manipulating the string directly.
A good library for practice, but this problem has been solved numerous times:
https://github.com/yosymfony/Config-loader
http://framework.zend.com/manual/2.4/en/modules/zend.config.introduction.html
I use Zends Soap Client in my projects left and right. Easy to use. The only pain is handling errors and trying to figure out if it is me or them. I know people don't like soap, but I think that is because they haven't used a soap,client that takes care of everything automatically.
http://framework.zend.com/manual/current/en/modules/zend.soap.client.html
Of course. But it's not a requirement.
This is written in the assignment they've given me: > You are free to implement the design how you want (eg. use jQuery, a framework, a css reset) as long as you do it within this Zend Framework setup that has been given to you. If you haven't worked with Zend Framework before it's easy to get going by read on http://framework.zend.com or use Google.
It's not. As the name implies, it's a gateway to a database table. In other words, a object representing the database table.
http://framework.zend.com/manual/current/en/modules/zend.db.table-gateway.html
I'm not personally familiar with the Zend Mail library, but according to a comment on this page the Transport class should throw an Exception\RuntimeException on a send error.
Do a try/catch for that, maybe log the exception and continue on with the loop.
Use the addProperty() method. There are methods that allow you to avoid the nested arrays. They are pretty obvious if you look at the following reference page:
> which method of quoting is conventional
At least in my experience, it depends on which coding standard the devs are following. I've been following the ZF Coding Style for a few years because that's what we use at work. There are other coding standards out there.
I think you read into this too much. I believe OP is using Zend to simply include a JS library (some lightbox).
I think his question is more along the lines of, "How do I make a button open a lightbox."
I might be wrong about the goal, but either way, the question is pretty vague.
I get the same one as well:
$ curl -I http://framework.zend.com HTTP/1.1 200 OK Date: Wed, 24 Dec 2014 15:32:26 GMT Server: Apache X-Frame-Options: SAMEORIGIN X-Powered-By: Play Framework Last-Modified: Wed, 24 Dec 2014 15:00:02 GMT Content-Type: text/html; charset=UTF-8
Maybe they just moved to a different server for a while?
Sure thing:
$ curl -I http://framework.zend.com HTTP/1.1 200 OK Date: Tue, 23 Dec 2014 23:10:02 GMT Server: Apache X-Frame-Options: SAMEORIGIN X-Powered-By: Play Framework Last-Modified: Tue, 23 Dec 2014 15:00:01 GMT Content-Type: text/html; charset=UTF-8
The ZF2 implementation seems good too.
http://framework.zend.com/manual/2.0/en/modules/zend.authentication.adapter.ldap.html
I think I have a repo with the ZF1 implementation using a whitelist. The class was written 4 years ago though.
PHPmyadmin folosesc by default.
N-am nici cea mai vaga idee cu ce se mananca design patterns, o sa arunc un ochi pe google.
Cat despre coding standard, folosesc(sau incerc macar) Zend Coding Standard care banuiesc ca e bazat pe unu'(sau mai multe) din cele 5 PSR-uri.
In general incerc sa-mi fac codu' cat mai usor de citit si cat mai scurt(si la obiect).
Am lucrat la proiecte personale dar am prostu' obicei sa nu le termin pana sar la altu'...
Yeah, I realize this is kind of a lousy example. I could express myself better if I knew which frameworks you use on a regular basis. I've edited my example to make things more clear.
My example is a pseudo-code representation of an entire MVC framework. The Holidays and HolidaysController classes shouldn't need any explanation. ViewInterface, HtmlView, and JsonView are tiny pseudo-code representations of a much larger view enguine. For example Zend\View. Pay particular attention to this part:
> Renderers take View Models and provide a representation of them to return. Zend Framework 2 ships with three renderers by default: a PhpRenderer which utilizes PHP templates in order to generate markup, a JsonRenderer, and a FeedRenderer for generating RSS and Atom feeds.
Also note the return values from the Zend controller examples. (A simple unescaped array)
Everything after "// Handle the request!" represents the front controller. In Symfony the front controller is web/app.php and in Zend Framework the front controller is index.php. This is where the app initializes the appropriate controller to handle the request, calls the controller action, and renders a response to the client.
The Zend Framework v1 provided a pure PHP Lucene search class that you could look at. It doesn't require any other servers or programs running.
http://framework.zend.com/manual/1.12/en/zend.search.lucene.html
ZF v1 is an older version of the framework and I don't think this module has been carried over to v2 but it's still usable code.
- Read this: http://framework.zend.com/manual/1.10/en/zend.cache.theory.html
- Others have already seemed to explain what PSR-6 is. As to why it matters: it would propose a common Interface for all cache related classes, for what each method should be named and what parameters should they accept; its purpose would be so you could use the exact same caching object in your own project's classes as anyone else's library's classes (as long as you both would respect PSR-6 of course). If this PSR-6 comes it in - say - half a year, I would not be happy to adopt any new cache libraries knowing that caching is going to be standardized soon anyway.
No, there are many ACL implementations, you can choose any but ACL is what are you looking for. The important point is that you must understand ACL logic:
http://en.wikipedia.org/wiki/Access_control_list
Zend has another ACL solution:
http://framework.zend.com/manual/1.12/en/zend.acl.introduction.html
You should modify the blog post a little. It seems that ZF2 now uses Zend\ServiceManager instead of Zend\Di because of performance issues.
It depends on your situation, if your stuck on shared host or pay is poor use a database queue, like Zend_Queue in an afternoon you can have the job done.
Advantages * No extra dependencies to manage. * Work in a shard host environment * Quicker to implement.
While the queue won't scale as effectively as the other suggested platforms if your traffic is not going to exceed the capacity of single server your database queue will be fine.
If you already have the code written, download the Zend Framework and use JUST THE LIBRARY classes, DO NOT TRY TO USE THE ZEND FRAMEWORK. You already have it all built, so you don't want to rebuild everything, just use the Zend library to assist you with doing your own login system.
Most PHP frameworks have a recommended project layout you can refer to, like this one for Zend Framework. If you site mostly resembles a blog, why not start with an existing blog platform like WordPress or Drupal and go from there? Either way, /r/PHP might be a better fit for these kind of questions.
Nearly every framework supports multiple controllers and views. That's half the point of the MVC pattern. Here's an example of setting up your routes in Zend Framework. You can also setup your routing to automatically understand "/application/controller/action" instead of the standard "/controller/action".
The point gets debated around here often, but unfortunately, it's the sort of thing you can only learn through experience. However, that does leave yourself open to picking up all sorts of bad habits - so I strongly recommend starting by learning a framework first, to at least get you using a strong methodology. CodeIgniter, Symfony (my fav), and Zend are all popular around here. After you have a good idea of how an application is structured, then you can worry about the low-level details.
The main thing is, you want to look at other people's well-written code, and try to get feedback from people who know the language well and can help you improve. Whatever you do, don't just code in a vacuum - we all learn by seeing what others are doing.
Try picking up an open source project and seeing how they structure their code - maybe Drupal or Joomla or one of those frameworks themselves. (Please not Wordpress - it's a great piece of software that's very poorly written.)
Wait.. You're doing this in PHP, but you're using some weird method in place of a normal loop. Why?
Do it the sensible way, like this:
<ul> <?php foreach ($this->variableArray as $item): ?> <li><?php echo $item->getValue() ?></li> <?php enforeach;?> </ul>
Have a look at Zend_View or similar.
It had performance benefits at the time I last checked.
http://news.php.net/php.standards/2
http://framework.zend.com/manual/en/coding-standard.naming-conventions.html
http://pear.php.net/manual/en/standards.classdef.php
Just reiterating your suggestions.
Just browse these to get an idea of how easy it should be... Symfony2 Form Zend_Form
> Why is $_REQUEST the best practise?
Ever work with multiple developers on thousands of scripts? It's really a simplification as you don't have to keep track of where it's coming from. In this particular context, bare-bones PHP with no additional layers, there are no practical differences comparing $_REQUEST to $_GET or $_POST.
However, if you ever use a framework such as Zend Framework, the story changes.
$this->_request->getParams();
http://framework.zend.com/manual/en/zend.controller.request.html
> Be cautious when accessing [GET and POST Data] from the request object as it is not filtered in any way. The router and dispatcher validate and filter data for use with their tasks, but leave the data untouched in the request object.
In general, never trust user input, and $_REQUEST / $_GET / $_POST is as raw as it gets.
An aside, I've seen this in live production code:
$safe_value = $_REQUEST['value']; $sql_query = 'DELETE FROM fart.foo WHERE name = ' . $safe_value;
No validation, lying variable names, no LIMIT... man, bad stuff.
Not implying that anyone here would do that, just wanted to pass that gem on. Moral? Again, never trust user input or variable names. Also, use prepared statements, etc.
> I didn't claim it was necessary to split it into two pages, just a possibility if you want to do minimal changes to the code.
True, you said it was an "alternative", but there is no practical reason for doing it; it increases clutter, spreads logic out unnecessarily, creates a more inflexible system, etc. Not something I would recommend to someone who is unfamiliar with it. Just because you can doesn't mean you should.
If you are already familiar with programming you might want to check out a framework. I prefer Zend Framework
http://framework.zend.com/manual/en/learning.quickstart.intro.html
It's also fun to read the actual source code for the framework you use to see how and what they are doing.
Re: Form generation in ZF
This generates a from from the doctrine model at run time: https://github.com/jhartikainen/zf-modelform Documentation: http://codeutopia.net/blog/?s=ModelForm
Or this one generates the forms using Zend_Tool: http://framework.zend.com/wiki/display/ZFPROP/Doctrine+1+and+Zend_Tool+Integration+-+Benjamin+Eberlei
Also you may go browse through the open issues in Zend's bug tracker.
Well, it looks like there are better ways to parse the data.
Either use resource with
http://framework.zend.com/manual/en/zend.view.helpers.html#zend.view.helpers.initial.navigation.acl
or grab the data that you want to use in easier ways, using of properties of the class:
http://framework.zend.com/manual/en/zend.navigation.pages.html
To answer both your points: here's a link to an article on this stuff and also a note that Zend Framework structures URLs like this. You configure your Apache conf file to redirect all requests to index.php (or whatever your bootstrap file is) and then that launches Zend and it parses the URL.
mmm right now I'm actually trying to make this SQL statement work: SELECT pais FROM pais LEFT OUTER JOIN users_has_pais ON pais.id = users_has_pais.pais_id WHERE users_has_pais.users_id = ?
but the documentation for that is kind of...well, weird. I'm trying...but I really don't know what to do:
$paisInstance = new Model_UsersHasPais(); $resultSetPais = $paisInstance->select() ->from('pais') ->joinLeft(array( 'users_has_pais', 'pais' ))
Why aren't you using Zend_Db_Table for retrieving and setting the data?
It has mechanisms for handling this stuff for you.
Zend_Service_Twitter_Search is pretty simple to work with. If you look at the twitter api, you'll see you can specify the offset tweetId. Quick hint: tweetId's are too big for PHP so you have to use floats or strings before it goes into mysql.
No, keep all js/css/images in the "public" folder. I think external dependencies are a nightmare as well. For example, you symbolically link the Zend Framework on your local workstation and symbolically link it on your server. You run the risk of the ZF version producing a mis match. Please read here for the ZF suggested project directory structure.
I've never had to do anything like this, but you can probably just go with Zend_Barcode for PHP. It's very simple to use, and you can use it on it's own without the rest of the Zend framework.
Zend_Barcode::factory('<format>', 'image', array('text' => 'hello world!'), array())->draw();
http://framework.zend.com is what we're building on at the moment. Its pretty awesome. Full MVC framework that was built by the guys who invented PHP. Its not actually a CMS, its just a framework that you can build into whatever you like. Ive used wordpress and silverstripe before but i just find that if you need to veer too far away from the original usage, the CMS really starts hindering your progress and not helping it.
You might need to get to the underlying PDO object itself and use it's wacky streams-based LOB reading mechanism.
Alternately, you can use the other, non-PDO Oracle adapter. I'm not entirely sure how to go about doing that, the proper name isn't clear from the documentation.
e: Sudden moment of clarity. You're connecting using PDO_OCI, but you're trying to use the non-PDO statement handler. Use the right classes and you should get the right behavior.
There are a few frameworks out there that do the "MVC" thing.
MVC can get complex in a hurry but all of these are open source so you can see how they engineered things out.