I try to set the following Route with Kohana 3.2:
api/<version>(/<controller>(/<action>(/<id>)))(.<format>)
and want to put the controller in an directory inside the controller folder with the name of the <version> param. But how can I name the Class so that Kohana find my Controller?
e.g. :
I open the url api/1.0/hello/say and want to load the controller inside the folder classes/controller/1.0/hello.php but as the convention says I need to name the controller like Controller_1.0_Hello... But as far as I know, php doesn't allow numbers and points on classnames..
How can I solve this?
You can map the route explicitly to any controller/method you want. I wrote a tutorial that might help you out: http://www.kineticklink.com/kohana-3-routing/
Basically, you can't have a period in a className, but you can have a number.
Routes are used to determine the controller and action for a requested URI.
directory is a folder;
controller is a file indirectory` folder;
action is method of controller class (defined in file).
If you want to select specific file based on Route, your only way is to use <controller> instead of <version> like:
api/<controller>(/<version>(/<action>(/<id>)))(.<format>);
You'll probably have to modify your URI format.
Related
I have Django model with Image field, but sometimes I don't need to actually upload file and store path to it, but I need to store only path. Especially url. I mean, I have web client, that receives both foreign urls like sun1-17.userapi.com and url of my own server, so sometimes I don't need to download but need to store url. Is it possible, to store url in ImageField, or I need to make CharField and save files via python? If its impossible, how do I save file in python3, having one, sent me via multipart?
The URL field in the ImageField is ReadOnly, so you cannot write it. You should probably use in addition a URLField (better than a CharField) to save the URLs.
You can allow null values on both and use only the appropriate one according to your scenario.
class FilePathField(path='', match=None, recursive=False, > allow_files=True, allow_folders=False, max_length=100, **options)
A CharField whose choices are limited to the filenames in a certain directory on the filesystem.
Has some special arguments, of which the first is required:
FilePathField.path
Required. The absolute filesystem path to a directory from which this FilePathField should get its choices. Example: "/home/images".
For more info visit the doc https://docs.djangoproject.com/en/3.0/ref/models/fields/#django.db.models.FilePathField
Is there an input directory for JSF, or library like Omnifaces or Primefaces? I don't need <h:inputFile> as the file actually no need to be uploaded, I would like to provide a field for user to input the path of a file for example:
C:\Folder One\myFile.txt
and ManagedBean will interpret the path, for example, read the content of the file. I don't want user to enter the file path manually in input text. And I don't have the client/server issue as the user will select the file on the machine which my JSF application is deployed.
If such component is not available, is there any workaround? like maybe I can provide a <h:inputFile> and get path from it?
Is there any solution to configure template engine use some alternative paths, as described below?
i.e.
templates/{file}.jade
../template2/{file}.jade
../../template/{file}.jade
at first resolves 1st path, if file doesnot exist, runs for 2nd and so on..
i'm using express and jade.
As far as I know, no. Jade uses the usual directory path structure not arbitrary file mapping, to map file to paths.
This is the natural and correct way. The directory structure would work for you too. If you want to implement a fallback, do it in node.js (for different files) or with express (for different requests). To be more precise do it in code, don't use include headers/lookup strategy to accomplish that.
Kohana 3.2 was designed to support the HMVC design pattern. The HMVC pattern consists of nested MVC-triads. Yet as far as I can tell, Kohana's cascading file system requires all Models and Controllers to be placed within a top 'classes' directory, and Views into a top 'views' directory. If Model/Controllers are thus separated from Views at the top level of the file system, then how are we supposed to implement nested MVC-triads?
Not sure if you'd want to hack the way that views are processed, but you can extend the Kohana_View class so that set_filename() function will accept any directory that you want.
If you want an auto-loading feature similar to controllers / models, you could implement it yourself.
For example (untested):
public function set_filename($view)
{
// Transform the class name into a path
$file = str_replace('_', '/', strtolower($view));
if ($path = Kohana::find_file('classes', $file))
{
// Store the file path locally
$this->_file = $path;
return $this;
}
throw new View_Exception('The requested view :view could not be found', array(
':view' => $view,
));
}
Yet as far as I can tell, Kohana's cascading file system requires all Models and Controllers to be placed within a top 'classes' directory, and Views into a top 'views' directory.
What you seem to want is a folder structure like Kohana 2, codeigniter and most likely other frameworks, which have dedicated folders for controllers, models, and views. Kohana 3 has a dedicated folder for classes. The way Kohana 3 is built enforces that controllers should have a Controller_ prefix. The Kohana 3 autoloader will look for classes with a Controller_ prefix in the classes/controller folder.
Then Kohana 3 also comes with very basic Model and View classes. The Kohana 3 core does not use the Model class as far as I am aware and it uses the View class only on a few occasions. But the convention to give models the Model_ prefix can be found in Model::factory(), it is not enforced however. You do not have to use them.
The View class looks for templates in de views folder. The (not recommended by Zombor) View_Module by Zombor (one of the devs) also happends to look there. The (redommended by Zombor) KOstache module, again by Zombor, looks for its templates in the templates folder. Both modules let you create View-Model classes for which the convention is to have the View_ prefix so they end up in classes/view. But nothing stops you from creating a View_ class which extends View for every template you put into the views folder and hardcode the path for that View-Model.
Please respect that the classes folder is only for classes.
So I'm new to XUL.
As a language it seems easy enough and I'm already pretty handy at javascript, but the thing I can't wrap my mind around is the way you access resources from manifest files or from xul files. So I did the 'Getting started with XULRunner' tutorial... https://developer.mozilla.org/en/getting_started_with_xulrunner
and I'm more confused than ever... so I'm hoping someone can set me straight.
Here is why... (you may want to open the tutorial for this).
The manifest file, the prefs.js and the xul file all refer to a package called 'myapp', that if everything I've read thus far on MDN can be trusted means that inside the chrome directory there must be either a jar file or directory called myapp, but there is neither. The root directory of the whole app is called myapp, but I called mine something completely different and it still worked.
When I placed the content folder, inside another folder called 'foo', and changed all references to 'myapp' to 'foo', thus I thought creating a 'foo' package, a popup informed me that it couldn't find 'chrome://foo/content/main.xul', though that's exactly where it was.
Also in the xul file it links to a stylesheet inside 'chrome://global/skin/' which doesn't exist. Yet something is overriding any inline styling I try to do to the button. And when I create a css file and point the url to it, the program doesn't even run.
Can someone please explain what strange magic is going on here... I'm very confused.
When you register a content folder in a chrome.manifest you must use the following format:
content packagename uri/to/files/ [flags]
The uri/to/files/ may be absolute or relative to the location of the manifest. That is, it doesn't matter what the name of the containing folder is relative to your package name; the point is to tell chrome how to resolve URIs of the following form:
chrome://packagename/content/...
The packagename simply creates a mapping to the location of the files on disk (wherever that may be).
The chrome protocol defines a logical package structure, it simply maps one URL to another. The structure on disk might be entirely different and the files might not even be located on disk. When the protocol handler encounters an address like chrome://foo/content/main.xul it checks: "Do we have a manifest entry somewhere that defines the content mapping for package foo?" And if it then finds content foobar file:///something/ - it doesn't care whether that URL refers to a file, it simply resolves main.xul relatively to file:///something/ which results in file:///something/main.xul. So file:///something/browser.xul will be the URL from which the data will be read in the end - but you could also map a chrome package to another chrome URL, a jar URL or something else (theoretically you could even use http but that is forbidden for security reasons).
If you look into the Firefox/XULRunner directory you will see another chrome.manifest there (in Firefox 4/5 it is located inside omni.jar file). That's where the mappings for global package are defined for example.