Harmeet and David,
Thank you for the comments! I agree that the ability I proposed could be
taken too far and eventually make mini-language harder to understand.
But at the same time, when a real need arrives to add a new type, it
should be easier to implement.
David - this started with the need to use TimeDuration in the framework.
Adding support for it results in much simpler script. Try this out in
any screen widget screen:
<actions>
<set field="durationLong" value="6000" type="Long"/>
<set field="duration" from-field="durationLong" type="TimeDuration"/>
</actions>
<widgets>
<container style="h2"><label text="${duration}"/></container>
</widgets>
-Adrian
David E Jones wrote:
Thanks for your comments Harmeet.
My main concern was that it makes these various bits of code bigger and
more complex, and to balance that I'm wondering what the need is... ie
what benefit comes from it? I know there are theoretical benefits like
"at some point someone might want to do something different" but that is
highly hypothetical, and in theory one can put an infinite amount of
effort into hypothetical needs and never actually solve any real problems.
Anyway, your point is good Harmeet that this could actually introduce a
weak point where customizers could create more issues.
I suppose my problem is that I've just never run into a need for
something like this... so I find it pretty low on my "care about" meter,
and if Adrian wants to go for it then great! ..and hopefully it will do
more good than harm should it ever do much of either.
-David
On Nov 10, 2009, at 9:58 PM, Harmeet Bedi wrote:
I think TimeDuration is a useful base type. It is something that
exists in .NET system package (TimeSpan class) but has not been given
as much importance in java land. I personally prefer name TimeSpan
over TimeDuration.
I think very nice to replace if-then-else with OO equivalents. Ofbiz
has too much if then else.. Makes things harder to extend.
On a note of caution. Currently system has very few fundamental types
and everything has to be built from those few blocks. It keeps the
foundation very simple.
Custom data types can be powerful but it could be bad if different
apps start adding their own types and building on that. Maybe this is
something that should be reasonably easy to add at system level but
users should not be encouraged to add types.
Harmeet
----- Original Message -----
From: "Adrian Crum" <[email protected]>
To: [email protected]
Sent: Tuesday, November 10, 2009 10:40:54 PM GMT -05:00 US/Canada Eastern
Subject: Discussion: User-Defined Java Data Types In The Framework
I first started thinking of this idea in a Jira issue:
https://issues.apache.org/jira/browse/OFBIZ-3125
I thought it would be easy to extend the framework to support a new
Java object type (or class). I wanted to be able to pass around a
TimeDuration instance in services, mini-lang, screen widgets, etc. I
thought it would be easy. It wasn't.
Those framework artifacts convert Java objects from one type to
another using the ObjectType class. I had to make changes to a huge
monolithic if-else-if block in that class. Then I had to modify some
code in the Entity Engine. I couldn't get the Entity Engine to support
the TimeDuration class because of two monolithic switch statements
where Java data types are mapped to integers, but not in a centralized
way.
I stopped trying to wedge the TimeDuration class into inflexible code,
and instead started working on making the code more flexible.
I replaced the monolithic if-else-if block in ObjectType with
polymorphism. Now components can extend the framework with their own
Java object type conversions.
I still need to work on the Entity Engine. I would like to replace its
monolithic conditionals with the new conversion code. Before I get
started, I wanted to present the idea to the community to see if there
were any objections.
The goal is to make it easier for developers to add new Java data
types to the framework. I see this as a big benefit to writing OFBiz
add-ons or customizations.
What do you think?
-Adrian
