Re: [convert] a different approach...

2004-11-27 Thread Ron Blaschke
Saturday, November 27, 2004, 1:46:28 PM, Matt Sgarlata wrote:

> Actually I'm taking on every problem that Convert was planning to take on,
> so short[] -> int[] is one type of conversion Morph will be able to perform.

Uups, sorry for getting things wrong.  Sounds all the more
interesting.

Ron



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [convert] a different approach...

2004-11-27 Thread Matt Sgarlata
Comments below...
- Original Message - 
From: "Ron Blaschke" <[EMAIL PROTECTED]>
To: "Matt Sgarlata" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, November 26, 2004 6:47 PM
Subject: Re: [convert] a different approach...


I've taken a quick look at your description and the source, which
looks quite promising.  Correct me if I am getting things wrong, but I
think we try to solve different problems, which is acutally a good
thing (as they might even complement each other).
If I get things right, you try to provide a framework for passing
"bean like" structures around, and convert them to their various
representations, as every library provides its own.
My focus is on trying to provide a "generic" conversion framework,
with primary focus on the type.  Eg, some libraries like to use "int,"
others prefer "short," which makes not much of a difference if all
values are, say, between 0 and 1000.
While this conversion is quite simple for some types, it can be
cumbersome for others, eg if you got a short[], but the library
prefers an int[].
Actually I'm taking on every problem that Convert was planning to take on, 
so short[] -> int[] is one type of conversion Morph will be able to perform. 
I do have a large focus in the code so far on "bean like" structures, as you 
put it, but I definitely will be focusing on "container like" structures as 
well, such as Arrays and Collections.  I have been doing some fairly major 
refactorings this weekend, and I hope to be able to complete a 0.3 release 
soon.  There will be more attention to "container like" structures in the 
upcoming 0.3 release.

I depart from Convert by also providing a Context notion as seen in the 
Chain package, and a Language notion, which will support languages like 
Velocity, JSTL EL, etc.  Since Morph makes working with "bean like" 
structures so easy, I thought the Context and Language abstractions would be 
good to include.  Context I definitely want in version 1.0, but Language may 
wait for a later release.  I want to get 1.0 out-the-door as quickly as 
possible so we can all start using it :)

Ron
Matt 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [convert] a different approach...

2004-11-26 Thread Ron Blaschke
Thursday, November 18, 2004, 5:57:48 AM, Matt Sgarlata wrote:

> I haven't been on the list a while but I saw your posts earlier
> this month.  I too, like Ron, spent some time developing my own
> approach to the goals of the commons-convert project.  I have some
> code started out that isn't incredibly well documented, but all the
> ideas are there.  Below is a summary of my approach.  The code is
> available at the URL below under the Apache 2.0 license.

I've taken a quick look at your description and the source, which
looks quite promising.  Correct me if I am getting things wrong, but I
think we try to solve different problems, which is acutally a good
thing (as they might even complement each other).
If I get things right, you try to provide a framework for passing
"bean like" structures around, and convert them to their various
representations, as every library provides its own.
My focus is on trying to provide a "generic" conversion framework,
with primary focus on the type.  Eg, some libraries like to use "int,"
others prefer "short," which makes not much of a difference if all
values are, say, between 0 and 1000.
While this conversion is quite simple for some types, it can be
cumbersome for others, eg if you got a short[], but the library
prefers an int[].

Ron



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [convert] a different approach...

2004-11-25 Thread Matt Sgarlata
make sure you add a link to the wiki so everyone can find morph :)
Done to the best of my ability.  I apologize in advance if I abused the Wiki 
in any way!

i don't see any real harm announcing releases and stuff on the mailing 
lists though it'd probably be wiser not to phrase any posts so as not 
raise the temperature unnecessary. (it's a temptation when you're the new 
project on the block to push general claims of superiority but often it's 
better to focus on individuality: what the project does better)
Thanks for the pointers and the invitation to post release notices :)  I'm 
hoping for a 0.3 release this weekend that will have a revised API.

JSTL (see EL), JEXL, XPath, velocity, jelly (and many, many more projects) 
all contain bean query languages. there are a lot of different approaches. 
one of the real pains with beanutils is that the  bean query language is 
deeply embedded in the component and cannot be easily changed. it became 
clear whilst working on beanutils that really one bean query language (no 
matter how good) really isn't suitable for all use cases.

the key is getting the right level of abstraction for the bean query 
language: close enough to take advantage of features in the introspection 
layer but abstract enough to allow radically different query languages to 
be used.
I'll try to keep this advice in mind, and I will definitely seek your advice 
once I have thought this through some more.  Thanks again for your help!

- robert
Matt 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [convert] a different approach...

2004-11-25 Thread robert burrell donkin
On 18 Nov 2004, at 23:18, Matt Sgarlata wrote:
Hi Robert, thanks for your comments : )  My responses are below...
why not start a little project on source forge...?
Already registered on SF this morning... I probably will create a SF 
project this weekend :)  My tentative project name is "Morph".
make sure you add a link to the wiki so everyone can find morph :)
i don't see any real harm announcing releases and stuff on the mailing 
lists though it'd probably be wiser not to phrase any posts so as not 
raise the temperature unnecessary. (it's a temptation when you're the 
new project on the block to push general claims of superiority but 
often it's better to focus on individuality: what the project does 
better)

- In place of BeanUtils.copyProperties there is a Copier interface.  
It is very similar to the Converter interface, but it's original 
intent was different: to copy data from one location to another, 
where creating a new object doesn't make sense.  For example, let's 
say we want to store information from a Map or an object graph as 
separate attributes in an HTTP request.  We can't just create a new 
HTTP request object... it already exists!  So we use a Copier.  
Basically, Converters are for the simple stuff like primitives, 
Dates, etc and Copiers are for fancier things like Object[] -> List. 
 You can always take something that is written with the Copier 
interface and expose it as a Converter but not vice-versa (The 
net.sf.morph.converters.CopierConverter class exposes a Copier as a 
Converter).
- While working on Copiers, I realized I needed to be able to pull 
information out of various different types of things: objects and 
maps are simple examples, but I might also want to be able to pull 
info from HTTP request parameters, etc.  This is what Reflectors are 
for.  They help Copiers get the job done.
hmmm sounds frameworkish...
Well yes and no.  You are free to implement the Copier interface 
directly, which is just as simple as the Converter interface (both 
have 2 very simple methods, isConvertible/isCopiable and 
convert/copy).  Reflectors are getting frameworkish because they are 
allowing you to plug into the Copiers that come out-of-the-box with 
Morph.  They are basically a mechanism to allow you to treat any 
"weird" type of object as a regular object that has properties. So 
they provide a universal API for accessing the "properties" of 
Objects, Maps, DynaBeans, HttpRequest parameters, HttpRequest 
attributes, HttpSession attributes, or perhaps even RDBMS schemas or 
XML DOMs.  The problem with BeanUtils.copyProperties, is the types of 
things that are considered to have properties are fixed.  They are 
Objects, Maps and DynaBeans -- no more, no less.
that's true enough.
there's nothing wrong with frameworks but IMHO it's important to stop 
good libraries becoming poor frameworks. your reasoning seems sound 
enough and so i'd say that there's space for a framework...

- The Language interface is interesting, but a little out there. 
Basically once we have Reflectors written, we can easily implement 
simple languages like the JSTL EL.  The nice thing about how 
Reflectors are setup though, is that you could easily define a 
reflector for a DynaBean or for some other arbitrary object type.  
This lets you extend your Language very easily.
getting the bean query language at the right level of abstraction is 
key
I'm not sure I follow... any ideas of things I should take a look at?
JSTL (see EL), JEXL, XPath, velocity, jelly (and many, many more 
projects) all contain bean query languages. there are a lot of 
different approaches. one of the real pains with beanutils is that the  
bean query language is deeply embedded in the component and cannot be 
easily changed. it became clear whilst working on beanutils that really 
one bean query language (no matter how good) really isn't suitable for 
all use cases.

the key is getting the right level of abstraction for the bean query 
language: close enough to take advantage of features in the 
introspection layer but abstract enough to allow radically different 
query languages to be used.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [convert] a different approach...

2004-11-18 Thread Matt Sgarlata
Hi Robert, thanks for your comments : )  My responses are below...
why not start a little project on source forge...?
Already registered on SF this morning... I probably will create a SF project 
this weekend :)  My tentative project name is "Morph".

- In place of BeanUtils.copyProperties there is a Copier interface.  It 
is very similar to the Converter interface, but it's original intent was 
different: to copy data from one location to another, where creating a 
new object doesn't make sense.  For example, let's say we want to store 
information from a Map or an object graph as separate attributes in an 
HTTP request.  We can't just create a new HTTP request object... it 
already exists!  So we use a Copier.  Basically, Converters are for the 
simple stuff like primitives, Dates, etc and Copiers are for fancier 
things like Object[] -> List.  You can always take something that is 
written with the Copier interface and expose it as a Converter but not 
vice-versa (The net.sf.morph.converters.CopierConverter class exposes a 
Copier as a Converter).
- While working on Copiers, I realized I needed to be able to pull 
information out of various different types of things: objects and maps 
are simple examples, but I might also want to be able to pull info from 
HTTP request parameters, etc.  This is what Reflectors are for.  They 
help Copiers get the job done.
hmmm sounds frameworkish...
Well yes and no.  You are free to implement the Copier interface directly, 
which is just as simple as the Converter interface (both have 2 very simple 
methods, isConvertible/isCopiable and convert/copy).  Reflectors are getting 
frameworkish because they are allowing you to plug into the Copiers that 
come out-of-the-box with Morph.  They are basically a mechanism to allow you 
to treat any "weird" type of object as a regular object that has properties. 
So they provide a universal API for accessing the "properties" of Objects, 
Maps, DynaBeans, HttpRequest parameters, HttpRequest attributes, HttpSession 
attributes, or perhaps even RDBMS schemas or XML DOMs.  The problem with 
BeanUtils.copyProperties, is the types of things that are considered to have 
properties are fixed.  They are Objects, Maps and DynaBeans -- no more, no 
less.

- The Language interface is interesting, but a little out there. 
Basically once we have Reflectors written, we can easily implement simple 
languages like the JSTL EL.  The nice thing about how Reflectors are 
setup though, is that you could easily define a reflector for a DynaBean 
or for some other arbitrary object type.  This lets you extend your 
Language very easily.
getting the bean query language at the right level of abstraction is key
I'm not sure I follow... any ideas of things I should take a look at?
- robert
Matt 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [convert] a different approach...

2004-11-18 Thread robert burrell donkin
On 18 Nov 2004, at 04:57, Matt Sgarlata wrote:
Hi Ron, Henri, Stephen, others -
(here are some random musing of mine on the concepts but be warned, i 
have looked at the code as yet)

I haven't been on the list a while but I saw your posts earlier this 
month.  I too, like Ron, spent some time developing my own approach to 
the goals of the commons-convert project.  I have some code started 
out that isn't incredibly well documented, but all the ideas are 
there.  Below is a summary of my approach.  The code is available at 
the URL below under the Apache 2.0 license.

http://www.crystalcognition.com/sgarlatm/morph.zip
why not start a little project on source forge...?
- In place of a registry that tries to 'pick' the right converter, I 
have the Converters themselves say which objects they can and cannot 
convert.  The user assembles these converters (programmatically, or 
via an IoC framework) in whatever order they like into a 
mega-converter, if you will, that will function more similarly to the 
ConvertUtils.convert method in BeanUtils.  This 'mega-converter' 
conforms to the simple Converter interface like every other, 
'non-mega' converter.
that sounds like a good approach
- In place of BeanUtils.copyProperties there is a Copier interface.  
It is very similar to the Converter interface, but it's original 
intent was different: to copy data from one location to another, where 
creating a new object doesn't make sense.  For example, let's say we 
want to store information from a Map or an object graph as separate 
attributes in an HTTP request.  We can't just create a new HTTP 
request object... it already exists!  So we use a Copier.  Basically, 
Converters are for the simple stuff like primitives, Dates, etc and 
Copiers are for fancier things like Object[] -> List.  You can always 
take something that is written with the Copier interface and expose it 
as a Converter but not vice-versa (The 
net.sf.morph.converters.CopierConverter class exposes a Copier as a 
Converter).
- While working on Copiers, I realized I needed to be able to pull 
information out of various different types of things: objects and maps 
are simple examples, but I might also want to be able to pull info 
from HTTP request parameters, etc.  This is what Reflectors are for.  
They help Copiers get the job done.
hmmm sounds frameworkish...
- The Language interface is interesting, but a little out there.  
Basically once we have Reflectors written, we can easily implement 
simple languages like the JSTL EL.  The nice thing about how 
Reflectors are setup though, is that you could easily define a 
reflector for a DynaBean or for some other arbitrary object type.  
This lets you extend your Language very easily.
getting the bean query language at the right level of abstraction is key
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]