GUI Handcode или [закрытый] инструмент gui-разработчика использования

Заглядывая в исходный код resteasy-client, Invocation#invoke(Class<T>) просто вызывает Invocation#invoke() и вызывает Invocation#extractResult(GenericType<T> responseType, Response response, Annotation[] annotations) для извлечения результата из Response:

@Override
public <T> T invoke(Class<T> responseType)
{
   Response response = invoke();
   if (Response.class.equals(responseType)) return (T)response;
   return extractResult(new GenericType<T>(responseType), response, null);
}

Invocation#extractResult(GenericType<T> responseType, Response response, Annotation[] annotations) закрывается Ответ в блоке finally:

/**
 * Extracts result from response throwing an appropriate exception if not a successful response.
 *
 * @param responseType
 * @param response
 * @param annotations
 * @param <T>
 * @return
 */
public static <T> T extractResult(GenericType<T> responseType, Response response, Annotation[] annotations)
{
   int status = response.getStatus();
   if (status >= 200 && status < 300)
   {
      try
      {
         if (response.getMediaType() == null)
         {
            return null;
         }
         else
         {
            T rtn = response.readEntity(responseType, annotations);
            if (InputStream.class.isInstance(rtn)
                 || Reader.class.isInstance(rtn))
            {
               if (response instanceof ClientResponse)
               {
                  ClientResponse clientResponse = (ClientResponse)response;
                  clientResponse.noReleaseConnection();
               }
            }
            return rtn;

         }
      }
      catch (WebApplicationException wae)
      {
         try
         {
            response.close();
         }
         catch (Exception e)
         {

         }
         throw wae;
      }
      catch (Throwable throwable)
      {
         try
         {
            response.close();
         }
         catch (Exception e)
         {

         }
         throw new ResponseProcessingException(response, throwable);
      }
      finally
      {
         if (response.getMediaType() == null) response.close();
      }
   }
   try
   {
      // Buffer the entity for any exception thrown as the response may have any entity the user wants
      // We don't want to leave the connection open though.
      String s = String.class.cast(response.getHeaders().getFirst("resteasy.buffer.exception.entity"));
      if (s == null || Boolean.parseBoolean(s))
      {
         response.bufferEntity();
      }
      else
      {
         // close connection
         if (response instanceof ClientResponse)
         {
            try
            {
               ClientResponse.class.cast(response).releaseConnection();
            }
            catch (IOException e)
            {
               // Ignore
            }
         }
      }
      if (status >= 300 && status < 400) throw new RedirectionException(response);

      return handleErrorStatus(response);
   }
   finally
   {
      // close if no content
      if (response.getMediaType() == null) response.close();
   }

}
14
задан oxbow_lakes 8 March 2009 в 15:19
поделиться

11 ответов

Я чувствую сильно, что необходимо использовать интерфейсного разработчика вместо кодирования руки GUI. Как в вопросе упомянул, что это - намного более чистое разделение и как только что-то должно быть отредактировано, это намного легче.

спокойный Разработчик заставил эту функцию создавать класс из .ui файл 1) , но я думаю, что не использование этой функции является лучшим способом, поскольку это создает просто более кодированный, который не должен существовать вообще. Проблема скорости создания окна от .ui - файл незначителен, потому что окно должно быть загружено только однажды.

Это - PyQt, но что-то подобное возможно в C++:

class SelectDateDialog(QDialog):
    def __init__(self):
        QDialog.__init__(self)
        uic.loadUi("resources/SelectDate.ui", self)

По существу это имеет тот же эффект как включая весь Ваш код UI в __init__() метод, но UI почти полностью разделяется от кода.

<глоток> 1) .ui файлы являются XML-файлами, которые описывают пользовательский интерфейс

4
ответ дан 1 December 2019 в 06:54
поделиться

Я был бы всегда ручной код дизайн GUI, где нет никакого стандарта (или фактический стандарт) язык разметки GUI (как с Java). Причина этого состоит в том, что я нашел, что с помощью разработчика GUI средство проектирования согласуется Вас к использованию конкретного IDE. Со временем лучший IDE для кода дизайна и/или написания GUI изменится и , каждый разработчик должен быть свободен выбрать, какой бы ни IDE они чувствуют себя больше всего комфортно с .

, Где я работаю в данный момент, у нас есть много графический интерфейсов пользователя прежней версии, которые были записаны с помощью разработчик Netbeans Matisse GUI (против моего совета в то время:-). Они теперь почти неудобны в сопровождении, потому что все разработчики предпочитают или ИДЕЯ IntelliJ или Eclipse как их IDE. Это не realistsic, или осуществимый, чтобы сделать, чтобы разработчики разожгли Netbeans только для изменения расположения GUI (люди не сохраняют определения проекта Netbeans в синхронизации и т.д.).

Другая точка - то, что общее время, выписывая код расположения GUI - вероятно, только 5% общего усилия по разработке из данного проекта. Даже если это берет Вас вдвое более длинный для написания кода самих, это не переводит, такое количество издержек в главной схеме вещей. И это - маленькая цена для оплаты за долгосрочную пригодность для обслуживания.

, пока Вы соглашаетесь с выделением логики макета GUI от бизнес-логики, я не полагаю, что что-либо страдает в результате. Никто здесь больше не использует разработчиков GUI!

16
ответ дан 1 December 2019 в 06:54
поделиться

Я делаю это вручную, намного легче переставить вещи вокруг, и панели повторного использования в приложении (некоторые панели могут появиться в нескольких местах).

Используя разработчика работает, когда Вы находитесь в команде, художники, как предполагается, делают GUI.

Нахождение правильного элемента в большой панели может быть трудным.

?? Я никогда не видел это.

7
ответ дан 1 December 2019 в 06:54
поделиться

Достаточно забавный это пошло наоборот для меня. Говоря с точки зрения Winforms, код, сгенерированный разработчиком, является довольно шумным с, возможно, четвертью или половиной всех действительно необходимых настроек свойства. Создание довольно больших средств управления является также большим количеством искушения при работе с разработчиком. Изменение некоторой иерархии средств управления в разработчике Winforms является настоящим кошмаром в моих глазах.

В моем последнем проекте я создал дополнительные API для установки разделителей в формах, dockmanagers, меню, панели инструментов и т.д. на декларативном виде. Они таковы, что далее осуществят разделение проблем.

я также пытаюсь положиться намного больше на функции автоматической компоновки, которые по общему признанию намного более хороши в WPF, но могут также пойти некоторым путем в Windows Forms.

4
ответ дан 1 December 2019 в 06:54
поделиться

При разработке бизнес-приложения с большим количеством форм ввода и табличных данных писание кода для UI и быстрее и более удобно в сопровождении, чем использование разработчика UI. В тех видах приложений, там почти никогда не должен точно помещать один элемент в предопределенном месте на экране, в то время как, с другой стороны, существует много конвенций повторения и дизайна, которые могут просто быть извлечены в отдельные методы.

Берут, например, Eclipse или предпочтительное диалоговое окно OpenOffice. Существует набор категорий и набор различных вариантов для установки для каждого. Если необходимо сделать что-то вроде того размера, рука, разрабатывая каждый экран является приземленной задачей. Намного лучший подход должен написать код, который генерирует элементы UI на лету, от обеспеченных доменных данных, согласно некоторым конвенциям и значениям по умолчанию.

я не вижу, как использование разработчика упрощает лучшее разделение, ни как то воспринятое разделение помогло бы с чем-либо, учитывая, что Вы уже не допускаете свою бизнес-логику в UI.

И, наконец, если Вы используете Java, убедиться проверить MigLayout. Это работает с Swing и SWT, синтаксис it очень краток и ясен, и это имеет режим отладки, это невероятно полезно.

3
ответ дан 1 December 2019 в 06:54
поделиться

Я был бы сильно совет Вы для использования Интерфейсного Разработчика на OS X. Выполнение вручную хорошо, если Вы хотите учиться, но Вы собираетесь сохранить себя много головных болей при помощи его на фактических проектах. Это действительно довольно мощно.

Что касается Java и C++, это зависит от того, что Вы делаете и от какой платформы. Для простых приложений Вам не может сойти с рук никогда наблюдение кода UI. Однако для сложных приложений и толстых клиентов, обычно необходимо делать часть кода вручную.

3
ответ дан 1 December 2019 в 06:54
поделиться

Это зависит от ситуации, действительно. Я думаю и имею их место, и я обычно использую гибридный подход.

всегда существуют некоторые вещи, которые разработчик GUI не может сделать (например, выбирание цвета к константе UIColor в Интерфейсном Разработчике). С другой стороны, большая часть работы UI является довольно приземленной (например, добавление статических маркировок).

я предпочитаю делать приземленный материал в разработчике GUI и более интересный материал в коде.

кроме того, я иногда редактирую XML, произведенный разработчиком GUI (Соедините интерфейсом с Разработчиком и поляной в моем случае), вручную.

2
ответ дан 1 December 2019 в 06:54
поделиться

Я склонен думать, что правильный ответ зависит от культуры целевой платформы. На OS X Интерфейсный Разработчик является такой неотъемлемой частью набора инструментальных средств, что трудно избежать его.

В Java (awt или колебание), реверс действительно верен. Нет никакой поддержки набора инструментальных средств этого.

Действительно, способ, которым можно сказать, способ, которым инструменты производят свои выводы. Взаимодействуйте через интерфейс Разработчик производит .nib файлы формата, которые характерны для способа, которым Какао помещает средства управления на экран. Это понимает то, что является по существу интерфейсным форматом разметки. Java не имеет такого подобного понятия. Все - скомпилированный класс и для этого его намного более трудное для получения удобных результатов.

GTK +, в сочетании с поляной, кажется, устанавливает разумное равновесие между двумя.

1
ответ дан 1 December 2019 в 06:54
поделиться

Ничто не препятствует смешать два подхода. Я часто делаю основное расположение формы в разработчике GUI (потому что это быстро, и Вы видите то, что Вы делаете), и помещенный там одна или несколько панелей, которые тогда заполняются с кодом. Это особенно полезно, когда GUI должен адаптироваться к определенным ситуациям - например, если GUI должен измениться согласно тому, какие аппаратные средства подключены.

В любом случае, самая важная вещь состоит в том, чтобы действительно разделить GUI и прикладную логику.

1
ответ дан 1 December 2019 в 06:54
поделиться

Мое представление об этом: 1. Кодированный рукой код GUI является намного большим количеством допускающих повторное использование 2. Проблемы расположения более просты с разработчиками

0
ответ дан 1 December 2019 в 06:54
поделиться

Ручное кодирование может быть хорошим, если Вы хотите некоторые нестандартные функции, включенные в Вас UI. У Вас есть больше гибкости, но необходимо будет инвестировать больше времени для создания хорошего интерфейса, потому что Java/C++ является языком, не средним для предназначения для дизайна UI.

На плюс то, если у Вас есть управление версиями, можно посмотреть на историю изменений, что-то, что не может быть сделано с разработанным, который использует двоичный формат или формат xml, который не является товарищеской встречей RCS.

Сегодня большинство доступных инструментов для визуальной разработки UI имеет пропавших без вести некоторых функций. Они не достаточно гибки, некоторые функции могут только быть достигнуты, кодировав их. Также в некоторых случаях сгенерированный код не является действительно человеческой товарищеской встречей, и если Вы изменяете вручную, Вы больше не можете быть в состоянии продолжить использовать разработчика.

, Но разработанный может быть действительно средство экономии времени, если дизайн прост, и мы можем надеяться, что разработчики будут улучшены в будущем, но я не буду держать шириной.

Мое заключение состоит в том при необходимости в гибкости сегодня, необходимо будет кодировать вручную интерфейс, если Вы хотите что-то простое и быстрое тогда, разработчик является лучшим выбором.

, Возможно, в будущем разработчики будут более мощными, или возможно будут новые языки, специализированные на дизайне UI, который более подойдет для использования в C++ / Java, что-то как XUL или XAML.

0
ответ дан 1 December 2019 в 06:54
поделиться
Другие вопросы по тегам:

Похожие вопросы: