 |
Reflecting on MVC
Posted by jhook on March 01, 2006 at 12:29 AM | Comments (13)
I've probably written a half a dozen solutions to MVC. All of them a discarded in a folder on my G: drive, never touched again. Every once and a while, after sitting with a notebook, I'll add another one to the G: drive. Maybe the 'G' stands for graveyard.
The other night, I watched a DVD documentary on the band, Keane. It rambles on to a comment from Tim Rice-Oxley about writing songs; how before they had a hit, he could sit down and just let the ideas flow-- how now there's an expecation that everything he writes has to be a hit. It's just not the same anymore.
In some foreign form, I think we can feel the same way. We work so hard to have that one hit, to create that solution that everyone loves.
I know that I will forever adding more ideas to my G: drive. It's not that the solutions are bad, just that the bar has been set. Everything evolves into some form of what's in place with JSF. Of course, each person has their own ideas as to what the perfect solution is, but JSF is my benchmark right now.
All the solutions start out with the idea of having a tree of components that operate on the model. Simple enough. My definition of a component is something that can be evaluated as part of a greater whole or separately. They also participate in all parts of MVC-- rendering, validation, updating, decoding, etc. The important thing is that they can be evaluated independently, and JSF already captures this with it's naked approach to exposing the whole component tree to the developer.
At this point, things get rough. Having the component tree managed like that has to be pricey-- we are talking about MVC on the web. What if the component tree was stateless? That might work, but then I would end up back at square one with requiring components each figure out how to render hidden state and coordinate change with other components. I've been using an Action/Request framework on a project right now and battling with hidden fields, iterative form controls with multiple updates, and JavaScript up the wahzoo.... well it's increasingly difficult. It's not that it can't be done, but I just can't see this being a good solution to require of developers. It's kind of like throwing them into a pit, and if you can crawl out, we'll give you a cookie. It seems that it would be a lot simpler to just have the framework guarantee state transfer for me. Now I'm back in the same boat as JSF again.
This is usually where I get frustrated and stop.
Everyone's so concerned about overhead of JSF and component solutions. Again, every ounce of data I've seen showed that JSF performed closely with solutions like Struts. At JavaOne, in the 'MVC Bottlenecks' BOF, early releases of MyFaces 1.0 were only had 6% less throughput and results like this make me scratch my head-- most graphs show only a few millisecond difference. I know some had mentioned scalability issues, but what was the real issue?
What about the comments that there's no front-controller, like Struts, for JSF with GET requests. Again, I reflect on how I've found myself using Action frameworks. I guess having that front-controller helps if I need to deliver an alternate view. Truthfully, I find that I really only have one view I ever associate to GET requests. All other conditions are considered errors or my single view displays the appropriate message. Authentication/Security is usually handled on a global level... so I've basically lost my need for a front-controller for GET requests. Yes, I do run into cases where I need to deliver alternate pages, but their all part of some transaction via POSTs and JSF has that covered.
Let's keep that ball rolling. Lets say you want to go from a GET request to another GET request with JSF? No one says you can't simply render an HTML anchor tag with a 'hand' generated URI. It's the same thing you would do with Action frameworks.
Despite all of this, I don't expect everyone to use JSF. Most people question the scalability of JSF, but again, I haven't seen actual benchmarks that proves it was an unsolvable issue either within the guts of a particular JSF implementation or within the hardware running the application. Is it even an issue when there's only a 4-6% difference? I guess to me, it's not a question of how easy a framework can scale on the hardware, but how easy it can scale use case requirements. Why do you choose full-ORM solutions over straight JDBC? I guess one could reach a point, just like with ORM, where performance starts to degrade. Is it the ORM's fault or is it because the ORM allowed you to easily do overly complicated things? Could the same be applied to component frameworks for all they provide to you?
JSF will always be a work in progress, just like every other framework out there. Even today, I got excited about JBoss's Serialization announcement since it could allow for an improved, plugable StateManager. So many times this evolution of enhancement has already occured in different ways with JSF-- but the tune is still the same.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Hi Jacob,
you make the mistake of assuming that "All the solutions start out with the idea of having a tree of components that operate on the model." This is simply not true. RIFE doesn't in fact. Instead of focusing on a tree of components, it starts from the principle that a component is a black box that has inputs, outputs and exits. Independently from that, you wire all these together in a three-dimensional site structure. The framework is then able to handle all state and data flow for you without having to serialize a component tree. Since components are black boxes, they can run anywhere in any context, from a widget, to a standalone page, to a predicate, to a filter, to a portlet, to an entire site, ... you name it. Since the black box is so simple, it maps directly to the HTTP request in the simplest case, giving you all the ease of use of action frameworks, but with managed state / URLs and the power / reuse of component frameworks.
Best regards,
Geert
Posted by: gbevin on March 01, 2006 at 05:09 AM
-
I was talking from personal example :-)
Out of curiousity, if components are black boxes, how do they interact with each other-- such as a table with other child components? As for managed state, how does each component manage it's state? The other merits you are describing are very similar to what JSF's component model has, but it looks like there's some differences in the implementation.
Posted by: jhook on March 01, 2006 at 06:03 AM
-
Ok :-)
Well as you say, the components are stateless by default, unless you use continuations, but you don't have to worry about the externalized state transfer and handling since the framework does this for you. The components are then responsible for restoring or rendering any internal state according to the data inputs that they receive. Of course, they can receive those from other components in which they are embedded, such as table cells.
Posted by: gbevin on March 01, 2006 at 09:46 AM
-
Looking at an example like this, how do you handle parameter name collisions with components or elements? The components become responsible again for maintaining this-- just like action frameworks?
Posted by: jhook on March 01, 2006 at 11:16 AM
-
Maybe slightly off topic , but I'd appreciate your thoughts on Ajax and JSF. I've just gone through the available frameworks blog post on which is likely to be the next Java Web Presentation Standard.
Any thoughts?
Paul
Posted by: paulbrowne on March 01, 2006 at 12:56 PM
-
I guess this blog kind of sums up the direction I'm headed.
Posted by: jhook on March 01, 2006 at 01:16 PM
-
Hi Jacob, actually not, the components don't have to worry at all about conflicts. RIFE knows about your entire dataflow and is able to target the values (even similarly named values) to the correct element. You can even have several times the same element embedded into another element's view and the submissions will always go to the correct one.
Posted by: gbevin on March 01, 2006 at 03:50 PM
-
One can use session-scoped objects in Struts/WebWork/Stripes as well. There is no need to follow "good practices" only because some big Struts or WebWork wigs wrote them. I use session-scoped forms in Struts, but it took me some time to get used to this approach. I thought that it would be great to promote the idea of stateful action form, but this does not work well. Newbies prefer to go by the book, even if the book is old and crappy. Easier to spin off another framework or to switch to one that works more to your taste. Considering multiple views for a single GET, JSF has subviews and "rendered" attribute, so creating several views per web resource is not a problem.
Posted by: michael_jouravlev on March 01, 2006 at 05:01 PM
-
The only way out of the success trap is to say “Everything I’ve done is totally crap. I can do better”. There is no greater limit to the creative process then the perception that an idea is “perfect” or “finished”. Artists have this problem all the time. Some of the greatest painters never thought very highly of their own work. The major difference is that for your ideas to be successful in a commercial way you need to be an advocate for the technology. One way to accomplish both might be to think “my solution sucks, but all the others suck more”. Then you can achieve beyond your own sucky solution to hopefully one that sucks less. At the same time you can still say “Use what I have done, because it’s better then XYZ”. Success need not be a limiting factor for you, keep going, and no matter what remember, its crap.
Posted by: aberrant on March 02, 2006 at 08:19 AM
-
I'd say that the biggest problem is that MVC is an architectural pattern more than a design pattern. MVC is a programming-in-the-large concept.
Posted by: bitpuddle on March 02, 2006 at 09:53 AM
-
One thing I wish was articulated better is what use cases are JSF suitable for. I hope you will address this in a future blog.
It seems to me that JSF is very suitable for internal corporate and enterprise applications -- the kind of applications that, in the past, would have a GUI built using Visual Basic or Oracle Forms. This target is not surprising considering the sponsors of Java -- Sun, IBM, Oracle, BEA -- they sell enterprise services, software, and hardware.
As for customer-facing applications, JSF applicability is more limited. It would be useful for cases that need fairly sophisticated data entry, wizards, etc., Examples would be airline seat selection, calendar application, etc.
But if you were tasked with implementing a website like IMDB, would you use JSF?
I think this is why JSF inspires a lot of hostility. Probably the largest segment of developers are developing content oriented websites like publishing a product catalog, pulling content from a CMS, etc. They evaluate JSF and see it as a poor match and say things like "JSF sucks!" without realizing that the use case JSF addresses is not meant to solve their type of problem.
Posted by: ahalsey on March 02, 2006 at 12:42 PM
-
"Of course, each person has their own ideas as to what the perfect solution is..."
For us it (still) is Tapestry 4.0. When you're doing web development this is the best one by far and very, very productive I might add!
Posted by: jvissers on March 02, 2006 at 04:09 PM
-
The only way out of the success trap is to say “Everything I’ve done is totally crap. I can do better”. There is no greater limit to the creative process then the perception that an idea is “perfect” or “finished”. Artists have this problem all the time. Some of the greatest painters never thought very highly of their own work. The major difference is that for your ideas to be successful in a commercial way you need to be an advocate for the technology. One way to accomplish both might be to think “my solution sucks, but all the others suck more”. Then you can achieve beyond your own sucky solution to hopefully one that sucks less. At the same time you can still say “Use what I have done, because it’s better then XYZ”. Success need not be a limiting factor for you, keep going, and no matter what remember, its crap.
acrobat
adaware
antivirus
antivirus
ares
avatar
avatars
clone
divx
download
edonkey
emoticone
emoticones
emule
firefox
gratuit
gratuite
icq
kazaaa
limewire
logiciel
logiciels
messenger
morpheus
msn
nero
realplayer
shareaza
skype
spybot
telechargementnu
telechargerdas
pitelechargerant
tytelechargerant
frtelechargerant
vlcolo
winampaww
rrewinmx
tiwinrar
powinzip
dedamateur
amateurdes
eeranalu
aseanime
okoasian
duiass
babere6
fubbw5
bdsm55
derbeach4
bisexualpo
bizarrecu
axsblack
deblonde5
tyhlowjob
cobondage
gubooty
vhuvukkake
ddecartoon
buexotic
celebriteuy
plitoris44
crwcloseup
edecoock
deacouple
qecreampie
sripumshot
judeepthroat
ggildo66
tredoublepenetra
verdrunk
lopebony
treethnic
bufaceh
mifacial
mhhofat
frefemdom
fetishhh55
dreffmm
tyfingering
fist timefre
istingde44f
flashingsa
footjobre
uckingdas
banggangtre
gay23i
gayssw
gloryghole
gugranny
hairypo
andjobde
hardcorereh
hentaityy
housewifesaw
indianerrh
interracial223
guujapanese
latexree
latinatyy
lesbianvgh
lingerieww
guumaid
ffmardigrasre
pasturbation
yumature
remidgeth
demilfg
frmmf
modeluy
nudeerh
nudistcre
oralvre
orgyoko
greoutdoor
pantiereh
pissingdas
plumperdes
ornstaroko
pregnantsas
repuffy
ushsy
redheadca8
rimjobse
schoolgirlas44
shavingde
sshemale66
showerbathh
smokinghh
softcoreh
spankinghh
squirting99
eshstories
tystrapon
reswinger77
mateenghy
nnthong34
uythreesome
destits
toesssa
toonty44
toynum
trannyoi
uglyplo44
ervirgin
tyuvoyeur
drewebcam
loweird9
yuwetshirt
pofilmgratuit
piorngratuit
poxxxgratuit
paornogratuit
losexgratuit
tysexegratuit
ggyxgratuit
oitelechargement
plotelechargemen
jutelechargement
atelechargemorno
eetelechargement
etelechargemsexe
utelechargementx
tytelechargermov
lltelechargerfil
aytelechargerorn
ketelechargerorn
vtelechargersex5
otelechargersexe
vytelechargerx
telechargerxxx76
gtdosex55
pororno
lamovie77
sdfaged
ffamazing22
adanime
ass3hole334
hybabe00
jubackseat
juibang
lobathing
frbeachhh
vebeauty
bybeaver5
hubed99
bubiggtit
lobimboh
nubizarre
beboyh
bybusty
yybutt
nucheerleader
michickk
kichinese
lochubby
beclassyy
nyplit
frcoed
buicorset
kicum77
likunt
nucurly
cadick77
dedirtyy
sedolll
aedorm
redressss
ggdrilled
trdrinking
uyfoot
ffgirlfriendd
iglasses55
gorgeous77ii
goth22uu
grannyf0
hiddenvv9
hirsute56
hooterby66
hornygr55
hugegats
jerkingjju
jizas
juicyce66
kinkyffr
kissing55
leg66ii
lickggh
malehy
nasturbatingr
melonfu
nistressre
momase44y
nakedaas
naturalder
naturetre
naughtyvu
nippleswe
nymphoww
oiled22
older99uu
orgasm32
orientalvb66
outsiderr66
pantytr
penetratefrr
petitekki
pinklo88
plumppe
ornstarve
prettyty77
privateru
skinnyde
szlutda44y
smokesa55i
spankserr
zzs3permfrss
spreade3
stockingrr5
stripe4ii
strippertr
studses
studentad
suckingase
sybiancv
tall334y
teaseuy
toplesszass
trannycre
tubash5h
twinkse
undressingre
baginao
bibratorry
vixentre
wwhooreedd
wivesas
Posted by: sallee on October 11, 2006 at 02:10 AM
|
java.net RSS Feeds
