.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/bundler/gems/pakyow-9d4d9be98b47/pakyow-presenter/lib/presenter/view_store.rb:105:in `template_with_name': No template named 'default' (Pakyow::Presenter::MissingTemplate)
Pakyow is looking for a template named default.html (in the app/views/_templates path unless you've changed your template path config option). If you're running on HEAD, this is likely being caused by a change to the default template name. In the last release, it was pakyow; now it's named default.
Related
I've placed my customised template in : advanced_search.post.tpl file in \cscart\design\backend\templates\addons\codes_searching\hooks\common\advanced_search.
: {include file="buttons/button.tpl" but_text=__("search_products") but_onclick=$but_onclick but_href=$but_href but_role="submit-button" but_name=$but_name}
It doesn't work, please help me!
If there is no placed hook on default advanced_search.tpl file, it doesn't work to creating advanced_search.post.tpl hook file.
Your have only one way that override template.Because there is no hook to hooking.
You must create
backend\templates\addons\codes_searching\overrides\common\advanced_search.tpl
file.
Then copy default advanced_search.tpl file content to overriding content, and do your changes.
How can I change the .eclipse folder in Linux? I tried adding this line:
-Dosgi.configuration.area=/directory/directory1/eclipse/.eclipse
at the top of eclipse.ini but it doesn't work. I've also tried adding it to various other places in the eclipse.ini but still no luck.
Edit
I have added this line:
-Dosgi.configuration.area=file:/directory/directory1/eclipse/.eclipse
immediately below -vmargs. When Eclipse starts, it now reads from the correct .eclipse location and if .eclipse does not exist there, it creates it. Unfortunately, after Eclipse has loaded, another .eclipse folder is created in my home folder and Eclipse then continues to read from that folder. I suspect that my eclipse.ini file is now correct but there is another file I need to change.
The simplest thing to do is probably pass java a different user.home so that all the other myriad of places that derive a location base it off of user.home. So instead of what you have, use this in .ini file:
-Duser.home=/directory/other/here
In addition to .eclipse, you will probably find other directories created in your overridden user.home, such as .p2, .oracle_jre_usage, etc.
Other notes:
-Dosgi.configuration.area is the changes the configuration area for Eclipse, it does not effect user area. You also probably don't want to change that setting away from the default unless you really want multiple configurations (read more below).
Additionally, the normal thing to do would be to use -configuration as an argument to eclipse{.exe} and let eclipse convert it to the appropriate VM argument.
You probably want -user though to override the user area. Have a look at locations in the Eclipse help for more info (quoted below).
However, there are still things that have individual control over their location, such as secure storage, which is controlled by the -eclipse.keyring command line argument.
Locations
The Eclipse runtime defines a number of locations which give
plug-in developers context for reading/storing data and Eclipse users
a control over the scope of data sharing and visibility. Eclipse
defines the following notions of location:
User (-user) {osgi.user.area} [#none, #noDefault, #user.home,
#user.dir, filepath, url]
User locations are specific to, go figure,
users. Typically the user location is based on the value of the Java
user.home system property but this can be overridden. Information such
as user scoped preferences and login information may be found in the
user location.
Install (-install) {osgi.install.area} [#user.home,
#user.dir, filepath, url]
An install location is where Eclipse itself
is installed. In practice this location is the directory (typically
"eclipse") which is the parent of the eclipse.exe being run or the
plugins directory containing the org.eclipse.equinox.launcher bundle.
This location should be considered read-only to normal users as an
install may be shared by many users. It is possible to set the install
location and decouple eclipse.exe from the rest of Eclipse.
Configuration (-configuration) {osgi.configuration.area} [#none,
#noDefault, #user.home, #user.dir, filepath, url]
Configuration
locations contain files which identify and manage the (sub)set of an
install to run. As such, there may be many configurations per install.
Installs may come with a default configuration area but typical
startup scenarios involve the runtime attempting to find a more
writable configuration location.
Instance (-data) {osgi.instance.area}
[#none, #noDefault, #user.home, #user.dir, filepath, url]
Instance
locations contain user-defined data artifacts. For example, the
Resources plug-in uses the instance area as the workspace location and
thus the default home for projects. Other plugins are free to write
whatever files they like in this location.
While users can set any of
these locations, Eclipse will compute reasonable defaults if values
are not given. The most common usecase for setting location is the
instance area or, in the IDE context, the workspace. To run the
default Eclipse configuration on a specific data set you can specify:
eclipse -data c:\mydata
You must put property definitions like this at the end of the eclipse.ini after the -vmargs line. If there is no -vmargs line you must add one.
So:
.... other lines ....
-vmargs
... other arguments
-Dosgi.configuration.area=/directory/directory1/eclipse.eclipse
I am attempting to learn puppet, and so far so good.
What I am having an issue with is using a variable that I have set for a node or group in the web console.
I created a variable called myCustomSetting, and then in a manifest:
file {/var/tmp/myfile.txt
ensure => file,
content => $::myCustomSetting,
}
When I apply the manifest with puppet apply mytest.pp, there are no errors, but the file is empty? What am I missing?
The double semi colon indicate that you wish to reach the top level scope, where you supposedly declared your variable. Check that your variable has not been declared in a local scope.
I know puppet modules always have a files directory and I know where it's supposed to be and I have used the source => syntax effectively from my own, handwritten modules but now I need to learn how to deploy files using Hiera.
I'm starting with the saz-sudo module and I've read the docs but I can't see anything about where to put the sudoers file; the one I want to distribute.
I'm not sure whether I need to set up a site-wide files dir in /etc/puppetlabs/puppet and then make subdirs in there for every module or what. And does Hiera know to look in /etc/puppetlabs/puppet/files/sudo if I say, source => "puppet:///files/etc/sudoers" ? Do I need to add a pathname in /etc/hiera.yaml? Add a line - files ?
Thanks for any clues.
My cursory view of the puppet module, given their example of using hiera:
sudo::configs:
'web':
'source' : 'puppet:///files/etc/sudoers.d/web'
'admins':
'content' : "%admins ALL=(ALL) NOPASSWD: ALL"
'priority' : 10
'joe':
'priority' : 60
'source' : 'puppet:///files/etc/sudoers.d/users/joe'
Suggest it assumes you have a "files" puppet module. So under you puppet modules section:
mkdir -p files/files/etc/sudoers.d/
Drop your files in there.
Explanation:
The url 'puppet:///files/etc/sudoers.d/users/joe' is broken down thus:
puppet: protocol
///: Three slashes indicate the source of the file is in a module.
files: name of the module
etc/sudoers.d/users/joe: full path to the file within the module's "files" directory.
You don't.
The idea of a module (Hiera backed or not) is to lift the need to manage the whole sudoers file from you. Instead, you can manage each single entry in the sudoers file.
I recommend reviewing the documentation carefully. You should definitely not have a file { "/etc/sudoers": } resource in your manifest.
Hiera doesn't have to do anything with Files.
Hiera is like a Variables Database, and servers you based on the hierarchy you have.
the files inside puppet, are usually accessed in methods like source => but also these files are using some basic structure.
In most cases when you call an file or template.
A template can serve your needs to automatically build an sudoers based on that.
There are also modules that supports modifying sudoers too.
It is up to you what to do.
In this case, saz stores the location of the file in hiera, but the real location can be a file inside your puppet (like a module file or something similar).
Which is completely unrelated.
Read about puppet file server
If you have questions, just ask.
V
We have a build script which build three types of projects - C++, Java and finally the respective InstallShield installers.
Right now the installer build script relies on the fact that the C++ projects are always built in the Release configuration.
But now I wish to allow building them in an additional configuration, namely Profile.
We are using the Jenkins CI server and thus the desired configuration is provided through a dedicated Jenkins build parameter DRIVER_PROXY_CONFIG, which is surfaced as an environment variable with the same name.
Now the problem. According to our InstallShield guy, IS cannot use an environment variable in part of a source file path. I quote:
You can use or 'environment variable' or 'user-defined path variables
defined through InstallShield' as file path.
So we can:
Create 'environment variable' for each component (since 'DRIVER_PROXY_CONFIG' is only part of the component path) – not desirable.
Make the 'environment variable' part of the component 'user-defined path variable' – not possible, I have just tried it.
Has anyone done anything like this? The installer depends on multiple source files in different locations, where a part of such a location path is the value of the DRIVER_PROXY_CONFIG environment variable. Note that this part is neither the path prefix nor the suffix.
You absolutely can create it as part of a path. Some exact behaviors do depend on the version of InstallShield, but for the last several you can even use relative parent directories. Just go to the Path Variables view, add a new environment path variable (say Env), and set the environment variable it references. Then either add any number of standard path variables (say Stn) that are defined as <Env>\Sub\Dir, or skip this step and just reference those for the ISBuildSourcePath of the relevant files. Typically adding a file from a path under a defined path variable will use that path variable as part of its path.
If you've already added the files, the convert source paths wizard may help here, but you might find it easier to visit the File table directly to update the ISBuildSourcePath
However there is at least one exception. If your environment variable has the value Sub and your full directory name is SubDirectory, you cannot always reference <Env>Directory. Typically the path variable support will turn that into Sub\Directory instead.
Michael:
What if 'env' is not prefix nor suffix of the path ("SomeDir\<env>\SubDir")?
I have created system env config=release
I have created IS variable 'MyConf' that reference the env 'config'
I have created IS standard path MyPath = "SomeDir\<MyConf>\SubDir"
If I add file from this path - IS won't suggest 'MyPath' as suggested path!!!
The only way I have found, is to add the files, and then visit the File table directly to update the ISBuildSourcePath.
I added the environment variable as a path variable, ytou can set environment variable types here (not string types!)
then you can use that anywhere you'd use a path variable - though I did have to enclose it in square brackets rather than the usual angle ones). It should work in the middle of a path as I have done that with ordinary path variables.