Quoting [EMAIL PROTECTED]: > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: Friday, December 19, 2003 11:00 AM > To: Struts Developers List > Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) > > Quoting [EMAIL PROTECTED]: > > > We have a solution for dynamic page content that is component based. > I > > wouldn't say that it stands up to JSF but it's similar in concept. > The > > content of the page is defined using xml metadata. > > > > However, I suppose that you could argue, why not use JSF? I would be > > interested in hearing what advantage you would have using struts with > JSF > > when JSF handles both the view layer and controller? > > > > >>Fair question. In the long run, we (Struts) are definitely going to > >>have to "compete" with this combination. > > >>The easiest way is to focus on features that are not present in JSF -- > >>one approach would be to build on top of the JSF controller > >>infrastructure. > > >>Besides the UI components, there are some very useful foundational > >>things there (such as managed beans, which generalize the way that > >>Struts auto-creates form beans on demand, fine-grained navigation > rules, >>and the ability to programmatically evaluate EL-ish > expressions, >>including the ability to plug in new evaluators for the > "." operator) >>that would be nice to use in a controller tier. > > I have been struggling to correlate the notion of a struts formbean with a > jsf UI component. Under struts, a single action can be associated with > only one formbean. If the form is a composition of many components, > should each component have its own "formbean"? It sounds as each jsf > component would pull values on its own behalf from the request parameters > thru a converter. >
In Struts terminology, a JSF UI component relates more to an individual form bean property than it does to the form bean itself. However, the type conversion mechanism *is* built in to the UI components in JSF, so you can have your "form bean" using native data types without the penalties you'd suffer doing this with the standard Struts tags. > To achieve visual component reuse, it sounds like jsf introduces the > notion of a client id. We have used an underscore as our component > delimiter because the beanutils handles the "." for nested components. > Components do have identifiers that are composed based on the "naming container" components (such as UIForm). The composition delimiter that JSF chose is the ":" character, primarily to avoid confusion over what "." means in JavaScript. > It seems that if you had a single form bean to map to a graph of UI > components, the form bean might get kind of ugly. > > <form-bean name="AboutForm" type="com.rustts.action.DynaRusttsForm" > > <form-property > name="aboutForm_BorderLayout_west_dateWidget_selDate" > type="java.lang.String"/> > <form-property > name="aboutForm_BorderLayout_center_calendarWidget_GridLayout_B0_yearWidget_year" > type="java.lang.String"/> > > <form-property > name="aboutForm_BorderLayout_center_calendarWidget_GridLayout_A0_monthWidget_month" > type="java.lang.String"/> > > </form-bean> > > It would be nice if the behavior of the formbean to an aciton could also > be associated with a UI component. > If you use the struts-faces integration library, you don't need to change anything at all about your form bean definitions -- you still use the property names. The page author, though, has to prefix the value reference expressions on each property with the name of the corresponding form bean (because JSF does not constrain you to a single form bean). > It sounds like the struts chains will be similar to the jsf component > tree? Could a chain command be associated with a individual formbean and > a command be corrolated to a UI component? > Hmm, I'm not sure I see that connection. I see the chain used (inside Struts) to compose the stuff that happens after a form has been submitted -- versus the hard coded logic inside RequestProcessor -- but you could certainly attach a different chain to each of the different submit buttons on a given form, for example. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
