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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected] > > > 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 < > > [email protected] > > > 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 < > > [email protected] > > > 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 <[email protected]> > 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: [email protected] > > 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. > >
