Which method is better?:
add(new Label("label", new PropertyModel<String>(cat, "name")));
or
add(new Label("label", cat.getName()));
I tried to find any information about comparison.. but couldn't find anything
How I understand the first method is for read/write logic and the second for read only logic, (if I am not right please write me). But for read only logic which better is?
They're functionally different.
The first one says: whenever this component is re-rendered, refresh the value. The second one says: display the value as it was at the time of creation.
Which one do you need? If you want a dynamically refreshing label, you have no choice, it's PropertyModel or CompoundPropertyModel (see later).
If you want it to stay the same, even if the underlying object changes, you can't use PropertyModels.
However, if you are absolutely sure that cat.getName() is never going to change, and therefore the two versions behave the same way, I personally wouldn't use PropertyModel for three reasons:
It breaks encapsulation: in the absence of a getter, it will try to access the private field itself.
As #Jesse pointed it out, it's "magic". If you refactor your class and rename your fields, your PropertyModel will break.
It's not easier to read or maintain. Granted, it's not that much harder either but why add any unnecessary complexity when you're not getting anything out of it? If you put cat.getName() there, you can "click through" in your IDE, your label will show up in a search for all invocations of the getName() method and so on.
If you have many components referring to fields of the same object, you can consider using CompoundPropertyModels, which, although still suffer from problems 1 and 2, make your code look a lot cleaner.
If you have three or fewer components like this though and you don't need a dynamic model, just use the modelless format.
This version is the better of the two options you gave:
add(new Label("label", new PropertyModel(cat, "name")));
It allows the value rendered on the page to update if the page is repainted later after the cat's name has changed.
The second option will only ever display the cat's name as it was at the time that the Label was created. It will never change if the cat's name changes.
There is something to be said for the dangers of using PropertyModel. It is "strings" programming. You compiler is not helping you verify the correctness of the property name "name". If you later refactor your code and change the name of the property to something like "firstName", then you will have to manually find all the places where you reference the old property name and change them by hand.
Related
I will need to create a Custom Button "convert lead" that will perform the same functionality as Standard Button "Convert" when the button is clicked.
What is the best approach to do it..?
That's a very broad question. What exactly you need, what have you tried so far? Do you really need just a button that opens the conversion page or something more?
If you want to somehow recreate it with Apex... Core of the coded solution would be the Database.convertLead method. You don't pass to it whole leads (like to Database.insert for example) but instead just their IDs + bunch of control flags to make it do exactly what you need. Read up about LeadConvert object. And similarly you can get Account/Contact/Opportunity ID from the result object if it succeeded.
I don't think there's programmatic way to access field names & mappings defined by administrator for lead conversion. Maybe you'd need to store this info somehow (in helper object? custom metadata?). So then you'd query the field names from metadata, then query the lead fields and finally display table of fields & mappings to the user.
I'm trying to implement a autocomplete function into a small app. I want to give the user the possibility to write down a city (from a long long list of cities) into a NSComboBox. That works fine, as long as the user is using the exact writing of the city inside my array of city names. But if they use, for whatever reason, a different spelling, it fails and the city is not found.
So if the user is looking for "Köln" for example, it's not a problem, but if he is looking for "Cologne" he wouldn't be able to find it.
For this I have, for each city an additional array of alternative spellings.
Now I would love NSComboBox (or any other type of TextField) to look not only in "city.name" but also within the array "city.alternativeNames". The shown value should as well represent what the user is writing.
I don't want to create an entry in the list of the pop-up part of NSComboBox for each alternative name, as that would make the list even longer than it is and would confuse people (cologne alone has 85 different spellings).
Thanks for your suggestions, I'm completely new to NSComboBox.
Interesting problem. I think probably you need to choose a different way to structure your data to make it easier.
Consider the lookup method (matching a string). Structuring your data for this case should account for the preferred spelling of each city (preferred by you, for the scrolled list).
How about a flat array of cities (to allow a simple search based on user spelling without also having to check each possible array of alternates and manage sorting them properly) but each has an optional (can be nil) "preferred spelling" pointer to the "correct" one. When displaying the options in the combo box, show the array filtered by those with no optional preferred spellings plus the currently-typed partial/full completion of the alternate spelling?
So a City has a name property and an optional preferred property. In your case, if Cologne is preferred, the Köln instance would have Cologne set as preferred. Köln would only appear in the list if the user typed it (even partially) and it would automatically be in the correct alpha-sorted position (assuming your cities are kept sorted).
Does this make sense or do I need to rephrase? Haven't had enough coffee this morning. :-)
I'm am currently building two custom validators that extends Zend_Validate_Abstract which are named respectively Lib_Validate_TimeAfter and Lib_Validate_TimeBetween. The names a pretty straight forward, the first one is used to test if a date/datetime/time comes after an other one and the second is used to test if a date/datetime/time comes between two other date/datetime/time.
Both of those validators would rely on the same method named _buildDate($value) which take a value in the form of a datestamp, a hourstamp(either hh:mm or hh:mm:ss), a timestamp or an ISO_8601 timestamp and convert it in a usable date format.
Since I dont want to repeat myself and copy/paste the method in both of my validator, I was looking for the best way to do it.
The avenues I am looking at right now would be to develop somekind of class helper that my validators would be able to use (kind of messy way of doing things since it add unessesary dependencies) or I could add an other layer of abstraction by building an other validator that validate date/datetime/time and then extend my two validators on that since I could share the method _buildDate($value), but then I don't think I would really need the validator.
So, what would be a good way (I am not really looking for the "Way of the gods" of doing thing) to structure that kind of code to avoid repetition (DRY)?
You might want to build one validator instead of two, where you can pass in a dateBefore, dateAfter which are both optional. If you pass only dateBefore, your $value will be valid if it is after that date, if you pass in both, it will have to be between them and if you pass in only dateAfter, the value will have to be before that date.
This would be flexible, clear, generic, less code and even cover one more case.
What about a class Lib_Validate_Common which extends Zend_Validate_Abstract which has your common method. And Lib_Validate_TimeAfter and Lib_Validate_TimeBetween extends Lib_Validate_Common .
I have a custom node type for which I want to have a field that uses a special combobox based on list_text. When one chooses the type list_text it is normally possible to enter a static list of selectable texts, however, I want this list to be dynamic, i.e. based on the results of a db_query. What is the best way to do this using Drupal 7?
A simple example for clarification: A node of this custom type X contains a field that points to another node, so whenever a node of type X is created I want a combobox that contains all other nodes.
(Best solution would be to only display the combobox during node creation, and no longer during edit. But I could also live with it if the combobox was shown during the edit as well.)
I have tried to customize options_select by defining my own data type and implementing hook_options_list accordingly. The combobox was displayed during creation with the correct values, however, I could not save it.. I have no idea what went wrong there, but on the first submit it would change to a different theme, and when I tried again I got an internal server error. Am I on the right track at all with defining a completely new data type for the field? there surely must be a simpler way?
You're right in that you don't need a new datatype. Here's a good tutorial on how to do this. It's not specifically for D7 but I didn't see much that wasn't still applicable. There may be a better way to do it in D7 specifically but I would love to know it too if so :)
The tutorial linked by allegroconmolto sent me on the right way. Thanks for that.
Here's the simpler way of doing it: tutorial
Basically, it is, as I assumed, a common problem and hence a simple solution for it was included in the webform module by now. It provides a hook_webform_select_options_info which can be used to register a callback method. The callback method is then called each time a corresponding option select of a webform is shown, so that you can easily fill it with the results of a dbquery or anything else. Works like a charm and takes next to no time to implement.
What is a good strategy for dealing with changing product and feature names in source code. Here's the situation I find myself in over and over again (most of you can relate?)...
Product name starts off as "DaBomb"
Major features are "Exploder", "Lantern" and "Flag".
Time passes, and the Feature names are changed to "Boom", "Lighthouse" and "MarkMan"
Time passes, and the product name changes to "DaChronic"
...
...
Blah, blah, blah...over and over and over
And now we have a large code base with 50 different names sprinkled around the directory tree and source files, most of which are obsolete. Only the veterans remember what each name means, the full etimologic history, etc.
What is the solution to this mess?
Clarification: I don't mean the names that customers see, I mean the names of directories, source files, classes, variables, etc. that the developers see where the changing product and feature names get woven into.
Given your clarification that you "don't mean the names that customers see, [you] mean the names of directories, source files, classes, variables, etc. that the developers see", yeah, this can be an annoying problem.
The way teams I've been on have coped with best when we've had a policy of always using only one name for each thing in the code base. If the name changes later on we either stay with the old name in the code, or we migrate all instances of the old name to the new name. The important thing is to never start using the new name in the code unless all instance of the old name have been migrated. That way you only ever have to keep 2 names for something in your head: the "old name", used in the code, and the name everyone else uses.
We've also often chosen a very generic/descriptive name for things when starting out if we know the "brand name" is likely to change.
I consider renaming to better naming conventions just another form of refactoring. Create a branch, perform the renames, run unit/integration tests, commit, merge, repeat. It's all about process control to keep consistency in the project.
The solution to the mess is to not create it in the first place. Once a code path is named, there's rarely a good reason to change it and never a good reason to use a new name alongside the old one. When "Exploder" becomes "Boom", you have two choices: Either keep using Exploder exclusively, and never mention Boom anywhere, or change all instances of Exploder to Boom and then continue on using Boom exclusively and never mention Exploder again.
If you're using both Exploder and Boom in the same code base, you're doing it wrong.
Also, I know you clarified that you're not talking about the user-visible names, but, if you start out working with your own internal names which are relevant to what the code does and completely independent of what marketing wants to call the product/feature, then this is much less likely to become an issue. If you're already referring to Exploder internally as TNT, then what difference does it make if Exploder gets changed to Boom?
How do you deal with Localization? Same thing; same method.
We use an internal and and external name. It could be as simple as a static variable definition like
public static final String EXPLODER = "Boom";
And in code you'll always use the reference to EXPLODER. Same for path names and the like - hard coding those paths at different places is a no-go anyway. If some guys starts digging through internal stuff (like JS sources or ini files or whatever), who cares if they discover Exploder?
Just use internal names, and ignore changes to marketing/official names: https://softwareengineering.stackexchange.com/a/208578/55472.