In our custom viewer, we have a specific annotation to identify Factory Methods.
We infer from the returned type the associated class they are able to
instantiate.
That way, we can draw a drop-down menu associated with a button, present in any
param requiring an entity of that class.
When a factory method menu is selected, the modal dialog associated with that
factory method action is shown, and if executed successfully, when the modal
dialog closes, the params combos are refreshed (if not dinamically loaded at
drop down).
I think that’s Martin’s initial requirement.
It’s also a quite generic solution.
HTH,
Oscar
> El 28 sept 2016, a las 16:02, Stephen Cameron <steve.cameron...@gmail.com>
> escribió:
>
> Hi,
>
> I'll briefly give my experiences, but first I have to admit that I've need
> to break some old habits, but I am still learning. I think the best way to
> think about Isis is in the OO manner of object methods being messages, that
> in triggering an action you are telling the object to do something, by
> passing a message. Do have a look at Estatio as a complex Isis Application,
> lots of action (buttons) used in places where they are most
> useful/logical/intuitive.
>
> My current idea on developing with Isis is to forget about the UI
> initially, and instead focus on creating fixtures and integration tests.
> My 'messages' start out as XML data and then this gets parsed into the
> domain model in the fixtures, and the integration test is simply checking
> that what was in the XML hierarchical structure is now in Java objects and
> hence the database.
>
> This is not a proven approach, but it does seem to me to have promise as a
> good way to build a solid foundation. The general test-driven approach is
> what most would recommend, but my angle is that the system UI will evolve
> easily from this evolving domain model foundation, as your understanding
> increases, in an agile way. I can explain this in more detail if you are
> interested to try it.
>
> I've added some comments inline below
>
> On Wed, Sep 28, 2016 at 10:00 PM, Martin <mwhesse+apachem...@gmail.com>
> wrote:
>
>> Thanks for your replies.
>>
>> You are right Dan, if the location was a more complex structure than just a
>> string this would of course clutter up the create dialogue of the concert.
>>
>> Stephen: that's an interesting approach. Let's say the user creates a
>> concert and leaves the location empty. Then per se this is a valid business
>> object (even though one attribute is missing). How would one go about
>> reminding/obliging the user to complete/finalize the object by going back
>> to the concert entity page to update/create a location?
>>
>> I struggled with this issue initially, but the answer is that you collect
> all the mandatory requirements in one hit to create a valid object. Then
> when DataNucleus creates the database record all the non-null 'columns' are
> filled. You can end up with a big list of requirements in some cases, but
> for me this eventually became a regular pattern in the UI anyway. I provide
> 'Update' actions for big fieldsets with the UI, these allow you to edit the
> set as a group of properties. There is quite a bit of coding to do this,
> and when you are used to HTML forms it seems silly to have to do it at
> first, but it once its done its easy to test and maintain, that is the
> Apache Isis payback IMO. For users this approach is kind of like a
> workflow, just traverse a new object clicking all the Update buttons in the
> fieldset name panels. Tabs made this even more so.
>
>
>> A few more thoughts on the topic:
>>
>> Inline creation of referenced entities from within a create dialogue in my
>> mind is a great way to streamline the usage of the any application, because
>> otherwise the user would have to remember what he has to do in which order.
>> For instance: before creating an entity A, he would have to know whether
>> all the non trivial / referenced entities of that entity A are already in
>> the database, or he would have to go and look it up.
>>
>> If A only references one other entity this approach may seem pretty easy,
>> but let's say A references 3 or 4 or 5 other entities, then this becomes
>> less straight forward.
>>
>
> When this is likely I have two actions, usually for collections, an 'Add'
> and an 'Add New' action. The Add will have a single parameter with list of
> existing entities, the Add New will collect the required property values
> for a valid new entity. The Add New just passes the values to an injected
> domain service to create the new object.
>
> I also suggest that the bookmarks in Isis are really useful to users, its
> not a big deal to skip off to another object and then come back to one you
> were recently at via the bookmarks. I think this would be something from
> the Naked Objects heritage of Isis, where multiple objects where visible.
>
>>
>> I also read another post the other day asking whether the framework
>> supports workflows. As far as I can tell a lot (most?) of the workflows out
>> there actually handle just that: offering the user the choice to select an
>> existing item or to create a new one and then continue with the next step,
>> thus aggregating a complex data structure little by little and most
>> importantly taking away from the user the burden of having to know too much
>> about which data already exists in the model.
>>
>> I think offering the capability of creating entities from within the create
>> dialogue in Apache Isis would already tackle a great portion of existing
>> requirements for anything resembling a workflow at much smaller costs than
>> introducing a complete new workflow system.
>>
>
> There is a workflow module part done, but interest in it doesn't seem
> sufficient to finish it off (?), which is evidence in support of your
> hypothesis. Workflows have their place, but to my mind using OO programming
> is not an big advantage in that place, so use something other than Apache
> Isis.
>
>>
>> In the last days have caught myself thinking about how my design of the
>> domain model would affect the usability of the application, especially
>> since I was taking into account the order in which things would have to be
>> done when the domain model gets more complex, just because of the fact that
>> one has to currently make sure certain things have to exist before others
>> (or as a matter of fast having to cancel a "create" action and go somewhere
>> else and come back, which could be frustrating too). From a purely
>> theoretical perspective a domain model should be free from such influences.
>>
>> What do you think?
>>
>
> The bookmarks comment is relevant.
>
> Read up on Evans's 'Domain Driven Design' is my strong suggestion, if users
> understand the domain design in terms of familiar class names,
> relationships, action names, then you are most of the way home.
>
> My thinking is that there are two kinds of data, static and dynamic, the
> static is a pretty constant and unchanging set and you usually want to
> control how new objects get created otherwise you can end up with messy
> data ("I couldn't see it in the list so I created another one"). [Dan's
> 'findOrCreate(String name)' approach is one simple solution, but if you
> want to enforce referential integrity at the database level but not have
> everything appear as an object link, it gets a bit more complex I found,
> see derived properties]
>
> In contrast dynamic is something that changes frequently (new members added
> to set, property values inserted or updated, new children added). Most
> domain models IMO are like this, things inside the domain that are complex
> and dynamic, things outside the domain, relatively static, beyond our
> control but still of interest, and often represented inside the domain
> model just by identifiers or names [In an ideal world such data would just
> be all be provided by web-services, such as envisaged in the semantic web]
>
> I hope this is helpful. Just browsing the documentation from cover-to-cover
> before coding is also a good idea, there is alot to learn about, thanks to
> Dan and others.
>
>>
>> Thx,
>> Martin
>>
>>
>> On Wed, Sep 28, 2016 at 6:11 PM, Dan Haywood <d...@haywood-associates.co.uk
>>>
>> wrote:
>>
>>> Thanks for these ideas, Steve.
>>>
>>> Which in turn reminds me... we have an existing module for modelling
>>> communication channels [1] that could be used/forked as the basis for
>>> handling locations. (If you want all the gmap location stuff, that is).
>>>
>>> Cheers
>>> Dan
>>>
>>>
>>> [1] https://github.com/incodehq/incode-module-commchannel
>>>
>>> On 28 September 2016 at 11:48, Stephen Cameron <
>> steve.cameron...@gmail.com
>>>>
>>> wrote:
>>>
>>>> Another option to try, assuming that the Concert has been created
>>> already,
>>>> is to have an action on, or contributed to, the Concert that allows
>>>> creation of a new ConcertLocation. Then the user can either set the
>>> concert
>>>> location by choosing an existing location from the pick list, or by
>>>> creating an new one via the action. The location property and the
>> action
>>>> can be associated via the layout.xml or annotation means.
>>>>
>>>> I use another alternative, which is more complex, for setting activity
>>>> addresses, which is to have 'named' addresses, these are addresses used
>>>> often for different activities. So the 'Update Address' action has a
>>>> picklist of existing named addresses, or you can create a new address
>> by
>>>> filling in street1, street2, suburb. But if you give that new address a
>>>> name as well (e.g XYZ Community Hall) it becomes a new named address.
>>>>
>>>> So the Update Address action has 5 parameters, a list of existing named
>>>> addresses, a name for a new address, street1,street2, a list of
>> suburbs.
>>>>
>>>>
>>>>
>>>> On Wed, Sep 28, 2016 at 7:48 PM, Dan Haywood <
>>> d...@haywood-associates.co.uk
>>>>>
>>>> wrote:
>>>>
>>>>> Hi Martin,
>>>>>
>>>>> This requirement has only come up infrequently so far, not
>> sufficiently
>>>> to
>>>>> build a particular widget or programming model for it.
>>>>>
>>>>> Where we have required it, we've simply provided two optional
>>> parameters,
>>>>> one listing the existing objects, the other for the name of a new
>>> object.
>>>>> (This assumes that a single string is sufficient to create said new
>>>>> object).
>>>>>
>>>>> public Concert create(@Nullable ConcertLocation
>>>>> existingConcertLocation, @Nullable String newConcertLocationName,
>>> String
>>>>> concertName) {
>>>>>
>>>>> ConcertLocation concertLocation =
>>>>> existingConcertLocation != null
>>>>> ? existingConcertLocation
>>>>> : concertLocationRepository.findOrCreate(
>>> newConcertLocationNam
>>>> e);
>>>>>
>>>>> return concertRepository.create(concertName, concertLocation);
>>>>> }
>>>>> public String validateCreate(ConcertLocation existingConcertLocation,
>>>>> String newConcertLocationName, String concertName) {
>>>>> if (existingConcertLocation == null && newConcertLocationName ==
>>>> null)
>>>>> return "Specify either an existing location or the name of a new
>> one";
>>>>> if (existingConcertLocation != null && newConcertLocationName !=
>>>> null)
>>>>> return "Specify either an existing location or the name of a new
>> one";
>>>>> return null;
>>>>> }
>>>>>
>>>>> However, that has the side effect of cluttering up the common use
>> case
>>>> (new
>>>>> Concert in an existing ConcertLocation), so I don't know if it's
>> worth
>>>> the
>>>>> effort. My recommendation would simply be to treat the creation of
>>>> concert
>>>>> locations and of new concerts independently.
>>>>>
>>>>> HTH
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 28 September 2016 at 09:32, Martin <mwhesse+apachem...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Let's say we have an entity Concert and an entity ConcertLocation
>> and
>>>> the
>>>>>> model is such that a Concert would reference a ConcertLocation
>>> (shared
>>>>>> ManyToOne association).
>>>>>>
>>>>>> In a create dialogue for the Concert entity I would like to offer
>> the
>>>>>> possibility to create a new ConcertLocation item if the desired
>>>> location
>>>>> is
>>>>>> not found in the dropdown or select box.
>>>>>>
>>>>>> This could for instance be by displaying a "create new location"
>> icon
>>>>> next
>>>>>> to the dropdown box for locations or anything else, which would
>> then
>>>> open
>>>>>> another modal on top of the create dialogue to create that
>>>>>> new ConcertLocation.
>>>>>>
>>>>>> Once the new ConcertLocation has been created it should then appear
>>> in
>>>>> the
>>>>>> list of available locations in the Concert create dialogue.
>>>>>>
>>>>>> How would I go about this in Apache Isis?
>>>>>>
>>>>>> I haven't found anything of the kind in the kitchen sink or the
>> todo
>>>> app
>>>>> or
>>>>>> any other examples available.
>>>>>>
>>>>>> Thanks and regards,
>>>>>> Martin
>>>>>>
>>>>>
>>>>
>>>
>>
Óscar Bou Bou
Socio - IT & GRC Management Services Director
m: +34 620 267 520
s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e:
o....@govertis.com <mailto:o....@govertis.com>
LinkedIn: https://www.linkedin.com/in/oscarbou
<https://www.linkedin.com/in/oscarbou>
Twitter: @oscarbou <https://twitter.com/oscarbou>
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 GOVERTIS ADVISORY SERVICES, 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:
GOVERTIS ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015 -
Valencia, y Paseo de la Castellana, 153, 28045 - MADRID. Asimismo, es su
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan
virus informáticos, y en caso que los tuvieran eliminarlos.
