Where to place "common" classes in YII Framework structure? - yii

I need to create a few classes and would like some help on where this would go in the YII Framework. I know if I create a Model, it must go in the "models" directory. And by the same logic I know where "views", "controllers" etc would go. However, where would the following be placed in my web application:
A class that contains a variety of "number" functions such as currency conversion, metric conversions etc?
A class that interacts with a REST API? (It interacts with the database)
Any tips?

To get started with adding custom classeses on YII you can check below link.
http://www.yiiframework.com/wiki/165/understanding-autoloading-helper-classes-and-helper-functions/
Hope it'll help you to start.

You can find an example here, it is pretty detailed in my opinion:
The directory structure of the Yii project site

Usually you can use any PHP class in within Yii. You can place it in the models folder (alongside the Yii generated models) and access them directly like so:
$myclass = new MyClass;
$myclass->methodname;
Alternatively (or if you run into any issues), you have can place it anywhere in your directory structure and include it in the main index.php (in the root) like so:
$myclass = dirname(__FILE__).'/myclass.php';
require_once($myclass);

Related

How can I create a less redundant project structure?

Currently I'm working on a webapp that has a structure roughly like this:
model
user
robot
service
user
robot
web
controller
user
robot
I'm noticing a lot of redundancy in this structure. Is there any way that I could create a project structure that is less redundant?
The main idea behind folders in a project is to encourage separation of concerns. Each folder should group code into separate functionalities.
Your folder structure seems fine, but I would suggest changing the name of the files so that you know exactly what you're dealing with.
Perhaps more like:
model
user
robot
service
userService
robotService
web
userController
robotController
This way you know immediately that:
model files show structure of entities but no functions or logic
services deal with business logic only
controllers deal with API interfaces

Where to put database Model for extensions?

I want to write a small extension that is able to take some informations from the database, based on some user filter preference, and show them on the main page.
I have read: PHPBB extensions development and took a look at: ACME DEMO extension but i didn't find an answer to where the database handling should be placed. Normally this should go into a Model that will handle the data to a Controller, in this case I was not able to figure out where the Model should be placed in to the structure and how it should work.
How should an extension database model should be handled? Where should it sit in to the extension structure?
I'm guessing you would need an event listener.
PHP event listeners work with core events to inject code into phpBB.
Core events are like hooks, and they can be found throughout phpBB’s
codebase at key points. They give your extension access to phpBB’s
variables and allow you to use and modify them or to inject additional
PHP code during phpBB’s execution. -per the Skeleton Extension
Page

Can I use/adapt the Kohana userguide module to create help pages for my application?

I'd like to create a userguide for the application I'm building using the Kohana framework, and I'm wondering if there's a way I can use the Kohana userguide module for this purpose.
I understand how to add userguide info for new modules that I create, and how to include my classes in the API, but I want to build a second, separate userguide for the actual application user, as opposed to the app developers.
At first, I thought I'd just try adding app help pages to the main userguide at APPPATH/guide. I tried adding a "application/guide" directory, and put a file in there called menu.md, but that just ended up replacing the Kohana menu in the userguide. After renaming the file to menu.myapp.md, it doesn't show up at all.
So then it occurs to me that I could simple edit modules/userguide/guide/menu.md to add sections for my app, and likewise add markdown files for each app component. But really it would be much better to have a completely separate userguide for app users since the Kohana documentation isn't relevant for them.
What's the best way to go about this? Should I create a duplicate of the entire userguide module and modify the routing, &c.? Or is there some way to set up both userguides using the one version of the module? Or am I barking up the wrong tree altogether? Is there some other module/approach that would be better for building "Help" pages for the app?
Thanks in advance for your help!
Yes, you can make docs for your application with the userguide. If you want examples, check out these links:
https://github.com/zombor/Auto-Modeler/blob/master/config/userguide.php
https://github.com/zombor/Auto-Modeler/tree/master/guide/auto-modeler
Note that you'll still get "api docs" and everything else, unless you change the config to hide them.

How to connect Social Media Streams (Twitter, Instagram) in Rails

I am doing my first baby steps with Rails (version 3) now. I'd like to create a simple app catching data from the twitter/instagram/ API. Thankfully there are already gems doing the heavy lifting with connecting to the services, providing the data. Now I wonder what the best-practice is to add this functionality to Rails correctly.
My feeling is the best way is to create a new non-DB Model for each service I want to include and create some scopes, which I will then use in the controller. The scope definition includes the functional code, instantiating and using the twitter/instagram gems to get the web service's data.
Is this model/scope approach right or did I miss something?
In future I might need to cache all the fetched data to handle common API request limitations. Is there any good approach for this?
I'd appreciate your thoughts or examples/resources on this topic.
I think in this situation a standard class would be ok e.g.
class TwitterImport
def get_tweets
# Download tweets
...
# Create tweets
Tweet.create(.....
end
end
I created something similar recently. I created a folder called scripts in my app directory and stuck a class in there called import.rb. Because this file lives within the app directory it automatically has access to the Rails goodness i.e. existing Models etc.
I then set it up as a rails runner script, you run it via teh console from your app's root directory:
rails runner -e development TwitterImport.get_tweets

ecommerce using stripes

We have planned to start an e commerce project using Stripes + Hibernate.
Please let me know if it is good to have admin & user part in same project or two separate ones.
If it is a single project , how do i separate admin side code & user code.
for eg: if i have admin actions in com.ecommerce.adminactions pacakge and user actions in com.ecommerce.useractions package should i use dynamicmappingfilter to direct admin request to com.ecommerce.adminactions and user request to com.ecommerce.useractions ?
-http://myecommerce.com/admin/* - > should always go to com.ecommerce.adminactions
-http://myecommerce.com/ -> should go to com.ecommerce.useractions
or
Should i use #urlbinding(/admin/st.action) in each class (Hard code).
The requirement is they need multistore concept.
Please let me know your thoughts on this.Your thoughts & suggestions will be helpful
Thanks
The Stripes framework does not really influence decisions on how you should organize you're project, or how you should organize your IDE project structure, or even Java package structure or URL structure.
One or more project
Unless you have many developers, keep it all in a single project.
Package structure
A package structure should organize you're Java classes so that you put classes that are logically related (as defined by your architecture!) is in the same package. For example: com.ecommerce.action.admin and com.ecommerce.action.. See also: Properly package your Java classes
URL structure
Typically you want you're URL structure to reflect the logical structure of your website (not the same as your technical structure). To accomplish this, you should not rely on the default URL's but use #UrlBinding. With the annotation you do not hard code links, as all generated links will automatically use the UrlBinding pattern.
Multi store concept
For a multi store concept, you will need to build logic in your application for distinguishing between the different shops. For example by adding a shop id to your URL parameters. Or more sophisticated by detecting the (sub)domain name used and map that to a shop id (You can implement this by using an interceptor).