I have to connect to lots of legacy databases and bring back the information for a single integrated page.
Will Zend let me do that "naturally" or is that something that can be done in Zend only as a "hack"?
Am I better off rolling my own for things like this kind of project and leaving frameworks out of the picture?
Thanks.
edit: most frameworks don't seem to cater to this. I often feel like I'm the only guy that needs to connect to a boatload of resources and put them in one page.
There is no limitation on Zend to do that, you can use the database resource loader to load several instances of Zend_Db objects and use them at your disposal.
You shouldn't have any problems. There's even a "multidb" resource plugin: Zend_Application_Resource_Multidb which sounds like it supports exactly your use-case.
Related
I'm just getting started with Go and as a first project I decided to make a simple REST API server. Unfortunately, I've hit a problem as I can't seem to find the best way to structure my project.
So far, I'm using the same structure as a Rails project meaning having controllers and models in their own folders, but it doesn't as idiomatic as go code should be.
Does anyone have any advice on how to properly structure a project?
It's probably do-able, but because of static compilation you're going to have a bit of a mess if you want a lot of Rails' automagic for figuring out routes.
I'd probably just have a models package with all the database models, and then something based on Gorilla's mux to bind some routes to some actions.
If things are getting complicated you can try a larger framework like Revel, which might be more suitable for a larger MVC application.
I own a Play 2.1 application.
Initially, I used the default template mechanisms from Play 2.1 until I .. learned AngularJS.
Now, I clearly want my client side to be an AngularJS app.
However, while surfing the net, I find there are no clear way to achieve it:
Letting Play behave as a simple RESTful application (deleting the view folder) and making a totally distinct project to build the view (AngularJS app initialized by grunt.js).
Advantage: Likely to be less messy, and front and backend teams would work easily separately.
Drawback: Need another HTTP server for the AngularJS app.
Try to totally integrate AngularJS app with the traditional Play's workflow.
Drawback: With a pretty complex framework like AngularJS, it would lead to a confusion of templates managementfor instance : scala.html (for Play) / tpl.html (for Angular) ... => messy.
Making a custom folder within the play project but distinct from the initial folders created by the Play scaffolding. Let's call it myangularview instead of traditional view for instance. Then, publish static contents generated by grunt.js into the Play's public folder, in order to be reachable from browser through Play's routing.
Advantage: SRP between components is still fairly respected and no need to use another light HTTP server for the client-side like in 1.
I pointed out my own views of advantage and drawbacks.
What would be a great way to achieve the combination of Play with Angular?
Yes, I'm answering to my own question :)
I came across this way of doing:
http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails?? No matter the framework is, the need remains exactly same.
It advocates a real separation between APIs (backend side), and front-end side (in this case making AJAX calls to backend server).
Thus, what I've learned is:
During development phase, a developer would use two servers: localhost on two distinct ports.
During production phase, the front-end elements would be encompassed into the whole backend side (the article would deal with a kind public folder, aiming to serve static contents: HTML, angular templates (for instance), CSS etc... Advantage? => dealing with a one and unique serving server's APIs exposition as well as static assets for the UI.
With this organization, some tools like Yeoman would be able to bring some really awesome handy things to developers like for instance: the livereload feature. :):)
Of course, during development phase, we end up with two different domains, (localhost:3000 and localhost:9000 for instance) causing issues for traditional ajax requests. Then, as the article points out, a proxy may be really useful.
I really find this whole practice very elegant and pleasant to work with.
There was an interesting discussion on the play mailinglist a couple of days ago about frontend-stack/solution, could be something in it for you, quite some people using angular it seems: https://groups.google.com/forum/#!searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ
I have a large project and want to move to the Yii Framework for PHP.
In the same dir i have 3 index page. index.mail.php, index.home.php, index.login.php and i have rewrite rules like localhost/mail, localhost/home, localhost/login. And these urls also accept their own GET and POST datas.
These tree application of course different. But they are using same library. (different view and models but same public classes)
All i want to do is host these 3 and more application at the same time in 1 Yii thread.
How can i do that? In yii, it seems i can only host 1 application at the same time. (maybe im wrong)
--
I'm asking this by regarding to this post: Which one to go; Yii or Symfony. I decided to use Yii.
Well Yii is correct decision and you should stick with it. You can use those three as modules.
Modules are basically small website applications but they can not work independently. Best option is Using modules for each thing.
you can have them on single yii application
Yii support "module" which have full functionality of MVC website, it is appropriate in your case.
http://www.yiiframework.com/doc/guide/1.1/en/basics.module
I am looking to upgrade an existing perl web-based application and wondering if there are any suggestions on how to solve a particular problem:
The application is used by several clients who each have a very customized dataset behind the scenes. There is very little overlap in the dataset between clients. However, they all load and use the same software. There are numerous configuration files that tell the software how to process this client and understand it's customized dataset.
In essence, there are common functions but different datasets that those functions work upon. I'm looking for a way to abstract the datasets into an ORM. However, most ORMs seem to expect a common dataset behind the scenes. I need to either load the ORM modules dynamically based on the client being used or dynamically create the ORM structure based on the same.
e.g.
The software provides View/Edit/Delete functionality but
Client A
Manages tables
Client B
Manages automobiles
The View function loads configuration files and has custom template files for each client that are relevant to the type of data they are managing.
Any suggestions?
Check out Jorge
See Rose::DB::Object (RDBO).
It support's loading the database structure at runtime by its Loader package. John Siracusa, the author of RDBO is always kindly responding to question in #rdbo on irc.perl.org or the mailing list.
It's also very fast (once loaded) and powerful. I can really recommend it if you have a DB application more complex than any example app.
I'm in the middle of converting an existing app built on top of zend framework to work as a plugin within wordpress as opposed to the standalone application it currently is.
I've never really used zend so I've had to learn about it in order to know where to begin. I must say that at first I didn't think much of zend, but it's funny because the more I understand how it works the more I keep questioning why I'd want to remove dependency when it's a clearly well thought out framework. Then I'm reminded that it's because of wordpress.
Now I already know there are WP plugins to make zend play nice with WP. In fact I'm aleady using a zend framework plugin just to get the app functional within the WP admin area which is allowing me to review code, modify code, refresh the browser, review changes, debug code, again and again.
Anyway, I really don't have a specific question but instead I'm looking for advice from any zend masters out there to offer advice on how to best go about a task like this one.... so any comments, advice, examples or suggestions would be super.
One area I'm a little stuck on is converting parts of zend->db calls to work as wpdb calls instead... specifically the zend->db->select.... not sure what to do with that one.
Also on how to handle all the URL routing with automatic calls to "whatverAction" within thier respective controllers files.
Any help would be great! Thanks
You're probably facing an uphill battle trying to get some of the more major components of ZF to work in harmony with Wordpress. It sounds like you've got a full MVC app that you're trying to integrate into a second app that has very different architecture.
You probably want to think about which components handle which responsibilities. Wordpress has it's own routing and controller system that revolves around posts, pages and 'The Loop'. This is entirely different from Zend's Action Controllers and routing system.
It's possible you could write a WP hook to evaluate every incoming request and decide if it should be handled by WP or a ZF controller. However, it is doubtful you would be able to replace WP's routing system outright with ZF's or vice versa.
Same idea, where Zend_Db is concerned. There's nothing stopping you from using Zend_Db to access Wordpress's database, but trying to somehow convert or adapt Zend_db calls into wpdb calls sounds painful. If you have a large model layer, you probably want to hang on to it, and find a way to translate data from those models into the posts/pages conventions that Wordpress uses.
Personally, I would use ZF to build a robust business layer that can be queried through an object model via a Wordpress plugin, and then rely on Wordpress to do the routing and handle the views.
Zend_DB_Select is simple SQL query (but created using objects) that can be used like any other query. Just turn it into string. Ex.:
mysql_query((string)$zendDbSelectObject);