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