I just started using the Netbeans 7.1 beta and it is calling out errors of a type which I have never seen before. Specifically:
A managed bean with a public field should not declare any scope other than #Dependent.
The fields it is complaining about are public static final. I can understand the restriction on non-static fields, but I can't think of a good reason this would not be allowed for a static field. Unfortunately I use a lot of them since I don't like having constants in my code.
I note that even though I get the red dot in the margin in the editor, the maven-driven build still works and GlassFish still runs my application the way I would expect.
So what is my denoument on this issue? Am I going to have to move my static fields elsewhere or is there another way of handling this?
Quoting the javax.enterprise.inject package javadocs:
If a managed bean has a public field, it must have scope #Dependent.
But I do agree wih #BalusC that if this compiles, Netbeans should report it as Warning (does it?).
Anyway, are those constants really part of the API? I mean, do you access they anywhere else but within their own classes? If not, reduce visibility to private. (If you just need to access the constants from the view you can also create accessors for the private constant). If yes, I would suggest you to move them somewhere else anyway.
Public fields (static or not) aren't proxyable - that's why they can only be dependent scoped. To work around this you obviously can access them through getter methods.
Related
I am coding in Unity 2D and am making some scripts to build my mobile game (i am adding a score counter) and everytime i solve a problem another one occurs after. i was able to solve all those
previous problems until now. I have uploaded some screenshots to help:
This is whats happening in Unity:
This is whats happening in VSCode:
This is also happening in VSCode:
ScoreCounter cannot be private so change it to public or internal. This is explained in the documentation for Compiler Error CS1527:
Type declarations in a namespace can have either public or internal
access. If no accessibility is specified, internal is the default.
...when no namespace is explicitly declared in your program code, all
type declarations are located implicitly within the global namespace.
Also, declaring MonoBehaviour as an interface is likely to cause you problems. The UnityEngine namespace already defines MonoBehaviour as a class.
I had convenience methods littered all over the place. I have now pushed these in to a couple of helper classes and I made the helper classes protected members of my layer supertypes.
Everything was going along swimmingly until I came to Zend View. I have extended Zend View to make my layer supertype but when I try to attach a protected member it throws a:
Zend View Exception: Setting private or protected class members is not
allowed.
Firstly, why would such members not be allowed? Any ideas? Secondly, have you circumvented it in the past? And how did that go? (It seems that the framework detects protected members by the presence of a leading underscore. This seems a bit hit-and-miss, and also easy to get around).
Note - I'm not saying that I would circumvent it. I'm just trying to find out what others have done in the past (since it seems an odd constraint).
It's an important point for me since I am using traits to bring the helpers and associated proxy methods into each superclass. I don't want to maintain a separate trait just for the View. Alternatively, I don't want to make the helpers public members of each superclass.
Thank you!
Data encapsulation.
Underscore properties are not allowed primarily so that the developer can't accidentally overwrite View properties that are part of the framework.
This essentially protects all of the framework's View properties and allows you, the developer, free rain over any public properties you wish to set.
The authors of Zend View can then be sure of two things: (1) they control (and author) the private and protected class properties and (2) you control the public properties. This makes for logical data encapsulation and maintainable class overloading.
OK so I understand that ion VB6, encapsulated properties in a class can belong to one of three categories:
Public Property
Friend
Public Variable
What is the difference between these and how do these compare to public and private properties in a more modern language like C#?
The scope qualifiers Public and Friend determine whether clients in different projects can see the item.
Public items will be accessible to client code in other projects1 and code in the same project.
Friend items are accessible only to code in the same project, not to code in other projects.
Private items are accessible only to code in the same class.
Properties are different from public variables, because with properties you can execute your own code when the client gets or sets the value2. EDIT following Deanna's comment: Also note that variables can be passed ByRef to a function and changes will work as expected. This is NOT the case for properties.
NB C# may be more modern, but IMHO the VB6 treatment of properties and public variables is significantly better than the .Net treatment.
In VB6 you can change a public variable into a property without breaking the clients. You don't even have to recompile them. Not true in .Net.
In VB6 public variables can be used with data binding. Not true in .Net.
In VB6 public variables could be used with interfaces. Not true in .Net.
IMHO Microsoft made a real design mistake in creating these differences between properties and public fields in .Net. Not convinced? After the first releases of .Net, the C# and VB compilers were modified to support automatically implemented properties. These allow you to create properties in just one line of code, so that it's later possible to add logic on get/set without causing problems. IMHO this proves that public variables should have been made indistinguishable from properties.
1 Assuming your project type actually allows your classes to be used by other projects (i.e. ActiveX DLL, OCX, or ActiveX exe).
2 In the Property Get, Property Let and Property Set procedures.
Public means that it is accessible by any other classes that
references your project/dll.
Friend means that it is accessible by
any other classes within your assembly (so only the exe you made the
class in)
variable and property are almost the same. Property is preferred since you can set if other classes can set or get the variable (Property encapsulates the variable)
In C# it is the same, only you use Internal instead of Friend
private property are those property that are used by ourselves and other family member. But, public property are those property which are used by all the people of our community, society or the country.
If I create a "Plugin Project" in Eclipse, it creates a default BundleActivator implementation that just sets the BundleContext in an unsynchronized static field.
Since it also creates a public static getter, this doesn't look Thread-safe, because even if OSGi performs some synchronization when calling the Activator, how do I know that any of my code which would call the getter would also run inside the same synchronization block?
In a "normal" context, both the getters and setters need to be synchronized, or we must use a volatile, to be sure that whatever Thread calls the getter later actually sees the current state of the static field.
If the field was set only once, it would not be a problem, but I understand that bundles can be started and stopped several times during the lifetime of the JVM, and under those conditions, it would be thinkable that a Thread has already a cached version of the field, and would not see a change, due to the lack of synchronization.
I can't imagine that Eclipse would generate plain wrong code by default, but I can't see how this would work either.
I agree that the generated code is incorrect and it doesn't surprise me at all that Eclipse PDE would generated incorrect code. There is no need for this static field, and in fact in most cases the activator itself is useless.
I have 2 databases that my site uses including a central user database that relates to other site-specific databases.
Sometimes it is adequate to call new User(array('db'=>'adapter1')); (but never convenient); other times, though, such as when declaring relationships between tables on different databases, there is no way to do this.
Does anyone know a way to specify which database adapter to use from within the Zend_Db_Table_Abstract class?
Thanks!
Getting back to this pretty late, but none of the answers here quite did it for me. A select few of my database models needed to use 'tdb' and the following code was added to each of those classes to have that happen automatically:
protected function _setupDatabaseAdapter()
{
$this->_db = Zend_Registry::get('tdb');
parent::_setupDatabaseAdapter();
}
I thank you all for your suggestions along the way!
Zend_Db_Table_Abstract provides a static method to set the default database adapter. Do this as follows:
Zend_Db_Table_Abstract::setDefaultAdapter($adapter);
Now, all your Table objects will use your adapter by default.
Note: the online docs sometimes don't make this obvious, so your second best place to check is in the API here: http://framework.zend.com/apidoc/core/
You could set the class variable $_db to the correct adapter in the constructor.
global $adapter1; //There are better ways than using a global variable
$this->_db = $adapter1;
Assuming the adapter object can be referenced in the constructor. That doesn't seem to portable, but I believe it would work.
The init function can be used, it is not used in Zend_Db_Adapter_Abstract, can be used in your class to setup whatever needs to be done. _setAdapter accepts a string naming a Registry Key.
public function init()
{
$this->_setAdapter('tdb');
}