Welcome Guest, Not a member yet? Register   Sign In
noob questions
#1

[eluser]mshallop[/eluser]
Hey - our shop is picking up ci as our framework, dumping cake because we need a framework that can easily connect to our broker-based backend...

so I have a few noob questions that have popped as I muddle through this ramp-up...using a simple email/authentication page that collects the two pieces of data via a post form and then packages and publishes a message to the broker -- and then returns the response for processing and generating the subsequent view...

1. Explain the difference, please, between a controller's __construct() and index() methods? I'm getting that they both basically proc when the controller is loaded and that index() is automagically invoked because of something to do with .htaccess squelching the index.hmtl out of the url? (And to always call parent::__construct() in your controller constructor...)

2. I'm tasked with integrating pieces of the back-end framework (rmq-based mongo/mysql stack) into c/i so that requests for data are morphed into broker requests as opposed to, say, db CRUD calls...

a) - c/i doesn't play well with singletons? seems like I'd want to convert my static classes into a c/i library and load these from the model when I'm preparing a message to publish to the broker...
b) - I use a LOT of constants (const FOO "bar"Wink in my code -- I should convert these to global defines in the application/config/constants.php file? Currently, I have them loading as a helper file that's loaded by the login model...
c) - The amqp libraries - I put these into application/libraries/{foo}/bar.inc - and am invoking in the controller constructor via a PHP require ( APPPATH . 'path stuffs') ... is this the "right" way to bring in a 3rd-party library? (that doesn't follow the CI convention of one-class, one file standard)

3. Anyone else use PHPStorm as your IDE for CI? This IDE is having problems parsing the various CI class trees with respect to flagging methods as not-found (annoying little yellow blocks)... Any known way of fixing these so we're "super green"?

Thanks for reading...looking forward to learning more...

--mike
#2

[eluser]johnpeace[/eluser]
Hi. welcome to codeigniter. It's way more straightforward and way less resource intensive than CakePHP.

Quote:1. Explain the difference, please, between a controller’s __construct() and index() methods? I’m getting that they both basically proc when the controller is loaded and that index() is automagically invoked because of something to do with .htaccess squelching the index.hmtl out of the url? (And to always call parent::__construct() in your controller constructor…)

The class constructor is called every time the class is instantiated, so it'll run any time any of the methods in the controller are called. The 'index' method is simply the default method that will be called when you access the controller by URL. I use the controller constructors to do things like load libraries/helpers that will be used by my controller methods, handle authentication, tasks that will be done whenever ANY (or at least, more than one) of it's methods are called.

Quote:3. Anyone else use PHPStorm as your IDE for CI? This IDE is having problems parsing the various CI class trees with respect to flagging methods as not-found (annoying little yellow blocks)... Any known way of fixing these so we’re “super green”?

Have you seen this tutorial?

http://grafikkaos.co.uk/blog/article/104...h-phpstorm

I use Eclipse and all of the IDEs work about the same, you need to declare variables with the names of CI's classes in your controllers/models (or their parent classes, I do it in core/MY_Controller and core/MY_Model), this will make those available in the $this-> context. I also need to include the CI code in my project include path, but that may be because my apps use a separate external directory for the ci/system files (so that multiple apps can use the same CI installation...to make version swapping and upgrades easier).

Good luck and enjoy!
#3

[eluser]Harold Villacorte[/eluser]
[quote author="mshallop" date="1362002730"]
a) - c/i doesn't play well with singletons? seems like I'd want to convert my static classes into a c/i library and load these from the model when I'm preparing a message to publish to the broker...
b) - I use a LOT of constants (const FOO "bar"Wink in my code -- I should convert these to global defines in the application/config/constants.php file? Currently, I have them loading as a helper file that's loaded by the login model...
c) - The amqp libraries - I put these into application/libraries/{foo}/bar.inc - and am invoking in the controller constructor via a PHP require ( APPPATH . 'path stuffs') ... is this the "right" way to bring in a 3rd-party library? (that doesn't follow the CI convention of one-class, one file standard
[/quote]

a) I don't think Ci's loader class will load classes in the singleton way. You would have to extend the loader class or load them manually.

b) You can put constants in config/constants.php.

c) You can just use the loader class. $this->load->library('your_library'); As long as the class name is the same as the file name and there are no dots in the file name. CI will automatically instantiate the class and assign it as property of the super object.
#4

[eluser]mshallop[/eluser]
Thank you for the quick responses - they were very helpful and informative!
#5

[eluser]Harold Villacorte[/eluser]
And one more thing. You should also familarize yourself with the index.php file. There are a bunch of constants defined in there as well and that is where you define the environment and the path to the system and application folders so you can move them out of the web root.
#6

[eluser]mshallop[/eluser]
quick question about web-root that you're referencing -- have also seen it referenced in other ci doc...

Say I have apache configured for the domain to be referenced at: /home/codeigniter...

Under this directory, then, I have the following set-up:

/codeigniter
|
- /application
|
- /controllers
- /models
- /views
|
- /system
|
- /assets
|
- /img
- /js
- /config
- /css

CI can access /assets as a sib directory to applications -- when I had /assets as a child directory to /application, I was getting 404'd...this make me assume that CI sees webroot as /codeigniter/application/ and anything that's at the same level as that directory is considered to be outside of the CI webroot - but should still be "visible" to apache...

If this assumption is correct, then shouldn't the apache documentRoot be set to: /home/codeigniter/application as well?

Slightly confusicated...

#7

[eluser]InsiteFX[/eluser]
No, if you look in the application directory you will see a .htaccess file which blocks access to it.
#8

[eluser]Harold Villacorte[/eluser]
This would be a simple file structure:

application/
system/
webroot/index.php
webroot/assets

Then in index.php you just have to define the path to the application and system directories like this:
Code:
$system_path = '../system';
$application_folder = '../application';
If you put the webroot in the application directory like you are saying then you would have to also put an .htaccess in there to override the one in the application directory root, but what you really want is for the "Deny from all" to apply to the entire application folder.




Theme © iAndrew 2016 - Forum software by © MyBB