@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
