db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trey Long <james_l...@provima.com>
Subject Re: Beans & Objects
Date Thu, 15 Dec 2005 14:52:04 GMT
Thanks Tom and Greg, that's basically where I was going with it. And I 
really can relate to the whole Generics argument since that would solve 
all my problems right now... grrr.

My original intent wasn't to change the way Torque works, I wouldn't 
introduce a systemic problem like that so readily, but to just add to 
the classes. I'm not worried about having more fields in Axis because if 
I can generate the correct accessor methods I can use bean descriptors 
in the Static {} block to exclude them.

I will start exploring the templates now, I'm sure this won't be the 
last question about this :)

Jim

Thomas Fischer wrote:
>
>
> I would think Greg is right when he says that you have to look at the
> methods rather than the intance variables.
> I'd also add generation of the array methods to the bean templates, located
> in the templates jar. One problem you might run into is that probably Axis
> would think that you have two properties, one for the array and one for the
> list, so you might also want to modify the templates such that the
> Collection getters and setters are protected rather than public.
>
> I do not know a good general solution for this. Using the beans in axis was
> one thing I had in mind when I wrote the beans stuff, but in our
> application we found that it was necessary to have the exposed objects
> separated from the data model in the database, so it never came to this,
> and I never run into this difficulties myself. If axis was the only use of
> the beans, I'd gladly change the collections to arrays, but as there are
> other uses (such as rmi and other network transfer stuff) and collections
> are far more easier to use than arrays, we cannot simply change that.
>
> Another idea: I remember dimly that Axis has serializer/deserializer
> classes which transfer java objects to soap and vice versa. Perhaps one
> could autogenerate a set of those ?
>
> Finally, a distant solution might be that Torque might support typed
> collections (Java1.5) at some point in the future, and Axis might support
> them, and all problems will have vanished.... (It's near Christmas after
> all. Time for some wishes....)
>
>     Thomas
>
>
> "Greg Monroe" <Greg.Monroe@DukeCE.com> schrieb am 14.12.2005 23:11:50:
>
>   
>> It sounds like Axis wants to use Index Property beans to manage
>> bean "collections".  An index property is defined by the JavaBean
>> spec to have methods like:
>>
>> Property[] getProperty()
>> Property getProperty(int index)
>>
>> and some others.
>>
>> The quick fix for this might be to expand the torque-gen-templates*
>> jar file and look thru the templates in the bean directory.  These
>> are the template files that create the beans code.  You probably
>> could add in an extra method or two to make life easier with Axis.
>> I'd add not replace to limit possible problems with a missing
>> method.
>>
>> I've occationally thought about seeing what's involved to create
>> a matching "collection" bean for each record bean.  I use
>> Dreamweaver to do GUI layouts and it has some simple app development
>> capablities that can use a collection bean as a datasource.
>>
>> So you would have TableBean and TableCollectionBean and be able to
>> do something like:  new TableCollectionBean(Criteria c) and use
>> the indexed property methods to get record beans.
>>
>> Of course, the downside is that you have to load the entire response
>> into memory at once.  The up side (at least for me) is that I can
>> use DW's app tools like coding drop downs populated from these beans.
>>
>> Maybe someday I'll find the time.
>>
>>
>>
>>     
>>> -----Original Message-----
>>> From: Trey Long
>>>
>>>
>>> I wrote about a similar idea a few messages ago when it comes to
>>> relationships in a table. As a recap I am using Axis + Torque
>>> to give my
>>> database web service wings as it were.
>>>
>>> Axis generates a WSDL for me, but if I expect it to be
>>> anything close to
>>> coherent I need to use strong typing with something like an
>>> Array. When
>>> the beans are generated they are nice enough to give me methods like
>>> 'getEmployeeBeans()' which will retrieve a collection of
>>> beans that are
>>> related to the current bean.
>>>
>>> class BaseCompanyBean {
>>>     protected List collEmployeeBeans;
>>>     public List getEmployeeBeans()    {
>>>         return collEmployeeBeans;
>>>     }
>>> }
>>>
>>> My question is: Is there a way, either by torque generator
>>> configuration
>>> or a good place to start in the generator source, a way to
>>> strictly type
>>> 'List colEmployeeBeans' to 'EmployeeBeans[]'? I am not interested in
>>> forcing torque to use an array over a list, what I would like
>>> to do is
>>> have perhaps an additional variable inside the base class or even the
>>> super class that contains EmployeeBeans[] so that when I
>>> point Axis to
>>> it I get a decent WSDL and avoid having to add a wrapper
>>> method to every
>>> Object generated by torque (that's a lot).
>>>
>>> I am looking for a little direction from you guys who know
>>> quite a bit
>>> about torque. Maybe I am barking up the wrong tree, maybe it's just
>>> something that torque hasn't made it to yet. Regardless, any advice
>>> would be great.
>>>
>>> If you don't understand my example let me know, I can try to make it
>>> clearer.
>>>
>>> Thanks, -James
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: torque-user-help@db.apache.org
>>>
>>>
>>>       
>> Duke CE Privacy Statement
>> Please be advised that this e-mail and any files transmitted with it
>> are confidential communication or may otherwise be privileged or
>> confidential and are intended solely for the individual or entity to
>> whom they are addressed.  If you are not the intended recipient you
>> may not rely on the contents of this email or any attachments, and
>> we ask that you  please not read, copy or retransmit this
>> communication, but reply to the sender and destroy the email, its
>> contents, and all copies thereof immediately.  Any unauthorized
>> dissemination, distribution or copying of this communication is
>> strictly prohibited.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: torque-user-help@db.apache.org
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>
>   

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message