On 28 September 2016 at 14:30, Rade, Joerg / Kuehne + Nagel / Ham GI-DP < [email protected]> 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:[email protected]] > Gesendet: Mittwoch, 28. September 2016 14:46 > An: users; [email protected] > Betreff: Re: choices / autocomplete with option to create new item > > On 28 September 2016 at 13:00, Martin <[email protected]> > 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. >
