Re: [convert] a different approach...
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...
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...
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...
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...
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...
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...
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]
