SWF / MVC write-up

[Brent Putman]

On 9/5/13 10:04 AM, Cantor, Scott wrote:
>> 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.

I haven't really done anything with views, UI, etc in SWF, but I am
pretty familiar with Spring MVC at this point, on which SWF is based
obviously.  I think MVC uses the term "model" pretty loosely.  It's
ultimately just a a string-indexed map of attributes.  So it's in
practice less formal than I what I think the M in MVC may have
originally meant (maybe).

>
>
> 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.

No, we can't anticipate everything.  But if SWF's notion of a model is
like Spring MVC's, can't they just add whatever they want to the view
scope using additional expressions on the view state?  Either the simple
way using SPEL expressions (i.e. the "standard" SWF web app way), or by
using an expression that really calls a POJO action whose sole job is to
populate view scope data.  The latter would allow much easier traversal
of the context tree and pulling data from it.  (I'm going by memory, so
maybe I have the details wrong here).


>
> But I *do* think we should make it possible to navigate the context tree
> from within Velocity, 

Well, maybe, but I don't quite understand that yet.  Just playing
devil's advocate: Usually a view just renders a UI, it doesn't do any
really logic.  So one could instead just populate the view with the
explicit simpler types (usually scalar values) that the view needs
(primitives, strings, collections thereof).  That's easy if you can do
what I outline above to use expressions to populate the view scope.

This is where I need to get a little more hands-on with SWF, I didn't do
much yet with views, etc.  I'll try and do soon.

> and that's not so easy to do (see my example). 

Yeah, it looks nasty.


> 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).

Yeah, I would say not even the contexts, but rather the actual needed
data items that they are wrapping.  And those simple types are most
probably Serializable.  (And which is probably why people generally
don't have an issue with the Serializable requirement on view scope data
- it's usually just simple types or collections).


>
> There's also the ESAPI encoder object, which is definitely needed inside
> Velocity templates, 

Well, again devil's advocate, not if you do the encoding on the data
before you put it into the Velocity context.  And btw, that is what we
do in v2, for the encoder binding templates, it's done by the encoder
before the data is put into the context, not in the template.


> 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.

Yeah, if ultimately it *does* need to be in there, then I agree that it
being non-Serializable is a problem obviously.