This is more of a general question, I've been bouncing around multiple posts on StackOverflow and reading what I've found so far in the docs. I haven't found anything super concrete yet to answer the post question which is: what are the benefits of linking documents to one another through the ref type vs. the string type?
As of now, I'm converting all my string "refs" to properly typed "refs". However, since i'm still relatively new to the platform I'm scratching my head wondering if this is even necessary. I assume I'd be just as effective at finding related docs with the string as with a reference.
Also, for the sake of future readers as of me posting this, you can set a ref like so:
db.collection(...).add({
...
reference: firebaseFirestore.doc(
`lesson_translations/${translationID}`
),
// reference is now typed as a 'ref'
})
I had found other posts on stackoverflow accessing it with .doc(...).ref which doesnt seem to be a thing anymore.
It's mostly a matter of personal preference and perceived convenience. There is not really anything a reference type can do that a string and your own code could not also do.
Having a reference type mostly saves you the trouble of building a new reference object in your code, if that's what you would have done with a string document ID anyway. You can also use it in security rules for the same purpose when it comes time to use get() to fetch another document referenced by a field.
Again, it's personal preference. Do whatever is most convenient for you.
When you call a document reference, you instantly get the document details while if you take a string path and call it, it will take some time to find that data. It is just a matter of a few milliseconds and a few lines of code. Imagine if you had a list of document references to store and you store them as strings, and then had to call all of them looping over it
I know of one tangible benefit, but it's only relevant if you are using a library for data binding that supports loading nested documents to n depth. I personally am using vuefire, but I would assume something similar exists for the react ecosystem.
It allows you to e.g. bind a collection or document to a variable, and automatically sync all the data of referenced documents.
Example
You sync a collection('users') with a depth of two, and each user document contains an array of favourites:
{
name:'John',
favourites: [ref1, ref2, ref3]
}
The library would immediately download the references and replace the original ref files with the data:
{
name:'John',
favourites: [{title:'foo'}, {title:'bar', {title: 'baz'}]
}
I'm trying to write a common test module for a localized application.
The first issue I'm having is the fact that MenuItems do not support controlname attributes. Currently my menu items are located via text or accessiblename attribute. Is there a way to support controlname attribute?
I've tried to make text and accessiblename attribute point to a variable and then bind the variable to some external dictionary. As I understand the external data sources are treated as rows which contain various data items for a single variable. I don't see a way to use external data sources that treat first column as variable name and second column as variable value. Is there a way to achieve such functionality?
I've thought about a way to extend RanorexXPath to accept functions. Then I could write something like ...menuitem[text=localizationService.Translate("#ADMINISTRATION") and have Ranorex find the menu item based on the result of localizationService.Translate function. Is there a way to do this?
Finally I've somewhat managed to get the result I need by using global variables and module variables. What I did was create a module that uses localizationService to fill module variables with correct data. Next I bind the module variables to global parameters and use the data in subsequent test. This is quite error prone and difficult to implement for large number of variables. Is there a way to access and set global variables directly from code (without the need to use binding)?
If any of the 4. points is possible please let me know.
The recomendation from Ranorex support team:
In general only the whole menu is a control in WinForms. The elements within that control (MenuItems) can only be recognized via MSAA.
The problem is that the "Name" attribute of the MenuItems is not accessible.
As workaround I would suggest to use the attribute "AccessibleDescription" in your application in order to automate the menu. This attribute can also be used for language independent names.
I am looking for a way to access components / field that are either in the same items array as the accessing one or even only in a same parent items array (the last one is just a option).
In ExtJS3 this was easy by simply defining a ref in the owner container but I didn't found anything like that in ExtJS4.
I know that I can use Ext.ComponentQuery() or the shortcuts up() / down() or even Ext.getCmp() but they are all not what I am looking for, cause they just executes a bunch of code while the ref was such an easy Way to do things.
Yes, I am aware of the fact that using a ComponentQuery is much more fail safe than the use of hard coded references. But I just want to know if there are some other ways to do this.
Alternately, for your case of getting the next element in a container, you can use the nextSibling or prevSibling. All components have these methods. It would be a little less walking around the DOM structure. They also allow for a selector argument.
They are described in the docs here.
Here are some tricks I have used:
//lookup by name
formPanel.getForm().findField('state');
//lookup using nextSibling/prevSibling in a fieldset or fieldcontainer
myField.ownerCt.nextSibling('textfield[fieldLabel=Description]')
Here fieldLabel property is used to narrow down field selection but you can use ANY property at all. So if you construct a field with a property ref you can then use it to select your field similar how you would use it in a ComponentQuery .
This is something I have been struggling about for some time now. The thing is: I have many (20 or so) static arrays of values. I say static because that is how I'm actually storing them, as static arrays inside some domains. For example, if I have a list of known websites, I do:
class Website {
...
static websites = ["web1", "web2" ...]
}
But I do this just while developing, because I can easily change the arrays if needed, but what I'm going to do when the application is ready for deployment? In my project it is very probable that, at some point, these arrays of values change. I've been researching on that matter, one can store application properties inside an external .properties file, but it will be impossible to store an array, even futile, because if some array gets an additional value, the application can't recognize it until the name of the new property is added where needed.
Another approach is to store this information in the database, but for some reason it seems like a waste to add 20 or more tables that will have just two rows, an id and a name.
And the last option, as far as I know, would be an XML, but I'm not very experienced with those. It seems groovy has a way of creating and reading XML files relatively easy, but I don't know how difficult would be to modify an XML whose layout is predefined in the application.
Needless to say that storing them in the config.groovy is not an option since any change will require to recompile.
I haven't come across some "standard" (maybe a best practice?) way of dealing with these.
So the questions is: Where to store these arrays?
Use Enum for a fixed set of attributes. Do this, if you rely at some places in your code on some concrete values.
If you do not rely on the attributes within your code (which you obviously don't), use a String-type. In this case, if you need to provide a select box, just do a distinct-query on this property in your database.
Default: Use a domain class per dynamic set of attributes. Another table is OK.
For something as simple as arrays you should use groovy own type of property files. They allow you too define properties as proper groovy variables (not just strings) and obviously loading them would be done dinamically in a simple way by using ConfigSlurper. For an example on how to use this kind of file you can have a look at the following ConfigSlurper:
For defining properties:
my.property.array=[1,2,3,4]
For loading property files:
def config = new ConfigSlurper().parse(new File('myconfig.groovy').toURL())
assert [1,2,3,4] == config.my.property.array
Tip: When you want to access the property files you want to do it in a way that can work for any environment. To make paths environment-independent use the following path as the root path:
import org.codehaus.groovy.grails.commons.ApplicationHolder
def ctx = ApplicationHolder.application.mainContext.servletContext
def rootPath = ctx.contextPath
Which naming convention do you use and why?
I like to use employeeNameTextBox, because:
It seems more natural from an English language perspective.
I find it's easier to look up with Intellisense.
The convention is similar to the convention used for events (MouseClickEvent, MouseClickEventHandler) and dependency properties (VisiblityProperty).
Note: I am using the full name rather than an abbreviation (such as "tb"), because it is in line with MS's naming conventions that say to avoid using abbreviations.
http://msdn.microsoft.com/en-us/library/ms229045.aspx
The only reason to use the control type in the name first (textBoxEmployeeName) is for easier grouping with Intellisense (All textbox controls would then show up together). Beyond that, there really is no benefit to using that way. I find the second way (employeeNameTextBox) more readable and prefer that way personally, but a lot of people will still go with the control type first, since that is the way it was done for a long time.
Naming your variables is so important. Thick client view conventions seem to be given the short end of the stick. Here are my thoughts:
Never put getters and setters for actual business values on your view. Don't do this:
public Name EmployeeName { get; set; }
To get or set an EmployeeName, your stateful code should explicitly call a method. Do it this way because it projects that the state is not stored on the view, but can be derived from or transposed to the view:
public void SetEmployeeName(Name employeeName);
public Name GetEmployeeName();
Hungarian notation is stupid. It was useful in languages <= VB6 because they used late binding of variable types. You had to protect yourself because type mismatches were runtime errors, not compile time. Only use txtEmployeeName if you also would use strEmployeeName and intEmployeeNumber.
If prefixing the pattern name isn't consistent with your naming convention, don't do it for the control type (which represents a pattern). If you wouldn't create a commandNameFormatting (instead of nameFormattingComamnd), then don't create a textBoxEmployeeName.
You'll probably need a suffix of some sort, since EmployeeName doesn't sufficiently describe the variable's purpose. An EmployeeName text box's purpose is to receive input. You could call it EmployeeNameTextBox if that makes you comfortable, but it might be better to call it EmployeNameInput. This has the added bonus that if you have a label, it's clear that EmployeeNamePrompt (or EmployeeNameLabel) is not the same as the text box. Without some sort of descriptive suffix, you don't have a good way to differentiate.
I (almost) always use [controltype][descriptive name]. I want to know right away what type of control I'm dealing with when I look at code, and if I DON'T remember the name, intellisense can help me out.
Just using a descriptive name (EmplyeeName) doesn't work for me. What type of control? Is it a label, a text box, or a combo box? Or a string? Or a file? It's important enough that the type of control or variable is always a part of it.
I propose a third option: uiEmployeName. Reasons:
It's not Hungarian. Both of the notations you mention are just flavors of Hungarian.
If you change an employee name text box over to a listbox you don't need to rename your variables.
Everything is grouped nicely in the intellisense without involving the type of the object.
The name of the object closely follows its function. It is a user-facing object that gets the employee name.
I generally try to keep the element type short, followed by a distinguishing label. I find that it quickly communicates the type and purpose of the element:
txtEmployeeName;
lblEmployeeName;
Why not EmployeeName? Seriously how does the control type as part of the name when it is already provided by your IDE assist in delivering easy to maintain code? Consider Ottenger's Rules for Variable and class Naming
K
As I read it, an article linked to in the article mentioned in the question (namely, Names of Resources) does use the control type at the end, in FileMenu (and ArgumentException though it's not a control).
My personal opinion is that this is also more readable, as it's the employee name text box and hence should be named the employeeNameTextBox, just like the words "File menu" are read in that order. (Though I substitute "Edit" for "TextBox" for brevity — I should probably kick that habit to use control names consistently with the environment name for them.)
A MUST READ is the XAML Guidelines released by Jaime:
Also read more here
WPF-specific Answer: No name at all.
Why? Because if you're developing using WPF you should not be naming your controls. If you are, you are doing something wrong.
WinForms required controls to be named because its data binding was so weak. WPF solves all that: The control itself can specify its data and behavior, so there is no need to name it.
I guess it's better to follow Microsoft's Object Naming Convention for naming your controls both in C# as well as Visual Basic.
I don't recommend hungarian notation in any form. textBoxEmployeeName is a form of hungarian notation. So I support the use of employeeNameTextBox.
Personally I don't even bother using the word TextBox, because it is not what is important about the variable. What is important is "Employee" and "Name". Not only does adding the word TextBox lock you in to a certain type, it also make it much harder to change that type, because you need to change the name to normalize your code and make it correct. Say for some reason you started this as a TextBox, but you later received a requirement to change this to a DropDownList or some other type, now you have to update all of your code and JavaScript to make it say DropDownList instead of TextBox.
It is much easier to forget about trying to type your variable names, and just simply name them. You have intellisense and compile time error checking for a reason, why not use it.
I would go with [controlType][DomainTerm] which in this case is textBoxEmployeeName. The reason is that while coding for the C# code behind you are more care about the UI controls than the domain specific terms.UI(View) side coding we need to identify/recognize the control type faster, which is little more important than the domain specific name in the View side , and since we read from 'Left to right' this naming convention is relevant.
I generally use txtEmployeeName or cmpEmployeeType , but textBox instead of txt is preferred as per MS guidelines
I have used both txtEmployeeName and employeeNameTextbox. Like many of the posts indicated, this is helpful for grouping. One groups by control types (txtEmployeeName, txtManagerName) while the other can group different related controls together (employeeNameTextbox, employeePhoneTextbox, managerNameTextBox, managerPhoneTextbox). In many cases I find the later more useful while coding.
You should do whatever it is that makes your code readable and self-documenting. Following hard and fast rules is always a mistake because they almost never cover all aspects of what needs to be done. There is nothing wrong with having guidelines (such as not using Hungarian notation), but it is more important that you are consistent and clear with your naming convention, whatever it is, than you follow some rules found on the Internet.
Ideas:
Avoid encodings/abbreviations.
The name should stand out from
similar names in the same scope.
Make the unique-most part the
left-most part. I suspect you have
several text boxes, but only one is
the employee name.
Avoid needless context. Are all the
names on this page about employees?
Is it an "employee" page? Then
EmployeeName is redundant. NameBox
or NameControl should be plenty.
Avoid needless context: do you have
names that are not controls? If so,
"Box", or "Control" is useful,
otherwise not so much.
Disclosure: I am the "ottinger" from "ottingers naming rules", which also evolved to be chapter 2 of "Clean Code". See short form at http://agileinaflash.blogspot.com/2009/02/meaningful-names.html
In VB I actually like to go with [ControlName]_[ControlType]. I can't remember how I started doing that but I suppose it's because it feels like a logical order. It also simplifies coding a bit because the code suggestions are grouped by the control description rather than the control type.
I name controls the same way in C# except I follow C#'s preference for camelCase: [controlName]_[controlType].
I also tend to use my own abbreviations for control types, though they are not vague.
Examples:
VB: Save_Btn and NewFile_MItem (menu item)
C#: save_btn and newFile_mItem
It works for me, but of course every programmer has their style.