ok, yes, that helps. In which case I think that all would be required is to extend @PropertyLayout / @CollectionLayout (or equivalently .layout.json file) to specify the tab. This could apply both to regular and contributed properties and collections. I guess there could be some defaults so that contributed collections appear on different tabs by default.
~~~ One complication here is that Jeroen and I have also been (off-list) mulling over the idea of implementing bookmarks as tabs... each opened object is shown on a separate tab (like tabs in a browser, I suppose). Separating out a single entity into multiple tabs would then result in tabs within tabs, which might be confusing. Thoughts? Dan On 12 December 2014 at 13:15, GESCONSULTOR <[email protected]> wrote: > > Hi dan. > > I Remember hen you implemented contributions that I thought it was really > similar (in fact, more powerful). > > I've used it also in our domain, and works wonderfully. > > The point here is that the returning entity, instead of being showed as a > property with a link to open it, is fully opened as an "attached tab". > > That way we,be found is more intuitive for the user, as it naturally looks > at all tabs, containing each one information related to the main entity, > coming from different BCs. > > HTH, > > Oscar > > > > El 12/12/2014, a las 13:54, Dan Haywood <[email protected]> > escribió: > > > > Hi Oscar, > > > > this sounds like contributed properties and collections... something > > already implemented? > > > > The only difference is that we don't have put the contributions in > separate > > tabs; they are indistinguishable from "regular" properties/collections. > > > > For example, in the todo app the "relative priority" property is > > contributed, as is the "similar items" collection. Basically these are > > actions on services that take a single ToDoItem and return either a > single > > object (= contributed property) or a list of objects (= contributed > > collection). > > > > With respect to the validator, the usual hideXxx, disableXxx rules apply. > > > > Note that contributed properties can't be updated; but (in Estatio at > > least) we only now update using actions. > > > > Have I understand you correctly? > > > > Cheers > > Dan > > > > > > > >> On 12 December 2014 at 12:20, GESCONSULTOR <[email protected]> > wrote: > >> > >> > >> There is other Important UI hint we implemented, perhaps useful from the > >> DCI perspective, regarding showing as "attached tabs" to one entity's > form, > >> information returned from another action (from URLs like this case, > other > >> entity "extending" on other DDD module this one - for example, think of > >> another module holding information generating ToDoItems when a Task > >> -different Entity- is created. And we don't want to create a dependency > on > >> the ToDoItem module. In that case we want, when the user accesses the > >> ToDoItem page, to show the Task "attached" to it. > >> > >> For that we have an annotation on the action, indicating that the > >> resulting "object" must be showed as an "attached tab" (or any other > >> similar way) when showing entities of the specified class passed as an > >> annotation field. > >> > >> As an improvement, Per-entity a validation could be done (by means of a > >> validator class that receives the concrete entity showing, in order to > >> decide if for that concrete instance it can be showed (or perhaps not > >> showing if it's returning null). > >> > >> I don't have here my laptop but can provide an example tomorrow. > >> > >> thanks, > >> > >> Oscar > >> > >> >
