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 <o....@gesconsultor.com> 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 <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 > >> >
