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