Synergy with OpenXava
14 views
Skip to first unread message
javierpaniza
May 2, 2008, 11:45:48 AM5/2/08
to jmatter
Hi all,
I'm Javier Paniza, project lead of OpenXava project,
http://www.openxava.org/
and I have a proposal for JMatter team and community.
OpenXava and JMatter are very alike products,
in fact, OpenXava compete against JMatter.
Even though, I think that JMatter and OpenXava
can cooperate in some way, and this can be profitable
for both, this can help us to gain ground against
MVC frameworks.
But, How ?
We can concentrate in portability. The idea is that a
develeper develops an applicaton for OpenXava, and in
any moment he could migrate it with a minimun effort
to JMatter. The same application, different engine
for running it. Even, if we will achieve a high level
of portability, the developer can have the application
on OpenXava (to use it inside a Java Portal) or in JMatter
to use it as a Java Client Application.
How we can obtain this portability ?
We can start using standard Java API as JPA for persistence,
and bean validation (JSR-303) for validation. Removing
from our frameworks all propietary annotation about these
issues.
Then, we can try to create a "common" specification for
layout, currently OX does it in this way:
http://openxava.wikispaces.com/view_en
and controller, OX does it in this way:
http://openxava.wikispaces.com/controllers_en
Maybe, this proposal is technically impossible,
or it's outside of the JMatter strategy.
But, maybe not.
This offer can include other model driven frameworks
as Trails, RomaFrameworks or Naked Objects.
What think about this the JMatter team ?
What think about this the JMatter community ?
Regards,
Javier Paniza
P.D.: I apologize if this is not the correct place for this issue. I
was looking for a "Discussion forum" or so.
I'm Javier Paniza, project lead of OpenXava project,
http://www.openxava.org/
and I have a proposal for JMatter team and community.
OpenXava and JMatter are very alike products,
in fact, OpenXava compete against JMatter.
Even though, I think that JMatter and OpenXava
can cooperate in some way, and this can be profitable
for both, this can help us to gain ground against
MVC frameworks.
But, How ?
We can concentrate in portability. The idea is that a
develeper develops an applicaton for OpenXava, and in
any moment he could migrate it with a minimun effort
to JMatter. The same application, different engine
for running it. Even, if we will achieve a high level
of portability, the developer can have the application
on OpenXava (to use it inside a Java Portal) or in JMatter
to use it as a Java Client Application.
How we can obtain this portability ?
We can start using standard Java API as JPA for persistence,
and bean validation (JSR-303) for validation. Removing
from our frameworks all propietary annotation about these
issues.
Then, we can try to create a "common" specification for
layout, currently OX does it in this way:
http://openxava.wikispaces.com/view_en
and controller, OX does it in this way:
http://openxava.wikispaces.com/controllers_en
Maybe, this proposal is technically impossible,
or it's outside of the JMatter strategy.
But, maybe not.
This offer can include other model driven frameworks
as Trails, RomaFrameworks or Naked Objects.
What think about this the JMatter team ?
What think about this the JMatter community ?
Regards,
Javier Paniza
P.D.: I apologize if this is not the correct place for this issue. I
was looking for a "Discussion forum" or so.
Eitan Suez
May 2, 2008, 4:49:48 PM5/2/08
to jma...@googlegroups.com
Hi Javier,
this is the correct place for discussions. thank you for
your message. i will take a little time to reflect before
responding. everyone on the mailing list, please
feel free to give your opinions on the subject.
Sincerely,
/ eitan
this is the correct place for discussions. thank you for
your message. i will take a little time to reflect before
responding. everyone on the mailing list, please
feel free to give your opinions on the subject.
Sincerely,
/ eitan
FriedDust
May 4, 2008, 2:55:03 AM5/4/08
to jmatter
if it helps us create 3 tier apps then I'm IN.
eitan
May 5, 2008, 6:19:01 PM5/5/08
to jmatter
here are my thoughts:
1. i agree that our like frameworks should try to work together
2. i think one way to make apps more portable across the
various like-frameworks is to define a standard way
to digest a model definition. i.e. it could be as simple
as "export my model to the common definition" and
"import this common definition model into jmatter."
( the umlc product from ryan ramage (ultraviolet)
i feel is a good candidate. )
i've often considered experimenting with other languages as
a more malleable substrate in which to define models.
in such a circumstance, jsr's may not work out as a
basis for a common definition
3. frieddust's comment below echoes what is probably the
most important feature lacking in jmatter: making it
work 3-tier. i do feel this is probably where the
majority of the dev effort in jmatter should focus.
it's been a long time since i've looked at OX. i will
need to spend a little time with it and get more familiar
to see if this is a possible area for collaboration.
thanks,
/ eitan
1. i agree that our like frameworks should try to work together
2. i think one way to make apps more portable across the
various like-frameworks is to define a standard way
to digest a model definition. i.e. it could be as simple
as "export my model to the common definition" and
"import this common definition model into jmatter."
( the umlc product from ryan ramage (ultraviolet)
i feel is a good candidate. )
i've often considered experimenting with other languages as
a more malleable substrate in which to define models.
in such a circumstance, jsr's may not work out as a
basis for a common definition
3. frieddust's comment below echoes what is probably the
most important feature lacking in jmatter: making it
work 3-tier. i do feel this is probably where the
majority of the dev effort in jmatter should focus.
it's been a long time since i've looked at OX. i will
need to spend a little time with it and get more familiar
to see if this is a possible area for collaboration.
thanks,
/ eitan
javierpaniza
May 7, 2008, 12:01:51 PM5/7/08
to jmatter
Hi Eitan,
thanks for your comments.
I answer you below.
> 1. i agree that our like frameworks should try to work together
Great!
> 2. i think one way to make apps more portable across the
> various like-frameworks is to define a standard way
> to digest a model definition. i.e. it could be as simple
> as "export my model to the common definition" and
> "import this common definition model into jmatter."
> ( the umlc product from ryan ramage (ultraviolet)
> i feel is a good candidate. )
Time ago I worked with XMI, exporting from TogetherJ and Importing
with VisualAge. This work for creating a first EJB application
rapidly, but really I didn't like this approach.
Personally, I prefer to use pure Java classes as definition lenguage,
and I like to use roundtrip UML tools, as the old TogetherJ.
For me the ideal, is that the Java code used for creating an OpenXava
application could work directly in a JMatter application, and vice
versa, without export/import.
>
> i've often considered experimenting with other languages as
> a more malleable substrate in which to define models.
> in such a circumstance, jsr's may not work out as a
> basis for a common definition
I'm just thinking in using Java POJOs as "lingua franca". And this
thread can be a first step for that.
Are you thinking in XML ? in Ruby ?
specific features outside of the scope of OpenXava. My goal is not to
mix OX and JMatter, or collobarate at code level, but creating a
common way for writting the model classes for our frameworks, In this
way, we can achieve more portability. Moreover, we add value to our
frameworks. The users of JMatter will not write application for
JMatter anymore, but they will write "standard" Java applications that
JMatter can be run.
For example, you use @Persist propietary annotation. Why not do you
use @Entity from JPA ? Why not to embrace JPA for collections,
relationships, inheritance, etc ?
And instead of using your own validation framework, why not to use
Hibernate Validator ?
Or JSR-303 when available.
If you do so, an application written for OpenXava (that uses JPA and
Hibernate Validator) can be ported to JMatter easily.
OpenXava uses JPA since version 3, before it used a propietary XML
format.
OpenXava uses Hibernate Validator since version 3.0.1, before it used
a propietary validator.
We changed OX in order to be more standard.
Are you willing to do the same with JMatter ?
What do you think ?
Cheers
Javier
thanks for your comments.
I answer you below.
> 1. i agree that our like frameworks should try to work together
> 2. i think one way to make apps more portable across the
> various like-frameworks is to define a standard way
> to digest a model definition. i.e. it could be as simple
> as "export my model to the common definition" and
> "import this common definition model into jmatter."
> ( the umlc product from ryan ramage (ultraviolet)
> i feel is a good candidate. )
with VisualAge. This work for creating a first EJB application
rapidly, but really I didn't like this approach.
Personally, I prefer to use pure Java classes as definition lenguage,
and I like to use roundtrip UML tools, as the old TogetherJ.
For me the ideal, is that the Java code used for creating an OpenXava
application could work directly in a JMatter application, and vice
versa, without export/import.
>
> i've often considered experimenting with other languages as
> a more malleable substrate in which to define models.
> in such a circumstance, jsr's may not work out as a
> basis for a common definition
thread can be a first step for that.
Are you thinking in XML ? in Ruby ?
>
> 3. frieddust's comment below echoes what is probably the
> most important feature lacking in jmatter: making it
> work 3-tier. i do feel this is probably where the
> majority of the dev effort in jmatter should focus.
> it's been a long time since i've looked at OX. i will
> need to spend a little time with it and get more familiar
> to see if this is a possible area for collaboration.
I know that JMatter is a very good a mature product with a lot of
> 3. frieddust's comment below echoes what is probably the
> most important feature lacking in jmatter: making it
> work 3-tier. i do feel this is probably where the
> majority of the dev effort in jmatter should focus.
> it's been a long time since i've looked at OX. i will
> need to spend a little time with it and get more familiar
> to see if this is a possible area for collaboration.
specific features outside of the scope of OpenXava. My goal is not to
mix OX and JMatter, or collobarate at code level, but creating a
common way for writting the model classes for our frameworks, In this
way, we can achieve more portability. Moreover, we add value to our
frameworks. The users of JMatter will not write application for
JMatter anymore, but they will write "standard" Java applications that
JMatter can be run.
For example, you use @Persist propietary annotation. Why not do you
use @Entity from JPA ? Why not to embrace JPA for collections,
relationships, inheritance, etc ?
And instead of using your own validation framework, why not to use
Hibernate Validator ?
Or JSR-303 when available.
If you do so, an application written for OpenXava (that uses JPA and
Hibernate Validator) can be ported to JMatter easily.
OpenXava uses JPA since version 3, before it used a propietary XML
format.
OpenXava uses Hibernate Validator since version 3.0.1, before it used
a propietary validator.
We changed OX in order to be more standard.
Are you willing to do the same with JMatter ?
What do you think ?
Cheers
Javier
Eitan Suez
May 7, 2008, 1:05:05 PM5/7/08
to jma...@googlegroups.com
hi Javier,
i'm thinking about groovy and jruby at the moment, but i have
to admit i have made little concrete progress in this direction.
i wonder whether differences in opinion on design might get in
the way of abiding by a single standard. for example i'm big on
using the equivalent of scala's val declaration (final members
in java) to model child fields. whereas i get the feeling that most
java developers prefer the javabeans convention.
moving to the jpa has been on my todo list for a long time. :-)
i do intend to get there. i think it's mostly an issue of prioritization.
hibernate validator is relatively new. i haven't yet looked at it. hibernate
projects do seem to quickly gain defacto standard status.
i'm not sure how i feel about the whole standards game. how
you design something to a great deal defines what it is. some
things are mundane, like the jpa annotations, so going with it
is a fairly straightforward decision.
i will try to get there. the main friction points for me at the moment are
not so much willingness, but time constraints and prioritization
of tasks (i.e. other tasks may get worked on before the ones you
propose).
anyhow, the first thing i should do is get up to speed on openxava
and see how ox models are defined and how they differ from jmatter's.
thanks,
/ eitan
I'm just thinking in using Java POJOs as "lingua franca". And this
thread can be a first step for that.
Are you thinking in XML ? in Ruby ?
>
i'm thinking about groovy and jruby at the moment, but i have
to admit i have made little concrete progress in this direction.
My goal is ... creating a
common way for writting the model classes for our frameworks, In this
way, we can achieve more portability. Moreover, we add value to our
frameworks. The users of JMatter will not write application for
JMatter anymore, but they will write "standard" Java applications that
JMatter can be run.
For example, you use @Persist propietary annotation. Why not do you
use @Entity from JPA ? Why not to embrace JPA for collections,
relationships, inheritance, etc ?
And instead of using your own validation framework, why not to use
Hibernate Validator ?
Or JSR-303 when available.
If you do so, an application written for OpenXava (that uses JPA and
Hibernate Validator) can be ported to JMatter easily.
OpenXava uses JPA since version 3, before it used a propietary XML
format.
OpenXava uses Hibernate Validator since version 3.0.1, before it used
a propietary validator.
We changed OX in order to be more standard.
Are you willing to do the same with JMatter ?
What do you think ?
i wonder whether differences in opinion on design might get in
the way of abiding by a single standard. for example i'm big on
using the equivalent of scala's val declaration (final members
in java) to model child fields. whereas i get the feeling that most
java developers prefer the javabeans convention.
moving to the jpa has been on my todo list for a long time. :-)
i do intend to get there. i think it's mostly an issue of prioritization.
hibernate validator is relatively new. i haven't yet looked at it. hibernate
projects do seem to quickly gain defacto standard status.
i'm not sure how i feel about the whole standards game. how
you design something to a great deal defines what it is. some
things are mundane, like the jpa annotations, so going with it
is a fairly straightforward decision.
i will try to get there. the main friction points for me at the moment are
not so much willingness, but time constraints and prioritization
of tasks (i.e. other tasks may get worked on before the ones you
propose).
anyhow, the first thing i should do is get up to speed on openxava
and see how ox models are defined and how they differ from jmatter's.
thanks,
/ eitan
Werner
May 8, 2008, 4:43:57 AM5/8/08
to jmatter
I would like to share my thoughts on this as an user of jmatter
(although a very fresh one, but my entusiasm is growing).
Moving to JPA Annotations would be a step towards on reusing model
definitions.
For example at the moment I use jmatter to design/build a data
structure. Jmatter helps me providing at the same time with low effort
to generate a nice looking UI which can directly go into production.
The data entered through the jmatter UI will be used later in another
enviroment (web, docs, etc.). In the first step I realise this through
export command, but later on i would other applications allow to
directly use the jmatter db.
This could be done with sharing the hbm mappings in the first step.
In short: The usage of jmatter allows me to fully concentrate on
designing a waterproof model definition on the one hand and on the
other also showing the end user what he will get. I think the term
agile software development would fit perfectly.
Now how cool would it be: Write a JPA Model definition. Put this
defition into jmatter / openxava and get a ready to use editor ui!
Even Frameworks like JBoss Seam could use these classes to manually
create a web frontend...
I hope you get the point what I mean - I am really entusiastic on this
approach
Werner
(although a very fresh one, but my entusiasm is growing).
Moving to JPA Annotations would be a step towards on reusing model
definitions.
For example at the moment I use jmatter to design/build a data
structure. Jmatter helps me providing at the same time with low effort
to generate a nice looking UI which can directly go into production.
The data entered through the jmatter UI will be used later in another
enviroment (web, docs, etc.). In the first step I realise this through
export command, but later on i would other applications allow to
directly use the jmatter db.
This could be done with sharing the hbm mappings in the first step.
In short: The usage of jmatter allows me to fully concentrate on
designing a waterproof model definition on the one hand and on the
other also showing the end user what he will get. I think the term
agile software development would fit perfectly.
Now how cool would it be: Write a JPA Model definition. Put this
defition into jmatter / openxava and get a ready to use editor ui!
Even Frameworks like JBoss Seam could use these classes to manually
create a web frontend...
I hope you get the point what I mean - I am really entusiastic on this
approach
Werner
Eitan Suez
May 8, 2008, 11:30:05 AM5/8/08
to jma...@googlegroups.com
i agree that great value can be derived from being able
to use the same model/database in various contexts:
a web app, a swing app, tooling, etc..
and the best way to distribute the work of building the
infrastructure to produce the tooling, the web app, the
swing app, etc.. is to have a common model definition.
when ryan built ultraviolet, he also had defined umlc,
a simple way to define a model, that he then was able
to translate into jmatter code using velocity templates.
i've often tried to imagine a dsl for the model. i'll *try* to
take a little time this weekend to ramp up.
/ eitan
to use the same model/database in various contexts:
a web app, a swing app, tooling, etc..
and the best way to distribute the work of building the
infrastructure to produce the tooling, the web app, the
swing app, etc.. is to have a common model definition.
when ryan built ultraviolet, he also had defined umlc,
a simple way to define a model, that he then was able
to translate into jmatter code using velocity templates.
i've often tried to imagine a dsl for the model. i'll *try* to
take a little time this weekend to ramp up.
/ eitan
javierpaniza
May 8, 2008, 12:33:53 PM5/8/08
to jmatter
Hi Eitan,
> i wonder whether differences in opinion on design might get in
> the way of abiding by a single standard. for example i'm big on
> using the equivalent of scala's val declaration (final members
> in java) to model child fields. whereas i get the feeling that most
> java developers prefer the javabeans convention.
In this case I prefer the standard (JSR or de facto) even though it
will be
not the best option. OX uses javabeans conventions for properties.
Although I don't like java properties,
look at this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1769130&group_id=123187&atid=695746
Yes, I don't like getters and setters and OX3.1 will allow work
without them,
but OX supports getters and setters first and it will continue
supporting them for ever.
In 90s a like Eiffel but I choose Java.
I loved JDO, but I choose JPA.
>
> moving to the jpa has been on my todo list for a long time. :-)
Fantastic!
> i will try to get there. the main friction points for me at the moment are
> not so much willingness, but time constraints and prioritization
> of tasks (i.e. other tasks may get worked on before the ones you
> propose).
>
I understand
Well! I let you to work, and when you have a JMatter JPA compatible
version,
we can take up again this issue. I see in you an open mind,
maybe we can achieve some interesting things in the future.
Cheers
Javier
> i wonder whether differences in opinion on design might get in
> the way of abiding by a single standard. for example i'm big on
> using the equivalent of scala's val declaration (final members
> in java) to model child fields. whereas i get the feeling that most
> java developers prefer the javabeans convention.
will be
not the best option. OX uses javabeans conventions for properties.
Although I don't like java properties,
look at this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1769130&group_id=123187&atid=695746
Yes, I don't like getters and setters and OX3.1 will allow work
without them,
but OX supports getters and setters first and it will continue
supporting them for ever.
In 90s a like Eiffel but I choose Java.
I loved JDO, but I choose JPA.
>
> moving to the jpa has been on my todo list for a long time. :-)
> i will try to get there. the main friction points for me at the moment are
> not so much willingness, but time constraints and prioritization
> of tasks (i.e. other tasks may get worked on before the ones you
> propose).
>
Well! I let you to work, and when you have a JMatter JPA compatible
version,
we can take up again this issue. I see in you an open mind,
maybe we can achieve some interesting things in the future.
Cheers
Javier
javierpaniza
May 8, 2008, 12:38:56 PM5/8/08
to jmatter
Hi Werner,
> Now how cool would it be: Write a JPA Model definition. Put this
> defition into jmatter / openxava and get a ready to use editor ui!
> Even Frameworks like JBoss Seam could use these classes to manually
> create a web frontend...
Yes, yes, yes. You get my point.
I think that this is not only useful for you, the application
developers, but
for us the framework providers.
Give us some time, and don't forget to put pressure on us.
Cheers
Javier
> Now how cool would it be: Write a JPA Model definition. Put this
> defition into jmatter / openxava and get a ready to use editor ui!
> Even Frameworks like JBoss Seam could use these classes to manually
> create a web frontend...
I think that this is not only useful for you, the application
developers, but
for us the framework providers.
Give us some time, and don't forget to put pressure on us.
Cheers
Javier
javierpaniza
May 8, 2008, 12:42:42 PM5/8/08
to jmatter
Hi Eitan
> is to have a common model definition.
We already have it. POJOs + JPA.
Is there a way for model definition more popular ?
Cheers
Javier
> is to have a common model definition.
Is there a way for model definition more popular ?
Cheers
Javier
Eitan Suez
May 8, 2008, 1:44:50 PM5/8/08
to jma...@googlegroups.com
On Thu, May 8, 2008 at 11:33 AM, javierpaniza <javier...@gestion400.com> wrote:
Hi Eitan,
In this case I prefer the standard (JSR or de facto) even though it
> i wonder whether differences in opinion on design might get in
> the way of abiding by a single standard. for example i'm big on
> using the equivalent of scala's val declaration (final members
> in java) to model child fields. whereas i get the feeling that most
> java developers prefer the javabeans convention.
will be not the best option. OX uses javabeans conventions for properties.
Although I don't like java properties, look at this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1769130&group_id=123187&atid=695746
Yes, I don't like getters and setters and OX3.1 will allow work
without them,
but OX supports getters and setters first and it will continue
supporting them for ever.
interesting. i know the new stock of languages (scala/groovy/jruby)
make properties more of a first-class notion, and don't require writing
the getters[/setters]. that's one reason i'm inclined to move in that
direction. that and the fact that these languages were designed for
instrumentation.
In 90s a like Eiffel but I choose Java.
I loved JDO, but I choose JPA.
that's interesting. yeah i suppose that neither jdo or eiffel are
mainstream any longer. look at rails though. they stuck to their
guns. i don't think because something is a standard is good
enough reason to use it. i'm always surprised to hear stories
about ex-smalltalkers moving to java back in the late 90's. i
suppose that's where the jobs were at the time. but that's the
wrong way to think. look at paul graham for example. i think
he came out on top when he stuck with lisp for building self-service
online stores. also the trend is fairly clear. talks on java-related
technologies at javaone are all being turned down (unless they
come from within sun i guess). most of the
talks on groovy and jruby and javascript and web are being
accepted. even what's his name, craig mclanahan, the author
of jsf, now attends and talks at rails events.
o/r mapping however remains one area where java is strong.
the groovy folks are wrapping hibernate with gorm to get around
the idiosynchracies of the api.
/ eitan
aalmiray
May 8, 2008, 9:23:57 PM5/8/08
to jmatter
Don't mind if I step in.
POJO + JPA looks to be the preferred way so far and I agree
with it. Going forward with the model's format I would suggest
Groovy (I know I'm biased as I love it) but also because of the
following reasons
- syntax is closer to Java
- syntax is short and expressive enough
+ properties do not require getter/setter, so converting a XO's
domain class to Groovy just needs to list its properties
- supports annotations out of the box
- XML is
So the model format may be solved with this approach but what
about the business logic? will it be migrated also? I now that models
in JMatter are behavior complete which means POJOs also hold
their business methods and relationships, I assume XO follows
a different path here so exporting behavior may be a little tricky.
My $0.02
On May 8, 10:44 am, "Eitan Suez" <eitan.s...@gmail.com> wrote:
> On Thu, May 8, 2008 at 11:33 AM, javierpaniza <javierpan...@gestion400.com>
POJO + JPA looks to be the preferred way so far and I agree
with it. Going forward with the model's format I would suggest
Groovy (I know I'm biased as I love it) but also because of the
following reasons
- syntax is closer to Java
- syntax is short and expressive enough
+ properties do not require getter/setter, so converting a XO's
domain class to Groovy just needs to list its properties
- supports annotations out of the box
- XML is
So the model format may be solved with this approach but what
about the business logic? will it be migrated also? I now that models
in JMatter are behavior complete which means POJOs also hold
their business methods and relationships, I assume XO follows
a different path here so exporting behavior may be a little tricky.
My $0.02
On May 8, 10:44 am, "Eitan Suez" <eitan.s...@gmail.com> wrote:
> On Thu, May 8, 2008 at 11:33 AM, javierpaniza <javierpan...@gestion400.com>
> wrote:
>
>
>
>
>
> > Hi Eitan,
>
> > > i wonder whether differences in opinion on design might get in
> > > the way of abiding by a single standard. for example i'm big on
> > > using the equivalent of scala's val declaration (final members
> > > in java) to model child fields. whereas i get the feeling that most
> > > java developers prefer the javabeans convention.
>
> > In this case I prefer the standard (JSR or de facto) even though it
> > will be not the best option. OX uses javabeans conventions for properties.
> > Although I don't like java properties, look at this:
>
> >http://sourceforge.net/tracker/index.php?func=detail&aid=1769130&grou...
>
>
>
>
>
> > Hi Eitan,
>
> > > i wonder whether differences in opinion on design might get in
> > > the way of abiding by a single standard. for example i'm big on
> > > using the equivalent of scala's val declaration (final members
> > > in java) to model child fields. whereas i get the feeling that most
> > > java developers prefer the javabeans convention.
>
> > In this case I prefer the standard (JSR or de facto) even though it
> > will be not the best option. OX uses javabeans conventions for properties.
> > Although I don't like java properties, look at this:
>
javierpaniza
May 9, 2008, 12:35:16 PM5/9/08
to jmatter
Hi Eitan,
as you see, I always have a last word to say ;)
> interesting. i know the new stock of languages (scala/groovy/jruby)
> make properties more of a first-class notion, and don't require writing
> the getters[/setters]. that's one reason i'm inclined to move in that
> direction. that and the fact that these languages were designed for
> instrumentation.
Look my comment here:
http://www.infoq.com/news/2007/02/railsanswer#view_5058
Maybe I was very influenced by Eiffel and the OOSC Meyer's book,
and I consider dynamic typed languages (as Ruby) as programmer
enemies.
Because, with dynamic type languages, the compiler does not help you
to find
your own mistakes. You will develop rapidly fragile systems.
I was user of an application developed with a dynamic type language
(VisualAge, developed with Smalltalk) and it was a very fragile
product,
I can swear you.
Maybe, if you will move to JPA, then possibly we can collaborate,
if you move to Ruby or Groovy, this will be more difficult. Maybe, you
have
reason, and it is a very good idea. Or perhaps, I will change my mind.
Anyways, I will follow the track of JMatter.
Cheers
Javier
as you see, I always have a last word to say ;)
> interesting. i know the new stock of languages (scala/groovy/jruby)
> make properties more of a first-class notion, and don't require writing
> the getters[/setters]. that's one reason i'm inclined to move in that
> direction. that and the fact that these languages were designed for
> instrumentation.
http://www.infoq.com/news/2007/02/railsanswer#view_5058
Maybe I was very influenced by Eiffel and the OOSC Meyer's book,
and I consider dynamic typed languages (as Ruby) as programmer
enemies.
Because, with dynamic type languages, the compiler does not help you
to find
your own mistakes. You will develop rapidly fragile systems.
I was user of an application developed with a dynamic type language
(VisualAge, developed with Smalltalk) and it was a very fragile
product,
I can swear you.
Maybe, if you will move to JPA, then possibly we can collaborate,
if you move to Ruby or Groovy, this will be more difficult. Maybe, you
have
reason, and it is a very good idea. Or perhaps, I will change my mind.
Anyways, I will follow the track of JMatter.
Cheers
Javier
javierpaniza
May 9, 2008, 12:43:38 PM5/9/08
to jmatter
Hola Andrés,
> Going forward with the model's format I would suggest
> Groovy (I know I'm biased as I love it) but also because of the
> following reasons
> - syntax is closer to Java
> - syntax is short and expressive enough
> + properties do not require getter/setter, so converting a XO's
> domain class to Groovy just needs to list its properties
> - supports annotations out of the box
> - XML is
These are not real advantage of Groovy over Java.
Can you mention some "practical" advantages of Groovy over Java?
> in JMatter are behavior complete which means POJOs also hold
> their business methods and relationships, I assume XO follows
> a different path here so exporting behavior may be a little tricky.
In OX the relationships and business logic are in the POJOs,
just as in JMatter.
Saludos
Javier
> Going forward with the model's format I would suggest
> Groovy (I know I'm biased as I love it) but also because of the
> following reasons
> - syntax is closer to Java
> - syntax is short and expressive enough
> + properties do not require getter/setter, so converting a XO's
> domain class to Groovy just needs to list its properties
> - supports annotations out of the box
> - XML is
Can you mention some "practical" advantages of Groovy over Java?
> in JMatter are behavior complete which means POJOs also hold
> their business methods and relationships, I assume XO follows
> a different path here so exporting behavior may be a little tricky.
just as in JMatter.
Saludos
Javier
aalmiray
May 9, 2008, 1:11:24 PM5/9/08
to jmatter
Javier,
I wasn't selling Groovy over Java, surely not! I meant to use
Groovy as the interchange format, not XML nor JSON.
If XO and JMatter allow POGOs and other Groovy goodness
that is their prerogative.
I wasn't selling Groovy over Java, surely not! I meant to use
Groovy as the interchange format, not XML nor JSON.
If XO and JMatter allow POGOs and other Groovy goodness
that is their prerogative.
Javier Paniza Lucas
May 9, 2008, 1:28:06 PM5/9/08
to jma...@googlegroups.com
Hola Andrés,
> Javier,
>
> I wasn't selling Groovy over Java, surely not! I meant to use
> Groovy as the interchange format, not XML nor JSON.
>
Sorry, I didn't understand your idea at first glance.
My original is idea is NOT to migrate from OX to JMatter or vice versa,
but that the same Java source code can run on both, without touch it.
You can have a unique application at same time, and running with
JMatter or OX. In this way, JMatter and OX are more like application
engines instead of frameworks.
> Javier,
>
> I wasn't selling Groovy over Java, surely not! I meant to use
> Groovy as the interchange format, not XML nor JSON.
>
My original is idea is NOT to migrate from OX to JMatter or vice versa,
but that the same Java source code can run on both, without touch it.
You can have a unique application at same time, and running with
JMatter or OX. In this way, JMatter and OX are more like application
engines instead of frameworks.
Saludos
Javi
Reply all
Reply to author
Forward
0 new messages