You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by GESCONSULTOR <o....@gesconsultor.com> on 2014/12/12 13:20:07 UTC
Showing action results as tabs attached to entity pages
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
Re: Showing action results as tabs attached to entity pages
Posted by GESCONSULTOR <o....@gesconsultor.com>.
I think that current bookmarks place in the new viewer (at least for me) fulfills their role.
But I really miss them for entities ... :((
> El 12/12/2014, a las 14:29, Dan Haywood <da...@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 <da...@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
>>
Re: Showing action results as tabs attached to entity pages
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Many thanks, Dan.
> El 3/1/2015, a las 16:39, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>
> I've raised
> * ISIS-993 [1] - for splitting out object into multiple tabs and
> * ISIS-994 [2] - contributed properties that return a URL should be shown inline within an iframe.
>
>
> [1] https://issues.apache.org/jira/browse/ISIS-993
> [2] https://issues.apache.org/jira/browse/ISIS-994
>
>> On 13 December 2014 at 17:32, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
>> Hi to all.
>>
>> I've uploaded some screenshots.
>>
>> I'm going to explain different behaviors or implementation alternatives that perhaps are of interest, including the ones exposed on previous posts on this thread.
>>
>> On [1], you can see the general current appearance of our entity forms. Perhaps we wouldn't choose the toolbar paradigm right now, but it allows to keep all forms with similar look&feel and a predefined set of actions defined.
>>
>> The green menu button contains menu items for all factory methods of the current entity.
>> The grey one contains the available actions detected through Isis metadata.
>>
>> I'll explain on a coming thread an alternative implementation for default "entity delete" and "collection remove" actions.
>>
>> As you can see, there are 2 different rows of tabs: the outer ones (Contributed Tabs) and the inner ones (Views).
>>
>> *** ENTITY VIEWS ***
>>
>> On screenshot [2] I've identified the inner tabs.
>> Those are automatically generated as a complement to "sections". We call them "Views".
>> That way, we can divide entity properties and collections not only in sections, but also on different views. There's always a "General" view present by default.
>>
>> The annotations for Entities (@XMSViews) & Property (@XMSInViews - same property/collection could be shown in more than one view) can be used as in this example:
>>
>>
>> @XMSViews({ @XMSView(name = "Dependency Assets", sequence = 110), @XMSView(name = "Impacted Assets", sequence = 120),
>> @XMSView(name = "Associated Costs", sequence = 130) })
>> public abstract class Asset extends AbstractMultiTenantEntity {
>>
>> // {{ RelationshipsWithDirectlyImpactedAssets (Collection)
>> @Persistent(mappedBy = "sourceAsset", dependentElement = "false")
>> private SortedSet<Relationship> relationshipsWithDirectlyImpactedAssets = new TreeSet<Relationship>();
>>
>> @Named("(SUMMARY) Relationships - Directly Impacted Assets")
>> @XMSInViews("Impacted Assets", "Other View")
>> @MemberOrder(sequence = "999")
>> public SortedSet<Relationship> getRelationshipsWithDirectlyImpactedAssets() {
>> return this.relationshipsWithDirectlyImpactedAssets;
>> }
>>
>> public void setRelationshipsWithDirectlyImpactedAssets(final SortedSet<Relationship> relationshipsAsSource) {
>> this.relationshipsWithDirectlyImpactedAssets = relationshipsAsSource;
>> }
>>
>> // }}
>>
>> ...
>>
>> }
>>
>>
>> *** CONTRIBUTED VIEWS ***
>>
>> On screenshot [3], I've identified the contributed tabs.
>>
>> They should the result of a contributed action on a different tab, instead of being showed as a contributed property/collection.
>>
>> For example, in [4] you can see the form corresponding to the Entity returned by an action that has been properly annotated on a Service with @XMSContributedView (our current implementation is a bit different, as we were including translations on them; but I've preferred to simplify).
>>
>> public class AssetsBCMInformation extends AbstractSingletonMultiTenantObjectRepositoryAndFactory<AssetBCMInformation> {
>>
>> @NotContributed(As.EITHER)
>> @DescribedAs("Contains the detailed Business Continuity Requirements for a given Asset")
>> @ActionSemantics(Of.SAFE)
>> @XMSContributedView
>> public AssetBCMInformation businessContinuityInformation(@Named("Asset") final Asset asset) {
>> ...
>> }
>>
>> ...
>> }
>>
>>
>> Perhaps both Entity & Contributed Views could be showed all-together on the same tab control, without requiring two tab rows.
>>
>>
>> **** CONTRIBUTED VIEW REFERRING TO AN EXTERNAL URL ***
>>
>> On [5], the content of a Contributed View is an external URL (on this case is a highly customized diagram editor).
>>
>>
>> Hope all this helps to clarify past posts ... :)
>>
>>
>> Regards,
>>
>> Oscar
>>
>>
>> [1] http://s23.postimg.org/ndvn4huez/Main_Form.png
>> [2] http://postimg.org/image/xg7mbfvh9/
>> [3] http://postimg.org/image/ucxki507l/
>> [4] http://postimg.org/image/43plbkg7j/
>> [5] http://postimg.org/image/k83i6b70x/
>>
>>
>>
>>
>>
>>
>>
>>
>>> El 12/12/2014, a las 15:31, GESCONSULTOR <o....@gesconsultor.com> escribió:
>>>
>>>
>>> Ok.
>>>
>>> I'll send them this weekend.
>>>
>>>
>>>> El 12/12/2014, a las 14:47, Dan Haywood <da...@haywood-associates.co.uk> 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 <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 <da...@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 <dan@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
>>
>>
>> Óscar Bou Bou
>> Responsable de Producto
>> Auditor Jefe de Certificación ISO 27001 en BSI
>> CISA, CRISC, APMG ISO 20000, ITIL-F
>>
>> 902 900 231 / 620 267 520
>> http://www.twitter.com/oscarbou
>>
>> http://es.linkedin.com/in/oscarbou
>>
>> http://www.GesConsultor.com
>>
>>
>>
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>> Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
>
Re: Showing action results as tabs attached to entity pages
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
I've raised
* ISIS-993 [1] - for splitting out object into multiple tabs and
* ISIS-994 [2] - contributed properties that return a URL should be shown
inline within an iframe.
[1] https://issues.apache.org/jira/browse/ISIS-993
[2] https://issues.apache.org/jira/browse/ISIS-994
On 13 December 2014 at 17:32, GESCONSULTOR - Óscar Bou <
o.bou@gesconsultor.com> wrote:
> Hi to all.
>
> I've uploaded some screenshots.
>
> I'm going to explain different behaviors or implementation alternatives
> that perhaps are of interest, including the ones exposed on previous posts
> on this thread.
>
> On [1], you can see the general current appearance of our entity forms.
> Perhaps we wouldn't choose the toolbar paradigm right now, but it allows to
> keep all forms with similar look&feel and a predefined set of actions
> defined.
>
> The green menu button contains menu items for all factory methods of the
> current entity.
> The grey one contains the available actions detected through Isis metadata.
>
> I'll explain on a coming thread an alternative implementation for default
> "entity delete" and "collection remove" actions.
>
> As you can see, there are 2 different rows of tabs: the outer ones
> (Contributed Tabs) and the inner ones (Views).
>
> *** ENTITY VIEWS ***
>
> On screenshot [2] I've identified the inner tabs.
> Those are automatically generated as a complement to "sections". We call
> them "Views".
> That way, we can divide entity properties and collections not only in
> sections, but also on different views. There's always a "General" view
> present by default.
>
> The annotations for Entities (@XMSViews) & Property (@XMSInViews - same
> property/collection could be shown in more than one view) can be used as in
> this example:
>
>
> @XMSViews({ @XMSView(name = "Dependency Assets", sequence = 110),
> @XMSView(name = "Impacted Assets", sequence = 120),
> @XMSView(name = "Associated Costs", sequence = 130) })
> public abstract class Asset extends AbstractMultiTenantEntity {
>
> // {{ RelationshipsWithDirectlyImpactedAssets (Collection)
> @Persistent(mappedBy = "sourceAsset", dependentElement = "false")
> private SortedSet<Relationship>
> relationshipsWithDirectlyImpactedAssets = new TreeSet<Relationship>();
>
> @Named("(SUMMARY) Relationships - Directly Impacted Assets")
> @XMSInViews("Impacted Assets", "Other View")
> @MemberOrder(sequence = "999")
> public SortedSet<Relationship>
> getRelationshipsWithDirectlyImpactedAssets() {
> return this.relationshipsWithDirectlyImpactedAssets;
> }
>
> public void setRelationshipsWithDirectlyImpactedAssets(final
> SortedSet<Relationship> relationshipsAsSource) {
> this.relationshipsWithDirectlyImpactedAssets =
> relationshipsAsSource;
> }
>
> // }}
>
> ...
>
> }
>
>
> *** CONTRIBUTED VIEWS ***
>
> On screenshot [3], I've identified the contributed tabs.
>
> They should the result of a contributed action on a different tab, instead
> of being showed as a contributed property/collection.
>
> For example, in [4] you can see the form corresponding to the Entity
> returned by an action that has been properly annotated on a Service with
> @XMSContributedView (our current implementation is a bit different, as we
> were including translations on them; but I've preferred to simplify).
>
> public class AssetsBCMInformation extends
> AbstractSingletonMultiTenantObjectRepositoryAndFactory<AssetBCMInformation>
> {
>
> @NotContributed(As.EITHER)
> @DescribedAs("Contains the detailed Business Continuity Requirements
> for a given Asset")
> @ActionSemantics(Of.SAFE)
> @XMSContributedView
> public AssetBCMInformation
> businessContinuityInformation(@Named("Asset") final Asset asset) {
> ...
> }
>
> ...
> }
>
>
> Perhaps both Entity & Contributed Views could be showed all-together on
> the same tab control, without requiring two tab rows.
>
>
> **** CONTRIBUTED VIEW REFERRING TO AN EXTERNAL URL ***
>
> On [5], the content of a Contributed View is an external URL (on this case
> is a highly customized diagram editor).
>
>
> Hope all this helps to clarify past posts ... :)
>
>
> Regards,
>
> Oscar
>
>
> [1] http://s23.postimg.org/ndvn4huez/Main_Form.png
> [2] http://postimg.org/image/xg7mbfvh9/
> [3] http://postimg.org/image/ucxki507l/
> [4] http://postimg.org/image/43plbkg7j/
> [5] http://postimg.org/image/k83i6b70x/
>
>
>
>
>
>
>
>
> El 12/12/2014, a las 15:31, GESCONSULTOR <o....@gesconsultor.com>
> escribió:
>
>
> Ok.
>
> I'll send them this weekend.
>
>
> El 12/12/2014, a las 14:47, Dan Haywood <da...@haywood-associates.co.uk>
> 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 <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 <da...@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 <dan@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
>
>
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> 902 900 231 / 620 267 520
> http://www.twitter.com/oscarbou
>
> http://es.linkedin.com/in/oscarbou
>
> http://www.GesConsultor.com <http://www.gesconsultor.com/>
>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo -
> 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia).
> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
> adjuntos no contengan virus informáticos, y en caso que los tuvieran
> eliminarlos.
>
>
>
>
>
>
Re: Showing action results as tabs attached to entity pages
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Hi to all.
I've uploaded some screenshots.
I'm going to explain different behaviors or implementation alternatives that perhaps are of interest, including the ones exposed on previous posts on this thread.
On [1], you can see the general current appearance of our entity forms. Perhaps we wouldn't choose the toolbar paradigm right now, but it allows to keep all forms with similar look&feel and a predefined set of actions defined.
The green menu button contains menu items for all factory methods of the current entity.
The grey one contains the available actions detected through Isis metadata.
I'll explain on a coming thread an alternative implementation for default "entity delete" and "collection remove" actions.
As you can see, there are 2 different rows of tabs: the outer ones (Contributed Tabs) and the inner ones (Views).
*** ENTITY VIEWS ***
On screenshot [2] I've identified the inner tabs.
Those are automatically generated as a complement to "sections". We call them "Views".
That way, we can divide entity properties and collections not only in sections, but also on different views. There's always a "General" view present by default.
The annotations for Entities (@XMSViews) & Property (@XMSInViews - same property/collection could be shown in more than one view) can be used as in this example:
@XMSViews({ @XMSView(name = "Dependency Assets", sequence = 110), @XMSView(name = "Impacted Assets", sequence = 120),
@XMSView(name = "Associated Costs", sequence = 130) })
public abstract class Asset extends AbstractMultiTenantEntity {
// {{ RelationshipsWithDirectlyImpactedAssets (Collection)
@Persistent(mappedBy = "sourceAsset", dependentElement = "false")
private SortedSet<Relationship> relationshipsWithDirectlyImpactedAssets = new TreeSet<Relationship>();
@Named("(SUMMARY) Relationships - Directly Impacted Assets")
@XMSInViews("Impacted Assets", "Other View")
@MemberOrder(sequence = "999")
public SortedSet<Relationship> getRelationshipsWithDirectlyImpactedAssets() {
return this.relationshipsWithDirectlyImpactedAssets;
}
public void setRelationshipsWithDirectlyImpactedAssets(final SortedSet<Relationship> relationshipsAsSource) {
this.relationshipsWithDirectlyImpactedAssets = relationshipsAsSource;
}
// }}
...
}
*** CONTRIBUTED VIEWS ***
On screenshot [3], I've identified the contributed tabs.
They should the result of a contributed action on a different tab, instead of being showed as a contributed property/collection.
For example, in [4] you can see the form corresponding to the Entity returned by an action that has been properly annotated on a Service with @XMSContributedView (our current implementation is a bit different, as we were including translations on them; but I've preferred to simplify).
public class AssetsBCMInformation extends AbstractSingletonMultiTenantObjectRepositoryAndFactory<AssetBCMInformation> {
@NotContributed(As.EITHER)
@DescribedAs("Contains the detailed Business Continuity Requirements for a given Asset")
@ActionSemantics(Of.SAFE)
@XMSContributedView
public AssetBCMInformation businessContinuityInformation(@Named("Asset") final Asset asset) {
...
}
...
}
Perhaps both Entity & Contributed Views could be showed all-together on the same tab control, without requiring two tab rows.
**** CONTRIBUTED VIEW REFERRING TO AN EXTERNAL URL ***
On [5], the content of a Contributed View is an external URL (on this case is a highly customized diagram editor).
Hope all this helps to clarify past posts ... :)
Regards,
Oscar
[1] http://s23.postimg.org/ndvn4huez/Main_Form.png
[2] http://postimg.org/image/xg7mbfvh9/
[3] http://postimg.org/image/ucxki507l/
[4] http://postimg.org/image/43plbkg7j/
[5] http://postimg.org/image/k83i6b70x/
> El 12/12/2014, a las 15:31, GESCONSULTOR <o....@gesconsultor.com> escribió:
>
> Ok.
>
> I'll send them this weekend.
>
>
>> El 12/12/2014, a las 14:47, Dan Haywood <da...@haywood-associates.co.uk> 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 <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 <da...@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 <dan@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
>>>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou <http://www.twitter.com/oscarbou>
http://es.linkedin.com/in/oscarbou <http://es.linkedin.com/in/oscarbou>
http://www.GesConsultor.com <http://www.gesconsultor.com/>
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: Showing action results as tabs attached to entity pages
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Ok.
I'll send them this weekend.
> El 12/12/2014, a las 14:47, Dan Haywood <da...@haywood-associates.co.uk> 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 <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 <da...@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 <dan@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
>>
Re: Showing action results as tabs attached to entity pages
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@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 <dan@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
> >>
>
Re: Showing action results as tabs attached to entity pages
Posted by GESCONSULTOR <o....@gesconsultor.com>.
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 <da...@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 <da...@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
>>
Re: Showing action results as tabs attached to entity pages
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@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
> >>
> >>
>
Re: Showing action results as tabs attached to entity pages
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Not sure I follow.
On 12 December 2014 at 13:29, GESCONSULTOR <o....@gesconsultor.com> wrote:
>
> 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 <o....@gesconsultor.com>
> 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 <da...@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
> >>>
> >>>
>
Re: Showing action results as tabs attached to entity pages
Posted by GESCONSULTOR <o....@gesconsultor.com>.
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 <o....@gesconsultor.com> 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 <da...@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
>>>
>>>
Re: Showing action results as tabs attached to entity pages
Posted by GESCONSULTOR <o....@gesconsultor.com>.
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 <da...@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
>>
>>
Re: Showing action results as tabs attached to entity pages
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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
>
>