Also, not sure about the default... I think that they should be shown by default on the same page.
At least, is our current implementation and is working nicely. Sorry ... :) > El 12/12/2014, a las 14:29, Dan Haywood <d...@haywood-associates.co.uk> > escribió: > > 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 <o....@gesconsultor.com> 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 <d...@haywood-associates.co.uk> >>> 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 <o....@gesconsultor.com> >> 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 >>
