1 Reply Latest reply on Sep 23, 2007 4:40 AM by Matt Drees

    can factory methods have parameters?

    Matt Galvin Newbie

      I've scoured the forum and docs trying to figure this out and have been unsuccessfull, so hopefully someone can steer me in the right direction.

      I have a page that displays a set of dataTable elements. The scenario is that I have a bunch of objects that can be categorized. The list of categories is dynamic. On the page, I am iterating over each category (using ui:repeat) and displaying a dataTable for each category. The dataTable snippet currently looks like:

      <ui:repeat value="#{allCategories}" var="category">
       <rich:dataTable width="100%" var="record" value="#{calculationManager.findCalculations(category.id)}">
       <rich:column>
       <h:outputText value="#{record.calculation)}"/>
       </rich:column>
       </rich:dataTable>
      </ui:repeat>
      


      The allCategories property is backed by a DataModel, this is fine. The dataTables are being populated by a bean (referenced by calculationManager) that contains the following:

      public List<FinancialCalculation> findCalculations(int categoryId) {
       return (List <FinancialCalculation>)em.createQuery("select f from FinancialCalculation f where category_id=:c")
       .setParameter("c", categoryId)
       .getResultList();
      }
      


      This is displaying as I want. However, my next step is that each item in each table needs to be clickable (it will take the user to a details page).

      There are two options that I've thought of. First, I can use a commandLink and pass an id of the selected item through it, then look up the object in the method that is called. I haven't done it, but can't think of why it wouldn't work. It just doesn't feel "correct".

      The second was to switch to using a DataModel to back each table and use the DataModelSelection functionality. This is what I think I should be doing. The problem is, I don't know how to create the DataModel using a factory method that needs to take a parameter (ie, make the findCalculations method above be a factory). Alternatively, I could remove the method parameters and add an injected property:
      @In private Integer categoryId

      But then I don't know how to have the proper value injected for each of the dataTables.

      Did I explain that clearly? If so, any suggestions?

      Thanks!
      Matt

        • 1. Re: can factory methods have parameters?
          Matt Drees Master

           

          "matt.galvin" wrote:

          There are two options that I've thought of. First, I can use a commandLink and pass an id of the selected item through it, then look up the object in the method that is called. I haven't done it, but can't think of why it wouldn't work. It just doesn't feel "correct".


          I don't think it's incorrect. This is what seam gen apps do. And my gut feel is you'll encounter less trouble this way.

          "matt.galvin" wrote:

          The second was to switch to using a DataModel to back each table and use the DataModelSelection functionality. This is what I think I should be doing. The problem is, I don't know how to create the DataModel using a factory method that needs to take a parameter (ie, make the findCalculations method above be a factory).


          Right, factory methods can't have parameters.

          "matt.galvin" wrote:

          Alternatively, I could remove the method parameters and add an injected property:
          @In private Integer categoryId

          But then I don't know how to have the proper value injected for each of the dataTables.

          You could (I'm pretty sure) do something like
          @In(value="#{category.id}") private integer categoryId
          


          However, I don't think you should use the @DataModel / @DataModelSelection approach here. The reason is you need multiple dataModels (one for each category), and @DataModel only gives you a single dataModel per variable. You could use multiple dataModels with a more traditional JSF approach, though I think your first idea is easier.