If there is a setting, we should probably add it to the archetype too. Dan On 10 Feb 2013 17:13, "Adam Howard" <[email protected]> wrote:
> Interesting. I wonder if there is some git setting I need to force UTF-8. > > -- Adam > > On Feb 10, 2013, at 10:35 AM, Christian Steinebach > <[email protected]> wrote: > > > I guess it's the ø in Gøteborg. I had the same problem. > > > > Christian > > > > > > ________________________________________ > > From: Mark Wood-Patrick [[email protected]] > > Sent: Sunday, February 10, 2013 5:18 PM > > To: [email protected] > > Subject: RE: Porting dddsample app > > > > I tried building the app on centos 5.8 and got the following error any > > suggestions on how I can fix it? > > > > [INFO] > > > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Building Quickstart Wicket/Restful/JDO Fixtures 1.0-SNAPSHOT > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] > > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ > onaboat-fixture > > --- > > [INFO] > > [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ > > onaboat-fixture --- > > [debug] execute contextualize > > [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy > filtered > > resources, i.e. build is platform dependent! > > [INFO] skip non existing resourceDirectory > > > /home/app_perf_catalog/mwoodpatrick/apache/isis/onaboat/fixture/src/main/res > > ources > > [INFO] > > [INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ > > onaboat-fixture --- > > [WARNING] File encoding has not been set, using platform encoding > > ANSI_X3.4-1968, i.e. build is platform dependent! > > [INFO] Compiling 5 source files to > > > /home/app_perf_catalog/mwoodpatrick/apache/isis/onaboat/fixture/target/class > > es > > [INFO] ------------------------------------------------------------- > > [ERROR] COMPILATION ERROR : > > [INFO] ------------------------------------------------------------- > > [ERROR] > > > /home/app_perf_catalog/mwoodpatrick/apache/isis/onaboat/fixture/src/main/jav > > a/onaboat/domain/model/location/SampleLocations.java:[26,75] error: > > unmappable character for encoding ASCII > > > > [INFO] 1error > > > > -----Original Message----- > > From: Dan Haywood [mailto:[email protected]] > > Sent: Friday, February 08, 2013 11:28 AM > > To: [email protected] > > Subject: Re: Porting dddsample app > > > > On 8 February 2013 03:44, Adam Howard <[email protected]> wrote: > > > >> Dan, > >> > >> I just pushed some minor changes to the Voyage model up to github[1]. > >> I took out the Collections.unmodifiableList() call so now the Voyage > >> page renders with just the VoyageNumber and a link to the Schedule. I > >> think the purpose of the Schedule class might be to represent the list > >> of CarrierMovements as a whole rather than having the list directly on > >> the Voyage. Maybe that pattern doesn't mesh well with Isis. Because > >> what I want to see on the Voyage page is really what you get when you > >> DO have a list of CarrierMovements directly off the Voyage: the table > >> view on the right hand side. > > > > > > Agreed. Last time I think I was asking about Schedule being, > apparently, > > a value type. In Isis value types aren't represented except in the > context > > of being owned by an entity. So, yes, I think Schedule as a value type > has > > to go. > > > > > > > > > >> I modified Voyage to have that list accesible directly and now I see > >> the table. I'm not married to making a line-by-line port of the > >> original dddsample code but if there is a Ubiquitous Language reason > >> for a class's presence I'd like to try to preserve it. > >> > >> > > My suggestion would be to preserve the name "Schedule" as being the > > collection of CarrierMovements in Voyage, ie: > > > > public class Voyage { > > > > public List<CarrierMovement> getSchedule() { ... } > > > > } > > > > > > > > > >> Side note: This got me thinking about AggregateRoots. Are there any > >> features in Isis that make AggregateRoots stand out? > > > > > > ARs aren't as that important in Isis if using JDO. We do have the > > @Aggregated annotation, though. This is used by the [not yet released, > > Rob's baby] NoSQL objectstore to indicate which entities should be > > serialized in the same JSON doc within Mongo. > > > > > > > >> Or is that really just > >> a technical concern and not related to the user's mental model? > >> > >> > > Most of the discussion and debate around ARs that I read I think relates > to > > a technical concern, trying to work very hard to make sure that the only > > entities modified within a transaction are those contained within an > > aggregate root. If one is adopting the CAP/NoSQL route, then its a valid > > technical constraint that one must worry about. If using a DBMS with > such > > exotic things as transactions and isolation levels, then it's not really > a > > concern (barring deadlocks, I suppose). > > > > There is, though, something about ARs that does pertain to a users' > mental > > model. I'm pretty sure this is what Eric Evans was mostly concerned > about > > (though I re-read the discussion on ARs in his book yesterday, and I > think > > there's a hell of a lot of hand-waving). But I say what I say because - > for > > example - when we say Order we usually also mean its OrderLines, and > when we > > say Car, we usually also mean its Engine, Wheels, Doors etc. > > > > One can have the same discussion about mental models with respect to > modules > > (namespaces, packages). Over on the big Government project in Ireland we > > find this i a much more important organizing concept... they talk there > > about the "customer BOM" (BOM=business object model), "means BOM", > > "communications BOM" etc. > > > > > > The next problem I've run into is that my fixture[2] is not saving the > full > >> object graph I pass to persist. Again, I create a Voyage with a > >> Schedule with a CarrierMovement and I pass the Voyage to > >> getContainer().persistIfNotAlready(). My Voyage is stored and I can > >> see it when I query for allInstances of Voyage.class. But, the > >> CarrierMovement list is empty. Does the in-memory object store support > >> persistence-by-reachability? > > > > > > It does, but before we delve into whether there's an actual issue here in > > Isis, let me just rewind on your domain object model structure. > > > > You've got lots of immutable classes, where the state is passed in > through > > the constructor. Although that's good OO design, the issue is that Isis > > needs to rehydrate the objects through setters. As you know, we use > > annotations to prevent the user from modifying state they shouldn't > > (@Disabled). > > > > For example, CarrierMovement looks like its an entity, but has no > setters. > > Ditto Voyage. > > > > You might be best figuring out what the class model is for the domain, > and > > then porting that over (rather than a line-by-line conversion of existing > > code). > > > > ~~~ > > I also see in your SampleVoyages setter that you're instantiating using > just > > "new". While that might be ok in this particular case, in general you > > should always use "container.newTransientInstance". Doing it this way > > allows Isis to inject domain services into your entities as they are > > instantiated. > > > > > > HTH > > Dan > > >
