As I understand, when using automated properties, one must write both set and get methods.
However, when I look at Microsoft's System.Exception, there are some properties that clearly does not follow this demand, for instance: http://msdn.microsoft.com/en-us/library/system.exception.innerexception.aspx.
Can someone please explain me how can this be?
When using an automatic property, one never writes set and get methods. The compiler provides both for you.
If you see a property without a set, or without a get, it was defined the long way, and not an automatic property.
The fact that the backing property is a legal C# name, and not a compiler-reserved name, is another clue that you're looking at a manual property. So is the fact that this property has been around since long before automatic properties were implemented.
Sorry?
What about "no public set"?
Can be.... protected or private and thus be filtered in the documentation.
Related
i am using jaxb to generate code from an xsd.
The generated code contains a lot of annotations; for classes and fields.
I am trying to use com.sun.tools.internal.xjc.Plugin to modify the generated code.
In the plugin run() method we are given an Outline class from which we can get ClassOutline. ClassOutline has an JDefinedClass final member which has the info about actual class which will be generated.
If i want to add anything, there are apis in JDefinedClass which can be used. But if i want to remove something, there is no way.
e.g. i cannot clear annotations, because the JDefinedClass.annotations() method returns an UnmodifiableCollection. so i cannot clear it or remove anything from it.
i tried to create another JDefinedClass by invoking the _class method but the ClassOutline.implClass variable is final, so i cannot set it.
how to get a JDefinedClass which does not have any annotations?
is there another phase of code generation which i can trap into to really control the generation of JDefinedClass?
The code model is, indeed mostly "write only". But, speaking of annotations, you have probably missed the methods like com.sun.codemodel.JDefinedClass.removeAnnotation(JAnnotationUse) and com.sun.codemodel.JMethod.removeAnnotation(JAnnotationUse) (implemented from com.sun.codemodel.JAnnotatable.removeAnnotation(JAnnotationUse)).
So they're there. You can remove annotations with the normal CodeModel API.
As I can see, you can also remove fields and methods from classes. So what exactly are you missing?
JDefinedClass.annotations() It return an unmodifiable collection object and you cannot modify them.
So work around for this, you can restrict annotation addition/deletion at class and field level before building JCodeModel.
You need to create a custom Jackson2Annotator class which extends Jackson2Annotator and override their methods according to your requirement.
Following are few methods which are being used for specific type of annotation property:
propertyOrder(OTB JsonPropertyOrder)
propertyInclusion(OTB JsonInclude)
propertyField(can be used for custom defined annotation at field level)
More you can discover by looking Jackson2Annotator class what fit into your need.
I am using the IBM Social Business Toolkit. I have defined a connection for my Notes app via endpoints in the faces-config xml file. I wonder how I can access this file pro grammatically since I could not find a service that returns me the base url of IBM Connections.
It's useful to remember that an endpoint definition is really just creating a managed bean. The managed bean has a variable name you refer to it - the managed-bean-name property. You can access this directly from SSJS or via ExtLibUtil.resolveVariable() in Java. The definition also tells you the Java class that's being used, e.g. com.ibm.sbt.services.endpoints.ConnectionsBasicEndpoint. That really gives you all the information you need to get or set the properties.
So from SSJS you can just cast it to the class name, e.g.
var myService:com.ibm.sbt.services.endpoints.ConnectionsBasicEndpoint = connections
So the bit after the colon will be the managed-bean-class value and the bit after the equals sign will be the managed-bean-name. In Java, you can use
ConnectionsBasicEndpoint myService = (ConnectionsBasicEndpoint) ExtLibUtil.resolveVariable(ExtLibUtil.getXspContext().getFacesContext(), "connections");
You'll then have access to all the methods of the class, so you should be able to retrieve what you need.
The properties are part of the Java class, who are referred to in the Faces-Config.xml. So get the class by his fully qualified name or by bean name and set or get the properties
I think the best route will most likely be what Paul is suggesting: resolve the variable by its name and use the getters to get the effective properties that way.
Sven's suggestion is a good one to keep in mind for other situations. By accessing the faces-config.xml file as a resource, you could load it into an XML parser and find the values using XPath. I'm doing much that sort of technique in the next version of the OpenNTF Domino API, which will have a set of methods for manipulating the Faces config. However, one key aspect there is that reading the XML file directly will just get you the string values, which may be EL expressions, whereas going the resolveVariable route will get you the real current properties.
I would like a bit of clarification about why each class (or nearly each class) in VBA (when you scroll through Object Browser) has an Application property.
MSDN says
When used without an object qualifier, this property returns an
Application object that represents the Microsoft Excel application.
When used with an object qualifier, this property returns an
Application object that represents the creator of the specified object
(you can use this property with an OLE Automation object to return the
application of that object). Read-only.
The first sentence is pretty clear. Your hosting application used without a qualifier can be one of the MS Office products supporting VBA.
In Excel Debug.Print Application = Microsoft Excel
In Word Debug.Print Application = Microsoft Word
etc...
but...the second sentence is totally unclear to me... So I am thinking like no matter where you call .Application from it will always return the host of an object...
So, what is the point of each class in VBA to have an Application property?
PS. you can always call .Parent => .Parent to go up the hierarchy... can't you? You can just call the Application wit no qualifier to get that...
I can't even think of one SSCCE OLE scenario for this so I am sorry I am not providing an example. The Application property (not to be confused with Application class) is poorly documented this is why I am asking for someone with more experience to clarify this for me.
One (well, sort of) scenario, but not sure it even applies here could be using Interop for Office. Like, when you have an external application that opens two files ( one Excel, and one Word ) then by getting references to Ranges in both, you may be able to return Microsoft Excel and Microsoft Word.. but would this be even useful to anyone? hmm..Am I not understanding this entire concept?
There are two levels to this. First, the reason every class has an Application property is because somebody thought it would be a good idea and they made a base class from which every other class inherits. Kind of like the decision to have a Value property or an Item property consistently applied through classes.
The real question is why somebody thought it was a good idea. I don't know, but it was probably Spolsky's idea, so he should answer. I can tell you how I use it.
If I'm automating Outlook from Excel, I'll generally create an olApp variable to hold the Outlook Application. But I don't have to. I could just create, say, a MailItem and reference Application via that. Where I do use the Application property is debugging. I have a MailItem object instantiated and I'm getting an error. I could, for instance, see how many items are in the inbox even though I don't have an application object variable in scope. In the immediate window:
?olMailItem.Application.GetDefaultFolder(1).Items.Count
I could string a bunch of .Parent calls together, but I don't necessarily know how many I would need. Here's where the second part of the MSDN description comes into play. If I use Application with not qualifier (I'm in Excel), it defaults to Excel.Application. But the Application property of olMailItem returns Outlook.Application because that's what's at the top of the object hierarchy that includes the MailItem class.
I think it's just a handy shortcut that somebody thought was so handy they coded it into the base class for all objects.
Hopefully there's a solution/patch to SubSonic SimpleRepository where I can specify a column/property with a default value so that it populates the DB with the default value set.
I'm still reading the SubSonic Docs and just ran across that issue. Maybe someone has an answer/solution for this that I can start using.
If you want a default value then set it on your object - an attribute shouldn't be used to set values.
Looks like you nailed it... In your class, simply set the default value in the constructor...
You could also set the value as a default in the appropriate DB column.
To my knowledge this feature doesn't currently exist in SimpleRepository and in my opinion it doesn't belong there. I like the SimpleRepository because it's so simple. You don't need to know about or understand a ton of configuration options or attributes; you just plug in your POCO objects and go. There are a handful of attributes that you can use to influence the underlying database table schemas, but I think that a good job was done with respect to keeping those attributes to the absolute bare minimum needed.
If you need to set 'default' values for some reason I think that's something that should be done within your "domain" related code. Setting them in the constructor of the object might make sense, or using a wrapper repository object that could set them prior to passing along to the SimpleRepository could also work. I've always kind of thought that having default value constraints defined in the database was a bit of a smell anyway; it won't always be immediately evident where that value came from or why it was chosen.
Such as:
Sealed Methods you might have liked to extend
Exceptions thrown are more vague than is helpful
Elimination of Connected Content which was a major feature in MCMS 2002
HTML is stripped from fields when stored and returned. No easy option to work around this problem
Creating an SPWeb takes an eternity.
Nonexistant migration path from MCMC 2002
I wish that the Sharepoint object model was purely managed code. Although having .NET wrappers is convenient, having to worry about disposing the many objects that implement IDisposable is a pain. It's so easy to run into memory issues when dispose does not get called in a WSS app. And I thought the reason for moving to .NET was to free developers from having to deal with memory management...
How about refactoring Properties that result in additional database calls to methods instead, for example the Items property on SPList.
Any of the SPList API could use a complete rewrite. Trying to deal with libraries with nested folders is a complete nightmare with the list being completely flattened with no obvious hierarchical structure.
Another wonderful addition would be adding interfaces to SPWeb, SPList and other Sharepoint classes to aid testing.
Has anyone seen this method:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx This method shows the unbelievable nonsense that Sharepoint exposes to developers.
My personal favourite is the SPField.GetFieldValue Method. I have no idea why they designed it the way they did, but to me it does hardly make sense. To get a object out of a ListItem you have to do somethine like:
SPField field = ((SPList)list).Fields.GetField("FieldName");
object fieldValue = field.GetFieldValue(((SPListItem)item)[field.Title].ToString());
Getting an object out of a ListItem is IMO a basic operation, so this should not be that complicated.
Inconsistencies when passing field names to methods or arrays. For example:
SPFieldCollection.ContainsField(): Internal name or display name
SPFieldCollection.GetField(): Internal name or display name
SPFieldCollection.GetFieldByInternalName(): Internal name
SPFieldCollection.Item: Display name
SPListItem.Item: Internal name or display name
SPListItem.GetFormattedValue(): Internal name or display name
SPViewFieldCollection.Exists: Internal name
To put the icing on the cake, there is usually no documentation about whether a method takes internal and/or display name.