Another thought, the pause after each change of parameter state in the
modal dialogue is no-doubt part of the Wicket server-side approach and
cannot be changed easily, but the slight background dimming with each such
change seems an unnecessary distraction, given the background is already
darkened. I'll look into this myself eventually.
On Thu, Sep 29, 2016 at 7:29 AM, Stephen Cameron <steve.cameron...@gmail.com
> wrote:
> Hi All,
>
> Good discussion going on, as usual, my first response to this was that
> Martin's requirement is just as Oscar describes, to make the new
> entity/instance a member of the 'options' list and the currently selected
> member of that list.
>
> Then I thought that it just satisifies an edge case, of them creating a
> new instance, deciding its not what they wanted to do, unselecting the new
> member, then changing their mind again and reselecting the new member.
>
> This would be the normal behaviour in most UI frameworks though, so its
> probably better to have it that way.
>
> Changing the subject, to something that is kind of related, when you
> choose or enter a parameter value in a model dialog in the Wicket Viewer it
> pauses each time (the background dims slightly), I presume as that change
> of UI state is communicated back to the server. To me it would be really
> nice if this didn't happen, and that the only pause is when you select OK
> to confirm that the action should proceed.
>
> Maybe these pauses are necessary when you have to call a factory method to
> instantiate a new object for a list, but otherwise it seems to the user
> that they are filling in a form within the modal dialog, that they then
> submit by clicking OK.
>
> Steve
>
>
>
>
>
> On Thu, Sep 29, 2016 at 4:56 AM, Dan Haywood <d...@haywood-associates.co.uk
> > wrote:
>
>> Hi Oscar,
>> thanks for this. Could you sketch out what that might look like in terms
>> of (an extension to) Isis' annotations?
>> Cheers
>> Dan
>>
>>
>> On 28 September 2016 at 18:24, Óscar Bou - GOVERTIS <o....@govertis.com>
>> wrote:
>>
>>>
>>> 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 e: o....@govertis.com
>>>
>>> LinkedIn: 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.
>>>
>>>
>>
>
