Big Javabean?
Hi There are 2 quick questions. 1) I'm considering making one huge javabean that will have 100+ fields. This bean will be share in the session across up to 23 different screen. I think this is probably the cleanest way, as the same field might show up in different screens. I don't think this will be a problem, however, I have never heard or made one single bean with that many fields. Have you seen or done that? Have you heard of any problem that might or have cause? 2) Also, since I'm on this note, I noticed if I have a variable name mI (stands for middle initial), therefore having getMI() and setMI(..), struts does not recognize those getter and setter because it is actually expecting getiM() and setiM(). I got around it by renaming my variable middleInitial, so that the getter and setter are getMiddleInitial() and setMiddleInitial(). This works fine. I'm just wondering if anyone out there aware of this or am I missing anything in the JavaBean standard? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Big Javabean?
--- Poon, Johnny [EMAIL PROTECTED] wrote: Hi There are 2 quick questions. 1) I'm considering making one huge javabean that will have 100+ fields. This bean will be share in the session across up to 23 different screen. I think this is probably the cleanest way, as the same field might show up in different screens. I don't think this will be a problem, however, I have never heard or made one single bean with that many fields. Have you seen or done that? Have you heard of any problem that might or have cause? It will be confusing for people to maintain a class that large. You should break your beans into logically separate classes. 2) Also, since I'm on this note, I noticed if I have a variable name mI (stands for middle initial), therefore having getMI() and setMI(..), struts does not recognize those getter and setter because it is actually expecting getiM() and setiM(). I got around it by renaming my variable middleInitial, so that the getter and setter are getMiddleInitial() and setMiddleInitial(). This works fine. I'm just wondering if anyone out there aware of this or am I missing anything in the JavaBean standard? Struts relies on commons-beanutils to find the bean properties. Having a variable named mI is an absolutely terrible idea anyways and middleInitial is much more descriptive. David Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Big Javabean?
Don't think there is a problem with a javabean that size. We have similar sizes. May want to think about using request scope though (with the same java bean). This means more calls to the database however. One question to ask is if you need to have concurrent access to the same data. Your session scoped bean could be out of date if someone else updates it. sandeep --- Poon, Johnny [EMAIL PROTECTED] wrote: Hi There are 2 quick questions. 1) I'm considering making one huge javabean that will have 100+ fields. This bean will be share in the session across up to 23 different screen. I think this is probably the cleanest way, as the same field might show up in different screens. I don't think this will be a problem, however, I have never heard or made one single bean with that many fields. Have you seen or done that? Have you heard of any problem that might or have cause? 2) Also, since I'm on this note, I noticed if I have a variable name mI (stands for middle initial), therefore having getMI() and setMI(..), struts does not recognize those getter and setter because it is actually expecting getiM() and setiM(). I got around it by renaming my variable middleInitial, so that the getter and setter are getMiddleInitial() and setMiddleInitial(). This works fine. I'm just wondering if anyone out there aware of this or am I missing anything in the JavaBean standard? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Big Javabean?
David, Thanks for your input. I guess I didn't give you enough specifics about the app that I'm developing for my question 1. It is a wizard-like app that allow user to go Back and Next. While I started out using several beans broken up logically to maintain the data, say bean1 and bean2, I found out that some screens has fields from both beans. As far as I know, struts only allow 1 form bean to be associated with a form action, I changed my design to use 1 single bean for all screen. This way, it's a lot easier to handle the Back situation where the previously entered data needs to be populated in the right fields. What I'm really asking is that, other than it might not be the easiest thing to maintain a bean with 100+, for those of you who've used such bean, is there any technical issue like performance, or session capacity, etc.? -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 9:38 AM To: Struts Users Mailing List Subject: Re: Big Javabean? --- Poon, Johnny [EMAIL PROTECTED] wrote: Hi There are 2 quick questions. 1) I'm considering making one huge javabean that will have 100+ fields. This bean will be share in the session across up to 23 different screen. I think this is probably the cleanest way, as the same field might show up in different screens. I don't think this will be a problem, however, I have never heard or made one single bean with that many fields. Have you seen or done that? Have you heard of any problem that might or have cause? It will be confusing for people to maintain a class that large. You should break your beans into logically separate classes. 2) Also, since I'm on this note, I noticed if I have a variable name mI (stands for middle initial), therefore having getMI() and setMI(..), struts does not recognize those getter and setter because it is actually expecting getiM() and setiM(). I got around it by renaming my variable middleInitial, so that the getter and setter are getMiddleInitial() and setMiddleInitial(). This works fine. I'm just wondering if anyone out there aware of this or am I missing anything in the JavaBean standard? Struts relies on commons-beanutils to find the bean properties. Having a variable named mI is an absolutely terrible idea anyways and middleInitial is much more descriptive. David Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Big Javabean?
I would disagree with having fine-grained action forms. You will run into problems by splitting them apart for a logicial entity. This is especially true if you have more than one type. JSP re-use is not a problem since this is done by reflection. However form-bean re-use will cause problems when you try and access some property of the base type but it isn't there and so you have some ugly casting. Using the validator solves a lot of this problem. The other advantage of coarse-grained is that you could probably write some XDoclet to help with this. Not great to have the back-end know about the front-end, but this should be minimal and with coarse-grained it won't know about the screens. Haven't done this, but wherever you need to know about the structure of the screens you could have a subclass from the XDoclet generated class. sandeep --- David Graham [EMAIL PROTECTED] wrote: --- Poon, Johnny [EMAIL PROTECTED] wrote: Hi There are 2 quick questions. 1) I'm considering making one huge javabean that will have 100+ fields. This bean will be share in the session across up to 23 different screen. I think this is probably the cleanest way, as the same field might show up in different screens. I don't think this will be a problem, however, I have never heard or made one single bean with that many fields. Have you seen or done that? Have you heard of any problem that might or have cause? It will be confusing for people to maintain a class that large. You should break your beans into logically separate classes. 2) Also, since I'm on this note, I noticed if I have a variable name mI (stands for middle initial), therefore having getMI() and setMI(..), struts does not recognize those getter and setter because it is actually expecting getiM() and setiM(). I got around it by renaming my variable middleInitial, so that the getter and setter are getMiddleInitial() and setMiddleInitial(). This works fine. I'm just wondering if anyone out there aware of this or am I missing anything in the JavaBean standard? Struts relies on commons-beanutils to find the bean properties. Having a variable named mI is an absolutely terrible idea anyways and middleInitial is much more descriptive. David Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
