Почему классы GWTRPC * Service Interface идут в пакете ".client" вместо ".shared"? - PullRequest
Новая
       4

Почему классы GWTRPC * Service Interface идут в пакете ".client" вместо ".shared"?

3 голосов
/ 27 августа 2011

При рассмотрении примеров приложений GWT и учебного пособия RPC используются следующие условные обозначения: 

./client/GreetingService.java
./client/GreetingServiceAsync.java
./server/GreetingServiceImpl.java

Несмотря на то, что документы GWT очень редки по передовым методикам, какие компоненты включены, где во время выполнения, ясная интуиция:

  • клиент - скомпилирован в JavaScript компилятором GWT
  • сервер - скомпилирован в байт-код javac
  • shared - скомпилирован в JavaScript компилятором GWT и скомпилирован в байт-код с помощью javac

Это заставит поверить, что код в client должен , а не находиться на исходном пути компиляции javac. Тем не менее, поскольку GreetingServiceImpl реализует GreetingService, очевидно, что код в client должен находиться на исходном пути во время компиляции и включаться в путь к классам выполнения при развертывании.

Учитывая это, почему интерфейс GreetingService не входит в shared?

Если вы попытаетесь вставить его в shared, плагин GWT Eclipse пожалуется на «отсутствие асинхронного интерфейса» ...

Ответы [ 3 ]

5 голосов
/ 29 августа 2011

Давайте попробуем прояснить:

  • Технических различий между client и shared не существует, это всего лишь соглашение. Оба объявлены как исходные пакеты в вашем модуле (файл .gwt.xml )
  • клиент и общий пакет скомпилированы в javascript и байт-код
  • На стороне сервера байт-код для всей клиентской части обычно доступен, хотя большая его часть не используется .
  • Поэтому некоторые люди просто удаляют пакет shared и помещают все в пакет client . Это дело вкуса.
  • Как сказал Томас, для вашего клиентского кода должен быть доступен интерфейс Service. Поэтому он должен быть либо в пакете client , либо в пакете shared . Но интерфейс ServiceAsync должен быть в том же пакете, что и интерфейс Service. И ServiceAsync, безусловно, не является чем-то, что считается общим для клиента и сервера . Таким образом, интерфейс ServiceASync должен быть в пакете client .
  • Как следствие, интерфейс Service помещается в пакет client .
  • В вашем случае плагин GWT Eclipse пожаловался на то, что интерфейс ServiceASync не найден в пакете интерфейса Service.
  • Вы все еще можете использовать пакет shared для классов, которые отправляются через RPC .

Это отвечает на ваш вопрос?

1 голос
/ 28 августа 2011

В моих проектах Service и ServiceAsync находятся в shared, и все работает нормально.На самом деле я не вижу другого способа, так как SercviceImpl в server реализует интерфейс Service, и компилятор должен иметь их в classpath.

0 голосов
/ 28 августа 2011

Генератор GWT-RPC использует соглашение об именах (добавляя суффикс Async к имени класса), добавляя «правило переименования пакетов» (Service в shared, в то время как ServiceAsync в client) не подходит для многих людей. Итак, правило заключается в том, что оба интерфейса находятся в одном пакете, независимо от имени пакета, что позволяет вам поместить их в shared, если хотите (как сказал Питер Кнего)

(это правило также является наследием, соглашение shared было введено в проектах GWT совсем недавно, по сравнению с GWT-RPC)

...