Re: File chooser

[Dan Haywood <da...@haywood-associates.co.uk>]

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].

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.

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


>
> 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

[2] 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

[4] http://incubator.apache.org/isis/applib/docbkx/html/guide/ch10.html

Re: File chooser

[Christophe Dehlinger <ch...@gmail.com>]

On Tue, Oct 4, 2011 at 12:06 AM, Dan Haywood
<da...@haywood-associates.co.uk>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>
>