To clarify this, it's complementary to current implementation. Perhaps a hint on the action's annotation to show its "full" form Ina tab instead of as a property (with the corresponding link)?
> El 12/12/2014, a las 14:15, GESCONSULTOR <[email protected]> escribió: > > 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 >>> >>>
