SWF / MVC write-up

[Cantor, Scott]

On 9/6/13 3:52 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>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).

I had the impression it meant a real class just because of the reverse
process of data binding form parameters back into the model. But I
certainly didn't try it, so I may be wrong.

I know that the actual process of turning the model into data fed into the
view is just a map, but AFAIK to actually produce that data to start with,
you need an actual object with properties, which means predefining a Java
class as a model. That's as formal as I was referring to.

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

Yes, provided it's reasonable syntactically. I'm not sure that it is (try
one and see, it's pretty ugly), or that it's better to have those
expressions locked inside a flow def file that is only loaded once vs. a
template that is loaded on the fly.

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

The latter, sure, but that means writing a Java class in an extension jar
simply to make a template do something slightly more advanced. I don't
love that idea.

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

You can, but it isn't terribly elegant from what I can see. Not that it's
tremendously elegant to do it in Velocity either, but if I can push two or
three context nodes into the view that cover 99% of the use cases, then
suddenly nobody has to touch the ugly expressions in the flow file.

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

We could do that, I suppose, literally just mirror the context contents I
had in mind into the view. It's just a bit more typing I suppose. I could
make a case that doing all that work for views that will never use most of
the data also bothers me vs. just pushing a couple of context nodes into
the tree as references.

I don't see this as a case of data hiding. The whole context tree is meant
to be the public API to all this information.

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

Yes, I can't say I'm fond of that separation of duty. To me, the encoding
is part of the rendering of the UI because it's specific to the UI
context, so to speak. The "model" shouldn't have to know the view is HTML
if you get my point.

Not to mention, sometimes the view may want to examine unencoded data, not
just the encoded result.

I'm not saying I think the template scripter should have to call the
escaping logic either, it should be automatic now after so many years of
XSS. But these view technologies are simply not smart enough to realize
they should be doing this job, I guess.

-- Scott