RE: Sturts - Custom Tags and limitations
Yes, it works fine with both JSTL and Struts tags.
(he said after hurriedly double checking) :-)
public class Person {
private boolean selected = false;
public boolean isSelected() { return selected; }
public void setSelected(boolean selected) { this.selected =
selected; }
}
Set in request as "person"...
Post some code if you're still having problems.
Steve
> -Original Message-
> From: Wendy Smoak [mailto:[EMAIL PROTECTED]
> Sent: June 29, 2003 8:20 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Sturts - Custom Tags and limitations
>
>
> Steve wrote:
> > No, isHuman()is an acceptable name for a getter.
> > getXXX, setXXX and isXXX (for boolean properties) are all valid. You can
> > also use indexed properties getXXX(int i) etc.
> > http://java.sun.com/products/javabeans/docs/spec.html
>
> Have you sucessfully gotten Struts/JSTL to recognize the 'is' methods? My
> brief attempt was unsuccessful. When I get one of those round
> tuits, I will
> try it again. Meanwhile, I stick to get/set methods and all is well.
>
> --
> Wendy Smoak
> Arizona State University
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sturts - Custom Tags and limitations
Steve wrote: > No, isHuman()is an acceptable name for a getter. > getXXX, setXXX and isXXX (for boolean properties) are all valid. You can > also use indexed properties getXXX(int i) etc. > http://java.sun.com/products/javabeans/docs/spec.html Have you sucessfully gotten Struts/JSTL to recognize the 'is' methods? My brief attempt was unsuccessful. When I get one of those round tuits, I will try it again. Meanwhile, I stick to get/set methods and all is well. -- Wendy Smoak Arizona State University
RE: Sturts - Custom Tags and limitations
No, isHuman()is an acceptable name for a getter. getXXX, setXXX and isXXX (for boolean properties) are all valid. You can also use indexed properties getXXX(int i) etc. http://java.sun.com/products/javabeans/docs/spec.html However, beans being processed by the view should be simple value objects (Data Transfer Objects). A class that is checking the database sound like part of the business or data access layers. http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html Steve > -Original Message- > From: Benjamin Stewart [mailto:[EMAIL PROTECTED] > Sent: June 29, 2003 6:01 PM > To: Struts Users Mailing List > Subject: Re: Sturts - Custom Tags and limitations > > > Just strange that I have always thought of a setter and getter with > reference to setting or getting a class field. > > But if I have a get function that is in a bean that is not used in > reference to a particular field, feels wrong to me. > > For example I have a class person which has field name I am happy to > have getName, setName. But if I have a function called isHuman which > runs off and check my database which contains a list of humans, if it > was to be bean accessible I would have to call it getIsHuman right ?? > > Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sturts - Custom Tags and limitations
Just strange that I have always thought of a setter and getter with reference to setting or getting a class field. But if I have a get function that is in a bean that is not used in reference to a particular field, feels wrong to me. For example I have a class person which has field name I am happy to have getName, setName. But if I have a function called isHuman which runs off and check my database which contains a list of humans, if it was to be bean accessible I would have to call it getIsHuman right ?? Ben Steve Raeburn wrote: The zero argument and serializable requirements are for there for persisting and re-instantiating beans. I guess without the zero arg constructor it's not *technically* a bean but I won't tell if you don't ;-) As long as you follow the bean naming conventions for setters & getters you'll be OK. Steve -Original Message- From: Benjamin Stewart [mailto:[EMAIL PROTECTED] Sent: June 29, 2003 5:23 PM To: Struts Users Mailing List Subject: Re: Sturts - Custom Tags and limitations In order to make our classes bean compliant we would have to change our constructors so they dont take parameters right ?? That is a pretty severe limitation, or are you saying just make your method calls bean compliant? Ben Steve Raeburn wrote: Struts (and JSTL) will be happy with a LinkedHashMap as it is a member of the Collection class hierarchy. I would not recommend with custom tags unless you need custom functionality. If you really can't change the existing method names you should consider adding additional methods that are bean compliant (they can just delegate to the existing methods). You should consider deprecating the old methods so they could be removed in future. If you can't touch the existing classes at all (why?), think about using adaptor classes. Steve -Original Message- From: Benjamin Stewart [mailto:[EMAIL PROTECTED] Sent: June 29, 2003 4:33 PM To: Struts Users Mailing List Subject: Sturts - Custom Tags and limitations Greetings, Before I go charging off and make a stack of custom tags, I thought I would post to the group to make sure I am heading in the right direction. We are devloping an applicaton and we have created the business logic that is able to fit a number of UI (web, Local application etc). A number of our classes have methods that are not bean compliant (addCategory for example). Many of the functions also return objects and datastructures like linked lists and hash maps. As I understand it struts is happy to use beans, but if I am using an object and make a method call that is not bean compliant I am going to have to create my own tag library to deal with this. For example, I have a bean function that returns a linked hash map, in order for me to itterate through this and display an output I will need to create my own tag library right? Any advice appreciated. Regards Ben Stewart - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sturts - Custom Tags and limitations
The zero argument and serializable requirements are for there for persisting and re-instantiating beans. I guess without the zero arg constructor it's not *technically* a bean but I won't tell if you don't ;-) As long as you follow the bean naming conventions for setters & getters you'll be OK. Steve > -Original Message- > From: Benjamin Stewart [mailto:[EMAIL PROTECTED] > Sent: June 29, 2003 5:23 PM > To: Struts Users Mailing List > Subject: Re: Sturts - Custom Tags and limitations > > > In order to make our classes bean compliant we would have to change our > constructors so they dont take parameters right ?? That is a pretty > severe limitation, or are you saying just make your method calls bean > compliant? > Ben > > Steve Raeburn wrote: > > >Struts (and JSTL) will be happy with a LinkedHashMap as it is a member of > >the Collection class hierarchy. > > > >I would not recommend with custom tags unless you need custom > functionality. > >If you really can't change the existing method names you should consider > >adding additional methods that are bean compliant (they can just > delegate to > >the existing methods). You should consider deprecating the old methods so > >they could be removed in future. > > > >If you can't touch the existing classes at all (why?), think about using > >adaptor classes. > > > >Steve > > > > > > > >>-Original Message- > >>From: Benjamin Stewart [mailto:[EMAIL PROTECTED] > >>Sent: June 29, 2003 4:33 PM > >>To: Struts Users Mailing List > >>Subject: Sturts - Custom Tags and limitations > >> > >> > >>Greetings, > >>Before I go charging off and make a stack of custom tags, I thought I > >>would post to the group to make sure I am heading in the right > direction. > >> > >>We are devloping an applicaton and we have created the business logic > >>that is able to fit a number of UI (web, Local application etc). A > >>number of our classes have methods that are not bean compliant > >>(addCategory for example). Many of the functions also return objects and > >>datastructures like linked lists and hash maps. As I understand it > >>struts is happy to use beans, but if I am using an object and make a > >>method call that is not bean compliant I am going to have to create my > >>own tag library to deal with this. > >> > >>For example, I have a bean function that returns a linked hash map, in > >>order for me to itterate through this and display an output I will need > >>to create my own tag library right? > >> > >>Any advice appreciated. > >> > >>Regards > >>Ben Stewart > >> > >> > >> > >> > >> > >>- > >>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] > > > > > > > > > > - > 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: Sturts - Custom Tags and limitations
I also misspoke. LinkedHashMap is, of course, not a Collection class but it does work. Been a long day for some reason ;-) Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sturts - Custom Tags and limitations
In order to make our classes bean compliant we would have to change our constructors so they dont take parameters right ?? That is a pretty severe limitation, or are you saying just make your method calls bean compliant? Ben Steve Raeburn wrote: Struts (and JSTL) will be happy with a LinkedHashMap as it is a member of the Collection class hierarchy. I would not recommend with custom tags unless you need custom functionality. If you really can't change the existing method names you should consider adding additional methods that are bean compliant (they can just delegate to the existing methods). You should consider deprecating the old methods so they could be removed in future. If you can't touch the existing classes at all (why?), think about using adaptor classes. Steve -Original Message- From: Benjamin Stewart [mailto:[EMAIL PROTECTED] Sent: June 29, 2003 4:33 PM To: Struts Users Mailing List Subject: Sturts - Custom Tags and limitations Greetings, Before I go charging off and make a stack of custom tags, I thought I would post to the group to make sure I am heading in the right direction. We are devloping an applicaton and we have created the business logic that is able to fit a number of UI (web, Local application etc). A number of our classes have methods that are not bean compliant (addCategory for example). Many of the functions also return objects and datastructures like linked lists and hash maps. As I understand it struts is happy to use beans, but if I am using an object and make a method call that is not bean compliant I am going to have to create my own tag library to deal with this. For example, I have a bean function that returns a linked hash map, in order for me to itterate through this and display an output I will need to create my own tag library right? Any advice appreciated. Regards Ben Stewart - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sturts - Custom Tags and limitations
Should read: I would not recommend creating custom tags... Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sturts - Custom Tags and limitations
Struts (and JSTL) will be happy with a LinkedHashMap as it is a member of the Collection class hierarchy. I would not recommend with custom tags unless you need custom functionality. If you really can't change the existing method names you should consider adding additional methods that are bean compliant (they can just delegate to the existing methods). You should consider deprecating the old methods so they could be removed in future. If you can't touch the existing classes at all (why?), think about using adaptor classes. Steve > -Original Message- > From: Benjamin Stewart [mailto:[EMAIL PROTECTED] > Sent: June 29, 2003 4:33 PM > To: Struts Users Mailing List > Subject: Sturts - Custom Tags and limitations > > > Greetings, > Before I go charging off and make a stack of custom tags, I thought I > would post to the group to make sure I am heading in the right direction. > > We are devloping an applicaton and we have created the business logic > that is able to fit a number of UI (web, Local application etc). A > number of our classes have methods that are not bean compliant > (addCategory for example). Many of the functions also return objects and > datastructures like linked lists and hash maps. As I understand it > struts is happy to use beans, but if I am using an object and make a > method call that is not bean compliant I am going to have to create my > own tag library to deal with this. > > For example, I have a bean function that returns a linked hash map, in > order for me to itterate through this and display an output I will need > to create my own tag library right? > > Any advice appreciated. > > Regards > Ben Stewart > > > > > > - > 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]
