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 > >
