could you sketch a quick code example, eg with Martin's original Concert
example... guess I'm being dumb, but I don't quite get it.
thx
Dan
On 29 September 2016 at 09:20, Óscar Bou - GOVERTIS <o....@govertis.com>
wrote:
> Hi, Dan.
>
> In our case it’s a top level annotation with any params.
>
> But probably on Isis it should be part of the @Action annotation.
>
> Important here is that, despite seeming that factory methods should have
> always “non-idempotent” semantics, if before creating the new instance, you
> verify it does not previously exists in the database and not create (only
> update) if so - an UPSERT operation - it would become an idempotent factory
> method.
>
> So we cannot infer from being a factory method that it’s an idempotent or
> non-idempotent action.
>
> We usually prefer non-idempotent actions as factory methods, but we have
> also some actions being both an idempotent and factory methods.
>
>
> Regards,
>
> Oscar
>
>
>
> El 28 sept 2016, a las 20:56, Dan Haywood <d...@haywood-associates.co.uk>
> escribió:
>
> 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.
>>
>>
>
>
> Ó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.
>
>
