Dynamic query-result rendering ...
8 views
Skip to first unread message
Dario Bahena Tapia
Nov 30, 2009, 6:34:41 PM11/30/09
to jma...@googlegroups.com
Hello Eitan and all,
First of all, thanks for creating JMatter ... I am in a hurry to
create an application for a couple of master courses, and NakedObjects
architecture, incarnated into your framework, seems long waited way to
go.
Having said that, I want to ask something about custom queries (I am
sorry if it was asked before, could not find it):
Let us say that I want a report which is build from a complex query,
and let us imagine that I am not even going to use HQL but plain old
SQL. So far, I think I can make this work if I:
1. Create a method returning and Object and getting annotated with
@Cmd (let us imagine for the moment we do not need user input
parameters).
2. Inside the method, I can get access to hibernate engine and make my
SQL query and catch the result into a List of certain Objects (whether
managed or not, that seems to be not relevant here, as long as they
are bean-flavored).
3. Construct a PlainListEObject passing the type of the list's items
and the list itself on the constructor. Returning that
PlainListEObject .
That's it, JMatter is capable of rendering that and this will suffice
to implement any fancy query.
However, this adds a little inconvenience, that may have to do with
hibernate as well: I need to create a dummy bean for each query of
this kind. I can automate that in several ways, I can even create a
class on the fly and catch it for each query result set.
But before going on any of this paths, I wanted to hear advice from
you. How would you do it? Is there anything else on JMatter that may
allow me to do this easier?
Thanks in advance.
First of all, thanks for creating JMatter ... I am in a hurry to
create an application for a couple of master courses, and NakedObjects
architecture, incarnated into your framework, seems long waited way to
go.
Having said that, I want to ask something about custom queries (I am
sorry if it was asked before, could not find it):
Let us say that I want a report which is build from a complex query,
and let us imagine that I am not even going to use HQL but plain old
SQL. So far, I think I can make this work if I:
1. Create a method returning and Object and getting annotated with
@Cmd (let us imagine for the moment we do not need user input
parameters).
2. Inside the method, I can get access to hibernate engine and make my
SQL query and catch the result into a List of certain Objects (whether
managed or not, that seems to be not relevant here, as long as they
are bean-flavored).
3. Construct a PlainListEObject passing the type of the list's items
and the list itself on the constructor. Returning that
PlainListEObject .
That's it, JMatter is capable of rendering that and this will suffice
to implement any fancy query.
However, this adds a little inconvenience, that may have to do with
hibernate as well: I need to create a dummy bean for each query of
this kind. I can automate that in several ways, I can even create a
class on the fly and catch it for each query result set.
But before going on any of this paths, I wanted to hear advice from
you. How would you do it? Is there anything else on JMatter that may
allow me to do this easier?
Thanks in advance.
Eitan Suez
Nov 30, 2009, 7:11:48 PM11/30/09
to jma...@googlegroups.com
a couple of initial thoughts..
1. if what you're after is the ability to generically display
a resultset for all sorts of different sql queries, then
adding that capability into the framework seems like
a better solution than creating a dummy bean for each
and every different type of result set.
i can show you the places in the system where the
cmd return type is inferred; the rest is mostly swing:
perhaps a jtable that's bound to the resulting list of
object[]'s.
2. the nice thing about jmatter is the fact that you define
a type and you get both [1] the ui for it, and [2] a persisted
entity (thanks mostly to hibernate). what i didn't spend
much time on, is a design that easily allows for
decoupling the two: defining a type that you want to
persist but not display, or display but not persist.
the former is fairly a no-brainer. not adding the type
to the class bar is one way to not have it in the ui.
the latter may be a little trickier. we can start by not
putting an @Entity on the type. but the base type
AbstractComplexEObject assumes you're dealing with
a persisted entity. i'm thinking perhaps base commands
such as type().Browse() may leak in the ui if the type
is added to the classbar.
/ eitan
1. if what you're after is the ability to generically display
a resultset for all sorts of different sql queries, then
adding that capability into the framework seems like
a better solution than creating a dummy bean for each
and every different type of result set.
i can show you the places in the system where the
cmd return type is inferred; the rest is mostly swing:
perhaps a jtable that's bound to the resulting list of
object[]'s.
2. the nice thing about jmatter is the fact that you define
a type and you get both [1] the ui for it, and [2] a persisted
entity (thanks mostly to hibernate). what i didn't spend
much time on, is a design that easily allows for
decoupling the two: defining a type that you want to
persist but not display, or display but not persist.
the former is fairly a no-brainer. not adding the type
to the class bar is one way to not have it in the ui.
the latter may be a little trickier. we can start by not
putting an @Entity on the type. but the base type
AbstractComplexEObject assumes you're dealing with
a persisted entity. i'm thinking perhaps base commands
such as type().Browse() may leak in the ui if the type
is added to the classbar.
/ eitan
--
You received this message because you are subscribed to the Google Groups "jmatter" group.
To post to this group, send email to jma...@googlegroups.com.
To unsubscribe from this group, send email to jmatter+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jmatter?hl=en.
Dario Bahena Tapia
Dec 1, 2009, 11:17:03 PM12/1/09
to jma...@googlegroups.com
Dear Eitan,
Thanks for your quick response. I think that I definitely want to go
with the first thought, and try to add that into the framework itself.
Then, any starting point where to look at would be appreciated.
Thanks again,
Dario.
> On Mon, Nov 30, 2009 at 5:34 PM, Dario Bahena Tapia <dari...@gmail.com>
Thanks for your quick response. I think that I definitely want to go
with the first thought, and try to add that into the framework itself.
Then, any starting point where to look at would be appreciated.
Thanks again,
Dario.
littlehouse
Dec 8, 2009, 5:12:07 AM12/8/09
to jmatter
I made something similar with hql without any change to the framework
(the problems written by Eitan are true but it works as grid that one
can export or print)
On 2 Dic, 05:17, Dario Bahena Tapia <dario...@gmail.com> wrote:
> Dear Eitan,
>
> Thanks for your quick response. I think that I definitely want to go
> with the first thought, and try to add that into the framework itself.
> Then, any starting point where to look at would be appreciated.
>
> Thanks again,
> Dario.
>
> > On Mon, Nov 30, 2009 at 5:34 PM, Dario Bahena Tapia <dario...@gmail.com>
(the problems written by Eitan are true but it works as grid that one
can export or print)
On 2 Dic, 05:17, Dario Bahena Tapia <dario...@gmail.com> wrote:
> Dear Eitan,
>
> Thanks for your quick response. I think that I definitely want to go
> with the first thought, and try to add that into the framework itself.
> Then, any starting point where to look at would be appreciated.
>
> Thanks again,
> Dario.
>
Reply all
Reply to author
Forward
0 new messages