isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: render contributed action eagerly
Date Wed, 04 Feb 2015 11:46:10 GMT
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 <mgrigorov@apache.org> 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, <JohanDoornenbal@filternet.nl> 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message