Hi
On Thu, May 12, 2011 at 8:21 PM, Biju Nair <biju74tec...@gmail.com> wrote:
> Just to clarify,
>
> the user bean will be something like,
> class User{
> Map<String, String> params;
> }
>
> Request Data will be user.params.k1=v1&*user.*params.k2=v2
Yes if User is a nested bean, otherwise just
params.k1=v1¶ms.k2=v2
if we have FormParam("") User
>
> Finally, the params map will have [{k1=v1},{k2=v2}]
>
> Right?
Yes
>
> I will check this and let you know.
>
Ok, thanks. By the way I'm planning to have this code reused for
handling more involved FIQL queries, ex, one can do
/books?_s=id=gt=1
"Find all books with id greater than 1"
but we can't express the same query if Book happens to have a nested
ID bean, etc:
/books?_s=id=gt=id.1
Cheers, Sergey
> Biju B
>
> On Thu, May 12, 2011 at 10:52 AM, Sergey Beryozkin
> <sberyoz...@gmail.com>wrote:
>
>> Hi
>>
>> On Thu, May 12, 2011 at 5:55 PM, Biju Nair <biju74tec...@gmail.com> wrote:
>> > Yes I understood that we don't need two solution for same problem :).
>> >
>> > Just want you let know, if you try to put something like
>> > "testaddress.City=Pleasanton&testAddress.stateName=CA"
>> > testAddress.stateName will not be populated. What I saw in your code is,
>> for
>> > first parameter the TestAddress instance is created and put into map as
>> > testaddress=<object> and in second parameter new TestAddress object is
>> > creates and put into map as testAddress=<object>.
>> >
>> > Code Says ==> parsedValues.put(beanKey, value);
>> >
>> I see, I checked the actual property name, such as "set+ 'stateName'"
>> is checked against available methods (and I guess fields) in a
>> case-insensitive way...
>>
>> > Anyway thanks for the discussion.
>> >
>> cool, thanks for starting it up
>>
>> > Can you elaborate on "Maps are not supported for example" - Let me see
>> > whether I can contribute?
>> >
>> Awhile back, a user asked about it but I recall I just did not get to
>> doing it, example
>>
>> user.params.k1=v1¶ms.k2=v2
>>
>> where a User bean has Map<String, String> property, which can be handy
>> in some cases too.
>> have a look please if you get a chance
>>
>> Cheers, Sergey
>>
>> > Biju B
>> >
>> > On Thu, May 12, 2011 at 2:43 AM, Sergey Beryozkin <sberyoz...@gmail.com
>> >wrote:
>> >
>> >> Hi
>> >>
>> >> On Wed, May 11, 2011 at 5:34 PM, Biju Nair <biju74tec...@gmail.com>
>> wrote:
>> >> > Thanks for the reply.
>> >> >
>> >> > Just for clarification,
>> >> > If I have a Employee bean as follows,
>> >> > class Employee{
>> >> > String name;
>> >> > Address homeAddress;
>> >> > //getters and setters are there
>> >> > }
>> >> >
>> >> > class Address{
>> >> > String line1;
>> >> > String line2;
>> >> > //getters and setters are there
>> >> > }
>> >> > there is a rest service as String update(@FormParam("") Employee
>> >> employee)
>> >> >
>> >> > In the current approach, we need to pass request data as *
>> >> > name=Joe&homeAddress.line1=MyLocation&homeAddress.line2=MyStreet*
>> >> >
>> >> > which means we need to have homeAddress as case sensitive right? and
>> it
>> >> > won't work with "homeaddress.line1" right?
>> >>
>> >> No, the comparison is case-insensitive.
>> >>
>> >> > Also later if we try to change the variable names we need to ask all
>> the
>> >> > clients to change the request params. Am I right or something missing
>> >> here.
>> >> >
>> >>
>> >> I guess some care has to be taken with regard to refactoring the bean
>> >> class which is meant to capture the input from
>> >> remote clients.
>> >>
>> >> If you have a User.setAddress() method which is meant to capture an an
>> >> 'address' property then yes, if you go ahead and remove it or rename
>> >> it to setUserAddress then yes, "address" property won't be injected -
>> >> but customers does not have to be affected in such cases - replacing
>> >> the form submission payload can be easily done on the server side, ex,
>> >> at the RequestFilter level or better yet, by providing a custom
>> >> MessageBodyReader which extends CXF FormEncodingProvider and overrides
>> >> its populateMap method - let superclass to read the data and then just
>> >> replace the key 'address' with say 'customerAddress'
>> >>
>> >> Look, as I tried to say in the previous email, it's basically not
>> >> about CXF solution is better then yours, etc :-). I just don't think
>> >> we should have two solutions for this case 'shipped' with CXF. The CXF
>> >> one may not be ideal but it has its benefits too, one of them is that
>> >> WADLGenerator can understand such beans when generating query or form
>> >> parameters, etc, the other one is that JAX-RS proxies understand how
>> >> to deal with them, etc.
>> >>
>> >> I'd encourage you to help us to improve the existing solution if you
>> >> find some drawbacks. Maps are not supported for example.
>> >>
>> >> Thanks, Sergey
>> >>
>> >> Cheers, Sergey
>> >>
>> >> > Please confirm.
>> >> >
>> >> > Biju B
>> >> >
>> >> >
>> >> >
>> >> > On Wed, May 11, 2011 at 1:45 AM, Sergey Beryozkin <
>> sberyoz...@gmail.com
>> >> >wrote:
>> >> >
>> >> >> Hi
>> >> >>
>> >> >> On Tue, May 10, 2011 at 10:07 PM, Biju Nair <biju74tec...@gmail.com>
>> >> >> wrote:
>> >> >> > Thanks for the reply.
>> >> >> >
>> >> >> > But in the first approach the client users has to follow Java
>> naming
>> >> >> > conventions (espc a non-java client) right?
>> >> >> Clients use "user.name" or "user.address.value" if they need to, the
>> >> >> difference between the two approaches
>> >> >> in that with your annotations you can selectively point to a
>> >> >> particular field and say this is what "user.name" has to be mapped
>> to,
>> >> >> while with the default approach one has to make sure nested beans are
>> >> >> available.
>> >> >>
>> >> >> >
>> >> >> > Regarding the MultiValueMap, i like the idea, but not for Bean
>> based.
>> >> >> Here
>> >> >> > the developers need to convert the map to Bean right?
>> >> >> >
>> >> >> > I still prefer to use *@FormParam("") object*, because this looks
>> like
>> >> >> > standard in CXF for primitive type arguments.
>> >> *@FormParam("identifier")
>> >> >> id.*
>> >> >>
>> >> >> I like @FormParam("") too, it's a CXF extension (using ""), but it
>> >> >> allows for capturing many values while still allowing for some
>> >> >> flexibility re property types as opposed to using MultiValuedMap
>> >> >> (which is JAX-RS compliant).
>> >> >>
>> >> >> > **
>> >> >> > I think you can ask the same contributer to include the annotation
>> >> >> approach
>> >> >> > or some custom way of declaring user-defined names, rather than
>> java
>> >> >> > variables.
>> >> >> >
>> >> >>
>> >> >> As I said the problem is how to have "user.a.b.c" mapped to a
>> >> >> particular property. CXF has one solution for it which I think is
>> good
>> >> >> enough. Your solution is also interesting but I'm not sure CXF should
>> >> >> multiple solutions for this particular issue
>> >> >>
>> >> >> Thanks, Sergey
>> >> >> > Biju B
>> >> >> >
>> >> >> > On Tue, May 10, 2011 at 1:22 PM, Sergey Beryozkin <
>> >> sberyoz...@gmail.com
>> >> >> >wrote:
>> >> >> >
>> >> >> >> Hi
>> >> >> >>
>> >> >> >> Please see comments inline
>> >> >> >>
>> >> >> >> On Tue, May 10, 2011 at 8:29 PM, Biju Nair <
>> biju74tec...@gmail.com>
>> >> >> wrote:
>> >> >> >> > Hi Team,
>> >> >> >> >
>> >> >> >> > Currently I was helping a team in building rest based services
>> >> using
>> >> >> CXF.
>> >> >> >> I
>> >> >> >> > noticed that for bean based service arguments (*Ex. String
>> >> >> >> > getData(@FormParam("") TestObj tObj)*)
>> >> >> >> > you have to include @FormParam with empty qualifer name and the
>> >> >> request
>> >> >> >> > parameter should follow bean property naming conventions. Say
>> >> example
>> >> >> >> > if TestObj has a property 'userName' (which is java style) then
>> the
>> >> >> >> request
>> >> >> >> > parameter should be userName=Joe.
>> >> >> >> > But in our requirement (mostly everywhere) the request
>> parameters
>> >> need
>> >> >> >> not
>> >> >> >> > use the Java Style. Here we were asked to use 'user.name'.
>> >> >> >> >
>> >> >> >> > I know for non-bean based parameters CXF supports this as
>> >> @FormParam("
>> >> >> >> > user.name") String userName, Is this possible for Bean Based
>> also?
>> >> >> >> >
>> >> >> >> > As part of providing solution to team, I wrote a CXF Request
>> >> Handler,
>> >> >> >> > which transforms all the request based parmeters to bean based.
>> >> >> >> > Now the TestObj will looks like,
>> >> >> >> > class TestObject {
>> >> >> >> > @RequestParam("user.name")
>> >> >> >> > String userName;
>> >> >> >> > ...
>> >> >> >> > }
>> >> >> >> > Using the @ReuestParam I will be identifying the actual request
>> >> param.
>> >> >> >> > The component I wrote supports primitives, nested beans and
>> >> >> collections
>> >> >> >> > also.
>> >> >> >> >
>> >> >> >> That is interesting, however I think your requirement can already
>> be
>> >> >> >> handled:
>> >> >> >>
>> >> >> >> public class TestObject {
>> >> >> >> public User getUser() {
>> >> >> >> return new User();
>> >> >> >> }
>> >> >> >> public void setUser(User user) {}
>> >> >> >> }
>> >> >> >>
>> >> >> >> public class User {
>> >> >> >> public String getName() {
>> >> >> >> return name;
>> >> >> >> }
>> >> >> >> public void setName(String name) {}
>> >> >> >> }
>> >> >> >>
>> >> >> >> That is more verbose that your solution but the user who
>> contributed
>> >> >> >> the patch earlier on did a lot of work for nested beans to work,
>> with
>> >> >> >> collections supported as well. And no extra annotations is
>> required.
>> >> >> >>
>> >> >> >> Another option is just use MultivaluedMap in case of form
>> submissions
>> >> >> >> or explicit FormParam("user.name")
>> >> >> >>
>> >> >> >> What do you think ?
>> >> >> >>
>> >> >> >>
>> >> >> >> Cheers, Sergey
>> >> >> >>
>> >> >> >> > *My Suggestion is can you include this feature in next version
>> of
>> >> CXF?
>> >> >> >> and
>> >> >> >> > Can I contribute my code?*
>> >> >> >> >
>> >> >> >> > Biju B
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Sergey Beryozkin
>> >> >> >>
>> >> >> >> Application Integration Division of Talend
>> >> >> >> http://sberyozkin.blogspot.com
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Sergey Beryozkin
>> >> >>
>> >> >> Application Integration Division of Talend
>> >> >> http://sberyozkin.blogspot.com
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Sergey Beryozkin
>> >>
>> >> Application Integration Division of Talend
>> >> http://sberyozkin.blogspot.com
>> >>
>> >
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Application Integration Division of Talend
>> http://sberyozkin.blogspot.com
>>
>
--
Sergey Beryozkin
Application Integration Division of Talend
http://sberyozkin.blogspot.com
