I would like to know why Zend autoloader require registering namespaces. At first it seems it could be avoided, so I would like to know what I am missing :
If I want to use an external class, I have to put in libraryFolder and when I use it, I have to reference its full name :
For example, if I want to use the class in /libraryFolder/myNamespace/package_name/Class/Name.php, I have to call \myNamespace\package_name\Class_Name.
So why do I have to register myNamespace ? Zend should find the class without registering thanks to the full name \myNamespace\package_name\Class_Name being given.
I know I am missing something but not sure what.
It seems to be a effort to put some limits on how far the autoloader will look for a class, however if you want the autoloader to load anything simply set : $autoloader->setFallbackAutoloader(true);
http://framework.zend.com/manual/1.12/en/zend.loader.autoloader.html
Related
I just started using puppet. I don't know how to execute classes in puppet.
I've my files "config.pp init.pp install.pp service.pp".
For example install.pp :
class sshd::install{ ... }
Next, i declare my class in init.pp with "include sshd::install".
I also tried to run classes with :
class{'sshd::install':} -> class{'sshd::config':} ~> class{'sshd::service':}
After that, i launch "puppet apply init.pp" but nothing.
My scripts work individualy, but with classes i don't know how to execute all my classes.
Thanks
I'm not sure how much research you've done into Puppet and how its code is structured, but these may help:
Module Fundamentals
Digital Ocean's guide.
It appears that you are starting out with a basic module structure (based on your use of init/install/service), which is good, however your execution approach is that of a direct manifest (Not the module itself) which won't work within the module you are testing due to autoloading unless your files are inside a valid module path.
Basically: You want to put your class/module structured code within Puppet's module path (puppet config print modulepath) then you want to use another manifest file (.pp) to include your class.
An example file structure:
/etc/puppetlabs/code/modules/sshd/manifests/init.pp
install.pp
service.pp
/tmp/my_manifest.pp
Your class sshd(){ ... } code goes in the init.pp, and class sshd::install(){ ... } goes in install.pp etc...
Then the 'my_manifest.pp' would look something like this:
include ::sshd
And you would apply with: puppet apply /tmp/my_manifest.pp.
Once this works, you can learn about the various approaches to applying manifests to your nodes (direct, like this, using an ENC, using a site.pp, etc... Feel free to do further reading).
Alternatively, as long as the module is within your modulepath (as mentioned above) you could simply do puppet apply -e 'include ::sshd'
In order to get the code that you have to operate the way you are expecting it to, it would need to look like this:
# Note: This is BAD code, do not reproduce/use
class sshd() {
class{'sshd::install':} ->
class{'sshd::config':} ~>
class{'sshd::service':}
}
include sshd
or something similar, which entirely breaks how the module structure works. (In fact, that code will not work without the module in the correct path and will display some VERY odd behavior if executed directly. Do not write code like that.)
I've read some documentation and downloaded samples but I still got a question.
In most sample, the GIN module uses something like :
bind(MainActivityMapper.class);
bind(VerticalMasterActivityMapper.class);
I don't understand what it does? If I remove it from the sample code, everything works perfectly.
Thanks for any answer.
Someone pointed me to the GUICE page : http://google-guice.googlecode.com/git/javadoc/com/google/inject/Binder.html
There is no reason for it to be different in Gin.
Here is what it says for this particular case :
This statement does essentially nothing; it "binds the
class to itself" and does not change Guice's default behavior. You may
still want to use this if you prefer your Module class to serve as an
explicit manifest for the services it provides. Also, in rare cases,
Guice may be unable to validate a binding at injector creation time
unless it is given explicitly.
Note: I'm not sure wether or not I should Accept my own answer, so I'll leave it as is.
When I use catalyst.pl to auto-generate my application, the AUTHOR section of the POD includes only my name like this.
Kiffin Gish,,,
What are the missing fields and how can I use them? Is it possible to use another boilerplate for the PODs?
It's using the GECOS field from your line in the passwd file (courtesy of getpwuid). You can change the author name that shows up by setting the AUTHOR environment variable, although this doesn't seem documented. As for overriding the entire thing: not so much, unless you want to write your own catalyst.pl that uses a custom subclass of Catalyst::Helper, or submit the patch to -Runtime to let everyone do that.:)
I am using the password confirmation validator from the official Zend framwork document here:
http://framework.zend.com/manual/en/zend.form.elements.html
In Bootstrap.php, I have set the namespace as
'namespace' => 'My_'
The file is located at
application/validate/PasswordConfirmation.php
However, "Fatal error: Class 'My_Validate_PasswordConfirmation' not found" occurs in my Zend_Form.
What should I do to fix the problem?
I designed and implemented Zend_Filter_Input, including its namespace feature.
You have a backwards understanding of how this feature works. It's meant to allow you to use a short name for a validator class when the actual name of that class is longer. You're apparently doing the reverse, trying to name a class with a longer name than it actually has.
To fix this I recommend the following steps:
Name the class My_Validate_PasswordConfirmation
Put it in `application/My/Validate/PasswordConfirmation.php
Add namespace=>'My_Validate' to your Zend_Filter_Input options.
Invoke the validator as simply "PasswordConfirmation".
update: I spent some time on this. It seems my first idea was off target. The namespace issue you have has nothing to do with the feature of Zend_Filter_Input, it has to do with the Zend_Application bootstrap feature. It seems that you can specify a class prefix to the autoloader.
Here's another clue:
Zend_Loader_Autoloader_Resource makes
the assumption that all code you are
autoloading will use an underscore
separator between namespaces,
components, and classes. As a result,
you do not need to use the trailing
underscore when registering a resource
autoloader.
So try this:
'namespace' => 'My',
with no trailing underscore.
Sorry this is a pretty long question, but i want to have some disucssions here.
i am new to zend and try to avoid using modules as I think the view aspect of zend is pretty flexible and module will add extra directory and confusion. However i am wondering one thing. The app i am building is pretty big it actually has the modules concept in the app.
I know if using module, things can be more organised, where you can put modules in its own directory and have seperate view and controller etc.
however i decided to simulate module directory in the form of
--lang/module(in fact the controller)/controller(that's the action)/action(that's the child-action)/other-params/--
how we go about and do this kind of simulation
The initial idea i have is add another route to the application take the 4th param as the child-action. e.g
class some_controller extend extends Zend_Controller_Action{
public function someAction{
switch (child-action) {
case 'child-action1':
....... excute some action
break;
case 'child-action2':
....... excute some action
break;....
}
}
something like that. Does that make sense or if there's any other approach? and with this approach how we integrate Zend_ACL as how to add the 'fake child action' as a resource?
Thank you.
Perhaps you could set up your routes like so:
/:controller/:action/:child-action
See here for more info on setting up routes.
Then in your action methods:
$childAction = $this->getParam('child-action');
// convert $childAction to camelCase.
if(method_exists($this, $childAction))
{
// Check ACL
$this->$childAction();
}
Do not name child actions with the Action postfix as that would allow the actions to be called directly. You could maybe postfix them with something like 'fooChild' but not 'fooChildAction' as they would then map to 'foo-child'.
I think this is making it plenty more complicated then just working with the module directory structure...
Which once set-up, is not that complicated at all, it's just a logical separation of classes...
It would make more sense to add a route ;)
have :module/:controller/:action/ -> admin/posts/add
and :module/posts/add/:action -> admin/posts/add/concept that would link to PostsAddController::ConceptAction();
better than switch statement i guess ;) But you can use it to... case "sth": $this->_forward('my-action','my-controller');