Ok. I'll send them this weekend.
> El 12/12/2014, a las 14:47, Dan Haywood <[email protected]> > escribió: > > Some screenshots/sketches would probably be useful; I'm not certain I'm > following everything you're saying here. > > >> On 12 December 2014 at 13:37, GESCONSULTOR <[email protected]> wrote: >> >> 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 <[email protected]> >>> 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 <[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 >>
