Re: [BeanUtils] - some small fixes, plus a proposal for namespace resolutions

[robert burrell donkin <ro...@blueyonder.co.uk>]

hi

you'll find that different open source projects are managed differently. 
here at apache, nearly all of our development is done in the open on 
public mailing lists.

so rather than discuss the issues you've raised, what i'm going to do is 
point you at the documents we've written to help people who want to 
contribute. once you've read them, post again to commons-dev mailing so 
that everyone has a chance look at your ideas and (if they wish) comment 
on them.

you should start by browsing the web site and in particular read

http://jakarta.apache.org/site/getinvolved.html

if you want to submit some patches, then you might find this document 
useful:

http://jakarta.apache.org/commons/patches.html

if you want to know about the apache software foundation, then browse

http://apache.org/foundation

hopefully these should answer most of your questions!

- robert

On Sunday, November 24, 2002, at 07:27 PM, Rune Toalango Johannesen wrote:

> Hi chaps,
>
> I have picked your addresses from the project.xml file of 
> Jakarta-Commons-BeanUtils.
>
> I have never contributed to any open source projects before, so I am not 
> quite sure about the procedure for commiting without "committer" status. 
> I downloaded the attached files from CVS yesterday and filtered out only 
> the files I have changed in the attached .zip file. A commit comment is 
> also attached in the .txt file. Not a big change - general QA - mostly 
> for myself to get familiar with the way this works.
>
> <<...>> <<...>>
> All the unit tests worked fine after the changes. Please let me know if 
> there is an easier way for non-commiters to commit proposals.
>
> I have used the BeanUtils as help classes in a project to accomplish the 
> following:
>
> Once you have a number of classes, potentially nested into maps and 
> arrays/lists, and you want to query this as a dedicated namespace, the 
> existing PropertyUtils comes to short. I also had a requirement to use 
> dots to separate the different elements in the namespace, regardles of 
> the underlying structure (map, bean, list, array).
>
> Example data structure:
>
> • 	Hashtable containing two entries, "foo" and "bar", each having a List 
> as their values.
> • 	The lists contain various Person bean objects with properties that 
> might return new beans, lists, maps or arrays
>
> Person {
>         Person[] getChildren();
>         Map getPhones();
>         String getFirstName();
>         String getLastName();
> }
>
> Example queries for this "namespace" structure:
>
> • 	foo.0.children.0.lastName
> • 	foo.5.firstName
> • 	bar.3.phones.work.extension
>
> A significant benefit of this approach is that the underlying structure 
> is not that relevant to the author of the queries. We could for instance 
> imagine that the above-mentioned getPhones() method returned a Phones 
> bean instead of the Map:
>
> Phone {
>         PhoneNumber getWork();
>         PhoneNumber getHome();
>         PhoneNumber getMobile();
> }
>
> PhoneNumber {
>         String getExtension();
>         String getCountryCode();
>         String getNumber();
> }
>
> The last example query wouldn't need to change, and the author doesn't 
> have to know what the actual data structure is.
>
> The missing features of the current PropertyUtils to accomplish this are:
>
> • 	Support for List, Array and Map implementations as "standalone" 
> structures outside bean properties in a nested set of objects
> • 	A proactive introspection of the "current" object ("Oh, I have a Map, 
> then the next element in the query must be the key")
>
> The latter is essential to be able to use one unified delimitor in the 
> queries. With the current PropertyUtils the query will fail if the query 
> contains "(aMapKey)" but the underlying structure isn't a map.
>
> I have gathered this feature in a class named ObjectUtils ("object" 
> because List, Map and Array implementations are not recognized as beans). 
> Additional features in this class include:
>
> • 	Nested keys: "a.key.with.{a.nested.key}.lots.of.dots.{another.one}". 
> The sub-keys in the {} are separate queries within the same "namespace" 
> object
> • 	A toString() method to print the whole content of nested bean 
> properties, lists, maps and arrays:
>
> foo.0.children.0.lastName = [Smith]
> foo.5.firstName = [John]
> bar.3.phones.work.extension = [45]
>
> The last method is a bit tricky once the structure contains circular 
> references… you can imagine how fast a recursive method eats up the 
> memory once a child bean references its parent, and vica versa. I am 
> working on a solution to prevent this. The toString() method is useful 
> during development time for debug purposes ("Give me the content of the 
> session object right now"), and it also helps authors of queries because 
> you can copy and paste the available keys directly.
>
> Do you think this additional feature is suitable within the BeanUtils 
> package? I could adapt the code conventions and logging facilities and 
> provide you with the ObjectUtils class for a future release if you think 
> it suits into the framework. The class doesn't contain support for 
> DynaBeans yet, but I think that could easily be added. I have also been 
> reluctant to throw exceptions - if the query doesn't find the "target" 
> value it simply returns null.
>
> To accomplish the nested keys I used some StringUtils from the 
> Commons-Lang package. I guess the introduction of new "external" 
> dependencies is not that popular, but the alternative is to clone a piece 
> of code. Any opinions about this? Struts has a lot of "external" Jakarta 
> dependencies already, and a danger is of course the potential version 
> conflicts this might cause once you have too many inter-dependencies.
>
> I'll sign up for the Jakarta-Commons email list shortly - I guess that is 
> where these discussions should find place?
>
> Keep up the good work!
>
>
> Best regards
>
> Rune Toalango Johannesen
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>