15 Apr
2009
15 Apr
'09
1:44 a.m.
fciubotaru (SVN) wrote:
Author: fciubotaru
Date: 2009-04-14 19:28:28 +0200 (Tue, 14 Apr 2009)
New Revision: 18649
Modified:
xoffice/trunk/xword/XWikiLib/XWikiLib.csproj
xoffice/trunk/xword/XWord/AddinActions.cs
xoffice/trunk/xword/XWord/XWikiAddIn.cs
Log:
XOFFICE-74 Navigation Pane does not auto-refresh the tree view when creating a new page
Patch submited by Teofil Achirei, reviewed by Florin Ciubotaru
public string currentPageFullName =
"";
+
/// <summary>
+ /// Specifies if the current page was published on the server.
+ /// It does not specify if the last modifications were saved, but
+ /// if the local document has a coresponding wiki page. It's FALSE
+ /// until first saving to wiki.
+ /// </summary>
Shouldn't properties start with uppercase? I thought that's the convention.
+ public bool currentPagePublished = false;
+ /// <summary>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
15 Apr
15 Apr
10:51 a.m.
New subject: [xwiki-devs] [xwiki-notifications] r18649 - in xoffice/trunk/xword: XWikiLib XWord
Sergiu Dumitriu wrote:
fciubotaru (SVN) wrote:
That is a field. While generally speaking public fields are bad practice
they seem to be used by VSTO devs in the add-in class because:
- COM and .NET interoperability is done by using ref parameters. Fields
can be passed as ref, properties cannot.
- They want to keep the addin class files shorter. Properties
significantly increase the length of the file
- Some use public fields and only when a custom getter, setter or
indexer is needed then it's switched to private/protected.
- Properties are slower if not inlined at release.
I'm don't like public fields, but I would like to have the XWikiAddin.cs
file cleaner having only VSTO specific events if possible.
IMO all fields should be encapsulated so I'm thinking at moving them and
the properties in another file but keeping them in the same class.
Then, COM interop will be handled by always boxing/unboxing to local
variables in the methods that call COM, this is what I'm usually doing
anyway.
This would be the fourth file for this class. What do you think about
more files vs less but larger files?
Author: fciubotaru
Date: 2009-04-14 19:28:28 +0200 (Tue, 14 Apr 2009)
New Revision: 18649
Modified:
xoffice/trunk/xword/XWikiLib/XWikiLib.csproj
xoffice/trunk/xword/XWord/AddinActions.cs
xoffice/trunk/xword/XWord/XWikiAddIn.cs
Log:
XOFFICE-74 Navigation Pane does not auto-refresh the tree view when creating a new page
Patch submited by Teofil Achirei, reviewed by Florin Ciubotaru
public string currentPageFullName =
"";
+
/// <summary>
+ /// Specifies if the current page was published on the server.
+ /// It does not specify if the last modifications were saved, but
+ /// if the local document has a coresponding wiki page. It's FALSE
+ /// until first saving to wiki.
+ /// </summary>
Shouldn't properties start with uppercase? I thought that's the convention.
+ public bool currentPagePublished =
false;
+ /// <summary>
7:20 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r18649 - in xoffice/trunk/xword: XWikiLib XWord
Florin Ciubotaru wrote:
Sergiu Dumitriu wrote:
I was just asking about the fact that, AFAIK, the C# naming convention
is to start things with upper case, like CurrentPagePublished instead of
currentPagePublished. As about more/less files for the same class, I'd
say it depends on whether the separation makes sense and is obvious, and
it actually improves the readability of the code. I can't say unless I
know what each file does.
Shouldn't properties start with uppercase? I
thought that's the convention.
That is a field. While generally speaking public fields are bad practice
they seem to be used by VSTO devs in the add-in class because:
- COM and .NET interoperability is done by using ref parameters. Fields
can be passed as ref, properties cannot.
- They want to keep the addin class files shorter. Properties
significantly increase the length of the file
- Some use public fields and only when a custom getter, setter or
indexer is needed then it's switched to private/protected.
- Properties are slower if not inlined at release.
I'm don't like public fields, but I would like to have the XWikiAddin.cs
file cleaner having only VSTO specific events if possible.
IMO all fields should be encapsulated so I'm thinking at moving them and
the properties in another file but keeping them in the same class.
Then, COM interop will be handled by always boxing/unboxing to local
variables in the methods that call COM, this is what I'm usually doing
anyway.
This would be the fourth file for this class. What do you think about
more files vs less but larger files? >> + public bool currentPagePublished =
false;
>> + /// <summary>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
5686
days inactive
5687
days old
2 comments
2 participants
participants (2)
-
Florin Ciubotaru -
Sergiu Dumitriu