И Используя GUID и Используя целое число автопостепенного увеличения
Отображаемый текст пунктов JList получается путем вызова toString() для этих элементов. JButton.toString() возвращает этот длинный текст «javax.swing.JButton [, 0,0,0x0, неверный ...». Вот почему вы получаете такой длинный текст по JList предметам.
Одним из способов решения этой проблемы является написание собственного класса, расширяющего JButton и переопределяющего toString() в вашем классе. Как в следующем примере.
ПРИМЕЧАНИЕ:
Если вы ожидаете функциональность JButton (например, нажатие кнопки) от своих элементов списка, вам придется сделать больше, чем это. Вам придется написать собственный рендерер ячеек и использовать его в своем JList.
import javax.swing.*;
public class ButtonList
{
public static void main(String[] args)
{
CustomButton test = new CustomButton("test");
CustomButton b2 = new CustomButton("button 2");
CustomButton b3 = new CustomButton("button 3");
DefaultListModel model = new DefaultListModel<>();
model.addElement(test);
model.addElement(b2);
model.addElement(b3);
JList emailList = new JList<>(model);
JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.getContentPane().add(new JScrollPane(emailList));
frame.pack();
frame.setLocation(300, 300);
frame.setVisible(true);
}
}
class CustomButton extends JButton
{
CustomButton(String text)
{
super(text);
}
@Override
public String toString()
{
return getText();
}
}
Вывод:
5 ответов
Я всегда склонен использовать суррогатные первичные ключи в своей базе данных. Это: те первичные ключи не имеют никакого фактического значения в проблемной области, и таким образом, те первичные ключи никогда не выставляются пользователям. (Если этот суррогатный первичный ключ имеет тип GUID или идентификационные данные, я не забочусь; это зависит от требований).
Если Вы говорите, что пользователи должны смочь определить объекты на основе удобного для пользователя идентификатора, то, я думаю, что этот удобный для пользователя идентификатор является значением, которое принадлежит Вашей 'проблемной области'. Это означает, что этот идентификатор должен действительно быть атрибутом в Вашей таблице, но это не должно использоваться в качестве первичного ключа в Вашей таблице.
Это также позволяет Вам легко изменять значение такого удобного для пользователя идентификатора (если это должно быть необходимо), без Вас имеющий необходимость волноваться об изменении связанных внешних ключей также.
В MySQL, необходимо будет установить числовое ID как a PRIMARY KEY, как AUTO_INCREMENT может быть только PRIMARY KEY, что означает, что это должно также быть NOT NULL.
Можно все еще определить a UNIQUE INDEX на Вашем GUID столбец и использование это где угодно, хотя InnoDB таблица будет кластеризироваться на числовом id, не на GUID.
Чтобы быть более конкретными относительно Вашего вопроса, да существуют другие проблемы с использованием GUID как первичные ключи в базах данных:
http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx
Проблема не так с использованием GUID как первичный ключ, его использование непоследовательного GUID как кластерный индекс для таблицы.
Еда на дом здесь должна или использовать другие поля в качестве кластерного индекса или использовать последовательный GUID для предотвращения этой фрагментации.
"Почему делают "пользователей, должен смочь определить объекты на основе удобного для пользователя идентификатора"?
По-моему, Ваши пользователи должны записи itentify с помощью кодов.
Скажем, Ваша база данных содержит продукты (поскольку Вы упомянули это рассматриваемый). Не был бы это быть лучше, если у них были коды для представления продуктов, что пользователи могли войти.
Скажем, у Вас есть таблицы и стулья как пользователь, я предпочел бы использовать tbl и chr, чем 1 и 2 для идентификации то, о чем я говорю.
Существует философская школа там, которая говорит, что Вы никогда не должны выставлять свой суррогатный идентификатор внешнему миру. Таким образом, они сказали бы, хотите ли Вы бизнес-идентификатор, необходимо использовать что-то еще для него.
В этой статье Wikipedia, например, говорится это:
Разъединение
Значения сгенерированных суррогатных ключей - потому что они сгенерированы и произвольны - не имеют никаких отношений к реальному значению данных, сохраненных подряд. При осмотре другой строки, содержащей ссылку внешнего ключа на суррогатный ключ, не возможно разработать значение его содержащий ту ссылку просто путем рассмотрения данных в самой строке. Слой добавляется к этой косвенности для каждого соединения внешнего ключа, по которому нужно переместиться при попытке понять элемент данных. Это может также сделать аудит более трудным, поскольку неправильные данные не очевидны на контроле.
Суррогатные ключи являются также не естественными для данных, которые экспортируются и совместно используются. Особая сложность - то, что два экземпляра схемы могут содержать записи, которые логически означают то же самое (который является - они - то же в деловом чутье), но которые имеют другой ключ вследствие истории того, как ключи были присвоены. Подход к контакту с этим должен принять правило, что суррогатные ключи никогда не экспортируются или импортируются: они никогда не выставляются вне базы данных за исключением текущих данных (наиболее очевидно, в выполняющихся приложениях, которые имеют "живое" соединение с базой данных).