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