WEBVTT

1
00:00:00.080 --> 00:00:04.040
<v Speaker 1>Okay, let's untack this. Welcome to the deep dive. We're

2
00:00:04.080 --> 00:00:06.879
<v Speaker 1>all about taking complex topics, cutting through the noise, and

3
00:00:06.919 --> 00:00:12.519
<v Speaker 1>really giving you those vital insights quickly, thoroughly, and hopefully

4
00:00:12.519 --> 00:00:15.839
<v Speaker 1>without that feeling of being overwhelmed. Exactly today we're diving

5
00:00:15.880 --> 00:00:19.000
<v Speaker 1>deep into Java MVC one point zero. It's well, it's

6
00:00:19.000 --> 00:00:22.239
<v Speaker 1>a pretty foundational design pattern, really critical if you're building

7
00:00:22.719 --> 00:00:27.120
<v Speaker 1>modern web apps, cloud services, even micro services. And our

8
00:00:27.120 --> 00:00:30.800
<v Speaker 1>guy for this is Peter Spieth's excellent book Beginning Java

9
00:00:30.920 --> 00:00:32.039
<v Speaker 1>Mvc one point zero.

10
00:00:32.159 --> 00:00:35.000
<v Speaker 2>Yeah, it's exciting stuff because we're not just looking at,

11
00:00:35.079 --> 00:00:38.119
<v Speaker 2>you know, a technology, We're digging into a fundamental design pattern,

12
00:00:38.439 --> 00:00:41.439
<v Speaker 2>one with some serious history behind it. Our goal here

13
00:00:41.520 --> 00:00:44.399
<v Speaker 2>is to give you a clear, kind of structured understanding

14
00:00:44.439 --> 00:00:46.799
<v Speaker 2>of Java mvc. What are the core pieces? How does

15
00:00:46.840 --> 00:00:49.240
<v Speaker 2>it fit into the whole Java enterprise world. Yeah, and

16
00:00:49.280 --> 00:00:52.079
<v Speaker 2>you should walk away with some practical insights, not just

17
00:00:52.159 --> 00:00:55.000
<v Speaker 2>the what, but the why? Why does this pattern even matter?

18
00:00:55.200 --> 00:00:56.840
<v Speaker 2>What does the lit developers actually do?

19
00:00:57.079 --> 00:01:00.640
<v Speaker 1>Absolutely? So, let's start big picture model. You control NBC.

20
00:01:00.840 --> 00:01:04.519
<v Speaker 1>It's not just Java, right, it's this fundamental software design pattern.

21
00:01:04.760 --> 00:01:05.719
<v Speaker 2>Oh yeah, fundamental.

22
00:01:05.879 --> 00:01:10.359
<v Speaker 1>It breaks down complex apps into three distinct roles, three

23
00:01:10.400 --> 00:01:12.959
<v Speaker 1>interconnected pieces. Think of it like I don't know a

24
00:01:13.000 --> 00:01:17.239
<v Speaker 1>well oiled machine, where each part has a specific job.

25
00:01:17.480 --> 00:01:18.280
<v Speaker 2>A good analogy.

26
00:01:18.480 --> 00:01:20.319
<v Speaker 1>So at the core you've got the model. This is

27
00:01:20.359 --> 00:01:23.959
<v Speaker 1>all about the application data, specifically the data the user

28
00:01:24.079 --> 00:01:27.280
<v Speaker 1>sees and might change. Right the state and the key

29
00:01:27.319 --> 00:01:30.280
<v Speaker 1>thing is the model is totally ignorant. It has no

30
00:01:30.400 --> 00:01:34.640
<v Speaker 1>idea how that data gets presented or how the application flows.

31
00:01:34.680 --> 00:01:36.599
<v Speaker 1>It's just the data, the source of truth.

32
00:01:36.760 --> 00:01:40.799
<v Speaker 2>Agnostic that's the word often used. It's data centric, not

33
00:01:40.959 --> 00:01:41.920
<v Speaker 2>presentation aware.

34
00:01:42.040 --> 00:01:44.879
<v Speaker 1>Then you have the view, Its job is purely presentation.

35
00:01:45.120 --> 00:01:47.359
<v Speaker 1>How does the model's data look to the user? All

36
00:01:47.400 --> 00:01:50.959
<v Speaker 1>the interactive bits, inputs, buttons, menus. That's the view.

37
00:01:51.159 --> 00:01:54.239
<v Speaker 2>Could be a desktop gooi, a mobile app screen, or

38
00:01:54.599 --> 00:01:56.480
<v Speaker 2>most often for us, a webpage.

39
00:01:56.560 --> 00:01:59.920
<v Speaker 1>It's the user's window basically exactly. And finally, the controller.

40
00:02:00.079 --> 00:02:04.640
<v Speaker 1>This is the coordinator, the brains. Maybe it handles user input,

41
00:02:04.719 --> 00:02:07.159
<v Speaker 1>It talks to the model to get or update data,

42
00:02:07.200 --> 00:02:10.800
<v Speaker 1>contains the application logic, calculations, data transformations, that kind of.

43
00:02:10.759 --> 00:02:14.919
<v Speaker 2>Thing, And crucially it decides how data gets stored or retrieved,

44
00:02:15.080 --> 00:02:16.639
<v Speaker 2>maybe from a database.

45
00:02:16.360 --> 00:02:19.000
<v Speaker 1>Right, But it doesn't care about how the view looks.

46
00:02:19.199 --> 00:02:22.520
<v Speaker 1>Its job is managing the flow, not painting.

47
00:02:22.159 --> 00:02:25.000
<v Speaker 2>The picture precisely keeps things separate.

48
00:02:25.120 --> 00:02:27.520
<v Speaker 1>Okay, to make this more concrete, let's use this book

49
00:02:27.520 --> 00:02:30.039
<v Speaker 1>club example application from the book. We'll keep coming back

50
00:02:30.039 --> 00:02:30.280
<v Speaker 1>to it.

51
00:02:30.360 --> 00:02:30.879
<v Speaker 2>Good idea.

52
00:02:31.039 --> 00:02:35.479
<v Speaker 1>So in book Club, the books themselves, their rental status,

53
00:02:35.599 --> 00:02:38.800
<v Speaker 1>member details. All that stuff lives in the model.

54
00:02:39.639 --> 00:02:40.520
<v Speaker 2>The core entities.

55
00:02:40.599 --> 00:02:42.879
<v Speaker 1>The web page is showing search results, the member sign

56
00:02:42.960 --> 00:02:46.560
<v Speaker 1>up form, the menus that's all view, the user interface,

57
00:02:46.680 --> 00:02:49.039
<v Speaker 1>and the controller that's the logic that takes your search

58
00:02:49.080 --> 00:02:52.439
<v Speaker 1>request or updates a book status when you rent. It

59
00:02:52.479 --> 00:02:55.240
<v Speaker 1>fetches member info from the database and then decides which

60
00:02:55.319 --> 00:02:56.159
<v Speaker 1>view to show next.

61
00:02:56.400 --> 00:02:59.520
<v Speaker 2>It handles the doing part based on user actions.

62
00:02:59.240 --> 00:03:01.000
<v Speaker 1>Exactly the logic behind it all.

63
00:03:01.159 --> 00:03:03.919
<v Speaker 2>And if you connect this to the bigger picture, like

64
00:03:03.960 --> 00:03:06.520
<v Speaker 2>you said, NBC isn't new. It goes way back.

65
00:03:06.719 --> 00:03:08.840
<v Speaker 1>Yeah, you mentioned history, right back.

66
00:03:08.719 --> 00:03:12.199
<v Speaker 2>To the nineteen seventies small talk. Originally, it didn't get

67
00:03:12.240 --> 00:03:14.719
<v Speaker 2>the explicit MVC name until the late.

68
00:03:14.560 --> 00:03:16.639
<v Speaker 1>Eighties wow, seventies.

69
00:03:16.080 --> 00:03:18.520
<v Speaker 2>But it's real power. Well that became obvious in the

70
00:03:18.599 --> 00:03:22.680
<v Speaker 2>nineties with the Internet boom. The pattern adapted surprisingly well

71
00:03:22.719 --> 00:03:26.400
<v Speaker 2>to web applications, even though AHGTP is inherently stateless.

72
00:03:26.479 --> 00:03:29.360
<v Speaker 1>That statelessness is always the challenge, isn't it always?

73
00:03:29.520 --> 00:03:33.319
<v Speaker 2>And it led to specific Web NBC challenges like how

74
00:03:33.360 --> 00:03:36.400
<v Speaker 2>do you keep track of a user across multiple requests?

75
00:03:36.919 --> 00:03:39.840
<v Speaker 2>That's where sessions came in, usually managed by frameworks using

76
00:03:39.840 --> 00:03:43.360
<v Speaker 2>cookies okay? Or how do you cleanly get modeled data

77
00:03:43.360 --> 00:03:46.599
<v Speaker 2>into the view. Templating engines solve that thing things like

78
00:03:47.000 --> 00:03:48.080
<v Speaker 2>user dot first.

79
00:03:47.879 --> 00:03:49.840
<v Speaker 1>Name right, accessing the data easily, and.

80
00:03:49.759 --> 00:03:51.960
<v Speaker 2>How do you update the page? We moved from reloading

81
00:03:51.960 --> 00:03:55.560
<v Speaker 2>the entire page to partial updates using scripts like ajax,

82
00:03:55.960 --> 00:03:59.159
<v Speaker 2>much smoother. And while other patterns like MVVM came along,

83
00:03:59.520 --> 00:04:02.919
<v Speaker 2>often adding more automation for data binding, they still build

84
00:04:02.919 --> 00:04:05.840
<v Speaker 2>on that core MVC idea of separating concerns.

85
00:04:05.919 --> 00:04:09.360
<v Speaker 1>That's a great historical context. So if MVC is that old,

86
00:04:09.400 --> 00:04:12.439
<v Speaker 1>what makes Java MVC this JSR three seventy one the

87
00:04:12.479 --> 00:04:14.319
<v Speaker 1>modern choice for enterprise JABA.

88
00:04:14.080 --> 00:04:17.759
<v Speaker 2>Good question. Java MVC is the dedicated standardized framework for

89
00:04:17.879 --> 00:04:20.480
<v Speaker 2>Java EE eight and now Deakarta E eight and later.

90
00:04:21.240 --> 00:04:23.800
<v Speaker 2>It filled the gap many developers felt.

91
00:04:23.560 --> 00:04:25.120
<v Speaker 1>Was there a standard was needed?

92
00:04:25.240 --> 00:04:27.720
<v Speaker 2>Kind of yeah, And it's important to remember JSR three

93
00:04:27.680 --> 00:04:30.680
<v Speaker 2>to seventy one defines the interface. You need an implementation

94
00:04:31.040 --> 00:04:33.040
<v Speaker 2>like eclips Crazo to actually use it.

95
00:04:33.079 --> 00:04:35.560
<v Speaker 1>Okay, So it's a spec needs a library exactly.

96
00:04:35.959 --> 00:04:40.399
<v Speaker 2>And what's clever is how it extends JXRS, Java's RES technology.

97
00:04:40.600 --> 00:04:42.759
<v Speaker 2>It's built on jxrs.

98
00:04:42.160 --> 00:04:44.399
<v Speaker 1>Ah, so it leverages RES right.

99
00:04:44.480 --> 00:04:47.000
<v Speaker 2>That makes it lean, gives it a concise style, and

100
00:04:47.040 --> 00:04:49.240
<v Speaker 2>it means it plays really nicely with ajx out of

101
00:04:49.240 --> 00:04:52.560
<v Speaker 2>the box. Because it's already using JXRS for handling requests.

102
00:04:52.759 --> 00:04:56.360
<v Speaker 1>That JXRS connection seems key. Does that feed into the

103
00:04:56.399 --> 00:04:57.079
<v Speaker 1>pros and cons?

104
00:04:57.120 --> 00:05:02.079
<v Speaker 2>Definitely? The pros well. Being closer to HTT means potentially

105
00:05:02.199 --> 00:05:05.199
<v Speaker 2>less memory overhead compared to some component based framework that

106
00:05:05.240 --> 00:05:09.279
<v Speaker 2>build big UI trees in memory like JSF Maybe potentially, Yeah,

107
00:05:09.319 --> 00:05:11.199
<v Speaker 2>it can have a smaller footprint. Plus being part of

108
00:05:11.199 --> 00:05:15.800
<v Speaker 2>the Jakarta EE spec means reliability, maintenance, community support, okay, stability,

109
00:05:15.879 --> 00:05:19.120
<v Speaker 2>and if you've used older frameworks like struts, the action

110
00:05:19.240 --> 00:05:21.959
<v Speaker 2>based approach of Java MBC will feel pretty familiar.

111
00:05:22.120 --> 00:05:22.600
<v Speaker 1>Makes sense.

112
00:05:22.720 --> 00:05:26.040
<v Speaker 2>What about the downsides, Well, it doesn't totally hide HGTP.

113
00:05:26.480 --> 00:05:29.079
<v Speaker 2>You still need some awareness of requests response as.

114
00:05:28.959 --> 00:05:31.680
<v Speaker 1>Headers, so not quite as much abstraction.

115
00:05:31.519 --> 00:05:35.040
<v Speaker 2>Right, and it doesn't typically offer two way data binding

116
00:05:35.040 --> 00:05:37.399
<v Speaker 2>out of the box. If a user types in a

117
00:05:37.480 --> 00:05:40.839
<v Speaker 2>form you the developer usually need to write code in

118
00:05:40.879 --> 00:05:43.360
<v Speaker 2>the controller to explicitly update the model.

119
00:05:43.480 --> 00:05:46.720
<v Speaker 1>Ah okay, so a more manual work there compared to

120
00:05:46.720 --> 00:05:47.480
<v Speaker 1>some other frameworks.

121
00:05:47.560 --> 00:05:50.519
<v Speaker 2>Potentially, Yes, it's a trade off more control, maybe a

122
00:05:50.519 --> 00:05:53.160
<v Speaker 2>bit more boilerplate. In some cases. It's about balancing that

123
00:05:53.240 --> 00:05:55.680
<v Speaker 2>abstraction versus control over HTTP.

124
00:05:56.079 --> 00:05:59.680
<v Speaker 1>So when would that extra control be a real advantage

125
00:05:59.720 --> 00:06:01.920
<v Speaker 1>and when might it just be extra work?

126
00:06:02.040 --> 00:06:05.199
<v Speaker 2>Great point. You benefit most when you need really fine

127
00:06:05.240 --> 00:06:09.040
<v Speaker 2>grain control over the HTTP request response. Maybe you're building

128
00:06:09.079 --> 00:06:12.839
<v Speaker 2>complex rest APIs that also serve htmail pages or highly

129
00:06:12.839 --> 00:06:16.680
<v Speaker 2>optimize micro services. The flexibility is powerful. Then the drawback

130
00:06:16.720 --> 00:06:18.800
<v Speaker 2>if you just want something super high level where the

131
00:06:18.800 --> 00:06:22.160
<v Speaker 2>framework does almost everything automatically. Maybe for simpler cru'd apps.

132
00:06:22.279 --> 00:06:24.680
<v Speaker 2>It depends on the project control versus speeded development.

133
00:06:24.720 --> 00:06:27.120
<v Speaker 1>Sometimes that makes a lot of sense. Okay, let's talk

134
00:06:27.120 --> 00:06:31.480
<v Speaker 1>about the foundation. Java NVC doesn't just run anywhere, right,

135
00:06:31.560 --> 00:06:35.839
<v Speaker 1>It needs that Java Enterprise Edition Server environment Java EE

136
00:06:36.199 --> 00:06:36.879
<v Speaker 1>or Jakarta E.

137
00:06:37.199 --> 00:06:40.000
<v Speaker 2>Absolutely, it relies on that infrastructure.

138
00:06:39.319 --> 00:06:41.399
<v Speaker 1>And Java itself. Well, it's been the go to for

139
00:06:41.560 --> 00:06:47.000
<v Speaker 1>enterprise apps, for ages, stability, database connections, talking to other systems,

140
00:06:47.040 --> 00:06:49.959
<v Speaker 1>handling complex logic. It's built for that scale and just

141
00:06:50.000 --> 00:06:53.120
<v Speaker 1>for context. Java started with Sun, went through j to EE,

142
00:06:53.319 --> 00:06:56.560
<v Speaker 1>then JG and now Jakarta E under the Eclipse Foundation.

143
00:06:56.959 --> 00:06:59.800
<v Speaker 1>We're focusing on Jakarta E eight and Java eight features

144
00:06:59.800 --> 00:07:00.360
<v Speaker 1>here right.

145
00:07:00.399 --> 00:07:03.279
<v Speaker 2>And the key is that Jakarta E provides this whole

146
00:07:03.279 --> 00:07:06.519
<v Speaker 2>ecosystem Java MVC plugs into. It's not standalone.

147
00:07:06.560 --> 00:07:08.839
<v Speaker 1>What are the key pieces it relies on Well.

148
00:07:08.759 --> 00:07:13.800
<v Speaker 2>JXRS, as we said, innovational, then JPA, the Java Persistence

149
00:07:13.839 --> 00:07:17.040
<v Speaker 2>API for database access handles all the tricky SQL stuff.

150
00:07:16.800 --> 00:07:19.439
<v Speaker 1>Usually OHRM right, Object relational mapping.

151
00:07:19.240 --> 00:07:23.199
<v Speaker 2>Exactly and critically CDI context and dependency injection. That's how

152
00:07:23.279 --> 00:07:26.160
<v Speaker 2>Java MVC manages beans their life cycles. It's core.

153
00:07:26.360 --> 00:07:27.680
<v Speaker 1>CDI sounds important.

154
00:07:27.839 --> 00:07:32.120
<v Speaker 2>It is plus being validation for data integrity and for learning.

155
00:07:32.360 --> 00:07:36.279
<v Speaker 2>The book recommends GlassFish Server version five point one, open source,

156
00:07:36.600 --> 00:07:37.600
<v Speaker 2>free group.

157
00:07:37.399 --> 00:07:39.879
<v Speaker 1>Of development, and you can manage GlassFish different ways.

158
00:07:39.959 --> 00:07:45.279
<v Speaker 2>Yeah, command line, a Sadman, WEBGUI, even Arrest API pretty flexible.

159
00:07:45.439 --> 00:07:49.399
<v Speaker 1>Okay, foundation set. Let's dive back into the MVC components,

160
00:07:49.480 --> 00:07:53.879
<v Speaker 1>but specifically the Java MVC way, starting with the model

161
00:07:54.079 --> 00:07:55.759
<v Speaker 1>and that CDI thing you mentioned.

162
00:07:55.639 --> 00:07:58.800
<v Speaker 2>Right, So Java MVC uses CDI two point zero to

163
00:07:58.879 --> 00:08:01.839
<v Speaker 2>manage your model classes. Yeah, you typically don't do new

164
00:08:01.920 --> 00:08:05.160
<v Speaker 2>my model. CDI handles creating and providing instances.

165
00:08:05.319 --> 00:08:06.959
<v Speaker 1>How does it know which classes to manage?

166
00:08:07.120 --> 00:08:10.279
<v Speaker 2>Usually annotate them. The simplest is that named You put

167
00:08:10.279 --> 00:08:12.720
<v Speaker 2>it named on your Java being, say your book class,

168
00:08:12.720 --> 00:08:15.279
<v Speaker 2>and CDI takes over makes it available to your views.

169
00:08:15.319 --> 00:08:17.000
<v Speaker 1>Okay, annotation magic pretty much.

170
00:08:17.439 --> 00:08:20.279
<v Speaker 2>And CDI manages the lifespan of these objects through scopes.

171
00:08:20.439 --> 00:08:22.279
<v Speaker 1>This is really important to the copes, like how long the

172
00:08:22.319 --> 00:08:23.480
<v Speaker 1>data lasts exactly.

173
00:08:23.600 --> 00:08:27.199
<v Speaker 2>There's request scope, a new instance for every single HTTP

174
00:08:27.360 --> 00:08:30.839
<v Speaker 2>request lives only for that request response cycle. Good perfect

175
00:08:30.839 --> 00:08:33.159
<v Speaker 2>for temporary stuff like the data submitted in a form.

176
00:08:33.399 --> 00:08:36.480
<v Speaker 2>Then session scope, the instance sticks around for the user's

177
00:08:36.600 --> 00:08:41.480
<v Speaker 2>entire browser session. Great for things like user login information, shopping.

178
00:08:41.080 --> 00:08:43.919
<v Speaker 1>Cards, data that needs to persist across pages for one

179
00:08:44.039 --> 00:08:45.080
<v Speaker 1>user precisely.

180
00:08:45.639 --> 00:08:48.679
<v Speaker 2>Then there's redirect scope. This one's need. It supports that

181
00:08:48.720 --> 00:08:50.559
<v Speaker 2>post redirect get pattern.

182
00:08:50.279 --> 00:08:52.960
<v Speaker 1>Ah to stop double form submission exactly.

183
00:08:53.200 --> 00:08:56.279
<v Speaker 2>The object lives across the post request and the following

184
00:08:56.320 --> 00:08:58.279
<v Speaker 2>get t redirect super useful.

185
00:08:58.240 --> 00:08:59.600
<v Speaker 1>It definitely needed that before.

186
00:08:59.639 --> 00:09:02.919
<v Speaker 2>Oh yeah, there's also application scope for data shared across

187
00:09:02.919 --> 00:09:06.919
<v Speaker 2>all users living until the app stops, and dependent scope

188
00:09:06.960 --> 00:09:09.960
<v Speaker 2>the default, which just inherits the scope of whatever injects it.

189
00:09:10.200 --> 00:09:12.799
<v Speaker 1>Lots of options. What if you need something really simple.

190
00:09:12.720 --> 00:09:15.159
<v Speaker 2>For quick things, there's a built in Javacs dot mvc

191
00:09:15.320 --> 00:09:18.039
<v Speaker 2>dot model's object you can inject into your controller. Just

192
00:09:18.080 --> 00:09:20.279
<v Speaker 2>add key value pairs to it and they're available in

193
00:09:20.279 --> 00:09:22.399
<v Speaker 2>the view. No need for a dedicated class.

194
00:09:22.399 --> 00:09:25.799
<v Speaker 1>Sometimes handy for simple cases. Okay, so CDI managed the

195
00:09:25.799 --> 00:09:27.840
<v Speaker 1>model data in its life, Now how do we show

196
00:09:27.840 --> 00:09:28.639
<v Speaker 1>it the view?

197
00:09:28.919 --> 00:09:32.960
<v Speaker 2>Right? The view layer. Java MVC mainly uses two templating

198
00:09:33.000 --> 00:09:37.279
<v Speaker 2>technologies here, JSPS, Java server pages and facelets.

199
00:09:37.360 --> 00:09:39.120
<v Speaker 1>JSPS are the older ones, right.

200
00:09:39.320 --> 00:09:43.159
<v Speaker 2>Yeah, classic. You mix HTML with dynamic bits the modern way,

201
00:09:43.320 --> 00:09:46.279
<v Speaker 2>and what the source recommends is using expression language el

202
00:09:46.480 --> 00:09:47.679
<v Speaker 2>that syntax.

203
00:09:47.279 --> 00:09:48.799
<v Speaker 1>Like dumb butt title exactly.

204
00:09:49.320 --> 00:09:52.000
<v Speaker 2>Access is your CDI beans cleanly. You should also use

205
00:09:52.039 --> 00:09:55.519
<v Speaker 2>JSDL tags like CT ORH for loops set to different conditions.

206
00:09:56.240 --> 00:10:01.879
<v Speaker 2>Avoid embedding raw javascriptlets percent jsps. If you can keep

207
00:10:02.000 --> 00:10:05.080
<v Speaker 2>logic out of the view, keep it clean definitely, and

208
00:10:05.120 --> 00:10:08.240
<v Speaker 2>the source really advises against using implicit objects like param

209
00:10:08.480 --> 00:10:11.679
<v Speaker 2>directly in the view that mixes controller responsibilities with presentation.

210
00:10:12.159 --> 00:10:13.159
<v Speaker 2>Bad idea, Got it?

211
00:10:13.320 --> 00:10:14.279
<v Speaker 1>What about facelts.

212
00:10:14.480 --> 00:10:17.360
<v Speaker 2>Facelits is newer xmail based came from the JSF world

213
00:10:17.519 --> 00:10:22.360
<v Speaker 2>Livesten webi nfus. Its strength is templating reasonable layouts using

214
00:10:22.360 --> 00:10:26.200
<v Speaker 2>tags like EI dot composition, uid, define, UI dot insert

215
00:10:26.519 --> 00:10:28.519
<v Speaker 2>really good for consistent page structure.

216
00:10:28.200 --> 00:10:30.399
<v Speaker 1>Sounds powerful any catches yes, a.

217
00:10:30.360 --> 00:10:33.519
<v Speaker 2>Big one for Java MBC. While facelts is great for templates.

218
00:10:33.559 --> 00:10:36.840
<v Speaker 2>You should avoid mixing in actual JSF components or using

219
00:10:36.919 --> 00:10:41.080
<v Speaker 2>JSS specific expression language. Why is that paradigm mismatch? JSF

220
00:10:41.080 --> 00:10:44.039
<v Speaker 2>has its own life cycling component model. Trying to shoehorn

221
00:10:44.080 --> 00:10:47.639
<v Speaker 2>that into Java mvc's request driven model can cause weird

222
00:10:47.679 --> 00:10:51.519
<v Speaker 2>issues in instability. Stick to facelets for templating, use standard

223
00:10:51.600 --> 00:10:53.600
<v Speaker 2>EEL for data access in Java mvc.

224
00:10:53.960 --> 00:10:57.159
<v Speaker 1>Okay, noted, keep JSF stuff out of Java mvc.

225
00:10:57.279 --> 00:11:00.559
<v Speaker 2>Facelts Right now, the controller, how do you make one annotations?

226
00:11:00.600 --> 00:11:00.840
<v Speaker 1>Again?

227
00:11:00.879 --> 00:11:03.759
<v Speaker 2>You bet at controller on the class, usually paired with

228
00:11:03.879 --> 00:11:07.840
<v Speaker 2>at path to define the base URL like at path books.

229
00:11:07.639 --> 00:11:10.840
<v Speaker 1>Okay, and methods handle requests YEP.

230
00:11:11.120 --> 00:11:13.759
<v Speaker 2>For a get request, say to show a list of books.

231
00:11:13.960 --> 00:11:15.799
<v Speaker 2>A method might return a string the name of the

232
00:11:15.879 --> 00:11:20.200
<v Speaker 2>JSP or Facebook file like booklist dot jsp simple, or

233
00:11:20.320 --> 00:11:23.080
<v Speaker 2>for more control, it can return a response object that

234
00:11:23.159 --> 00:11:26.679
<v Speaker 2>lets you set h GDP status codes, headers, cookies explicitly.

235
00:11:26.919 --> 00:11:28.600
<v Speaker 1>Ah more power there, and.

236
00:11:28.519 --> 00:11:31.919
<v Speaker 2>The final URL path is built up application path class

237
00:11:31.960 --> 00:11:34.799
<v Speaker 2>at path method at path all cancatenated makes sense.

238
00:11:34.840 --> 00:11:36.919
<v Speaker 1>How does the controller prepared data for the view?

239
00:11:37.159 --> 00:11:39.919
<v Speaker 2>It injects the needed CDI beans the model objects using

240
00:11:39.960 --> 00:11:42.679
<v Speaker 2>it inject that, it calls methods on them, sets values

241
00:11:42.679 --> 00:11:44.639
<v Speaker 2>whatever is needed before the view gets rendered.

242
00:11:44.919 --> 00:11:47.320
<v Speaker 1>Okay, and post requests like.

243
00:11:47.279 --> 00:11:51.759
<v Speaker 2>Forms handled similarly, but you use annotations like at form

244
00:11:51.799 --> 00:11:55.960
<v Speaker 2>paarent book title within the method arguments to grab the

245
00:11:56.039 --> 00:11:57.200
<v Speaker 2>submitted data directly.

246
00:11:57.279 --> 00:12:00.240
<v Speaker 1>Okay, that covers the core components. What about making is

247
00:12:00.240 --> 00:12:03.919
<v Speaker 1>more robust handling user input validation crucial stuff?

248
00:12:03.919 --> 00:12:07.879
<v Speaker 2>So you capture data from forms or query parameters. Now

249
00:12:07.919 --> 00:12:10.639
<v Speaker 2>what if the user types letters into a number field

250
00:12:11.360 --> 00:12:12.840
<v Speaker 2>or leave something blank.

251
00:12:13.440 --> 00:12:14.120
<v Speaker 1>Errors happen?

252
00:12:14.320 --> 00:12:18.000
<v Speaker 2>Right? Java MBC uses binding result. You audit as a

253
00:12:18.039 --> 00:12:21.600
<v Speaker 2>parameter to your controller method. It automatically catches conversion errors

254
00:12:21.679 --> 00:12:24.639
<v Speaker 2>or validation failures, and then you can check binding result

255
00:12:24.720 --> 00:12:27.399
<v Speaker 2>for errors. If there are any. You typically add the

256
00:12:27.399 --> 00:12:29.919
<v Speaker 2>air messages to the model's object and return to the

257
00:12:29.919 --> 00:12:32.080
<v Speaker 2>same view showing the user what went wrong.

258
00:12:32.200 --> 00:12:33.559
<v Speaker 1>Nice keeps them on the form.

259
00:12:33.519 --> 00:12:36.799
<v Speaker 2>Exactly and being validation makes this even better. You put

260
00:12:36.840 --> 00:12:39.320
<v Speaker 2>annotations right on your controller method parameters or on your

261
00:12:39.320 --> 00:12:42.279
<v Speaker 2>model bean fields at notinal at size and five at

262
00:12:42.279 --> 00:12:45.320
<v Speaker 2>pattern Reex built in rules loads of them, and you

263
00:12:45.320 --> 00:12:48.279
<v Speaker 2>can create custom ones too. Plus you can easily internationalize

264
00:12:48.279 --> 00:12:52.120
<v Speaker 2>the error messages using validation messages dot properties files, so

265
00:12:52.240 --> 00:12:54.080
<v Speaker 2>error messages appear in the user's language.

266
00:12:54.159 --> 00:12:58.159
<v Speaker 1>Very professional. Okay, what about state you mentioned sessions earlier.

267
00:12:57.879 --> 00:13:02.360
<v Speaker 2>Yeah, persisting state. HTTP is stateless, but web apps aren't.

268
00:13:02.960 --> 00:13:05.679
<v Speaker 2>We need to remember things about a user between requests.

269
00:13:06.200 --> 00:13:08.360
<v Speaker 2>HTTP session is the standard.

270
00:13:08.039 --> 00:13:10.200
<v Speaker 1>Javaway managed by the server YEP.

271
00:13:10.200 --> 00:13:13.080
<v Speaker 2>Usually via cookies behind the scenes. Java MBC makes this

272
00:13:13.159 --> 00:13:16.879
<v Speaker 2>easy with at session scope CDI beans. Just inject your

273
00:13:16.919 --> 00:13:20.440
<v Speaker 2>ad session scope user preferences being and its data sticks

274
00:13:20.440 --> 00:13:23.600
<v Speaker 2>around for that user. Session. Seems convenient, it is, but

275
00:13:23.960 --> 00:13:28.679
<v Speaker 2>big caveat. Don't stuff everything into the session, especially large

276
00:13:28.679 --> 00:13:31.000
<v Speaker 2>objects or lots of data per user. If you have

277
00:13:31.120 --> 00:13:32.360
<v Speaker 2>thousands of users.

278
00:13:32.039 --> 00:13:34.480
<v Speaker 1>Online, memory usage explodes exactly.

279
00:13:34.639 --> 00:13:37.519
<v Speaker 2>It can kill your server's performance and stability. Use session

280
00:13:37.600 --> 00:13:40.759
<v Speaker 2>scope judiciously only for data that truly needs to persist

281
00:13:40.879 --> 00:13:41.840
<v Speaker 2>for the session duration.

282
00:13:42.039 --> 00:13:44.519
<v Speaker 1>Good warning. What about making the UI more dynamic? You

283
00:13:44.559 --> 00:13:46.559
<v Speaker 1>mentioned AJX.

284
00:13:46.080 --> 00:13:49.919
<v Speaker 2>Right AGX asynchronous JavaScript in XML, though nowadays it's off

285
00:13:49.919 --> 00:13:52.960
<v Speaker 2>in JSON not XML. The idea is the browser uses

286
00:13:53.039 --> 00:13:55.879
<v Speaker 2>JavaScript to make background requests to the server without a

287
00:13:55.919 --> 00:13:56.960
<v Speaker 2>full page reload.

288
00:13:57.279 --> 00:13:59.200
<v Speaker 1>Smoother experience, much smoother.

289
00:14:00.039 --> 00:14:02.799
<v Speaker 2>Mber Is like jQuery made this easier, but modern JavaScript

290
00:14:02.799 --> 00:14:06.759
<v Speaker 2>has fetch api built in Your Java mvc controller can

291
00:14:06.799 --> 00:14:10.399
<v Speaker 2>handle these AJAX requests. Instead of returning a full page name,

292
00:14:10.639 --> 00:14:12.960
<v Speaker 2>it might return just an h T Mel fragment or

293
00:14:12.960 --> 00:14:13.919
<v Speaker 2>maybe Jason data.

294
00:14:13.960 --> 00:14:16.600
<v Speaker 1>Okay, so the controller can serve both full pages and

295
00:14:16.879 --> 00:14:18.399
<v Speaker 1>AJX snippets.

296
00:14:18.440 --> 00:14:21.519
<v Speaker 2>Absolutely. The JavaScript on the front end then takes that

297
00:14:21.600 --> 00:14:24.039
<v Speaker 2>response and updates just the relevant part of the page,

298
00:14:24.039 --> 00:14:26.960
<v Speaker 2>maybe updates account, refreshes, a list, shows a status message.

299
00:14:27.039 --> 00:14:29.000
<v Speaker 1>Very cool. You also mentioned observers.

300
00:14:28.679 --> 00:14:31.360
<v Speaker 2>Yeah, CD observers. This is a really elegant way to

301
00:14:31.399 --> 00:14:36.440
<v Speaker 2>handle cross cutting concerns, things like logging, performance monitoring, security checks.

302
00:14:36.840 --> 00:14:38.840
<v Speaker 2>Stuff that needs to happen in response to events, but

303
00:14:38.960 --> 00:14:40.320
<v Speaker 2>isn't core business logic.

304
00:14:40.440 --> 00:14:41.240
<v Speaker 1>How does it work.

305
00:14:41.559 --> 00:14:44.120
<v Speaker 2>You create a method in a cdibing and annotate it

306
00:14:44.159 --> 00:14:47.799
<v Speaker 2>with at observes. You specify the event type you're interested in,

307
00:14:47.879 --> 00:14:50.720
<v Speaker 2>like maybe an event fired just before a controller method

308
00:14:50.840 --> 00:14:55.039
<v Speaker 2>runs bore controller event from javax dobc dot event ah.

309
00:14:55.080 --> 00:14:57.960
<v Speaker 1>So it listens for specific points in the process.

310
00:14:57.559 --> 00:15:02.120
<v Speaker 2>Exactly when that event happens, automatically calls your observer method.

311
00:15:02.879 --> 00:15:06.200
<v Speaker 2>It keeps that logging or monitoring code completely separate from

312
00:15:06.200 --> 00:15:08.840
<v Speaker 2>your controller logic. Really improves maintainability.

313
00:15:09.039 --> 00:15:12.519
<v Speaker 1>That separation of concerns again seems to be a running theme.

314
00:15:12.720 --> 00:15:15.679
<v Speaker 2>It's the theme of good architecture really, which brings us

315
00:15:15.679 --> 00:15:18.080
<v Speaker 2>to bigger enterprise integration like databases.

316
00:15:18.240 --> 00:15:22.360
<v Speaker 1>Right, how does Java MBC talk to a database JPA.

317
00:15:22.120 --> 00:15:26.360
<v Speaker 2>YEP JPA, Java persistence API the standard way in Jakarta EE.

318
00:15:26.840 --> 00:15:29.960
<v Speaker 2>It abstracts away most of the raw sequel uses orim

319
00:15:30.039 --> 00:15:31.200
<v Speaker 2>object relational mapping.

320
00:15:31.360 --> 00:15:34.720
<v Speaker 1>So your Java book object maps to a books table precisely.

321
00:15:34.840 --> 00:15:37.879
<v Speaker 2>You define this mapping using annotations at entity table at

322
00:15:37.960 --> 00:15:40.840
<v Speaker 2>iocolumn right on your Java class and you can figure

323
00:15:40.879 --> 00:15:43.759
<v Speaker 2>the database connection details in a persistence dot XML file.

324
00:15:43.919 --> 00:15:46.600
<v Speaker 1>And how do you actually interact with the data through.

325
00:15:46.399 --> 00:15:49.080
<v Speaker 2>The entity manager. You inject it, and it has methods

326
00:15:49.120 --> 00:15:54.919
<v Speaker 2>like find, persist, merge, remove. It handles translating those calls

327
00:15:54.919 --> 00:15:57.639
<v Speaker 2>into SQL. You'll also need to set up a database

328
00:15:57.679 --> 00:15:59.840
<v Speaker 2>like apatchy Derby and can figure a data source in

329
00:16:00.000 --> 00:16:01.080
<v Speaker 2>glass Fish okay.

330
00:16:01.080 --> 00:16:04.039
<v Speaker 1>So JPA handles the database mapping and interaction. What about

331
00:16:04.039 --> 00:16:08.080
<v Speaker 1>EJBs Enterprise Java beans EJBs.

332
00:16:07.440 --> 00:16:10.440
<v Speaker 2>Are components for business logic. They run in a container

333
00:16:10.480 --> 00:16:15.799
<v Speaker 2>that provides services like transactions, security, concurrency management automatically.

334
00:16:15.200 --> 00:16:17.000
<v Speaker 1>More than just plan Java objects right.

335
00:16:17.360 --> 00:16:20.919
<v Speaker 2>There are different types, mainly session EJBs. Stateless ones are common.

336
00:16:20.960 --> 00:16:24.000
<v Speaker 2>They don't hold client specific state between calls. Good for

337
00:16:24.039 --> 00:16:27.960
<v Speaker 2>service operations like processing a book rental okay. Stateful EJBs

338
00:16:28.000 --> 00:16:30.759
<v Speaker 2>do maintain state across multiple calls from the same client.

339
00:16:31.440 --> 00:16:34.440
<v Speaker 2>Useful for multi step processes like a Wizard or complex

340
00:16:34.519 --> 00:16:38.200
<v Speaker 2>checkout Singleton. EJBs ensure only one instance exists for the

341
00:16:38.200 --> 00:16:41.480
<v Speaker 2>whole application. Good for cases or coordinating tasks.

342
00:16:41.639 --> 00:16:43.840
<v Speaker 1>How does your MBC controller use an EJB?

343
00:16:44.159 --> 00:16:47.320
<v Speaker 2>Usually just inject it Using an EJB, the container handles

344
00:16:47.320 --> 00:16:50.799
<v Speaker 2>providing the instance. EJBs also have cool features like at

345
00:16:50.840 --> 00:16:54.320
<v Speaker 2>asynchronous for background tasks and its schedule for time, jobs.

346
00:16:54.120 --> 00:16:58.519
<v Speaker 1>Powerful stuff and managing all this complexity, Logging must be vital.

347
00:16:58.320 --> 00:17:02.879
<v Speaker 2>Absolutely critical, and enterprise apps for debugging, auditing, just understanding

348
00:17:02.879 --> 00:17:06.839
<v Speaker 2>what's going on. GlassFish uses the standard JSR forty seven

349
00:17:06.960 --> 00:17:07.799
<v Speaker 2>logging API.

350
00:17:08.240 --> 00:17:09.920
<v Speaker 1>By default, where did the logs go?

351
00:17:10.160 --> 00:17:14.519
<v Speaker 2>Typically to server dot log. You have different levels severe warning, info, fine,

352
00:17:14.599 --> 00:17:17.319
<v Speaker 2>finer finance. You configure the level to control how much

353
00:17:17.359 --> 00:17:18.039
<v Speaker 2>detail you get.

354
00:17:18.119 --> 00:17:20.119
<v Speaker 1>Can you use other logging frameworks?

355
00:17:20.200 --> 00:17:23.640
<v Speaker 2>Yes. Log forg is a very popular, powerful alternative. It

356
00:17:23.680 --> 00:17:27.160
<v Speaker 2>separates the logging API from the implementation, can reload its

357
00:17:27.160 --> 00:17:30.640
<v Speaker 2>configuration without restarting the server. Lots of advantages. You can

358
00:17:30.640 --> 00:17:33.160
<v Speaker 2>integrate at server wide or just for your application.

359
00:17:33.440 --> 00:17:35.559
<v Speaker 1>Choosing the right logging level seems important.

360
00:17:35.759 --> 00:17:38.960
<v Speaker 2>It is too little, you can't debug too much. It

361
00:17:39.000 --> 00:17:42.279
<v Speaker 2>impacts performance. You need a strategy. What stands out here

362
00:17:42.400 --> 00:17:46.319
<v Speaker 2>is just how essential good logging is for maintaining complex systems.

363
00:17:46.359 --> 00:17:50.559
<v Speaker 1>Definitely so bringing it all together, this book club example

364
00:17:50.640 --> 00:17:52.359
<v Speaker 1>really uses all these pieces.

365
00:17:52.000 --> 00:17:54.039
<v Speaker 2>Doesn't it. It really does. It uses Derby as the

366
00:17:54.119 --> 00:17:58.880
<v Speaker 2>database configured in glass Fish. It has internationalization for messages,

367
00:17:59.400 --> 00:18:03.799
<v Speaker 2>It uses APA entities for member book rental. It uses

368
00:18:03.839 --> 00:18:09.319
<v Speaker 2>stateless EJBs as data access objects baos to handle the database.

369
00:18:08.920 --> 00:18:11.200
<v Speaker 1>Operations, okay, EJB's for the data logic.

370
00:18:11.279 --> 00:18:13.599
<v Speaker 2>Then it has simple CDI beans acting as the model

371
00:18:13.599 --> 00:18:16.960
<v Speaker 2>for the views. A central Java MVC controller manages all

372
00:18:17.000 --> 00:18:20.799
<v Speaker 2>the web interactions, and the views are jsps using fragments

373
00:18:20.839 --> 00:18:23.000
<v Speaker 2>and some JavaScript for those dynamic updates.

374
00:18:23.079 --> 00:18:25.680
<v Speaker 1>It's quite a good demonstration of how these seemingly separate

375
00:18:25.680 --> 00:18:30.680
<v Speaker 1>technologies MBC, CDI, JPA, EJB all integrate cleanly within the

376
00:18:30.759 --> 00:18:31.920
<v Speaker 1>Jakarta E platform.

377
00:18:32.079 --> 00:18:34.400
<v Speaker 2>Exactly. You see how a complex system gets built from

378
00:18:34.440 --> 00:18:36.000
<v Speaker 2>these well defined modular parts.

379
00:18:36.039 --> 00:18:38.279
<v Speaker 1>Okay, well, that feels like a pretty third journey through

380
00:18:38.400 --> 00:18:41.559
<v Speaker 1>Java Mvc one point zero. We started with the basic

381
00:18:41.640 --> 00:18:44.799
<v Speaker 1>MBC pattern, looked at Java NBC specifics under JSR three

382
00:18:44.839 --> 00:18:48.440
<v Speaker 1>seventy one, touched on its Jakarta E foundations.

383
00:18:48.240 --> 00:18:51.720
<v Speaker 2>Cover the component's model with CDI scopes, view a JSP

384
00:18:51.920 --> 00:18:55.279
<v Speaker 2>and facelooks, caveats, controller handling requests right.

385
00:18:55.279 --> 00:19:00.480
<v Speaker 1>And then validations, state management with sessions, AJAX observers, integrating

386
00:19:00.519 --> 00:19:04.920
<v Speaker 1>with JPA databases and EJBs, and finally logging strategies.

387
00:19:05.160 --> 00:19:06.200
<v Speaker 2>A comprehensive look.

388
00:19:06.319 --> 00:19:08.640
<v Speaker 1>So hopefully you now have a really solid grasp of

389
00:19:08.680 --> 00:19:11.480
<v Speaker 1>how Java NBC works and how you can use it

390
00:19:11.519 --> 00:19:17.480
<v Speaker 1>to build robust, scalable, maintainable applications, web cloud, micro services,

391
00:19:17.559 --> 00:19:17.920
<v Speaker 1>the lot.

392
00:19:18.400 --> 00:19:20.920
<v Speaker 2>And maybe this raises an important question for you, the listener,

393
00:19:21.000 --> 00:19:24.359
<v Speaker 2>to think about as patterns evolve, How does understanding something

394
00:19:24.400 --> 00:19:26.880
<v Speaker 2>foundational like MVC help you adapt?

395
00:19:27.079 --> 00:19:28.279
<v Speaker 1>Hmmm, good question.

396
00:19:28.480 --> 00:19:31.519
<v Speaker 2>Think about how these core ideas, separation of concerns, defined

397
00:19:31.599 --> 00:19:35.599
<v Speaker 2>roles for data logic presentation might show up even in

398
00:19:35.680 --> 00:19:38.960
<v Speaker 2>newer frameworks, maybe just with different names or syntax. How

399
00:19:39.000 --> 00:19:41.000
<v Speaker 2>does this foundation empower you? What stands out to you

400
00:19:41.039 --> 00:19:44.839
<v Speaker 2>about how these architectural patterns really help developers build better software.

401
00:19:45.039 --> 00:19:47.799
<v Speaker 1>That's fantastic thought to leave things on something to definitely

402
00:19:47.880 --> 00:19:49.799
<v Speaker 1>mull over. Thank you so much for joining us on

403
00:19:49.799 --> 00:19:51.599
<v Speaker 1>this deep dive. We hope you found it valuable.