I generally don't encourage dynamic forms. One of JSF's strengths is that instead of having to have programmers painstakingly create and debug the UI from logic (one of the annoying things about frameworks such as java awt), you can have non-JSF people "paint" a form in declarative View Template Language (xhtml) and let JSF do all the dirty work. Some people, alas think that they're too clever for that, but the results are generally awkward and expensive.
Beside, there's a simpler way (in JSF, there usually is).
You get as many rows as there are elements in the "mybean.people" datamodel object.
An IDE is no substitute for an Intelligent Developer.
Joined: Oct 13, 2010
Let me add a scenario here to make more understandable what I'm aiming for. I am going to have several tables (studying purpose), such as person, cars, fruits, etc., and I'll eventually add some info there, but I don't want to create a view for each one, I'll pass thru URL param the kind of object that I want to add. Ex.:
based on objKind, I'll access the corresponding bean and load all fields within it regarding its rules, length(), etc,.
I already did that implementation that you showed me, but it is no for the same purpose that I'm after, it would be an n-1 relation. I'm just aiming to generate the form and then persist. My brain is boiling already with it
There are 3 common expressions of this concept, which itself transcends JSF.
1. Dynamic application form construction. People end up essentially re-creating the framework, only with more complexity, less flexibility, less reliability and no vendor support. I've seen some real abominations. The reason that JSF is so clean and flexible in comparison has less to do with the relative cleverness of the people involved and more to do with the fact that there were more people involved in more environments and the framework design and implementation wasn't secondary to a specific business app.
2. Generic database table view/edit. I wrote one of these, and one of these days, I'll add the last few features that it needs and open-source it. It has dynamic forms because it's not a business application, it's a database utility and therefore doesn't have a static pre-defined set of objects to work from.
3. Code generator. Been there/did that circa Y2K. Created an open-source tool called the EJBWizard that would introspect tables and apply a set of macro templates to generate compilable code. Originally, the code was EJB version 1 and the View definitions were JSPs. I later wrote templates for Struts and then JSF. Like I said, the concept transcends JSF.