I am a little bit confused right now...in the CakePHP documentation, it states that PHP's visibility can be replaced as follows: private with __ and protected with _. But doing the necessary replacements, and calling a private method from within another class leads to the execution of that method without any restriction. What am I missing?
If you're setting them in the model, just use private and protected, the _ and __ only work for controller actions
the underscore is only effective for controller method, since the user can't access it. Inside Cake app, it's really just a convention. Besides I don't think it's a problem: You only need to lock your house from outside, you don't need to lock every doors if you are the only one in it. If you want to achieve that use private and protected PHP keywords.
Using _ and __ for protected resp. private methods is a CakePHP convention because CakePHP (up to v1.3.x) is still a PHP4 framework and PHP4 doesn't have the protected and private keywords. This means, that even if you prefix your method names in such a way, they are still public methods as far as PHP is concerned.
In your application I would follow the approach used by the coming CakePHP 2: use the naming convention together with the respective visibility keyword. For example, a private method would then be defined as private function __myPrivateMethod().
Related
In our React codebase I see private in front of almost every functions in all the components. This is a class component. eg:
private componentDidMount() {
this.props.onLoad(false)
}
private UNSAFE_componentWillReceiveProps(
nextProps: Partial<IAdminPortalDispatchCarrierProps>,
)
What's the idea here? When would these methods be used publicly?
private is a typescript modifier, that makes these functions only accessible from inside the class. By marking something as private, typescript will give you a compile time error if you attempt to use the private function from outside the class. This lets you communicate to the other developers (including future-you) which pieces of code are meant for public consumption, and which ones are internal implementation details.
For the specific functions you listed though, I suggest making them public, not private. React lifecycle hooks must be called from outside the class to do their job. Specifically, they get called by react's internal code. Fortunately, typescript gets removed when compiling, so react is able to call your private functions regardless. But the misleading modifiers may lull you into a false sense that these functions are not being called.
Using qooxdoo 5.0.2 (or previous version) I subclass a tablet widget and override _onKeyPress method.
Then, generating source I get a correct behavior, but with generate build the behavior is different.
I simplified my question, with this example below.
I subclass table widget and override _onKeyPress method WITH THE SAME CODE from qooxdoo 5.0.2 table widget source.
Run the example, edit a cell, and press enter.
Using
var tbl = new qx.ui.table.TableModified(tableModel)
the behavior is bad.
Using
var tbl = new qx.ui.table.Table(tableModel)
the behavior is correct.
If you put the example in a blank 5.0.2 project, using qx.ui.table.TableModified, you get a behavior if compile source, and another with compile build.
What is wrong with this? Where is my error?
Playground example
In qooxdoo there are, per convention, protected and private class members like methods or instance variables. Protected members start with an underscore like _myProtectedMethod, private members start with two underscores like __myPrivateMethod. The protected members are not affected by the build process and left as they are. This way they are override-able by derived classes.
Private members are obfuscated by the compiler to a random name, so that trying to access the private method or variable outside the class where they are defined leads to an exception.
In your playground example you've overridden the method _onKeyPress which per se is OK to be overridden as it is a protected member.
But within the overridden code you're using private members like this.__focusedRow which fails, because in the build version there is no more __focusedRow member as it got obfuscated. There are more private members in the code like __focusedCol, __selectionManager etc.
To successfully override the method, you have to replace those private members by their accessors, like this.getFocusedRow() instead of this.__focusedRow, this.getFocusedColum() instead of this._focusedCol etc.
I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here. I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.
Here's a piece from CustomApplicationClass:
public class CustomApplicationClass extends Application {
private static boolean something;
#Override
public void onCreate() {
[...]
}
public static boolean isSomething() {
return something;
}
public static void setSomething(boolean something) {
this.something = something;
}
}
Now, if i want to retrieve value of "something" variable somewhere in my code, say, from my application Activity, is there a difference between:
boolean var1 = ((CustomApplicationClass)getApplicationContext()).isSomething();
and
boolean var1 = CustomApplicationClass.isSomething();
? When running the application, both work fine. Is the second way safe to use, or is it inadvisable?
I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here.
Except that you're not doing that.
I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.
Of course. You could just as easily had CustomApplicationClass extend Object, then executed CustomApplicationClass.getSomething(). You are gaining nothing by your current approach versus just using an ordinary singleton pattern in Java, and you are losing flexibility, as an application can only have one custom subclass of Application.
Is the second way safe to use, or is it inadvisable?
The first way is pointless, since your data member and methods are static.
Either:
Make your stuff in CustomApplicationClass not be static, and then use getApplicationContext().
Refactor CustomApplicationClass to not extend Application, and then use the static data member and/or accessor methods, or switch more formally to the Java singleton pattern.
Personally, I would go with option #2.
If you check the api of android.app.Application (http://developer.android.com/reference/android/app/Application.html) then you will find on Class Overview as following:
Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created.
There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.
I have an admin controller that I would like to utilize functions in other controllers (these functions do not represent pages that someone would load in their browser), but it cannot utilize those functions because the functions in the other controllers are private. They are private because I don't want the public to access them. Is there a way to make a controller function not accesible to the public without making the function private or protected?
public function __blah(){
// function that can't be accessed from outside, but can be called from other functions
}
Based on what I've read in the comment of the answer Piotr gave you:
You don't use an admin controller. You want to use admin prefixes:
http://book.cakephp.org/view/950/Prefix-Routing
And authentication:
http://book.cakephp.org/view/1250/Authentication
If you call - and thats how your comment sounds like - one controller from another you're doing something totally wrong in an MVC framework. If it should be re-usable code it should go into components if it's about admin action use the prefix routing and admin_* methods, auth component and protected methods for what you call "helper" methods.
Yes.
You have a lot of information in the CakePHP Book about ACL (access control list) and that is exactly what you're looking for.
Or you may use Auth component.
I see three possible solutions (they can also be combined):
The first solution is to move the code you want to reuse to components (as mentioned by burzum).
The second solution depends on your code. It's possible that you do stuff in the controller which should be done in the model. In this case, move the respective code to the model.
The third solution is to put the code you want to reuse into plain old PHP classes and load them as vendor files.
Is there a way to create a private method in XBL?
--update
The only documentation on MDN says nothing about private methods, but it's a wiki that's not always complete..
The answer to your question is that XBL does not support private methods. However, this doesn't mean that you simply have to leave your public methods openly exposed and just accept this situation without a fight. there are some options that you have at your disposal that can help communicate that a method is private or help discourage using or modifying them:
Use an underscore in method names:
Mozilla recommends using an underscore to mark methods and fields as private. Additionally, many JavaScript libraries use underscores in the methods that the developers wish to mark as private. Although a novice developer could ignore this and still invoke the method, most people who have some basic experience with JavaScript libraries, Firefox Extension development, or JavaScript in general should know what you mean when you have a method preceded by an underscore.
Use inheritance to hide private methods:
Out of sight, out of mind.
In some languages, functionality that is common to a series of subclasses is oftentimes moved to a base abstract class. In the subclass, the inherited methods won't be seen in the subclass code.
Although this is definitely not "private", you could encapsulate your "private" methods in an XBL binding and place your public methods in an XBL binding that extends the parent binding. Inheritance is one of the most powerful features of XBL, and this could help protect your private methods from being used simply because they won't appear in the XBL binding the developer is directly interacting with.
You could then put extensive comments in the parent that describes the purpose of the "private" functionality and that it isn't meant to be public.
Keep in mind that even if you could mark a method as private, this still won't stop someone who is determined. One could still simply mark the method as "public" and use it anyway.
Here is documentation on XBL, which asserts that methods are private, and also discusses inheritance:
https://developer.mozilla.org/en/XUL_School/Custom_XUL_Elements_with_XBL