> Jezus, Jonathan you're a nit-picker, I've indeed stopped > reading the exchange here and feel quite sad that you > turned a fruitful discussion about the different varieties > of template engines into your own playground. You seem to > make it your mission to try to prove how right you > personally are with that blog post from a year ago and the > approaches taken in Freemarker.
Uhh, well, actually, Geert, you know, the goal of a debate is actually to demonstrate via logical argument that your position is correct.
It seems that you are taking me to task for actually just debating.
What we have on the other side of the debate is at least one person who does not even adhere the basic rules of a debate, which is that you do have to back up the things that you say with facts and logical argumetns.
> You're right about one > thing though, there's probably not a soul anymore that > will read this thread until here.
That was not my conjecture. It was Eelco who said that (wishfully, I think...) I have no idea how many people are reading this conversation, not even to an order of magnitude. I wouldn't care to speculate on it.
> > Let me pick up some points that I still remember from the > posts that I did read on this thread. Apparently a let of > this discussion stems from your definition of SoC. > The official definition is: > In computer science, separation of concerns (SoC) is > the process of breaking a program into distinct features > that overlap in functionality as little as possible. A > concern is any piece of interest or focus in a program. > Typically, concerns are synonymous with features or > behaviors. > (http://en.wikipedia.org/wiki/Separation_of_concerns) > > So, if you already disagree with the world on this basic > principle, then there isn't really much to discuss about. > SoC is about designing and partitioning code, not > separating and isolating task / languages / ... for people > with different capabilities.
Well, this business of the exact definition of SoC is nitpicking par excellence. To me, the exact definition of an abstract concept like that is not very important.
What matters in the real world is that you can partition a problem fairly cleanly so that different people can work on different pieces unhindered. If that somehow is my own personal definition of what SoC realy is about, then fine, I still don't think it's central, because in the end, whether that's what the official academic definition of SoC is or not, I'm pretty sure that that is what the real point of it is.
> > Going from there, having logic inside templates (which was > the original discussion) violates the concern that the > original purpose of a template in the layout world (which > you admit you know nothing about, you never even started > Illustrator, as you said yourself in your blog post)
I wasn't talking about the template facilities that exist in layout programs like dreamweaver etcetera.
> only > contains building blocks to create your own layout, these > templates don't operate on their layout elements > themselves through their own execution model. Thus, > similar to the layout applications that allow their users > to pick parts of the template and aggregate them to build > their own document, you can do that perfectly well with > the main programming language of your project (be it Java, > Ruby, Groovy,
Well, are you being deliberately obtuse here, Geert?
Sure, I can. But I don't want to, because whatever reusable elements I encapsulate, probably people will have other requests, that they want something different, and so on. I want to hand off the whole mess to a separate subteam, and I wouldn't want to assume too much ability on their part in the main programming language being used on the back end, be it Java or something else.
> ... your pet-peeve about the deployment > issue is again not relevant).
I don't think that was my pet peeve. That was Eelco. He thinks that even tweaking a template should require a full rebuild/restart of the system apparently.
> The text manipulation > capabilities of this language is a non-issue since you're > not manipulating text, your merely re-structuring and > aggregating semantic layout elements that have textual > counterparts in the templates.
???
Whatever...
> > How you structure that code in your main programming > language and how you isolate, is up to the programmer. Of > course, if there's JDBC code in there or whatever, then he > could be violating concerns again. This is a possibility > anywhere you provide developers with a sufficiently > capable programming language. There are very distinct > advantages though to not having any logic inside template, > for instance: they do become clearer and more concise as > you only have the text content in there,
Fine, but if the display task is of a certain level of complexity, you're simply achieving the simplicity here by pushing the extra logic/complexity somewhere else. I would say there's no free lunch on this.
> nobody has to > learn another language or toolset, the template clearly > expresses what the individual layout elements are without > anyone having to understand the logic that's intertwined, > and you can properly create reusable pieces of code. What > you advocate with Freemarker macros is only a small part > of reusability story, most web applications nowadays are > not really interested in reusing code snippets of how you > created a table layout, but rather create richer > components that incorporate state handling and a lot more. > Simple macros don't cut it here unless you start violating > a lot of concerns and tightly intertwine with your > server-side state handling inside your templates. > > Now, to play your own game, people like Jonathan Locke, > Eelco Hillenius, Howard Lewis Ship, Terrence Parr, and me > have all deeply thought about this too (surprise, you're > not the only one) and came up with a solution going into a > similar direction, though with different implementations.
First of all, you're throwing out these names, in what appears to be some kind of "appeal to authority". Earlier, you objected that I mention being the main author of the FreeMarker core as an illegitimate argument. Not that I was making that as a key argument or anything, I was simply saying that you shouldn't dismiss what I say out of hand.
But okay, you have Wicket, you have Tapestry, and you have StringTemplate. Let's talk about the first two now. By all accounts Wicket and Tapestry are quite elegant frameworks. In the case of Tapestry, it has been under the apache umbrella for a number of years, so it has pretty good visibility.
Here is what I consider the $64,000 question. How come these elegant frameworks, in the real world, cannot, even after years, displace something crappy old Struts 1.x?
Now, some of this is the visibility, that Struts started early as a jakarta project and gained momentum that way and once people started using something, conservatism....
Still, even so, it is amazing, because Struts 1.x is not only an action framework that uses crappy old JSP's and tends to have logic in the view, but it is, frankly, not even a very good action framework. (By all accounts, Struts 2, which is really Webwork, is a pretty half-decent action framework. (And Stripes, from what I hear is really very good.))
But we see here that even a crappy action framework is an order of magnitude more popular than tapestry and wicket and rife and so on all put together.
Why?
I somehow doubt that this is solely because the general developer public out there is comprised of idiots. (That's one factor, but still....)
I frankly don't know for sure, but I am going to make a tentative stab at explaining this phenomenon.
I think it has something to do with the 3-way article I wrote. Basically, for all its crappiness, at the end of the day, something like Struts corresponds better to how most real world teams out there really do build websites than the elegant frameworks like Tapestry and so on really do.
So, my take on it is that the strict 2-way separation of concerns that Wicket or Tapestry espouse (and that you seem pretty religious about) does not actually map well onto how teams build large web apps. That was really what I was trying to get at somewhat in the article on designer/developer division of labor.
And as a final point, you mention Terence Parr and StringTemplate. What are the usage statistics approximately on FreeMarker vs. StringTemplate?
Certainly, Terence's article and other writings on model-view separation and entanglement have gotten a fair bit of exposure out there, and so on, and supposedly StringTemplate encapsulates all of Terence's great wisdom on the matter, right?
And what is the reaction of the developer world, by and large, to this?
Almost complete indifference. It is not solely because StringTemplate competes at such a visibility disadvantage with JSP or even Velocity. I think it's safe to say that FreeMarker, which has no special visibility advantage over ST; has 10x as many users.
If people really were much more productive at their work using these tools that enforce strict separation, would they not have gradually supplanted the other, less productive tools? (As a tangent, this is the same thing I wonder when I hear functional programming advocates talk about how great FP is.)
> Most of us did a lot more than just work on template > engines and we thus probably have a clearer image of the > bigger picture. We have certainly all by far exceeded your > credentials when it comes to community involvement and > eagerness to innovate.
Excuse me, Geert. Regarding the above comments of yours, I have a certain ummm... little something I have to share with you now.
Geert, you're full of shit.
If you want to convince somebody like me of something, formulate some convincing argument and argue it, don't come at me with all this bullshit about how you and all these other people did whatever and won whatever awards. That's just bullshit.
And I will re-iterate, you did all these wonderful things and somehow, the world is indifferent. Crappy old Struts 1.x has more 10x more users than all of this wonderfully elegant stuff you've done all put together.
Why?
> Some of us even won awards for > that. What kind of self-righteous person comes in here, > touting his own greatness when you're just a very small > piece of the puzzle. A little bit of humility would do you > good. You might learn something.
Well, the boy who pointed out that the emperor was wearing no clothes should have learned proper humility too. Who was he to say that this great emperor was butt naked? How dare he? The nerve...
The more you huff and puff, the more convinced I am that your position on this is pretty flimsy. If you had stronger arguments, I think you would bring them out, and not be trotting out all this appeal to authority, and we're the gods of programming sort of annoying bullshit.
Btw, I'm following Eelco, discussing with you is pointless and a waste of time, so I'll now just ignore and let you marvel at yourself in the center of your own wonderful universe.
> Wicket is different from the two frameworks (or at least > Tapestry as I'm not too familiar with WO) in quite a few > aspects, including the fact that Wicket doesn't allow to > embed logic in templates, whereas at least Tapestry does.
It does?!?! It didn't last I looked at it. :-/ Neither does WO.
I think we probably agree that executable code in templates is BAD. Token binding/replacement is fine as it promotes a "well formed" and modular kind of template - exactly the kind of thing seldom seen in JSP which often has half completed structures woven all over the place.
> > Wicket is different from the two frameworks (or at > least > > Tapestry as I'm not too familiar with WO) in quite a > few > > aspects, including the fact that Wicket doesn't allow > to > > embed logic in templates, whereas at least Tapestry > does. > > It does?!?! It didn't last I looked at it. :-/ Neither > does WO.
Well, not arbitrary exectuable code, but you can define things like loops and branches etc in the templates without having to explicitly define that you'll be doing this in Java, right? This was what I meant, sorry if that wasn't clear.
You've fallen victim to one of the more mysterious should-have-technical-cred-but-is-really-just-a-troll trolls with Eelco. I've found it's best to just ignore him when it's possible.
He delights in arbitrary meaningless debate with no real conclusions or technical learning involved and is also very good at subtle offenses.
I won't be participating in any tom-trollery here but thought I should help another fellow victim when in need. =p
Jesse, we were just wondering whether/ when you would show up here (I won the bet; others said you would be smarter than this, but I was right!). You could be twin brothers...
> > Wicket is different from the two frameworks (or at > least > > Tapestry as I'm not too familiar with WO) in quite a > few > > aspects, including the fact that Wicket doesn't allow > to > > embed logic in templates, whereas at least Tapestry > does. > > It does?!?! It didn't last I looked at it. :-/ Neither > does WO. > > I think we probably agree that executable code in > templates is BAD. Token binding/replacement is fine as it > promotes a "well formed" and modular kind of template - > exactly the kind of thing seldom seen in JSP which often > has half completed structures woven all over the place.
Well, as I commented earlier, I don't see where there's a free lunch on this. You don't want whatever programmatic logic in the template. But it still has to go somewhere. I do not find Eelco's response that it all has to be on the java side to be at all satisfying.
For starters, you can take outrageous, barbaric examples of messy JSP's or even FreeMarker templates, but that's still something of a straw man. It is not obvious why moderate, sane usages of logic in templates is going to lead to unwieldy, unmaintainable code. I mean, take something like:
Far be it from me to defend JSP's, and yes, the syntax is awkward, but even so, the idea that something like the above is so very evil and puts you on the road to perdition is not at all obvious to me.
And meanwhile, I have a strong gut feeling that systems that empower non-programmers to alter the look and feel of the application without asking for help from programmers are going to be more popular out there in the real world than systems that require all logic (even presentational logic) to be maintained in the java code. And I think there are very strong pragmatic reasons that would be so. The field is still pretty young, and maybe it's too early to tell, but these kinds of frameworks that prevent logic in templates do not seem to be particularly popular. Okay, they have their adherents, but I don't think you can really say that Tapestry, Wicket, Rife, and so on, are quite mainstream technologies.
I anticipate that people will jump out again and say that they don't care about that, and that life is not a popularity contest and so on. And I agree, up to a point. But finally, I still think it is worth reflecting on the possible reasons that these wonderfully engineered OOP frameworks are not more popular out there in the real world than they are.
Jesse, I'll help you and give the readers some links so that they can read how nasty I've been to you. If this thread didn't convince people that I'm an arrogant spiteful bastard, I'm sure these will:
And then for Jonathan, well I don't know, but he keeps this http://revusky.com/strutsmessages.txt at his site like it's a trophy. I guess we have different opinions on how to conduct meaninful discussions.
Let's just keep out of each other's way the next time ok?
I have a strong gut feeling that systems that empower non-programmers to alter the look and feel of the application without asking for help from programmers are going to be more popular out there in the real world than systems that require all logic (even presentational logic) to be maintained in the ... code.
I used to be the chief architect for a web internationalization company. Taking it down a level - you would think that it would be simple to give a language translator take an html page and ask him to just ignore the technical HTML tags and only translate the human readable text part.
You would think that.
You would be very very wrong.
It turns out that people should not modify documents that they do not understand in their entirety because when they do, they invariably change the meaning. In the case of translation, they simply would remove or shuffle the order of tags here and there - generally breaking the page.
In the case of your templating system - I have no doubt at all that designers who are not programmers will inadvertently mess up the jsp part of the code nearly all of the time.
So I don't find the property you embrace to be at all desireable and your scenario is pretty much a total fantasy in practice.
Believe me, I have used all manner of systems here and you need programmers to modify files with code in them.
> And meanwhile, I have a strong gut feeling that systems > that empower > non-programmers to alter the look and feel of the > application without > asking for help from programmers are going to be more > popular out > there in the real world than systems that require all > logic (even > presentational logic) to be maintained in the java code. > And I think > there are very strong pragmatic reasons that would be so.
Amen to that, brother. I used Velocity to build a site and it was great to empower the designer to do things where he didn't have to bother me to do things like - traverse a list, sort a list, add a field, format dates, etc.. I eventually gave him the ability to access database tables - the simplicity of the relational model makes it very suitable for non programmers. Since he was pulling a lot of stuff straight from the database, there was really no need for any java application logic. Just a SQL select object so he could say things like $Select.AddFields("Product","Price") and $Select.AddToWhereClause("Customer",EQ,$CustomerID). Once I did this, he pretty much finished the site on his own.
I agree with Ivar Jacobsen, who says that MVC is a general paradigm, and all objects tend to fall into one of the three categories. I think to do anything significant, you typically need objects from all 3 categories. For instance, math functions are controller (C) type objects - but imagine trying to implement a GUI (V) without them !
Flat View: This topic has 69 replies
on 5 pages
[
«
|
2345
]
Previous Topic
