While I don't necessarily disagree with your points Jeff, I feel given that you
pulled out a couple of specific ones publicly here that its worth addressing
them here, but i'll be quick so I don't distract from the conversation at hand.
Regarding configuring routes in one location (in this case JSON, but Java is
also possible, and more testable). In the context of a web application, having
all the endpoint mappings in one location can really help with discoverability
and maintenance. With restful services, there is a much more logical place to
home things (usually around the entity), so having the endpoint definitions
scattered around code is less problematic. If you have an application developed
by many people, which is iterating quickly it can be very useful to see and
update all endpoints in one spot. We chose this pattern because our experience
on large apps before has shown that little used endpoints (for admin functions,
rarely used user features, etc) are much more vulnerable to bitrot.
Regarding returning concrete view types, like JspView, rather than domain
models:
I think you can split the needs of a framework right down the middle - data
views and template views. Data views usually expose some sort of API model
(which you back with a java model), and consumers need to understand the
available Apis. Most people do this restfully these days, get put post delete.
Then there are template views. Rendering the template (usually to HTML, but
emails, messages etc) fold together a couple of concepts.
1) screen flow - any post (or put or delete) will have a paired get request
simply to show a page with a form and probably some JavaScript. Usually it goes
further with input validation, redirect on post etc
2) supplementary/reference data - every drop down needs possible options,
usernames are displayed, carousel widgets, navigation elements etc.
Specific view types allow the explicit definition of the required data. For
example, a jsp requires a view name (the jsp file), and model data. Once it's
concretely defined, it becomes easy to test.
There are other advantages, for example a unified output engine means you can
reuse views, such as jsps for rendering emails or mms, rather than a different
templating language.
Tl;dr
Testability, maintainability and discoverability trumps saving yourself typing
'new JspView(' or 'new Js<ctrl><space><enter>'
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
