You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Martin <mw...@gmail.com> on 2016/09/28 08:32:10 UTC
choices / autocomplete with option to create new item
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
Re: choices / autocomplete with option to create new item
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 28 September 2016 at 14:30, Rade, Joerg / Kuehne + Nagel / Ham GI-DP <
Joerg.Rade@kuehne-nagel.com> wrote:
> Hi,
>
> one could probably disable certain actions like sending concert
> announcements until all preconditions are fulfilled (date, artists,
> location set), but how can the missing data be signaled to the user?
>
>
Interesting requrement. I suppose one way to do this could be to use CSS
to tag individual properties, and then have the CSS be set dynamically (as
opposed to statically as it is now within .layout.xml).
To do that would require a new implementation of CssFacet that could listen
to some sort of domain event subscriber and use that to set the CSS for
properties that are required. That would certainly be a very general
purpose solution, and probably quite easy to hack together. If there's
interest, I'll see if I can spike it.
> Instead of hardcoding the logic into disableAnnouncement, a set of rules
> could be used controlling the transition of the domain model from
> State.IN_PREPARATION to State.READY.
>
>
For this type of stuff I quite like to put into a domain event subscriber,
as it centralizes the rules.
> It would be nice if the rules could be made transparent to the user and
> thereby educating him from a process follower to a problem solver.
>
>
+1 on that.
> My 2c
> -j
> -----Ursprüngliche Nachricht-----
> Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
> Gesendet: Mittwoch, 28. September 2016 14:46
> An: users; mwhesse+apachemail@gmail.com
> Betreff: Re: choices / autocomplete with option to create new item
>
> On 28 September 2016 at 13:00, Martin <mw...@gmail.com>
> wrote:
>
>
>
> >
> >
> > 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?
> >
> >
>
> In general we discourage workflows... let the user navigate the domain in
> whichever way they wish. So your instinct is correct... just model the
> domain, but without worrying too much about how it is going to be
> rendered. I notice you talked about "pages", but that's a technical
> vocabulary; focus on the responsibilities underlying domain object itself.
>
> More generally, on the topic of workflows, there's a whole philosophy
> about this... problem solvers vs process followers, see eg [1]. The naked
> objects paradigm leans (quite heavily) towards the former.
>
> For high volume use cases - once the "desire lines" [2] have been
> discovered - then view models can be used to support those cases.
>
> For example, in Estatio [3] we generate 120 invoices at a time (one for
> each tenant of the shopping center). These get approved in bulk using an
> InvoiceSummary view model; it's responsibilities are to find all pending
> invoices for a property and present them to the user.
>
> We are currently in the process of extending this functionality to be able
> to bulk generate a (PDF) document of all invoice and then to email these
> documents to tenants. The way I am tackling this is to provide the
> capability to create a document for a single invoice, and then to email a
> single document. After that, the InvoiceSummary can provide the ability to
> do this in bulk (and to act as a "dashboard" of sorts for the users to
> verify that all emails have been sent).
>
> Hope that helps
>
> Dan
>
>
> [1]
> https://github.com/incodehq/radrace2015#app-requirements-
> actually-not-a-problem
> [2] https://sugoru.files.wordpress.com/2012/09/desire-line.png?w=651
> [3] http://isis.apache.org/powered-by.html#_powered-by_estatio
>
> Kühne + Nagel (AG & Co.) KG
> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
> 812773878.
> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Yngve Ruud (Vors.), Martin
> Brinkmann, Matthias Heimbach, Jan-Hendrik Köstergarten, Nicholas Minde,
> Michael Nebel, Lars Wedel.
> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:
> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
> Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Diederick de
> Vroet, Dominic Edmonds, Thierry Held, Uwe Hött, Richard Huhn, Björn
> Johansson, Holger Ketz, Jan Kunze.
>
> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
> Spediteurbedingungen 2016 (ADSp 2016). Die ADSp 2016 beschränken in Ziffer
> 23 die gesetzliche Haftung für Güterschäden in Höhe von 8,33 SZR/kg je
> Schadenfall bzw. je Schadenereignis auf 1 Million bzw. 2 Millionen Euro
> oder 2 SZR/kg, je nachdem, welcher Betrag höher ist, und bei multimodalen
> Transporten unter Einschluss einer Seebeförderung generell auf 2 SZR/kg.
> Den vollständigen Text der ADSp 2016 übersenden wir Ihnen gerne auf Anfrage
> und können Sie auch unter http://www.kuehne-nagel.com einsehen.
>
AW: choices / autocomplete with option to create new item
Posted by "Rade, Joerg / Kuehne + Nagel / Ham GI-DP" <Jo...@Kuehne-Nagel.com>.
Hi,
one could probably disable certain actions like sending concert announcements until all preconditions are fulfilled (date, artists, location set), but how can the missing data be signaled to the user?
Instead of hardcoding the logic into disableAnnouncement, a set of rules could be used controlling the transition of the domain model from State.IN_PREPARATION to State.READY.
It would be nice if the rules could be made transparent to the user and thereby educating him from a process follower to a problem solver.
My 2c
-j
-----Ursprüngliche Nachricht-----
Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
Gesendet: Mittwoch, 28. September 2016 14:46
An: users; mwhesse+apachemail@gmail.com
Betreff: Re: choices / autocomplete with option to create new item
On 28 September 2016 at 13:00, Martin <mw...@gmail.com> wrote:
>
>
> 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?
>
>
In general we discourage workflows... let the user navigate the domain in whichever way they wish. So your instinct is correct... just model the domain, but without worrying too much about how it is going to be rendered. I notice you talked about "pages", but that's a technical vocabulary; focus on the responsibilities underlying domain object itself.
More generally, on the topic of workflows, there's a whole philosophy about this... problem solvers vs process followers, see eg [1]. The naked objects paradigm leans (quite heavily) towards the former.
For high volume use cases - once the "desire lines" [2] have been discovered - then view models can be used to support those cases.
For example, in Estatio [3] we generate 120 invoices at a time (one for each tenant of the shopping center). These get approved in bulk using an InvoiceSummary view model; it's responsibilities are to find all pending invoices for a property and present them to the user.
We are currently in the process of extending this functionality to be able to bulk generate a (PDF) document of all invoice and then to email these documents to tenants. The way I am tackling this is to provide the capability to create a document for a single invoice, and then to email a single document. After that, the InvoiceSummary can provide the ability to do this in bulk (and to act as a "dashboard" of sorts for the users to verify that all emails have been sent).
Hope that helps
Dan
[1]
https://github.com/incodehq/radrace2015#app-requirements-actually-not-a-problem
[2] https://sugoru.files.wordpress.com/2012/09/desire-line.png?w=651
[3] http://isis.apache.org/powered-by.html#_powered-by_estatio
Kühne + Nagel (AG & Co.) KG
Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878.
Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Yngve Ruud (Vors.), Martin Brinkmann, Matthias Heimbach, Jan-Hendrik Köstergarten, Nicholas Minde, Michael Nebel, Lars Wedel.
Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Diederick de Vroet, Dominic Edmonds, Thierry Held, Uwe Hött, Richard Huhn, Björn Johansson, Holger Ketz, Jan Kunze.
Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen Spediteurbedingungen 2016 (ADSp 2016). Die ADSp 2016 beschränken in Ziffer 23 die gesetzliche Haftung für Güterschäden in Höhe von 8,33 SZR/kg je Schadenfall bzw. je Schadenereignis auf 1 Million bzw. 2 Millionen Euro oder 2 SZR/kg, je nachdem, welcher Betrag höher ist, und bei multimodalen Transporten unter Einschluss einer Seebeförderung generell auf 2 SZR/kg. Den vollständigen Text der ADSp 2016 übersenden wir Ihnen gerne auf Anfrage und können Sie auch unter http://www.kuehne-nagel.com einsehen.
Re: choices / autocomplete with option to create new item
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 28 September 2016 at 13:00, Martin <mw...@gmail.com> wrote:
>
>
> 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?
>
>
In general we discourage workflows... let the user navigate the domain in
whichever way they wish. So your instinct is correct... just model the
domain, but without worrying too much about how it is going to be
rendered. I notice you talked about "pages", but that's a technical
vocabulary; focus on the responsibilities underlying domain object itself.
More generally, on the topic of workflows, there's a whole philosophy about
this... problem solvers vs process followers, see eg [1]. The naked
objects paradigm leans (quite heavily) towards the former.
For high volume use cases - once the "desire lines" [2] have been
discovered - then view models can be used to support those cases.
For example, in Estatio [3] we generate 120 invoices at a time (one for
each tenant of the shopping center). These get approved in bulk using an
InvoiceSummary view model; it's responsibilities are to find all pending
invoices for a property and present them to the user.
We are currently in the process of extending this functionality to be able
to bulk generate a (PDF) document of all invoice and then to email these
documents to tenants. The way I am tackling this is to provide the
capability to create a document for a single invoice, and then to email a
single document. After that, the InvoiceSummary can provide the ability to
do this in bulk (and to act as a "dashboard" of sorts for the users to
verify that all emails have been sent).
Hope that helps
Dan
[1]
https://github.com/incodehq/radrace2015#app-requirements-actually-not-a-problem
[2] https://sugoru.files.wordpress.com/2012/09/desire-line.png?w=651
[3] http://isis.apache.org/powered-by.html#_powered-by_estatio
Re: choices / autocomplete with option to create new item
Posted by Stephen Cameron <st...@gmail.com>.
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.62@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 <dan@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.62@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 <mw...@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 <
>>> dan@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.62@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 <
>>>
>>> dan@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 <mw...@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.bou@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.
>>>
>>>
>>
>
Re: choices / autocomplete with option to create new item
Posted by Stephen Cameron <st...@gmail.com>.
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 <da...@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 <st...@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 <mw...@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 <
>> dan@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.62@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 <
>>
>> dan@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 <mw...@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.bou@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.
>>
>>
>
Re: choices / autocomplete with option to create new item
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
thanks, oscar.
On 1 October 2016 at 23:34, Óscar Bou - GOVERTIS <o....@govertis.com> wrote:
>
> Hi all.
>
> I’ve just created a Jira ticket [1] and a PR at [2] that allows to define
> a Factory Method this way:
>
> class Concert {
>
> @Action(factoryMethod=true)
> public Concert someAction() {
> return new Concert();
> }
> }
>
>
> Factory Methods cannot return void, but no other restriction has been
> applied by now (i.e., should we limit it to Domain Entities? ).
>
> Further work should be done at the UI level.
> As a workflow example:
> - When executing an Action, add a drop-down menu to show all Factory
> Methods whose returned class is assignable from the param’s class.
> - When clicked, launch the action’s modal dialog, overlapping the original
> action invocation dialog.
> - When returning from the factory method invocation to the original action
> invocation dialog, if the factory method’s action :
> - has been successfully executed, the returned object should be the
> param’s currently selected value.
> - has been cancelled, the param’s currently selected value is not changed.
>
>
>
>
> HTH,
>
> Oscar
>
> [1] https://issues.apache.org/jira/browse/ISIS-1509
> [2] https://github.com/apache/isis/pull/55/files
>
>
>
>
>
> El 30 sept 2016, a las 5:07, David Tildesley <da...@yahoo.co.nz.INVALID>
> escribió:
>
> Hi All,
>
> Imho:
>
> Putting the "don't do CRUD" principle spin on this: Isn't it just a matter
> of allowing a "Concert" component (I call it component since it will have
> several objects that are associated with the primary moment-interval)
> instance to be "built up" until it can be "published"? All you need is a
> "canPublish()" method returning a boolean that does all the necessary
> checks to ensure all the required bits and bobs are in place before
> "publishing" it (for want of a better term). Why are you wanting to create
> a rod for you own back by having database constraints to enforce business
> logic when you can enforce the constraints in logic in your code with more
> flexibility? I may be wrong, but I think the Naked Object model would force
> you take this approach because you are only allowed to "see" domain objects
> in the viewer. Use of view models will tend to take you in the other
> direction - caution needed. Conflating "view" aspects with "domain" aspects
> will make the situation worse.
>
> Next make sure you have firmly in your mind the separation of UI concerns
> from domain layer concerns - don't conflate them. If you need to create
> some view models to build aggregate forms or a wizard - because that is
> what your users demand just remember the separation of concerns principle
> - view models are UI, not domain layer and they will tend to cause you to
> compromise the domain layer/model if you are not fastidious about this.
>
> By the way, it is next to impossible to have this discussion without a
> proper domain model available - if there is no domain model available then
> you are already traveling an unsound path.
>
> Regards,
>
> David.
>
> On 30-Sep-16 12:37 PM, Stephen Cameron wrote:
>
> Hi Martin,
>
> Just a few thoughts in response inline.
>
> On Fri, Sep 30, 2016 at 12:51 AM, Martin <mw...@gmail.com>
> wrote:
>
> Thanks all for your replies and your input.
>
> The DDD book was actually one of the books I bought many years ago and
> enjoyed reading a lot. I still recommend it to friends and colleagues.
>
> :) Which probably led you to trying Apache Isis?
>
> I gave Stephens idea a second thought and tried out this approach today.
> For the association of more complex objects, like let's say a
> ConcertLocation which cannot be created from within the Concert dialogue
> there is a Fixture creating a dummy placeholder ConcertLocation object,
> which can be selected instead, and the Concert entity has an action to
> create a new ConcertLocation, so that things can be corrected after
> creation.
>
> I'm don't think this is the best approach to take, if a Concert must have a
> concert location then offer the user two options in the Concert dialogue, a
> list of existing ConcertLocations and a String parameter to (at least) name
> a new one if the one of interest does not pre-exist. A validate method for
> the create action can check that one of these but not both is
> selected/filled. That was Dan's suggestion I think.
>
> If the problem is that there are so many mandatory properties for a Concert
> the Concert 'create' action gets to become a big list of parameters, and
> one that is confusing to 'naive' users, which I don't Apache Isis being a
> good fit for anyway. There might be a case for designing a ConcertBuilder
> domain class, this is just used to collect data for then creating a new
> valid Concert. Such a ConcertBuilder could be a state-machine maybe, it has
> a series of Actions that are enabled or disabled based on current state?
>
> I will still have to come up with a way to highlight/color fields that
> reference placeholder objects (identified by name or by a flag) to make it
> clear in the UI that something still needs to be done. This does the trick
> for a few cases where there the next level object only has trivial
> properties or associations to already existing objects.
>
> To address how to draw attention of the users to replacing placeholders
> with real objects a possible approach would be to have special query for
> the placeholder objects to see which other objects reference them, maybe
> thus proposing a set of ToDos/problems to the user on the dashboard that
> need to be addressed. Such as: there are currently three concerts
> referencing the dummy/placeholder location, please go look at them and
> correct that. One could probably construct a business rule from that to
> check for overall validity of an object tree. If any of the referenced
> objects in the tree is a placeholder, then the path is invalid.
>
> There is a incode Notes module [2] that I think could be of value, this
> could be used in the 'create' action to attach a note to the concert saying
> that a new ConcertLocation has been created that might need further
> validation. Maybe by a data-quality person. I am using this module.
>
> I was thinking about the distinction between static and dynamic data. There
> are certainly cases when a user should not be allowed to add a new entity
> to a collection, but then again I can also think about times when the data
> structures that are being transferred from the real world into the system
> by a user can be very complex and diverse by nature, and referenced objects
> just cannot be pre-created or pre-thought of (example: a very complex
> contract, or for instance a data structure that requires collaboration to
> establish, and things just don't come in in the order that would be
> required by the domain model to allow for validity and referential
> integrity at all time, so that you need to create "proxy" objects as
> placeholders).
>
> I think my distinction is misunderstood, if something complex is modelled
> in the domain model it's inherently part of the model, the source of the
> data is irrelevant. Maybe static vs dynamic is the wrong wording, perhaps
> its best to think of the model as having a boundary (models are by
> definition simplifications), and some things outside the boundary are still
> of interest but are represented inside the model just by identifiers. [In
> my ideal world more detail on such things could be resolved in real time
> via a web-services, hypermedia essentially, so the boundary is not that
> distinct].
>
> I'm now trying to think of ways to improve performance of my app, I'll look
> at caching, this distinction seems useful here too, things that are dynamic
> aren't good candidates for caching whereas things that are static are. This
> might be a first pass caching strategy, then there might be specific
> dynamic objects that are accessed by lots of users, but to cache them needs
> more logic.
>
> I found an issue in my app that presenting a list of choices to the user
> was very slow, as I assume Apache Isis was building all the complete
> objects, essentially just to be able to create the title of each to show in
> the UI. So to get around this I created an "ParticipantIdentity" ViewModel
> class (based on a database view) that just has the title and primary key
> integer as properties, it is used in the 'choices' method for the
> "Participant" action parameter, and once a choice has been made the action
> resolves just one real Participant object to use.
>
> I would also be very curious to see a quick code example from Oscar, since
> that seems to address my issue/request very well, and an annotation would
> give the opportunity to make a case by case decision on when to allow this
> in the domain and when not.
>
> Thanks and regards,
> Martin
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Sep 29, 2016 at 4:24 PM, Dan Haywood <dan@haywood-associates.co.uk
> wrote:
>
> 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 <dan@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.bou@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.62@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+apachemail@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 <
> dan@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.62@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 <
>
> dan@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 <mw...@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.bou@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.bou@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.bou@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.
>
>
Re: choices / autocomplete with option to create new item
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Hi all.
I’ve just created a Jira ticket [1] and a PR at [2] that allows to define a Factory Method this way:
class Concert {
@Action(factoryMethod=true)
public Concert someAction() {
return new Concert();
}
}
Factory Methods cannot return void, but no other restriction has been applied by now (i.e., should we limit it to Domain Entities? ).
Further work should be done at the UI level.
As a workflow example:
- When executing an Action, add a drop-down menu to show all Factory Methods whose returned class is assignable from the param’s class.
- When clicked, launch the action’s modal dialog, overlapping the original action invocation dialog.
- When returning from the factory method invocation to the original action invocation dialog, if the factory method’s action :
- has been successfully executed, the returned object should be the param’s currently selected value.
- has been cancelled, the param’s currently selected value is not changed.
HTH,
Oscar
[1] https://issues.apache.org/jira/browse/ISIS-1509
[2] https://github.com/apache/isis/pull/55/files
> El 30 sept 2016, a las 5:07, David Tildesley <da...@yahoo.co.nz.INVALID> escribió:
>
> Hi All,
>
> Imho:
>
> Putting the "don't do CRUD" principle spin on this: Isn't it just a matter of allowing a "Concert" component (I call it component since it will have several objects that are associated with the primary moment-interval) instance to be "built up" until it can be "published"? All you need is a "canPublish()" method returning a boolean that does all the necessary checks to ensure all the required bits and bobs are in place before "publishing" it (for want of a better term). Why are you wanting to create a rod for you own back by having database constraints to enforce business logic when you can enforce the constraints in logic in your code with more flexibility? I may be wrong, but I think the Naked Object model would force you take this approach because you are only allowed to "see" domain objects in the viewer. Use of view models will tend to take you in the other direction - caution needed. Conflating "view" aspects with "domain" aspects will make the situation worse.
>
> Next make sure you have firmly in your mind the separation of UI concerns from domain layer concerns - don't conflate them. If you need to create some view models to build aggregate forms or a wizard - because that is what your users demand just remember the separation of concerns principle - view models are UI, not domain layer and they will tend to cause you to compromise the domain layer/model if you are not fastidious about this.
>
> By the way, it is next to impossible to have this discussion without a proper domain model available - if there is no domain model available then you are already traveling an unsound path.
>
> Regards,
>
> David.
>
> On 30-Sep-16 12:37 PM, Stephen Cameron wrote:
>> Hi Martin,
>>
>> Just a few thoughts in response inline.
>>
>> On Fri, Sep 30, 2016 at 12:51 AM, Martin <mw...@gmail.com>
>> wrote:
>>
>>> Thanks all for your replies and your input.
>>>
>>> The DDD book was actually one of the books I bought many years ago and
>>> enjoyed reading a lot. I still recommend it to friends and colleagues.
>>>
>> :) Which probably led you to trying Apache Isis?
>>
>>> I gave Stephens idea a second thought and tried out this approach today.
>>> For the association of more complex objects, like let's say a
>>> ConcertLocation which cannot be created from within the Concert dialogue
>>> there is a Fixture creating a dummy placeholder ConcertLocation object,
>>> which can be selected instead, and the Concert entity has an action to
>>> create a new ConcertLocation, so that things can be corrected after
>>> creation.
>>>
>> I'm don't think this is the best approach to take, if a Concert must have a
>> concert location then offer the user two options in the Concert dialogue, a
>> list of existing ConcertLocations and a String parameter to (at least) name
>> a new one if the one of interest does not pre-exist. A validate method for
>> the create action can check that one of these but not both is
>> selected/filled. That was Dan's suggestion I think.
>>
>> If the problem is that there are so many mandatory properties for a Concert
>> the Concert 'create' action gets to become a big list of parameters, and
>> one that is confusing to 'naive' users, which I don't Apache Isis being a
>> good fit for anyway. There might be a case for designing a ConcertBuilder
>> domain class, this is just used to collect data for then creating a new
>> valid Concert. Such a ConcertBuilder could be a state-machine maybe, it has
>> a series of Actions that are enabled or disabled based on current state?
>>
>>> I will still have to come up with a way to highlight/color fields that
>>> reference placeholder objects (identified by name or by a flag) to make it
>>> clear in the UI that something still needs to be done. This does the trick
>>> for a few cases where there the next level object only has trivial
>>> properties or associations to already existing objects.
>>>
>>> To address how to draw attention of the users to replacing placeholders
>>> with real objects a possible approach would be to have special query for
>>> the placeholder objects to see which other objects reference them, maybe
>>> thus proposing a set of ToDos/problems to the user on the dashboard that
>>> need to be addressed. Such as: there are currently three concerts
>>> referencing the dummy/placeholder location, please go look at them and
>>> correct that. One could probably construct a business rule from that to
>>> check for overall validity of an object tree. If any of the referenced
>>> objects in the tree is a placeholder, then the path is invalid.
>>>
>> There is a incode Notes module [2] that I think could be of value, this
>> could be used in the 'create' action to attach a note to the concert saying
>> that a new ConcertLocation has been created that might need further
>> validation. Maybe by a data-quality person. I am using this module.
>>
>>> I was thinking about the distinction between static and dynamic data. There
>>> are certainly cases when a user should not be allowed to add a new entity
>>> to a collection, but then again I can also think about times when the data
>>> structures that are being transferred from the real world into the system
>>> by a user can be very complex and diverse by nature, and referenced objects
>>> just cannot be pre-created or pre-thought of (example: a very complex
>>> contract, or for instance a data structure that requires collaboration to
>>> establish, and things just don't come in in the order that would be
>>> required by the domain model to allow for validity and referential
>>> integrity at all time, so that you need to create "proxy" objects as
>>> placeholders).
>>>
>> I think my distinction is misunderstood, if something complex is modelled
>> in the domain model it's inherently part of the model, the source of the
>> data is irrelevant. Maybe static vs dynamic is the wrong wording, perhaps
>> its best to think of the model as having a boundary (models are by
>> definition simplifications), and some things outside the boundary are still
>> of interest but are represented inside the model just by identifiers. [In
>> my ideal world more detail on such things could be resolved in real time
>> via a web-services, hypermedia essentially, so the boundary is not that
>> distinct].
>>
>> I'm now trying to think of ways to improve performance of my app, I'll look
>> at caching, this distinction seems useful here too, things that are dynamic
>> aren't good candidates for caching whereas things that are static are. This
>> might be a first pass caching strategy, then there might be specific
>> dynamic objects that are accessed by lots of users, but to cache them needs
>> more logic.
>>
>> I found an issue in my app that presenting a list of choices to the user
>> was very slow, as I assume Apache Isis was building all the complete
>> objects, essentially just to be able to create the title of each to show in
>> the UI. So to get around this I created an "ParticipantIdentity" ViewModel
>> class (based on a database view) that just has the title and primary key
>> integer as properties, it is used in the 'choices' method for the
>> "Participant" action parameter, and once a choice has been made the action
>> resolves just one real Participant object to use.
>>
>>> I would also be very curious to see a quick code example from Oscar, since
>>> that seems to address my issue/request very well, and an annotation would
>>> give the opportunity to make a case by case decision on when to allow this
>>> in the domain and when not.
>>>
>>> Thanks and regards,
>>> Martin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 29, 2016 at 4:24 PM, Dan Haywood <dan@haywood-associates.co.uk
>>> wrote:
>>>
>>>> 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 <dan@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.bou@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.62@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+apachemail@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 <
>>>>>> dan@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.62@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 <
>>>>>>
>>>>>> dan@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 <mw...@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.bou@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.bou@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 <http://www.govertis.com/> e: o.bou@govertis.com <ma...@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.
Re: choices / autocomplete with option to create new item
Posted by Stephen Cameron <st...@gmail.com>.
An interesting thought David, canPublish() ! Your idea that having database
constraints is making a rod for your back is quite valid, It's not until a
database is shared between apps that it becomes critical, non-null
specifically. If none of the conventional thinking about pros of
using relational database applies, graph databases seem very attractive
with Apache Isis, it's still on my list to try Neo4j.
On Friday, September 30, 2016, David Tildesley <da...@yahoo.co.nz.invalid>
wrote:
> Hi All,
>
> Imho:
>
> Putting the "don't do CRUD" principle spin on this: Isn't it just a matter
> of allowing a "Concert" component (I call it component since it will have
> several objects that are associated with the primary moment-interval)
> instance to be "built up" until it can be "published"? All you need is a
> "canPublish()" method returning a boolean that does all the necessary
> checks to ensure all the required bits and bobs are in place before
> "publishing" it (for want of a better term). Why are you wanting to create
> a rod for you own back by having database constraints to enforce business
> logic when you can enforce the constraints in logic in your code with more
> flexibility? I may be wrong, but I think the Naked Object model would force
> you take this approach because you are only allowed to "see" domain objects
> in the viewer. Use of view models will tend to take you in the other
> direction - caution needed. Conflating "view" aspects with "domain" aspects
> will make the situation worse.
>
> Next make sure you have firmly in your mind the separation of UI concerns
> from domain layer concerns - don't conflate them. If you need to create
> some view models to build aggregate forms or a wizard - because that is
> what your users demand just remember the separation of concerns principle
> - view models are UI, not domain layer and they will tend to cause you to
> compromise the domain layer/model if you are not fastidious about this.
>
> By the way, it is next to impossible to have this discussion without a
> proper domain model available - if there is no domain model available then
> you are already traveling an unsound path.
>
> Regards,
>
> David.
>
> On 30-Sep-16 12:37 PM, Stephen Cameron wrote:
>
>> Hi Martin,
>>
>> Just a few thoughts in response inline.
>>
>> On Fri, Sep 30, 2016 at 12:51 AM, Martin <mw...@gmail.com>
>> wrote:
>>
>> Thanks all for your replies and your input.
>>>
>>> The DDD book was actually one of the books I bought many years ago and
>>> enjoyed reading a lot. I still recommend it to friends and colleagues.
>>>
>>> :) Which probably led you to trying Apache Isis?
>>
>> I gave Stephens idea a second thought and tried out this approach today.
>>> For the association of more complex objects, like let's say a
>>> ConcertLocation which cannot be created from within the Concert dialogue
>>> there is a Fixture creating a dummy placeholder ConcertLocation object,
>>> which can be selected instead, and the Concert entity has an action to
>>> create a new ConcertLocation, so that things can be corrected after
>>> creation.
>>>
>>> I'm don't think this is the best approach to take, if a Concert must
>> have a
>> concert location then offer the user two options in the Concert dialogue,
>> a
>> list of existing ConcertLocations and a String parameter to (at least)
>> name
>> a new one if the one of interest does not pre-exist. A validate method for
>> the create action can check that one of these but not both is
>> selected/filled. That was Dan's suggestion I think.
>>
>> If the problem is that there are so many mandatory properties for a
>> Concert
>> the Concert 'create' action gets to become a big list of parameters, and
>> one that is confusing to 'naive' users, which I don't Apache Isis being a
>> good fit for anyway. There might be a case for designing a ConcertBuilder
>> domain class, this is just used to collect data for then creating a new
>> valid Concert. Such a ConcertBuilder could be a state-machine maybe, it
>> has
>> a series of Actions that are enabled or disabled based on current state?
>>
>> I will still have to come up with a way to highlight/color fields that
>>> reference placeholder objects (identified by name or by a flag) to make
>>> it
>>> clear in the UI that something still needs to be done. This does the
>>> trick
>>> for a few cases where there the next level object only has trivial
>>> properties or associations to already existing objects.
>>>
>>> To address how to draw attention of the users to replacing placeholders
>>> with real objects a possible approach would be to have special query for
>>> the placeholder objects to see which other objects reference them, maybe
>>> thus proposing a set of ToDos/problems to the user on the dashboard that
>>> need to be addressed. Such as: there are currently three concerts
>>> referencing the dummy/placeholder location, please go look at them and
>>> correct that. One could probably construct a business rule from that to
>>> check for overall validity of an object tree. If any of the referenced
>>> objects in the tree is a placeholder, then the path is invalid.
>>>
>>> There is a incode Notes module [2] that I think could be of value, this
>> could be used in the 'create' action to attach a note to the concert
>> saying
>> that a new ConcertLocation has been created that might need further
>> validation. Maybe by a data-quality person. I am using this module.
>>
>> I was thinking about the distinction between static and dynamic data.
>>> There
>>> are certainly cases when a user should not be allowed to add a new entity
>>> to a collection, but then again I can also think about times when the
>>> data
>>> structures that are being transferred from the real world into the system
>>> by a user can be very complex and diverse by nature, and referenced
>>> objects
>>> just cannot be pre-created or pre-thought of (example: a very complex
>>> contract, or for instance a data structure that requires collaboration to
>>> establish, and things just don't come in in the order that would be
>>> required by the domain model to allow for validity and referential
>>> integrity at all time, so that you need to create "proxy" objects as
>>> placeholders).
>>>
>>> I think my distinction is misunderstood, if something complex is modelled
>> in the domain model it's inherently part of the model, the source of the
>> data is irrelevant. Maybe static vs dynamic is the wrong wording, perhaps
>> its best to think of the model as having a boundary (models are by
>> definition simplifications), and some things outside the boundary are
>> still
>> of interest but are represented inside the model just by identifiers. [In
>> my ideal world more detail on such things could be resolved in real time
>> via a web-services, hypermedia essentially, so the boundary is not that
>> distinct].
>>
>> I'm now trying to think of ways to improve performance of my app, I'll
>> look
>> at caching, this distinction seems useful here too, things that are
>> dynamic
>> aren't good candidates for caching whereas things that are static are.
>> This
>> might be a first pass caching strategy, then there might be specific
>> dynamic objects that are accessed by lots of users, but to cache them
>> needs
>> more logic.
>>
>> I found an issue in my app that presenting a list of choices to the user
>> was very slow, as I assume Apache Isis was building all the complete
>> objects, essentially just to be able to create the title of each to show
>> in
>> the UI. So to get around this I created an "ParticipantIdentity" ViewModel
>> class (based on a database view) that just has the title and primary key
>> integer as properties, it is used in the 'choices' method for the
>> "Participant" action parameter, and once a choice has been made the action
>> resolves just one real Participant object to use.
>>
>> I would also be very curious to see a quick code example from Oscar, since
>>> that seems to address my issue/request very well, and an annotation would
>>> give the opportunity to make a case by case decision on when to allow
>>> this
>>> in the domain and when not.
>>>
>>> Thanks and regards,
>>> Martin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 29, 2016 at 4:24 PM, Dan Haywood <
>>> dan@haywood-associates.co.uk
>>> wrote:
>>>
>>> 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.bou@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 <
>>>>> dan@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.bou@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.62@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+apachemail@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 <
>>>>>> dan@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.62@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 <
>>>>>>
>>>>>> dan@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 <mw...@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.bou@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.bou@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.
>>>>>
>>>>>
>>>>>
>
Re: choices / autocomplete with option to create new item
Posted by David Tildesley <da...@yahoo.co.nz.INVALID>.
Hi All,
Imho:
Putting the "don't do CRUD" principle spin on this: Isn't it just a
matter of allowing a "Concert" component (I call it component since it
will have several objects that are associated with the primary
moment-interval) instance to be "built up" until it can be "published"?
All you need is a "canPublish()" method returning a boolean that does
all the necessary checks to ensure all the required bits and bobs are in
place before "publishing" it (for want of a better term). Why are you
wanting to create a rod for you own back by having database constraints
to enforce business logic when you can enforce the constraints in logic
in your code with more flexibility? I may be wrong, but I think the
Naked Object model would force you take this approach because you are
only allowed to "see" domain objects in the viewer. Use of view models
will tend to take you in the other direction - caution needed.
Conflating "view" aspects with "domain" aspects will make the situation
worse.
Next make sure you have firmly in your mind the separation of UI
concerns from domain layer concerns - don't conflate them. If you need
to create some view models to build aggregate forms or a wizard -
because that is what your users demand just remember the separation of
concerns principle - view models are UI, not domain layer and they will
tend to cause you to compromise the domain layer/model if you are not
fastidious about this.
By the way, it is next to impossible to have this discussion without a
proper domain model available - if there is no domain model available
then you are already traveling an unsound path.
Regards,
David.
On 30-Sep-16 12:37 PM, Stephen Cameron wrote:
> Hi Martin,
>
> Just a few thoughts in response inline.
>
> On Fri, Sep 30, 2016 at 12:51 AM, Martin <mw...@gmail.com>
> wrote:
>
>> Thanks all for your replies and your input.
>>
>> The DDD book was actually one of the books I bought many years ago and
>> enjoyed reading a lot. I still recommend it to friends and colleagues.
>>
> :) Which probably led you to trying Apache Isis?
>
>> I gave Stephens idea a second thought and tried out this approach today.
>> For the association of more complex objects, like let's say a
>> ConcertLocation which cannot be created from within the Concert dialogue
>> there is a Fixture creating a dummy placeholder ConcertLocation object,
>> which can be selected instead, and the Concert entity has an action to
>> create a new ConcertLocation, so that things can be corrected after
>> creation.
>>
> I'm don't think this is the best approach to take, if a Concert must have a
> concert location then offer the user two options in the Concert dialogue, a
> list of existing ConcertLocations and a String parameter to (at least) name
> a new one if the one of interest does not pre-exist. A validate method for
> the create action can check that one of these but not both is
> selected/filled. That was Dan's suggestion I think.
>
> If the problem is that there are so many mandatory properties for a Concert
> the Concert 'create' action gets to become a big list of parameters, and
> one that is confusing to 'naive' users, which I don't Apache Isis being a
> good fit for anyway. There might be a case for designing a ConcertBuilder
> domain class, this is just used to collect data for then creating a new
> valid Concert. Such a ConcertBuilder could be a state-machine maybe, it has
> a series of Actions that are enabled or disabled based on current state?
>
>> I will still have to come up with a way to highlight/color fields that
>> reference placeholder objects (identified by name or by a flag) to make it
>> clear in the UI that something still needs to be done. This does the trick
>> for a few cases where there the next level object only has trivial
>> properties or associations to already existing objects.
>>
>> To address how to draw attention of the users to replacing placeholders
>> with real objects a possible approach would be to have special query for
>> the placeholder objects to see which other objects reference them, maybe
>> thus proposing a set of ToDos/problems to the user on the dashboard that
>> need to be addressed. Such as: there are currently three concerts
>> referencing the dummy/placeholder location, please go look at them and
>> correct that. One could probably construct a business rule from that to
>> check for overall validity of an object tree. If any of the referenced
>> objects in the tree is a placeholder, then the path is invalid.
>>
> There is a incode Notes module [2] that I think could be of value, this
> could be used in the 'create' action to attach a note to the concert saying
> that a new ConcertLocation has been created that might need further
> validation. Maybe by a data-quality person. I am using this module.
>
>> I was thinking about the distinction between static and dynamic data. There
>> are certainly cases when a user should not be allowed to add a new entity
>> to a collection, but then again I can also think about times when the data
>> structures that are being transferred from the real world into the system
>> by a user can be very complex and diverse by nature, and referenced objects
>> just cannot be pre-created or pre-thought of (example: a very complex
>> contract, or for instance a data structure that requires collaboration to
>> establish, and things just don't come in in the order that would be
>> required by the domain model to allow for validity and referential
>> integrity at all time, so that you need to create "proxy" objects as
>> placeholders).
>>
> I think my distinction is misunderstood, if something complex is modelled
> in the domain model it's inherently part of the model, the source of the
> data is irrelevant. Maybe static vs dynamic is the wrong wording, perhaps
> its best to think of the model as having a boundary (models are by
> definition simplifications), and some things outside the boundary are still
> of interest but are represented inside the model just by identifiers. [In
> my ideal world more detail on such things could be resolved in real time
> via a web-services, hypermedia essentially, so the boundary is not that
> distinct].
>
> I'm now trying to think of ways to improve performance of my app, I'll look
> at caching, this distinction seems useful here too, things that are dynamic
> aren't good candidates for caching whereas things that are static are. This
> might be a first pass caching strategy, then there might be specific
> dynamic objects that are accessed by lots of users, but to cache them needs
> more logic.
>
> I found an issue in my app that presenting a list of choices to the user
> was very slow, as I assume Apache Isis was building all the complete
> objects, essentially just to be able to create the title of each to show in
> the UI. So to get around this I created an "ParticipantIdentity" ViewModel
> class (based on a database view) that just has the title and primary key
> integer as properties, it is used in the 'choices' method for the
> "Participant" action parameter, and once a choice has been made the action
> resolves just one real Participant object to use.
>
>> I would also be very curious to see a quick code example from Oscar, since
>> that seems to address my issue/request very well, and an annotation would
>> give the opportunity to make a case by case decision on when to allow this
>> in the domain and when not.
>>
>> Thanks and regards,
>> Martin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 29, 2016 at 4:24 PM, Dan Haywood <dan@haywood-associates.co.uk
>> wrote:
>>
>>> 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\u2019s 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 \u201cnon-idempotent\u201d 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\u2019s 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 <dan@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.bou@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\u2019s Martin\u2019s initial requirement.
>>>>>
>>>>> It\u2019s also a quite generic solution.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Oscar
>>>>>
>>>>>
>>>>>
>>>>> El 28 sept 2016, a las 16:02, Stephen Cameron <
>>>>> steve.cameron.62@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+apachemail@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 <
>>>>> dan@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.62@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 <
>>>>>
>>>>> dan@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 <mw...@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.bou@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 \u2013 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.bou@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 \u2013 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.
>>>>
>>>>
Re: choices / autocomplete with option to create new item
Posted by Stephen Cameron <st...@gmail.com>.
Hi Martin,
Just a few thoughts in response inline.
On Fri, Sep 30, 2016 at 12:51 AM, Martin <mw...@gmail.com>
wrote:
> Thanks all for your replies and your input.
>
> The DDD book was actually one of the books I bought many years ago and
> enjoyed reading a lot. I still recommend it to friends and colleagues.
>
:) Which probably led you to trying Apache Isis?
>
> I gave Stephens idea a second thought and tried out this approach today.
> For the association of more complex objects, like let's say a
> ConcertLocation which cannot be created from within the Concert dialogue
> there is a Fixture creating a dummy placeholder ConcertLocation object,
> which can be selected instead, and the Concert entity has an action to
> create a new ConcertLocation, so that things can be corrected after
> creation.
>
I'm don't think this is the best approach to take, if a Concert must have a
concert location then offer the user two options in the Concert dialogue, a
list of existing ConcertLocations and a String parameter to (at least) name
a new one if the one of interest does not pre-exist. A validate method for
the create action can check that one of these but not both is
selected/filled. That was Dan's suggestion I think.
If the problem is that there are so many mandatory properties for a Concert
the Concert 'create' action gets to become a big list of parameters, and
one that is confusing to 'naive' users, which I don't Apache Isis being a
good fit for anyway. There might be a case for designing a ConcertBuilder
domain class, this is just used to collect data for then creating a new
valid Concert. Such a ConcertBuilder could be a state-machine maybe, it has
a series of Actions that are enabled or disabled based on current state?
>
> I will still have to come up with a way to highlight/color fields that
> reference placeholder objects (identified by name or by a flag) to make it
> clear in the UI that something still needs to be done. This does the trick
> for a few cases where there the next level object only has trivial
> properties or associations to already existing objects.
>
> To address how to draw attention of the users to replacing placeholders
> with real objects a possible approach would be to have special query for
> the placeholder objects to see which other objects reference them, maybe
> thus proposing a set of ToDos/problems to the user on the dashboard that
> need to be addressed. Such as: there are currently three concerts
> referencing the dummy/placeholder location, please go look at them and
> correct that. One could probably construct a business rule from that to
> check for overall validity of an object tree. If any of the referenced
> objects in the tree is a placeholder, then the path is invalid.
>
There is a incode Notes module [2] that I think could be of value, this
could be used in the 'create' action to attach a note to the concert saying
that a new ConcertLocation has been created that might need further
validation. Maybe by a data-quality person. I am using this module.
>
> I was thinking about the distinction between static and dynamic data. There
> are certainly cases when a user should not be allowed to add a new entity
> to a collection, but then again I can also think about times when the data
> structures that are being transferred from the real world into the system
> by a user can be very complex and diverse by nature, and referenced objects
> just cannot be pre-created or pre-thought of (example: a very complex
> contract, or for instance a data structure that requires collaboration to
> establish, and things just don't come in in the order that would be
> required by the domain model to allow for validity and referential
> integrity at all time, so that you need to create "proxy" objects as
> placeholders).
>
I think my distinction is misunderstood, if something complex is modelled
in the domain model it's inherently part of the model, the source of the
data is irrelevant. Maybe static vs dynamic is the wrong wording, perhaps
its best to think of the model as having a boundary (models are by
definition simplifications), and some things outside the boundary are still
of interest but are represented inside the model just by identifiers. [In
my ideal world more detail on such things could be resolved in real time
via a web-services, hypermedia essentially, so the boundary is not that
distinct].
I'm now trying to think of ways to improve performance of my app, I'll look
at caching, this distinction seems useful here too, things that are dynamic
aren't good candidates for caching whereas things that are static are. This
might be a first pass caching strategy, then there might be specific
dynamic objects that are accessed by lots of users, but to cache them needs
more logic.
I found an issue in my app that presenting a list of choices to the user
was very slow, as I assume Apache Isis was building all the complete
objects, essentially just to be able to create the title of each to show in
the UI. So to get around this I created an "ParticipantIdentity" ViewModel
class (based on a database view) that just has the title and primary key
integer as properties, it is used in the 'choices' method for the
"Participant" action parameter, and once a choice has been made the action
resolves just one real Participant object to use.
>
> I would also be very curious to see a quick code example from Oscar, since
> that seems to address my issue/request very well, and an annotation would
> give the opportunity to make a case by case decision on when to allow this
> in the domain and when not.
>
> Thanks and regards,
> Martin
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Sep 29, 2016 at 4:24 PM, Dan Haywood <dan@haywood-associates.co.uk
> >
> wrote:
>
> > 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 <dan@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.bou@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.62@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+apachemail@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 <
> >>> dan@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.62@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 <
> >>>
> >>> dan@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 <mw...@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.bou@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.bou@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.
> >>
> >>
> >
>
Re: choices / autocomplete with option to create new item
Posted by Martin <mw...@gmail.com>.
Thanks all for your replies and your input.
The DDD book was actually one of the books I bought many years ago and
enjoyed reading a lot. I still recommend it to friends and colleagues.
I gave Stephens idea a second thought and tried out this approach today.
For the association of more complex objects, like let's say a
ConcertLocation which cannot be created from within the Concert dialogue
there is a Fixture creating a dummy placeholder ConcertLocation object,
which can be selected instead, and the Concert entity has an action to
create a new ConcertLocation, so that things can be corrected after
creation.
I will still have to come up with a way to highlight/color fields that
reference placeholder objects (identified by name or by a flag) to make it
clear in the UI that something still needs to be done. This does the trick
for a few cases where there the next level object only has trivial
properties or associations to already existing objects.
To address how to draw attention of the users to replacing placeholders
with real objects a possible approach would be to have special query for
the placeholder objects to see which other objects reference them, maybe
thus proposing a set of ToDos/problems to the user on the dashboard that
need to be addressed. Such as: there are currently three concerts
referencing the dummy/placeholder location, please go look at them and
correct that. One could probably construct a business rule from that to
check for overall validity of an object tree. If any of the referenced
objects in the tree is a placeholder, then the path is invalid.
I was thinking about the distinction between static and dynamic data. There
are certainly cases when a user should not be allowed to add a new entity
to a collection, but then again I can also think about times when the data
structures that are being transferred from the real world into the system
by a user can be very complex and diverse by nature, and referenced objects
just cannot be pre-created or pre-thought of (example: a very complex
contract, or for instance a data structure that requires collaboration to
establish, and things just don't come in in the order that would be
required by the domain model to allow for validity and referential
integrity at all time, so that you need to create "proxy" objects as
placeholders).
I would also be very curious to see a quick code example from Oscar, since
that seems to address my issue/request very well, and an annotation would
give the opportunity to make a case by case decision on when to allow this
in the domain and when not.
Thanks and regards,
Martin
On Thu, Sep 29, 2016 at 4:24 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> 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 <da...@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.62@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 <mw...@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 <
>>> dan@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.62@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 <
>>>
>>> dan@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 <mw...@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.bou@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.bou@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.
>>
>>
>
Re: choices / autocomplete with option to create new item
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@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 <st...@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 <mw...@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 <
>> dan@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.62@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 <
>>
>> dan@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 <mw...@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.bou@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.bou@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.
>
>
Re: choices / autocomplete with option to create new item
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
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 <da...@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.bou@govertis.com <ma...@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.62@gmail.com <ma...@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+apachemail@gmail.com <ma...@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 <dan@haywood-associates.co.uk <ma...@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 <https://github.com/incodehq/incode-module-commchannel>
>>>>
>>>> On 28 September 2016 at 11:48, Stephen Cameron <
>>> steve.cameron.62@gmail.com <ma...@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 <
>>>> dan@haywood-associates.co.uk <ma...@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+apachemail@gmail.com <ma...@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 <tel:%2B34%20620%20267%20520>
> s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: o.bou@govertis.com <ma...@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.
>
>
>
Ó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.bou@govertis.com <ma...@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.
Re: choices / autocomplete with option to create new item
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <st...@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 <mw...@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 <dan@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.62@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 <
>
> dan@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 <mw...@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.bou@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.
>
>
Re: choices / autocomplete with option to create new item
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
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 <st...@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 <mw...@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 <dan@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.62@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 <
>>> dan@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 <mw...@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.bou@govertis.com <ma...@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.
Re: choices / autocomplete with option to create new item
Posted by Stephen Cameron <st...@gmail.com>.
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 <mw...@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 <dan@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.62@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 <
> > dan@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 <mw...@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
> > > > >
> > > >
> > >
> >
>
Re: choices / autocomplete with option to create new item
Posted by Martin <mw...@gmail.com>.
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?
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.
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.
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?
Thx,
Martin
On Wed, Sep 28, 2016 at 6:11 PM, Dan Haywood <da...@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.62@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 <
> dan@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 <mw...@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
> > > >
> > >
> >
>
Re: choices / autocomplete with option to create new item
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <st...@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 <dan@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 <mw...@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
> > >
> >
>
Re: choices / autocomplete with option to create new item
Posted by Stephen Cameron <st...@gmail.com>.
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 <da...@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(newConcertLocationName);
>
> 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 <mw...@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
> >
>
Re: choices / autocomplete with option to create new item
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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(newConcertLocationName);
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 <mw...@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
>