Orsburn (Static Content)

It's not immediately clear how to differentiate between public and private properties in CFML CFC s (ColdFusion Components, which in turn are classes).  Defining methods is more straightforward, in that they provide for public and private keywords to signal their scope.  It would stand to reason that these scoping keywords might also be applicable for properties as well.  After all, this is the approach taken with other languages such as Java and PHP . Alas, it is not the case.  And to compound matters, searching the Web doesn't really provide much clarification on the matter either.  Answers range from, it's just not possible, to initializing variables in the constructor to make them act like private properties. The examples provided here bear out that, CFML, at least running on Railo / Lucee , do in fact, support the scoping of properties.  It works like this.  Properties intitialized using the this.variableName form are public.  Simply initializing a variable with

Preface To begin with, the operation described here is something that falls outside of the way Eclipse is meant to be worked with.  Eclipse has a concept of "Workspaces" to allow the IDE to be completely reconfigured for the type of development that is being done. This is a great idea in theory, but in practice it can be quite cumbersome and off-putting.  Off-putting simply because changing a Workspace means that everything needs to be reconfigured again.  Font colors, view locations, and who knows what else. It's true that creating a new Workspace allows the Workbench Layout and Working Sets to be copied.  And the settings can be exported from one Workspace to the next.  Still, once all of this is done, if changes are made in one, they would have to be applied to any of the other Workspaces that have been create as well, if one wants to maintain a consistent environment across all projects.  Plus, it doesn't really work anyway.  All Views still need to be repl

Use the git config command to point Git to a custom location for storing the listing of files to ignore in repositories. git config --global core.excludesfile ~/.gitignore Additionally, the setting can be added by editing the config file directly.  The config file is at the root of the user's home directory and is named ".gitconfig." Most articles around the Web instructing users how to ignore specific types of files across repositories, describe creating a file named ".gitignore."  Almost without fail, the instructions suggest putting the .gitignore file at the root of the user's home direcory. ~/.gitignore The expectation is that this is a location that Git looks at by default to pick up any files that it should ignore.  It does not.  Rather, the default locations that Git looks to are: $XDG_CONFIG_HOME/git/ignore $HOME/.config/git/ignore If the first place is not found, then the second place is checked.  Git will not look at ~/.giti

Issue Attempts to create or import a project consistently fail stating that a project with the specific name already exists.  However, the project does not appear in the explorer or navigator views. Cause The issue is because Eclipse is set to list only a certain set of projects (Working Set). Solution The steps to resolve this issue will depend on the "file" view in use.  This means things like an explorer ( PHP Explorer for instance) or the Navigator.  There is a downward pointing triangle, most likely along the top right of the view. View Menu | Select Working Set… Choose a combination of options The selection in the second step should probably be Window Working Set or No Working Set . Environment Version Eclipse 4.4 Luna (any version that supports working sets) OS Any Browser Not applicable Details There is no clear indication or any sort of visual cue to make it readily known that the projects in a listing are for a specific

Issue GitEye version 1.9.x may fail with a time out error during its update procedure. The error reported may resemble the example below. An error occurred while collecting items to be installed session context was:(profile=DefaultProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). Unable to read repository at http://downloads.open.collab.net/git/giteye/release/plugins/org.eclipse.core.databinding_1.4.2.v20140729-1044.jar. Read timed out Unable to read repository at http://downloads.open.collab.net/git/giteye/release/plugins/org.eclipse.core.filesystem_1.4.100.v20140514-1614.jar. Read timed out Cause The reason why this happens isn't easily identified.  The indication of a timeout issue though leads suspicion towards things like a slow data connection or too many packages to update for the allotted time the package manager has specified. Solution Repeated attempts to update the software may eventually resolve the issue.