Hi, I usually access my cached droplist data directly from the jsp - eg have placed a bean called "ReferenceDataCache" on application scope with getter methods. In jsp I can simply call: I also try to keep my struts forms only containing properties for the http posted data. The controllers responsibility is dealing with http requests (flow control, forwarding to the correct action etc) so I'm not quite sure what you mean by saying "the jsp tag actually by pass the controller to get the data from Datasource" Additionally, specialized data can be added as request attributes, either via your action/helper class or some sort of page controller (tiles has this feature) - the idea behind a page controller (view tier) is your page knows what data it needs, and your jsps are not tied to your actions - in an ideal world you could reuse your jsps without having to change much (or if any) backend java code. Sometimes action classes/methods contain far to much business logic which including supplying data necessary for the view - even if you decide to forward to a different page your action is still preparing data for a page that no longer needs it! Just my 2c Regards, Paul ________________________________ From: Zhang, Larry (L.) [mailto:lzhang20@ford.com] Sent: Sat 2/3/2007 9:39 AM To: Struts Users Mailing List Subject: Design issue Think about a typical struts app, and on the jsp there are text field and drop downs. There are two approaches: (1) the action populates all the text fields and drop downs from the Database, and then set the value into the actionform, then the JSP will get the values from the actionform (2) the action populates some fields (text field for example), and leave other fields (drop down for example) to JSP to populate, on which a jsp tag can go to the datasource to get the values. I personally prefer (1) since in (2) the jsp tag actually by pass the controller to get the data from Datasource. What do you think? Thanks. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@struts.apache.org For additional commands, e-mail: user-help@struts.apache.org ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@struts.apache.org For additional commands, e-mail: user-help@struts.apache.org