JSF отступающая бобовая структура (лучшие практики)
Объявите variable для bottomNavigationBar content как
var navContent;
Создайте метод для исключения вашего bottomNavigationBar
excludeBottomNavigationBar(){
return Container(
height: 0.0,
);
}
Теперь вам нужно назначить контент bottomNavigationBar согласно вашему требованию, исключите bottomNavigationBar для страницы входа
import 'package:flutter/material.dart';
import './login/login.dart';
import './alerts/alerts.dart';
import './home/home.dart';
import './Theme.dart';
import './settings/settings.dart';
import './enroll/enroll.dart';
import './add_device/add_device.dart';
import './eachDevice/index.dart';
import './device_settings/device_settings.dart';
import 'splash_screen/splash_screen.dart';
import './geofences/geofence_list.dart';
import './geofences/draw_geofence.dart';
import 'package:firebase_messaging/firebase_messaging.dart';
import './home/second_navigation_bar.dart';
import 'dart:io';
import 'package:path/path.dart';
void main() {
GlobalKey<NavigatorState> navigator = new GlobalKey<NavigatorState>();
HttpOverrides.global = new AppHttpOverrides();
var navContent;
excludeBottomNavigationBar(){
return Container(
height: 0.0,
);
}
Map<String, WidgetBuilder> _routes = <String, WidgetBuilder>{
"/alerts": (BuildContext context){
navContent = myBottomNavigationBar();
new Alerts();
},
"/login": (BuildContext context){
navContent = excludeBottomNavigationBar();
new LoginPage();
},
"/settings": (BuildContext context){
navContent = myBottomNavigationBar();
new Settings();
},
"/enroll": (BuildContext context){
navContent = myBottomNavigationBar();
new Enroll();
},
"/add_device": (BuildContext context){
navContent = myBottomNavigationBar();
new AddDevice();
},
"/history": (BuildContext context){
navContent = myBottomNavigationBar();
new History();
},
"/home": (BuildContext context){
navContent = myBottomNavigationBar();
new Home();
},
"/device_settings": (BuildContext context){
navContent = myBottomNavigationBar();
new DeviceSettings()
},
"/geofence_list": (BuildContext context){
navContent = myBottomNavigationBar();
new GeofenceList()
},
"/draw_geofence": (BuildContext context){
navContent = myBottomNavigationBar();
new DrawGeofence()
},
};
runApp(new MaterialApp(
navigatorKey: navigator,
home: new SplashScreen(),
builder: (context, child) {
return new Scaffold(
body: child,
bottomNavigationBar:navContent,
resizeToAvoidBottomPadding: false
);
},
theme: buildTheme(),
routes: _routes,
));
}
5 ответов
Возможно, вы захотите проверить это: определение различий между различными типами управляемых компонентов JSF .
Вот описание различных типов компонентов, как определено в приведенная выше статья Нила Гриффина:
- Управляемый компонент модели : Обычно объем сеанса. Этот тип управляемого bean-компонента участвует в проблеме «Модель» шаблона проектирования MVC. Когда вы видите слово «модель» - думайте ДАННЫЕ. Бин-модель JSF должен быть POJO, который следует шаблону проектирования JavaBean с инкапсулирующими свойствами геттеров / сеттеров. Наиболее распространенный вариант использования модельного bean-компонента - это быть объектом базы данных или просто представлять набор строк из набора результатов запроса к базе данных.
- Поддержка Managed-Bean : Обычно область запроса . Этот тип управляемого компонента участвует в функции «Просмотр» шаблона проектирования MVC. Назначение компонента поддержки - поддерживать логику пользовательского интерфейса и имеет отношение 1 :: 1 с представлением JSF или формой JSF в композиции Facelet. Хотя он обычно имеет свойства в стиле JavaBean со связанными с ними геттерами / сеттерами, это свойства представления, а не базовой модели данных приложения. Компоненты поддержки JSF могут также иметь методы JSF actionListener и valueChangeListener.
- Управляемый компонент контроллера : Обычно область запроса. Этот тип управляемого bean-компонента участвует в «контроллере» шаблона проектирования MVC. Назначение bean-компонента контроллера - выполнить некую бизнес-логику и вернуть результат навигации обработчику навигации JSF. Бины-контроллеры JSF обычно имеют методы действий JSF (а не методы actionListener).
- Поддержка управляемого компонента : Обычно сеанс или область приложения. Этот тип bean-компонента "поддерживает" одно или несколько представлений в отношении "View" шаблона проектирования MVC. Типичный вариант использования - это предоставление в JSF раскрывающихся списков h: selectOneMenu ArrayList, которые появляются более чем в одном представлении JSF. Если данные в раскрывающихся списках относятся к конкретному пользователю, то компонент будет храниться в области сеанса. Однако, если данные применяются ко всем пользователям (например, раскрывающиеся списки провинций), то компонент будет храниться в области действия приложения, чтобы его можно было кэшировать для всех пользователей.
- Utility Managed-Bean : Обычно область применения. Этот тип bean-компонента предоставляет некоторую "полезность" для одного или нескольких представлений JSF. Хорошим примером этого может быть bean-компонент FileUpload, который можно повторно использовать в нескольких веб-приложениях.
Я не мог бы ответить на каждый ваш вопрос, потому что мало кто, кажется, вполне зависит от случая к случаю.
Это хорошо иметь бизнес-логику в своем бобе поддержки. Это зависит от того, откуда ты. Если вы практикуете проектирование на основе предметной области, у вас будет соблазн включить бизнес-логику в компонент поддержки или может быть логикой персистентности. Они утверждают, что почему такой тупой объект. Объект должен нести не только состояние, но и поведение. С другой стороны, если вы рассматриваете традиционный способ выполнения действий в Java EE, у вас может возникнуть ощущение, что вы должны иметь данные в своем компоненте поддержки, который также может быть вашим компонентом управления сущностями, и другую логику ведения бизнеса и персистентности в каком-либо компоненте сеанса или что-то еще. Это тоже хорошо.
Совершенно хорошо иметь один боб для всей страницы. Я не вижу никаких проблем с этим одним. Это может показаться неправильным, но это зависит от случая.
Ваш другой вопрос гораздо больше зависит от случая, который вы имеете в руках. Я бы предпочел использовать здесь домен, возможно, было бы целесообразно добавить свойства к существующему или иным образом создать новый компонент для этого. Который когда-либо подходит лучше. Я не думаю, что для этого есть какая-то серебряная пуля.
Каким свойствам принадлежит какой боб. Ну разве это не зависит от предметной области? Или, может быть, вопрос не так ясен.
Более того, в приведенном вами примере кода я не вижу какой-либо огромной выгоды.
Который когда-либо подходит лучше. Я не думаю, что для этого есть какая-то серебряная пуля.Каким свойствам принадлежит какой боб. Ну разве это не зависит от предметной области? Или, может быть, вопрос не так ясен.
Более того, в приведенном вами примере кода я не вижу какой-либо огромной выгоды.
Который когда-либо подходит лучше. Я не думаю, что для этого есть какая-то серебряная пуля.Каким свойствам принадлежит какой боб. Ну разве это не зависит от предметной области? Или, может быть, вопрос не так ясен.
Более того, в приведенном вами примере кода я не вижу какой-либо огромной выгоды.
I would not necessary keep only one backing bean per page. It depends on functionality but most of the time I had one bean per page as mostly one page handle one functionality. For example on a page I have a register link (I will link with RegisterBean) and a shopping basket link (ShoopingBasketBean).
I do use this <:outputText value="#{myBean.anObject.anObjectProperty}" /> as I normally keep backing beans as action beans which holds data object. I don't want to write a wrapper in my backing bean to access the properties of my data objects.
Отличный вопрос. Я много страдал с той же дилеммой, когда перешел в JSF. Это действительно зависит от вашего приложения. Я из мира Java EE, поэтому я бы рекомендовал иметь как можно меньше бизнес-логики в ваших бинах. Если логика связана исключительно с представлением вашей страницы, тогда хорошо иметь ее в бэк-бине.
Я полагаю, что одна из (многих) сильных сторон JSF на самом деле заключается в том, что вы можете напрямую выставлять доменные объекты на управляемых бобах. Поэтому я настоятельно рекомендую подход <: outputText value = "# {myBean.anObject.anObjectProperty}" /> , в противном случае вы в конечном итоге создаете слишком много работы для себя, вручную выставляя каждое свойство. Кроме того, было бы немного беспорядочно при вставке или обновлении данных, если вы инкапсулировали все свойства. Существуют ситуации, когда одного объекта домена может быть недостаточно. В этих случаях я подготавливаю ValueObject перед тем, как выставлять его в bean-компоненте.
РЕДАКТИРОВАТЬ: На самом деле, если вы собираетесь инкапсулировать каждое свойство объекта, которое вы хотите представить, я бы рекомендовал вместо этого связать пользовательский интерфейс компоненты в базовый компонент, а затем вводят содержимое непосредственно в значение компонента.
С точки зрения структуры компонента, поворотным моментом для меня было то, что я принудительно проигнорировал все, что я знал о создании веб-приложений, и начал рассматривать его как приложение с графическим интерфейсом вместо. JSF имитирует Swing, и поэтому лучшие практики для разработки приложений на Swing в основном применимы и к созданию приложений JSF.
Я думаю, что самое важное с вашими бобами - разделить их логику. Если у вас есть первая страница для системы CMS, я бы посчитал плохой практикой помещать каждый кусок кода в один компонент, потому что:
- компонент в конечном итоге станет очень большим
- другим людям будет легче найти то, что их искать, если они устраняют неполадки на странице входа в систему, если они могут легко найти файл loginBean.java.
- Иногда у вас есть небольшие функциональные возможности, которые явно отличаются от остальной части вашего кода. Разделив это, я бы подумал, что вам будет проще перестроить / развернуть этот код в нечто большее, когда у вас уже есть хороший боб с хорошей структурой.
- Имея 1 большой боб, чтобы сделать все это, сделает его более зависимым от памяти, если / когда вы должны будете делать объявления вроде этого MyBigBean bigBean = new MyBigBean (); вместо того, чтобы использовать funksjonality, который вам действительно нужен, выполнив LoginBean loginBean = new LoginBean (); (Поправьте меня, если я здесь не прав ???)
- По моему мнению, разделение ваших бобов похоже на разделение ваших методов. Вам не нужен 1 большой метод, который запускает более 100 строк, а лучше разделить его с помощью новых методов, выполняющих их конкретные задачи.
- Помните, что, скорее всего, кому-то другому, кроме вас, придется работать над вашими проектами JSF.
] Что касается связывания, я не рассматриваю это как проблемную проблему, позволяющую вашим страницам JSF также обращаться к свойствам объектов вашего бэк-бина. Это поддержка, встроенная в JSF, которая на самом деле облегчает чтение и сборку imo. Вы уже строго разделяете логику MVC. Делая это, вы экономите тонны линий с помощью геттеров и сеттеров в своем бэкане. Например, у меня есть действительно огромный объект, данный мне веб-сервисами, где мне нужно использовать некоторые свойства в моей презентации. Если бы я должен был создать метод получения / установки для каждого свойства, мой компонент расширился бы еще как минимум на 100 строк переменных и методов для получения свойств. Используя встроенную функциональность JSF, мое время и драгоценные строки кода экономятся.
Только мои 2 цента за это, даже если вопрос уже помечен как ответ.