isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grigorov <mgrigo...@apache.org>
Subject Re: render contributed action eagerly
Date Wed, 04 Feb 2015 12:30:00 GMT
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 <dan@haywood-associates.co.uk>
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 <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