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 <[email protected]> escribió:
> 
> 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
>>> 


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





Reply via email to