SWF / MVC write-up

[Cantor, Scott]

On 9/4/13 8:04 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Tom sent me a note earlier asking if we could move java-shib-testbed to
>svn.shibboleth.net.  Like I said on the call a few weeks ago, that's
>perfectly fine, we just need to decide a place to put it.  IMHO it
>shouldn't really be a part of the IdP codebase, nor is it really an
>extension or utility.  So maybe it should just be a (presumably
>temporary and transient) repo all unto itself?

It's not exactly *not* a utility, though not a library of course, but I'm
not opposed to just keeping it separate.

>The other is that apparently Java Serializable is viewed by many as a
>Bad Thing(tm). Chad was very opposed to implementing Serializable on
>that basis as well. I was skeptical of this reason initially. However, I
>saw Joshua Bloch (notable designer of many things in the Java platform
>itself and respected software engineer) speak once at OSCON about
>language/platform features that have been added to Java since the
>initial language design; his opinion was that Serializable was the
>single worst mistake they had made (up to and including Java 7 stuff).

I defer to people with more experience on it. My issues with it have to do
with the complex issues around object versioning, which I don't really
understand very well, but those don't apply all that much to transitory
uses of serialization. It is why I don't like the idea of using binary
serialization for longer term needs.

But I am well aware that lots of people don't like Java Serialization, and
as a non-native to the language, I tend to take that seriously. I don't
find it compelling that lots of frameworks expect it, because people
writing frameworks are going to do what's easy for them.

>On view scope stuff specifically:  Admittedly I don't have a lot of
>hands-on with this, but my expectation all along has been that you
>wouldn't just stuff the entire context tree into the view scope.

No, I'm not trying to.

>You'd put the specific things that that particular view needed into the
>scope.  That's consistent with how MVC usually works; in a controller
>you don't stuff every object you know about into the view, you just
>expose the specific model data that the view is rendering.  Maybe we
>have more complex cases where that usual assumption doesn't always hold,
>though.

If we were building a UI solely as a development task ourselves, yes, we'd
build a model.


The problem is, it's not up to us what a view needs if we expect deployers
to be able to customize the templates. I may need virtually nothing from
the tree, but somebody building a very rich login form that wants to
access information about the request will. We can't anticipate everything
they might need, and I don't think we should try.

But I *do* think we should make it possible to navigate the context tree
from within Velocity, and that's not so easy to do (see my example). So I
thought it better to just inject specific contexts that would be valuable
as a general matter, but I can't do that without getting the snapshotting
turned off (though I'm coming to think that's the right thing to do
anyway).

There's also the ESAPI encoder object, which is definitely needed inside
Velocity templates, and is not Serializable. Velocity has no built-in HTML
escaping support, so writing out error messages isn't safe without having
the encoder available.

-- Scott