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 <d...@haywood-associates.co.uk> wrote: > Thanks for these ideas, Steve. > > Which in turn reminds me... we have an existing module for modelling > communication channels [1] that could be used/forked as the basis for > handling locations. (If you want all the gmap location stuff, that is). > > Cheers > Dan > > > [1] https://github.com/incodehq/incode-module-commchannel > > On 28 September 2016 at 11:48, Stephen Cameron <steve.cameron...@gmail.com > > > wrote: > > > Another option to try, assuming that the Concert has been created > already, > > is to have an action on, or contributed to, the Concert that allows > > creation of a new ConcertLocation. Then the user can either set the > concert > > location by choosing an existing location from the pick list, or by > > creating an new one via the action. The location property and the action > > can be associated via the layout.xml or annotation means. > > > > I use another alternative, which is more complex, for setting activity > > addresses, which is to have 'named' addresses, these are addresses used > > often for different activities. So the 'Update Address' action has a > > picklist of existing named addresses, or you can create a new address by > > filling in street1, street2, suburb. But if you give that new address a > > name as well (e.g XYZ Community Hall) it becomes a new named address. > > > > So the Update Address action has 5 parameters, a list of existing named > > addresses, a name for a new address, street1,street2, a list of suburbs. > > > > > > > > On Wed, Sep 28, 2016 at 7:48 PM, Dan Haywood < > d...@haywood-associates.co.uk > > > > > wrote: > > > > > Hi Martin, > > > > > > This requirement has only come up infrequently so far, not sufficiently > > to > > > build a particular widget or programming model for it. > > > > > > Where we have required it, we've simply provided two optional > parameters, > > > one listing the existing objects, the other for the name of a new > object. > > > (This assumes that a single string is sufficient to create said new > > > object). > > > > > > public Concert create(@Nullable ConcertLocation > > > existingConcertLocation, @Nullable String newConcertLocationName, > String > > > concertName) { > > > > > > ConcertLocation concertLocation = > > > existingConcertLocation != null > > > ? existingConcertLocation > > > : concertLocationRepository.findOrCreate( > newConcertLocationNam > > e); > > > > > > return concertRepository.create(concertName, concertLocation); > > > } > > > public String validateCreate(ConcertLocation existingConcertLocation, > > > String newConcertLocationName, String concertName) { > > > if (existingConcertLocation == null && newConcertLocationName == > > null) > > > return "Specify either an existing location or the name of a new one"; > > > if (existingConcertLocation != null && newConcertLocationName != > > null) > > > return "Specify either an existing location or the name of a new one"; > > > return null; > > > } > > > > > > However, that has the side effect of cluttering up the common use case > > (new > > > Concert in an existing ConcertLocation), so I don't know if it's worth > > the > > > effort. My recommendation would simply be to treat the creation of > > concert > > > locations and of new concerts independently. > > > > > > HTH > > > Dan > > > > > > > > > > > > > > > On 28 September 2016 at 09:32, Martin <mwhesse+apachem...@gmail.com> > > > wrote: > > > > > > > Let's say we have an entity Concert and an entity ConcertLocation and > > the > > > > model is such that a Concert would reference a ConcertLocation > (shared > > > > ManyToOne association). > > > > > > > > In a create dialogue for the Concert entity I would like to offer the > > > > possibility to create a new ConcertLocation item if the desired > > location > > > is > > > > not found in the dropdown or select box. > > > > > > > > This could for instance be by displaying a "create new location" icon > > > next > > > > to the dropdown box for locations or anything else, which would then > > open > > > > another modal on top of the create dialogue to create that > > > > new ConcertLocation. > > > > > > > > Once the new ConcertLocation has been created it should then appear > in > > > the > > > > list of available locations in the Concert create dialogue. > > > > > > > > How would I go about this in Apache Isis? > > > > > > > > I haven't found anything of the kind in the kitchen sink or the todo > > app > > > or > > > > any other examples available. > > > > > > > > Thanks and regards, > > > > Martin > > > > > > > > > >
