Something like: https://git1-us-west.apache.org/repos/asf?p=isis.git;a=commitdiff;h=ae6a80dd;hp=eae15a260fd9f24ab33e9a862959fb77c3dc8de7 ? If it is not correct then don't spend time to explain it in words now. I'll check your commit tomorrow! :-)
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Feb 4, 2015 at 1:46 PM, Dan Haywood <[email protected]> wrote: > No, I know what the issue is. > > An @Action is indeed a button to invoke. But for domain services, it can > also be a contributed as a collection or as a property, if it takes a > single arg of an entity or view model, and if it has query-only semantics. > > The action is treated as a contributed collection if it returns a > java.util.Collection (or subtype); as a contributed property otherwise. > > It *is* therefore valid to have @Action and also @CollectionLayout; these > are the collection UI semantics when the action is treated as a contributed > collection. It would also be valid to have @Action and @PropertyLayout, > for similar reasons. > > Previously the @Render annotation worked more-or-less by accident. With > these new annotations things are somewhat more precisely defined. > > I *think* I know what needs to be done in the metamodel; also process the > @PropertyLayout and @CollectionLayout annotations against actions. Will > look at tonight or tomorrow (unless you want to, Martin?). > > NB: for xxx.layout.json, it does work fine, I think. > > Thx > Dan > > > > > > On 4 February 2015 at 11:37, Martin Grigorov <[email protected]> wrote: > > > Hi, > > > > What exactly is the problem ? > > > > > > > https://github.com/johandoornenbal/matching/blob/master/dom/src/main/java/info/matchingservice/dom/Match/BrancheElementComparisonService.java#L69-L73 > > having both @CollectionLayout and @Action looks odd to me. > > > > I still don't fully understand all these things but for me @Action is a > > button in the UI that when pressed executes some logic and returns > results. > > In this case the action collects some results and asks Isis to render > them. > > To me RenderType should be in effect when some entity is being rendered > and > > this entity has a collection property. Here the RenderType hints Isis > > whether to fetch the collection elements eagerly or lazily. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Wed, Feb 4, 2015 at 1:14 PM, <[email protected]> wrote: > > > > > Hi Dan, > > > > > > > > > > > > The problem is still persisting. It is not blocking at all beause I can > > > solve it in several ways. But just to let you know... > > > > > > Note: is a contributed collection. > > > > > > See code: [1] line 69 > > > > > > See online example: [2] (login with frans - pass > > > > > > > > > > > > grtz Johan > > > > > > > > > > > > [1] > > > > > > https://github.com/johandoornenbal/matching/blob/master/dom/src/main/java/info/matchingservice/dom/Match/BrancheElementComparisonService.java > > > > > > > > > > > > [2] > > > > > > http://xtalus.apps.gedge.nl/simple/wicket/entity/info.matchingservice.dom.Profile.ProfileElementTag:L_25 > > > > > > > > > Just got round to looking at this... can't reproduce the problem, I'm > > > afraid. > > > > > > Well, I did find a slight issue... the default value for > > > @CollectionLayout#renderType() was set to EAGERLY, should've been > LAZILY. > > > Fixed that. > > > > > > Anyway, what you should see is: > > > > > > - if the xxx.layout.json specifies the renderType, then this will be > used > > > [1] > > > - otherwise, will use @CollectionLayout#renderType(), if present (and > > will > > > default to LAZILY if the renderType attribute is not specified) > > > - otherwise, if there is no @CollectionLayout, then will look at the > > > deprecated @Render. That one defaults to EAGERLY. > > > > > > Double check with the latest archetype (I just recreated it), see if > you > > > can reproduce with that. Give the build 30 mins or so from this email > to > > > do its thang. > > > > > > Thx > > > Dan > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://github.com/apache/isis/blob/94529f19bef246cadc667344873b382f16c751e6/example/application/todoapp/dom/src/main/java/dom/todo/ToDoItem.layout.json#L175 > > > > > > > > > > > > > > > On 29 January 2015 at 12:01, wrote: > > > > > > > Hi Dan, > > > > > > > > > > > > > > > > The deprecated works correctly indeed. > > > > > > > > > > > > > > > > grtz Johan > > > > > > > > > > > > > > > > > > > > hmm, that looks correct. > > > > > > > > I wonder if there's a bug with that annotation. > > > > > > > > If you replace @CollectionLayout(render=...) with the deprecated > > > > @Render(Type.EAGERLY), does it work? > > > > > > > > > > > > > > > > On 29 January 2015 at 10:43, wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Is there a way to render the (list) result of a contributed action > > > > eagerly? > > > > > > > > > > > > > > > > > > > > I tried: > > > > > > > > > > > > > > > @Action(semantics=SemanticsOf.SAFE) > > > > > > > > > > @CollectionLayout(render=RenderType.EAGERLY) > > > > > > > > > > public List showProfileMatches(Profile demandProfile) { > > > > > > > > > > > > > > > > > > > > [1] line 39 > > > > > grtz Johan > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/johandoornenbal/matching/blob/master/dom/src/main/java/info/matchingservice/dom/Match/ProfileMatchingService.java > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
