Sorry that was confusing. A new ModelDriven Interface would be better. ModelFacing<?> from an Implementation perspective: - push the Model object to the top of the stack such that members can be set directly (same as model driven) - register a pre-result listener, which will revert the action class to being at the top of the stack.
ModelBacking<?> - Leave the model as is - Register a pre-result listener, which will push the object specified in ModelBacking to the top of the value stack. Since the later functionality is readily achieved using <s:push> there is not much need for the second. But someone recently was talking about managing legacy views and this sort of decoupling might have minor use in that case. It could also have use with Struts results which expect a certain object, but then using the appropriate interface directly on the action is more obvious. Another possible use is for security. Certain results can serialize the action, a decoupling here could be useful (on action uses the same class for a JSP view, an XML producing result and a JSON producing result). In this case having the opportunity to create an object against which the view will only have access could make what people are supposed to have access to clearer and allow the serializers to cleanly operate over the whole object rather than having to use there APIs to prune parts of the tree. Hope this is clearer. I don't know if it is just me. I like the idea of ModelDriven but find that having the same model for the front and the back too restrictive. After all the general flow in most actions is: Get data, execute business logic, marshal data for view, possibly some processing of view data... How often do we want to send the same type of object back to the view we just received? Not that often. On Mon, Sep 30, 2013 at 2:26 AM, Lukasz Lenart <lukaszlen...@apache.org>wrote: > @Ken I'm bit lost with your mails, right now I don't know what you > want - new Model interfaces or current ModelDriven approach is valid? > Maybe start a new discussion? > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > 2013/9/26 Ken McWilliams <ken.mcwilli...@gmail.com>: > > ...more often than not, NOT what I want (wrt: "Maybe it's just me but for > > some reason this is more often than not what I want (I want the model > > towards the request but not towards the view), so I need to forgo > > ModelDriven."). Sorry everyone! > > > > > > On Wed, Sep 25, 2013 at 7:39 PM, Ken McWilliams < > ken.mcwilli...@gmail.com>wrote: > > > >> Sorry should have read the last couple lines before posting! It was in > >> defense of ModelBacking suggesting that the congruent structure could > allow > >> us to publish the action into the stack and then handle it knowing the > >> interface. A certain result type for instance could require a specific > >> backing model to even handle the request (could include it in the plugin > >> for that request, as a way to clearly make you satisfy it's > requirements). > >> > >> Seems to be in the actions scope. Get data, validate data, invoke > business > >> logic, marshal data for view (massage data for view if required). If > would > >> fall under the latter. > >> > >> > >> On Wed, Sep 25, 2013 at 7:32 PM, Ken McWilliams < > ken.mcwilli...@gmail.com>wrote: > >> > >>> Not sure if this is the place to bring this up, this is an annoyance > >>> coming from ModelDriven may offer a solution... > >>> > >>> Issue: It's hard to get past the model if you want to add more > attributes > >>> to the action. Also when using ModelDriven the same view of the action > is > >>> applied from the HTTP side as the views side. Maybe it's just me but > for > >>> some reason this is more often than not what I want (I want the model > >>> towards the request but not towards the view), so I need to forgo > >>> ModelDriven. > >>> > >>> What I though might be interesting is a ModelFacing<?> and > >>> ModelBacking<?> interfaces. > >>> > >>> ModelFacing provides the same functionality as ModelDriven but only > >>> towards the request. Any other methods defined in the action are not > >>> accessible. ModelBacking isn't so interesting, same effect could be > >>> achieved using s:push tag I suppose, so the later isn't needed so > much. But > >>> it wouldn't to have the later because should we want to expose an > interface > >>> via OGNL we could say some component provides X interface and it would > be > >>> available from the value stack that way without needing a view. It's > pretty > >>> obvious how conventions could determine the white listed methods from > this. > >>> > >>> > >>> On Tue, Sep 24, 2013 at 3:21 AM, Lukasz Lenart < > lukaszlen...@apache.org>wrote: > >>> > >>>> 2013/9/24 Christoph Nenning <christoph.nenn...@lex-com.net>: > >>>> >> > But still: method:add works while !add does not. > >>>> >> > >>>> >> If you could prepare a small demo app, I'd like investigate that. > >>>> >> > >>>> >> > >>>> > > >>>> > I can do so next week, sorry for the delay > >>>> > >>>> No problem, I'm busy too ;-) > >>>> > >>>> > >>>> Regards > >>>> -- > >>>> Łukasz > >>>> + 48 606 323 122 http://www.lenart.org.pl/ > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >>>> For additional commands, e-mail: user-h...@struts.apache.org > >>>> > >>>> > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > >
