problem with sync classes in domain
Lukas Krejci
lkrejci at redhat.com
Wed Aug 10 09:18:46 UTC 2011
Well, these sync classes are not exactly domain classes in the sense that they
would be backed by the database but they are more of DTOs that are shared
between the server/jar, cli and GUI (in the future, more detail below). I know
that I could have just put them in the server/jar and be done with it but I
thought that the domain is just a more logical place for them.
Why they use java.io.InputStream? It's a DTO produced by the export that
provides a convenient way of storing the lazily initialized export file (the
InputStream itself) and error messages / notes produced by the export (which
is filled up while the input stream is being read). It is a way to provide the
(future) GUI with a way of saying "here's your export file and here's what we
have to say about it (thinks like "this might not import cleanly because blah
blah, you need to make sure that blah blah" or "These 5 entities failed to
export but otherwise it went fine. Are you okay with that?").
I know about the errors the GWT compiler gives out but since it is not harming
anyone, I left it like that. These classes will never cross to the client side
(at most they will be used by the GWT service impls to prepare the data for
the GUI consumption in an efficient way).
Why I even bothered with a complicated approach like this? Currently, the
export only handles system settings and metric templates and the XML it
produces has 0.5MB (it's sent zipped up over the wire and it's only a few KB
then) and I wanted to make sure we don't need several passes through that data
(and thus either having to store it on the disk or in the memory serverside)
to provide all the information to the user. This will become more of an issue
when/if more is added to the export file (alert templates with all the configs
for notifications, groups, roles, users, ...).
On Wednesday, August 10, 2011 10:21:17 Heiko W.Rupp wrote:
> Am 09.08.2011 um 23:51 schrieb John Mazzitelli:
> > It may be true that these classes are not going to be used by GWT
> > clients, however, we need to keep stuff out of the GWT compilation if
> > they a) are not to be intended to be used by GWT clients and/or b) they
> > can't be compiled by GWT.
> >
> > We can discuss tomorrow how to fix this. We either a) must move these
> > out of the domain module entirely or b) figure out a good "exclusion"
>
> Remember that there may be other clients that may need those
> classes.
>
> > policy for putting things in domain but keeping them out of the GWT
> > compilation unit. We already have one class in domain where we are doing
>
> So exclusion may make more sense.
>
> The underlying question here is why domain classes need java.io
More information about the rhq-devel
mailing list