I was just looking to get some clarification on how FuelPHP handles language files across modules and the application directory. Does it merge all of them of the same name into one language array or if it finds it in the application does it just stop there?
If I was to create a foo.php language file in the application and in a module, will I have access to all the stuff in both files or just the one in application?
If you are in a module context, Lang::load('foo') will load the language file from the module, and will merge it with a global 'foo' if that exists.
You only have to explicitly specify the module using Lang::load('module::foo') if you are not in a module context, or you want to load something from another module then the active module.
Related
For my doxygen project, I have setup the program such that every directory in a large, multilevel project is doxygenized while linking itself to its subdirectories by way of tagfiles.
Because the files tab does not account for this nested tagging method, I decided to use an external File Tree plugin for jquery that dynamically loads the subdirectory tree dynamically via PHP. I have the code setup in external/directories.txt with standard page comments so that every subdirectory doxygen uses the same external folder as an input.
However, when I attempt to create a page called Directory with the name of directory.html, it no longer generates the page after a few doxygen runs through subdirectories. When I changed the name to directory_tree, it begins to generate again for some time until it exhausts most subdirectories. Is there any way to have pages with the same name on a per directory basis even when tagfiles are used? Thanks.
Edit: My original post is extremely confusing, so I'm clarifying it here.
I have a generic file called directories.txt in a folder called input that looks like this:
/**
#page directory Directories
<h2>Click on text to go to directory, Click on tab to see subdirectories</h2>
<div id="fileTree" class="demo"></div>
*/
The idea is that every time i run doxygen on a directory, I would pull from this generic file to create a page called directories since the fileTree is a generic template to create a directory map for all subdirectories underneath the directory. However, because doxygen does not allow for the same named pages for linked projects via tagfiles, I can't generate a file called directory.html for every directory automatically. Is there a work around for this?
I am new to web programming but have experience working on perl scripts that have to do with file processing. Recently got a copy of MVC project source code. As I am trying to come to terms with template files, control & view modules, one question that came across is:
I see the template file in .tt extension(mypage.tt), there is the control module in .pm extension(MyPage.pm)) containing handler function to call the template and call to process subroutine in the View module(View.pm). But how does it generate .pl or html. I can't seem to find a perl executable or html file in the project. What should i enter in my url under
localhost/myapp/....
to call execute the script
I have loaded the project in my local directory with apache & mod_perl installed. Would be helpful if someone can explain if i need to write a perl script to call the handler function in the .pm file and generate the html if that's not too much to ask for :).
You project, if it is really a mod_perl app will have Apache configuration that maps URLs to handler methods.
Template files with a .tt extension typically are from the Template Toolkit, and perform their generation step by calling a method called process() on an instance of Template.
So you need to find the Apache handlers. They will tell you which methods are running, and then you can read hose methods to see how the template toolkit is being employed to generate the HTML.
I was wondering what is the best way to do a clean up of autonomy teamsite7. I basically have loads of dcr files that are not in use anymore and want to delete these. Whats the best way to search through the CMS and identify what .page and dcrs are published on the live site and what is not used and can be deleted so I dont have to go through manually?
Template-based pages use extended attributes to associate a generated page with a DCR and Presentation template.
In the past, I have written Perl scripts that would generate a list of the active DCRs. You can then compare the DCRs in the workarea to that list and delete those that aren't on the list.
Basically set it up as a cron job that cleaned up the "templatedata" directory once a month.
If I had this particular scenario, I think my first thought would be to run a simulated comparison deployment with OpenDeploy to generate the list of files that were in the workarea but not on the webserver. You could parse the resulting log with a perl script (or whatever your favorite language is) to then remove those files.
I've started using Zend framework, and Im following this simple Zend form tutorial. The form is located in application/forms directory I have included the Zend framework in the Path (by going to computer properties). However when i access form.php page, i get this error:
Fatal error: Class 'Zend_Form' not found
I have also tried by copying the Zend folder from the Zend framework in the library folder of the application, however error still remains same. Thanks.
It sounds like you are confusing two notions: the system path and the include path.
The system path is an operating system concept. When you ask the OS to execute a command, the system path is a list of places to look for the executable.
In contrast, the include path is a PHP concept that tells PHP a list of folders in which to look for files invoked by PHP include/require statements.
Any path that you find in "Computer > Properties" is almost certainly the OS-level system path. What you need to do is to make sure the Zend folder on the PHP include path, either by moving the Zend folder or by modifying PHP's include path to include a point to the Zend folder.
In a typical ZF app, the include folder is set in index.php (the front controller). So, the only explanation for not finding Zend_Form is that the autoloader is not being instantiated.
If you are using Zend_Application, this happens automatically. However, it seems like you are bypassing public/index.php and the whole Zend_Application instantiation by trying to directly "access" a file called form.php directly. If this file contains only the definition of your form (extending Zend_Form), then the absence of autoloading could easily explain the error message you are getting.
I'd try instantiating the form in a controller action, by which time in the request processing cycle, the autoloading is probably already in place.
[At that point, given the file locations you cite, we might run into a resource-loader issue, but that's a somewhat different issue that can be handled by instantiating a Zend_Application_Module_Autoloader in your Bootstrap.]
It looks like you do not use Zend_Loader. You should focus on it.
You can also manually in your custom form class include Zend_Form class.
I have some JavaScript files, a main HTML file, a main CSS file, and some CSS files that get imported into the main one.
I understand that I can put static files in two places: a) the 'war' folder; or b) the 'public' folder.
Where is the best place to put my static files? Are the two locations treated differently? Is there a 'best practice' on this issue?
The difference between the 2 locations is that files in the public folders are copied by the gwt compiler to the 'your module' folder in the 'war' folder. This is means if you deploy the 'war' (for example via the google plugin to the google appengine) the files from the 'public' folder are not at the toplevel.
For example, if you have an index.html in the 'public' folder with gwt module named 'mymodule' and you deploy it to www.example.com it looks as follows, you need to access it via:
www.example.com/mymodule/index.html
If you have the index.html in the 'war' folder, you get:
www.example.com/index.html
Summarizing. Your landing page should be in the 'war' folder. Resource files used by the landing page can also be stored here (css, images). Any other resource file that is referred to in any gwt module file (or code, like images) should be stored in the 'public' folder related to the gwt module.
The new way of working in GWT is to use the war folder.
But, if you project is a reusable widget library which is used in a GWT application then you should put the resources in the public folder. The compiler will make sure that the files are automatically included in the generated package.
As I see it, it depends on your requirements, but let's start at a speaking example first ...
I find the documentation (should be GWT 2.6.0) about this to be incorrect or at least incomplete/confusing. As I see it (I am not a guru so please correct me if my investigations are wrong!) I am looking at the following example proj structure
myproj/
src/my/gwtproj/
client/
img/
foo1.png
AppClientBundle.java
foo2.png
public/
img/
foo3.png
foo4.png
war/
img/foo5.png
foo6.png
.classpath
.project
Imagine we may (or may not) need to reference such resources in some AppClientBundle interface (or other application reference context):
interfaces AppClientBundle extends ClientBundle {
#Source("img/foo1.png")
ImageResource fooImg();
}
Then it seems to depend on your Requirements, e.g.:
R.a) these resources (like images) are refered to in the application code, e.g. in our AppClientBundle interface via #Source annotations
R.b) these resources are to be grouped by folders, e.g. foo2.png vs. img/foo1.png
R.c) these resources should be available outside some specific application URL context path, e.g. if used as widget library, e.g. http://host1/gwtapp1/foo4.png vs. http://host1/gwtapp2/foo4.png
R.d) these resources need to be application-independently (e.g. externally) URL-referenced, e.g. http://host1/gwtapp1/foo4.png vs. http://host1/foo6.png
Here's what one can do (Possibilities) and it's implications regarding R.* above:
P.1) (generally recommended as I see it) put nicely folder-structured resources under my.gwtproj.client (here e.g. foo1.png)
this way #Source("img/foo1.png")... works fine
in the docs above they speek about some public folder (in my case my.gwtproj.public), but creating it as a package in Eclipse does not me allow this (since public is a reserved Java key word, but creating it via the Navigator view works)
however, this way the #Source above does not work (likely because it's an issue with the relative AppClientBundle file system location)
nevertheless if the resource should be publicly available under the application context one may have to do it via this public folder
P.2) put "ungrouped" resources directly under myproj/war, e.g. projdir/war/foo6.png
this way it can be used/found within annotations, e.g. #Source
and it can be referenced outside the application itself via e.g. http://host1/foo6.png
P.3) put folder-structured resources under myproj/war, e.g. projdir/war/img/foo5.png
in contrast to P.2) #Source("img/foo5.png") would not work anymore