On Tue, Oct 4, 2011 at 12:06 AM, Dan Haywood <[email protected]>wrote:
> > > On 30/09/2011 08:39, Christophe Dehlinger wrote: > >> Hello, >> > > Hi Christophe, thanks for your interest. > > > >> I'm currently evaluating isis for a new application. One of the >> requirements >> is that users should be able to import and export data as spreadsheets. >> >> There doesn't seem to be file choosing views shipped with the dnd viewer, >> so >> I've been trying to roll out my own (the usual pair of a text field and >> button that opens a file chooser). Unfortunately, I got overwhelmed by all >> the concepts involved (views, view requirements, factories, >> > > These classes relate to the DnD viewer itself, and I can't help you out > very much since I didn't write the DnD viewer. I can point you to the > (incomplete) notes in the DnD guide [1]; but I've asked Rob Matthews (who > was the author of the Dnd viewer) if he can reply more fully. > > > > specifications > >> and builders, facets and their factories, object adapters, the various >> contexts...) and their relations, and ultimately have been unabled to get >> anything working so far. >> > > I can help you a little more here, as these are the classes that belong to > the core framework. The break into two: > > a) the specifications (ObjectSpecification), Facet and FacetFactory are > part of the metamodel. You can think of ObjectSpecification as equivalent > to java.lang.Class, while Facet is a piece of metadata associated with a > class. There is also ObjectMember; facets can be associated with these two. > > This stuff is reasonably well documented in [2]. > > D'oh ! Don't know how I missed that document... This seems detailed enough for my purpose. > b) the ObjectAdapter is a runtime wrapper around a pojo, so is broadly > equivalent to java.lang.Object. Every ObjectAdapter references its > corresponding ObjectSpecification (just as every Java object knows its > runtime class). > > Isis supports the notion of pluggable runtimes, but there is currently only > one runtime, the "default runtime". It's implementation is reasonably well > documented in [3]. > > > > >> Also, the app will be deployed in client/server mode, and I can't figure >> out >> whether domain object methods are run on the server or on the client. >> > > You should know that, even though the largest system built using (the > precursor to) Isis does use the client/server configuration, these days I > wouldn't necessarily recommend it as a deployment approach. The issue with > the design is that the garbage collection of object adapters is not > particularly well-defined. Instead, you might want to consider one of the > webapp viewers. > > What are there consequences to the GC problem ? Server-side memory leaks ? As to the other viewers, I actually tried out the Wicket viewer before the DnD viewer. But the two offer very different user experiences. The latter's desktop-like UI is much more flexible for the user, letting him in some way arrange his own work environment and customize his workflow. In contrast, the various webapp viewers seem more rigid, imposing a more hierachical workflow. I liked in particular that the DnD viewer allows the user to select action parameters by dragging domain objects he found by navigating the domain in any unspecified way, while the webapp viewers force him to choose the action and then pick the parameters using the repositories only. I also liked having many windows with possibly unrelated data on the same screen, while the webapp viewers only allow to work with one piece of data at a time. I might be overvaluing this kind of flexibility though. Unfortunately, the quick-start application is really too minimal to get a good feel of the various viewers. Is the claims application available anywhere ? I tried https://wicketobjects.svn.sourceforge.net/svnroot/wicketobjects/trunk/testapp/claims but it seems outdated; the pom.xml refers to the 0.1-SNAPSHOT version and a "plugins" parent artifact that does not seem to exist anymore. On a side note, I should also add that adding a file chooser component for the Wicket viewer was very easy, even for an Isis and Wicket newbie like me. > But, to answer your question... by default domain object methods by default > run on the server if the object is persistent, but are run on the client if > the object is transient. However, this can be overridden using the > @Executed(Where) annotation (Where.LOCALLY=on the client, Where.REMOTELY=on > the server). > > > > > As a > >> consequence, I don't know whether the argument to the import action should >> be a reference to the file (a la java.io.File) or its contents (a wrapper >> on >> byte[]). >> > > You could do this by having a object with an action taking a simple string, > being the name of the file. (As you say, it'd be better if the DnD viewer > had a file chooser dialog for this, and Rob might be able to say how to do > this). But in terms of the domain object model, it'd just be a filename. > > Another option might be to use the @Value annotation to instruct Isis that > a java.io.File is a value type. There's coverage of this in the applib > guide [4]. > > > Hope that all helps a little, > Dan It does help a lot. I'll go read [2] and finish up that file chooser. Thank you for your help. > >> I'd be grateful if someone could give me a summary of the classes I have >> to >> implement. >> >> Thanks, >> Christophe >> >> > [1] http://incubator.apache.org/**isis/viewer/dnd/docbkx/html/** > guide/ch04.html<http://incubator.apache.org/isis/viewer/dnd/docbkx/html/guide/ch04.html> > > [2] http://incubator.apache.org/**isis/core/docbkx/html/guide/** > isis-core.html<http://incubator.apache.org/isis/core/docbkx/html/guide/isis-core.html> > > [3] http://incubator.apache.org/**isis/runtimes/dflt/docbkx/** > html/guide/ch05.html<http://incubator.apache.org/isis/runtimes/dflt/docbkx/html/guide/ch05.html> > > [4] http://incubator.apache.org/**isis/applib/docbkx/html/guide/** > ch10.html<http://incubator.apache.org/isis/applib/docbkx/html/guide/ch10.html> >
