JSF CDI : Conversation scope bean[s] best practice

*JSF CDI : Conversation scope bean[s] best practice*
Hello, im currently learning about JSF 2.0 and im so glad for the existence of this conversation scope feature, which is very helpful in opening a new tab or a new window on the same page and having separate resources, not overriding one another.
But im curious on how to implement this in a good way, about when to start the conversation and when to close it.
In my case, i have each CDI bean for each JSF page. And let's say that i have a menu, and when it's clicked, this will lead to page A, and from A, could lead to B, B could lead to C, C could lead to D, all these 4 pages are connected in one chain.
Accessing A's bean properties from B or C or D beans is possible, accessing B's properties is also possible from C or D beans and so forth.
Now im quite confused about :
* whether all these A B C D should be in conversation scope or not, or perhaps just A ? Because i think sometimes from another page that is outside the ABCD chain, like a page F, it could navigate to page B, although i dont know how to supply the data to the bean B yet.
* whether all these A B C D should be combined into one bean
* where and when to start the conversation, im thinking about the constructor, but i dont think it's a good idea, because i prefer starting the conversation when first accessing the page, not the bean
* where and when to stop the conversation, so that there wont be unused resources hanging around
Regards,
Albert Kam

There are also some commandButtons on the view page, which performs actions on Product object, fetched by passed ID.

Similar Messages

  • Bean load best practice

    I am not new to Java, but up until now have been a programmer. I am now getting more into design and architecture and have a question about best practice. This question arises from a UML class I was taking. But in the class we stayed within the UML and did not get into implementation.
    My Question
    When creating classes and designing how they interact, what is the best practice for implementing associative relationships. For example, if I were modeling a Barn that contained Animals, I would create a Barn bean and an Animal bean. Since the Barn contained Animals I could create the code like this:
    public class Barn {
    String color;
    Collection animals;
    void setColor(String newcolor);
    String getColor( );
    void setAnimals(Collection newanimals);
    Collection getAnimals( );
    public class Animals{
    String name;
    void setName(String newname);
    String getName( );
    }The Collection within the Barn bean would be made up of Animal beans.
    This seems fairly straight forward. However, what if I loaded the bean from a database? When building the bean, do I also find all animals and build the Animal beans and create the Collection to store within the Barn object?
    Or
    Do I omit the animal Collection from my Barn bean and only populate the Collection at runtime, when someone calls the getAnimals method?
    I am confident that the latter is the better design for performance and synchonization issues. But I wanted to get other opinions.
    Do I need to read up more on object design?
    Thanks,
    Lonnie

    And lazy initialization. Basically, unless the data is needed. Don't load it.

  • Managed bean inheritance best practice

    Hi!
    I'm new to JSF so I would like to apologize if my question is trivial, but I haven't been able to find proper solution.
    I'm using JSF 1.2 on WAS CE. I have a page where user can search for some entities, both person and company, which share some data, but have some different properties. Both inherit from entity class, so search results are displayed in dataTable as base entity objects. Each dataTable row has commandLink which should navigate user to specific (person or company) page for editing data. For example, if user clicks on commandLink in person data row, I would like to show personEdit page with all data set to components. I understand that I can use action to set navigation to proper page, and I have done so (following action() method). I have implemented EntityBean, PersonBean and CompanyBean:
    public class EntityBean {
        protected Entity entity;
        public int getId() {
            return entity.getId();
        public void setId(int id) {
            entity.setId(id);
        public String action() {
            // Some code which defines return value for action invoking.
        public void edit(ActionEvent event) {
            // Get entity data for edit.
    public class PersonBean extends EntityBean {
        public String getFirstName() {
            return ((Person)entity).getFirstName();
    public class CompanyBean extends EntityBean {
        public String getName() {
            return ((Company)entity).getName();
    }I tried combining action with actionListener method (+edit(ActionEvent event)+ method) invoked from commandLink, but if it is invoked on mapped entityBean, I get only entity properties set on any other page which is shown after invoked action. If method is invoked on i.e. personBean (same method, not overriden), I get NullPointerException for trying to access property for base entityBean.
    How should I invoke proper data initialization for bean shown on another page?
    Thanks in advance.

    Thank you for your quick reply. Beside the code for managed bean classes, here's the rest of the code for this specific problem.
    In faces-config.xml I have the following configuration:
         <managed-bean>
              <managed-bean-name>entitySearchBean</managed-bean-name>
              <managed-bean-class>entities.EntitySearchBean</managed-bean-class>
              <managed-bean-scope>request</managed-bean-scope>
         </managed-bean>
         <managed-bean>
              <managed-bean-name>personBean</managed-bean-name>
              <managed-bean-class>entities.PersonBean</managed-bean-class>
              <managed-bean-scope>request</managed-bean-scope>
         </managed-bean>
         <managed-bean>
              <managed-bean-name>entityBean</managed-bean-name>
              <managed-bean-class>legalentities.EntityBean</managed-bean-class>
              <managed-bean-scope>request</managed-bean-scope>
         </managed-bean>On my JSP, I have a dataTable loaded with entityBean objects, and the following code for showing editPage:
         <h:column>
              <h:commandLink id="editLink" action="#{entitySearchBean.editEntity}" actionListener="#{entityBean.edit}">
                   <h:outputText value="#{bundle.edit}" />
                   <f:param id="editId" name="editId" value="#{entity.id}" />
              </h:commandLink>
         </h:column>
    </h:dataTable>So, what I'm trying to do is to call entityBean.edit which should initialize EntityBean with entity data, and it sets i.e. person data to entity field of EntityBean class. I also call editEntity method on EntitySearchBean class (bean used just for searching entities with some criteria), and pass id property of selected entity in dataTable.
    What I'm expecting is to get personEdit.jsp with loaded personBean data initialized from actionListener on searchPage.jsp. Is it possible or is there some other way to do this?

  • EJB3 entity bean update, best practice

    I have an ejb3 entity bean that models a time that can be reserved in a booking system.
    I need a way to reserve the time for a specific user. Ofcourse the reservation should not overwrite if the time has already been reserved by another user.
    What is the best/cleaneste way to provide this service?
    I have thought of the following ways.
    I could put a version field on the entity. When the user is set in the frontend the entitybean will check that the time is not already reserved. If not it will be sent backup to the stateless session bean for persisting. If the time has been reserved by another user in the meantime JPA will throw an exception since the version doesn't match any more. The frontend can then show the error to the user.
    I could make the frontend call a method in a stateless session bean to reserve the time. The function could take the times primary id and the users primary id and loaded them from persistence. Then check if the time is already reserver else set the user and persist the time again. This should ofcourse be within a transaction and possibly also use a version attribute on the entity.

    Only fields detected as persistent-dirty will be updated in the database record.
    Laurent

  • JSF - Best Practice For Using Managed Bean

    I want to discuss what is the best practice for managed bean usage, especially using session scope or request scope to build database driven pages
    ---- Session Bean ----
    - In the book Core Java Server Faces, the author mentioned that most of the cases session bean should be used, unless the processing is passed on to other handler. Since JSF can store the state on client side, i think storing everything in session is not a big memory concern. (can some expert confirm this is true?) Session objects are easy to manage and states can be shared across the pages. It can make programming easy.
    In the case of a page binded to a resultset, the bean usually helds a java.util.List object for the result, which is intialized in the constructor by query the database first. However, this approach has a problem: when user navigates to other page and comes back, the data is not refreshed. You can of course solve the problem by issuing query everytime in your getXXX method. But you need to be very careful that you don't bind this XXX property too many times. In the case of querying in getXXX, setXXX is also tricky as you don't have a member to set. You usually don't want to persist the resultset changes in the setXXX as the changes may not be final, in stead, you want to handle in the actionlistener (like a save(actionevent)).
    I would glad to see your thought on this.
    --- Request Bean ---
    request bean is initialized everytime a reuqest is made. It sometimes drove me nuts because JSF seems not to be every consistent in updating model values. Suppose you have a page showing parent-children a list of records from database, and you also allow user to change directly on the children. if I hbind the parent to a bean called #{Parent} and you bind the children to ADF table (value="#{Parent.children}" var="rowValue". If I set Parent as a request scope, the setChildren method is never called when I submit the form. Not sure if this is just for ADF or it is JSF problem. But if you change the bean to session scope, everything works fine.
    I believe JSF doesn't update the bindings for all component attributes. It only update the input component value binding. Some one please verify this is true.
    In many cases, i found request bean is very hard to work with if there are lots of updates. (I have lots of trouble with update the binding value for rendered attributes).
    However, request bean is working fine for read only pages and simple binded forms. It definitely frees up memory quicker than session bean.
    ----- any comments or opinions are welcome!!! ------

    I think it should be either Option 2 or Option 3.
    Option 2 would be necessary if the bean data depends on some request parameters.
    (Example: Getting customer bean for a particular customer id)
    Otherwise Option 3 seems the reasonable approach.
    But, I am also pondering on this issue. The above are just my initial thoughts.

  • Looking for best practice on application scope beans

    Hey – a portal newbie here. I’ve got some application scope beans that need to be initialized on startup. First thought was to create a servlet that would set the bean. Then I saw the GlobalApp setting, but I think that looks like it is more session scope than application… Looking to be corrected here if I am wrong.
    Is there a place where these type of things traditionally happen? Read only, so no cluster worries (I think) Using WLP 8.1 SP4 and looking for best practices. Thanks for the help!

    To support "code sharing" you need an integrated source code control system. Several options are out there but CVS (https://www.cvshome.org/) is a nice choice, and it's completely free and it runs on Windows, Linux, and most UNIX variants.
    Your next decision is on IDE and application server. These are usually from a single "source". For instance, you can choose Oracle's JDeveloper and Deploy to Oracle Application Server; or go with free NetBeans IDE and Jakarta Tomcat; or IBM's WebSphere and their application server. Selection of IDE and AppServer will likely result in heated debates.

  • Best practice for initializing objects in a JSF backing bean?

    Hi,
    What is the best practice for initializing some objects in the JSF to-page backing bean before the to-page is displayed for the first time? The initialization would vary and depend upon a command link in the from-page.
    Regards,
    Al Malin

    f:view has two new attributes in 1.2: beforePhase and afterPhase
    which allows you to specify a phase listener method
    which will be called before and after the view is processed.

  • JSF best practice for managed bean population

    hi;
    consider a simple session scope managed bean with 1 attribute which is calculated dynamically.
    there seem to be 3 ways of populating that attribute (that i could think of):
    1. have the bean's get<attribute> get the data and populate it
    2. have the constructor of the bean get the data and populate it
    3. have an action get the data, and set it from the action code (maybe use a valueBinding to get the bean if the bean which needs population is not the same bean that holds the action) .
    option 1 seems ok for situations where i need my data to be calculated for every valueRef for that attribute but is an overhead for data that need not be calculated for every valueRef.
    option 2 will ensure that te data is calculated only once per session. but it still looks kinda strange to do it
    with option 3, it seems you should populate the dynamic content of the next page and its intuitive but some places in the page might be common content with dynamic data and this has nothing to do with navigation and the next page to be displayed.
    is there a best practice of how to populate a managed bean data?
    are different cases fit different ways?
    any thoughts are appriciated.

    I think it should be either Option 2 or Option 3.
    Option 2 would be necessary if the bean data depends on some request parameters.
    (Example: Getting customer bean for a particular customer id)
    Otherwise Option 3 seems the reasonable approach.
    But, I am also pondering on this issue. The above are just my initial thoughts.

  • Best practice how to retrieve & update data w/o any jsf-lifecycle-overhead

    I have a request scoped jsf managed bean called "ManagedBean". This bean has a method annotated with "@PostConstruct" that retrieves data from a database. The data is shown in a jsp "showAndEditData.jsp" in <h:inputText /> components - so the data is editable.
    The workflow is as follows:
    First, when navigating to "showAndEditData.jsp", the ManagedBean is created, the "@PostConstruct"-method is invoked, and the data retrieved from the database is shown to the user.
    Second, the user changes the data.
    Third, the user presses the submit button, the ManagedBean is created again, the "@PostConstruct"-method is invoked again, and the data is retrieved from the database again. Then the data is overridden by the changes the user made and passed to the business-tier (where it will be saved to the database).
    Every step that i marked with "*again*" is completely unneccessary and a huge overhead.
    Is there a way to prevent these unneccessary steps.
    Or asking in other words: Is there a best practice how to retrieve and update data efficently and without any overhead using JSF?
    I do not want to use session scoped managed beans, because this would be a huge overhead as well.

    The first "again" is neccessary, because after successfull validation, you need new object in request to store the submitted value.
    I agree to the second and third, really unneccessary and does not make sense.
    Additionally I think it�s bad practice putting data in session beansTotal agree, its a disadvantage of JSF that we often must use session.
    Think there is also an bigger problem with this.
    Dont know how your apps are working, my apps start an new database transaction per commit on every new request.
    So in this case, if you do an second query on postback, which uses an different database transaction, it could get different data as for the inital request.
    But user did his changes <b>accordingly</b> to values of the first snapshot during the inital request.
    If these values would be queried again on postback, and they have been changed meanwhile, it becomes inconsistent, because values of snapshot two, do not fit to user input.
    In my opionion zebhed has posted an major mistake in JSF.
    Dont now, where to store the data, perhaps page scope could solve this.
    Not very knowledge of that section, but still ask myself, if this data perhaps could be stored in the components and on an postback the data are rendered from components + submittedvalues instead of model.

  • What is the best practice to handle JPA methods in JSF app?

    I am building a JSF-JPA web app(No EJB).
    I have several methods that has JPA QL inside.
    Because I have to put those methods inside JSF beans to inject EntityManagerFactory (am I right about this?).
    And I do want to separate those methods from regular JSF beans which are used by page authors.
    And I may need to use them in different JSF managed beans.
    My question here is that what is the best practice to handle that?
    I. write a or a few separate JSF Beans and inject them into regular Beans?
    II. write a or a few separate JSF Beans and access them into regular Beans using FacesContext?
    III. others?
    Waiting to hear from you opinions.

    You can create named queries on your Entities themselves then just call entityMgr.createNamedQuery("nameOfQuery");
    Normally, we put these named queries in the class of the entity which will be returned. This allows for all information pertaining to a given entity and all ways of accessing that entity (except em.find() and stuff, of course) to be in one place. As long as the entity is defined in your persistence.xml file, any named queries which reside on that entity will be available through the EntityManager.
    As for the EntityManagerFactory, we normally create an application scope bean which holds the factory itself (because this is a heavy-weight object) and then just get all EntityManager instances from that by injecting this bean into whatever needs it. For example, I might have:
    //emfBB is the injected app scope bean which holds the entity manager factory.
    private EmfBB emfBB;
    private void lookupSomeData()
    EntityManager em = this.getEmfBB().getEmf()
    I hope this answered your question?
    ~Zack
    Edited by: zmarr on Nov 6, 2008 1:29 PM

  • Managed Bean Best Practices

    Hi
    Are there any best practices for using Managed Beans?
    We plan to use our own custom-built JSF components. Need to understand how to design backing beans for performance/effort optimization.
    For example :
    1. How to make managed beans thread-safe for concurrent requests, without compromising on efficiency/speed?
    2. How to enforce the J2EE security with managed-beans?
    3. How to decide the scope of these beans to ensure minimal data-storage in session?
    4. How to decide the granularity at which a managed-bean should be used for example :
    4.1 One bean-per-component
    Advantages :
    a) if complex components require special data-holding/processing/event-handling capabilities from bean
    (e.g. datagrid model,tree model,menu model)
    Problems :
    - with multiple components in a page/form
    a) it becomes tedious to debug/change/track which bean serves which component
    b) if session scope is required, too many beans will be cached in session
    c) unnecessarily too many beans will be created on server (= n pages * m components-per-page)
    d) unnecessarily increases the length of faces-config.xml
    4.2 One bean-per-form
    Advantages :
    a) in multi-form web pages, to ensure the functional behaviour of each form is separate/modular in its own bean.
    b) each managed-bean would map to specific/meaningful functionality/user-interaction in use-case.
    Problems :
    - if form includes complex components (datagrid/tree/menu) requiring a specialised bean class, then
    a) either one of the specialized bean has to be augmented with additional logic to handle data/events for all other components within the form
    (Not good, as it mixes-up the responsibilities of component-specific-beans, and the bean may no more be reusable in another form)
    b) or without using component-specific beans, only single form bean should handle the data/events for all components in the form?
    (Neither good, since if a complex tree-compoent is reused in multiple forms, then the logic to handle data/events for such a component will be repeated in those many form-specific managed beans)
    4.3 One bean-per-page
    Advantages :
    a) seems more modular/meaningful way - since a page would map to some feature within the use-case
    b) bean will contain only behaviour which is relevent for the associated page/function within use-case
    Problems :
    a) in multi-form pages, can single bean handle data/events for multiple forms?
    b) if page uses complex component (e.g datagrid, tree) that needs its own bean - how does page-bean exchange data with component-bean?
    Thanks,
    Arti

    Are there any best practices for using Managed
    Beans?There are no best practices for using Managed Beans in terms of Sun, or other vendors recommendations. But there are some patterns that can be applied to the managed beans (The managed bean is already a pattern). Also common sense is allways a good practice.
    For example, the managed bean should not have business logic code, only presentation logic code, etc.
    1. How to make managed beans thread-safe for
    concurrent requests, without compromising on
    efficiency/speed?The beans can be created by request, so concurrency is not an issue. If they are session scope, also is not an issue because, a user can only have one thread running. Only in application scope you must have carefull.
    >
    2. How to enforce the J2EE security with
    managed-beans?see this:
    http://jsf-security.sourceforge.net/
    About jsf-security
    >
    3. How to decide the scope of these beans to ensure
    minimal data-storage in session?If you wnat minimal data-storage in session the answer is request or none.
    In question 4, you make the question and give the answer ;-)

  • Best practices desiging JSF applications

    I have an intermediate level of knowledge on JSF but after completing a component for an application I'm still stumped about the best practices required when designing a Java Server Faces application.
    The issue I faced mostly in the first iteration was Loading of dependant objects.
    Wherever we needed to display an editable view of an object by way of a request parameter there was always the question at what point to load the entity?
    For example, I have a page edit.jspx?itemId=21
    In my faces config, I have a Backing bean which has a managed property:
    <managed-property>
        <property-name>itemId</property-name>
        <property-class>java.lang.Integer</property-class>
        <value>#{param.itemId}</value>
    </managed-property>My backing bean has the getters and setters for this property but at which point is it best to load the item with id of "itemId"?
    It also gets a bit more complex when I depend on other injected properties for example an application scope manager class.
    One thing I have learned is, that the order that you declare the managed-properties in the faces-config appears to be the order that they are injected - I can't make a definitive answer on this as that's just the way it works on Sun App Server 8.1 and JSF 1.1. But I'm still trying to work out when to undertake a simple load for dependant entities in a backing bean.
    One appraoch I have looked at taking is introducing some "Loader" classes - basically a POJO that performs loads based on request param setting events:
        <managed-bean>
            <managed-bean-name>UserLoader</managed-bean-name>
            <managed-bean-class>testfaces.loader.UserLoader</managed-bean-class>
            <managed-bean-scope>request</managed-bean-scope>
            <managed-property>
                <property-name>invManager</property-name>
                <property-class>testfaces.aspect.InvestigationManager</property-class>
                <value>#{InvestigationManager}</value>
            </managed-property>
            <managed-property>
                <property-name>userId</property-name>
                <property-class>java.lang.Integer</property-class>
                <value>#{param.userId}</value>
            </managed-property>
        </managed-bean>
        <managed-bean>
            <managed-bean-name>ItemBean</managed-bean-name>
            <managed-bean-class>testfaces.jsf.bean.ItemBean</managed-bean-class>
            <managed-bean-scope>request</managed-bean-scope>
            <managed-property>
                <property-name>user</property-name>
                <property-class>org.ikeda.testfaces.model.UserEntity</property-class>
                <value>#{UserLoader.user}</value>
            </managed-property>
        </managed-bean>Ergo, each time I use the ItemBean in a JSP it will try and set the "user" property which is retrieved from the UserLoader provided the param.userId is set from the query string. Mind you this limits me to using only the request parameter (okay for Portlet integration) as there is no property called userId in the ItemBean - another workaround to work out!
    Of course this kind of functionality can be rolled into the ItemBean, but it's amazing how much of a mess the Backing bean becomes when you encapsulate this logic into the backing bean.
    What experiences has everyone else had with JSF and this kind of situation?
    Does anyone know of any good resources about "designing" JSF applications (writing is one thing, designing is another)?
    Regards,
    Anthony

    I have an intermediate level of knowledge on JSF but after completing a component for an application I'm still stumped about the best practices required when designing a Java Server Faces application.
    The issue I faced mostly in the first iteration was Loading of dependant objects.
    Wherever we needed to display an editable view of an object by way of a request parameter there was always the question at what point to load the entity?
    For example, I have a page edit.jspx?itemId=21
    In my faces config, I have a Backing bean which has a managed property:
    <managed-property>
        <property-name>itemId</property-name>
        <property-class>java.lang.Integer</property-class>
        <value>#{param.itemId}</value>
    </managed-property>My backing bean has the getters and setters for this property but at which point is it best to load the item with id of "itemId"?
    It also gets a bit more complex when I depend on other injected properties for example an application scope manager class.
    One thing I have learned is, that the order that you declare the managed-properties in the faces-config appears to be the order that they are injected - I can't make a definitive answer on this as that's just the way it works on Sun App Server 8.1 and JSF 1.1. But I'm still trying to work out when to undertake a simple load for dependant entities in a backing bean.
    One appraoch I have looked at taking is introducing some "Loader" classes - basically a POJO that performs loads based on request param setting events:
        <managed-bean>
            <managed-bean-name>UserLoader</managed-bean-name>
            <managed-bean-class>testfaces.loader.UserLoader</managed-bean-class>
            <managed-bean-scope>request</managed-bean-scope>
            <managed-property>
                <property-name>invManager</property-name>
                <property-class>testfaces.aspect.InvestigationManager</property-class>
                <value>#{InvestigationManager}</value>
            </managed-property>
            <managed-property>
                <property-name>userId</property-name>
                <property-class>java.lang.Integer</property-class>
                <value>#{param.userId}</value>
            </managed-property>
        </managed-bean>
        <managed-bean>
            <managed-bean-name>ItemBean</managed-bean-name>
            <managed-bean-class>testfaces.jsf.bean.ItemBean</managed-bean-class>
            <managed-bean-scope>request</managed-bean-scope>
            <managed-property>
                <property-name>user</property-name>
                <property-class>org.ikeda.testfaces.model.UserEntity</property-class>
                <value>#{UserLoader.user}</value>
            </managed-property>
        </managed-bean>Ergo, each time I use the ItemBean in a JSP it will try and set the "user" property which is retrieved from the UserLoader provided the param.userId is set from the query string. Mind you this limits me to using only the request parameter (okay for Portlet integration) as there is no property called userId in the ItemBean - another workaround to work out!
    Of course this kind of functionality can be rolled into the ItemBean, but it's amazing how much of a mess the Backing bean becomes when you encapsulate this logic into the backing bean.
    What experiences has everyone else had with JSF and this kind of situation?
    Does anyone know of any good resources about "designing" JSF applications (writing is one thing, designing is another)?
    Regards,
    Anthony

  • Best practice for backing bean population? (also, ActionListener RANT)

    Hello,
    I am about 3/4 of the way through development of a small to medium size JSF application. Sometimes I really like JSF, but much of the time I am left puzzled or frustrated for hours trying to find workarounds to JSF's bugs/glitches and design flaws.
    For example, early on, I was impressed with how easily it was to invoke a method from a page using an actionlistener. Now that I'm actually building things with JSF, the actionlistener funtionality still seems cool, but incredibly half baked. I find myself using request parameters LIKE CRAZY to work around the fact that JSF doesnt support passing parameters directly to backing bean methods. This feels awkward and wrong considering the fact that JSF is intended to abstract the HTTP underpinnings. To add insult to injury, I often have to iterate through ALL of the request parameters looking for one that has an id with an ending matching my desired property name (since JSF appends it's own crap to the beginning). I don't like doing things in a hacky way. This seems very hacky, and I feel dirty doing it.
    So, my first question is, what is the best practice for populating backing beans??? How do others accomplish this. I can think of several other approaches, but none feel less hacky.
    Second, are there plans in the next spec (please say there are) to allow parameters to be passed to backing bean methods? If not, WHY THE HECK NOT?
    Even though JSF expert group people have been conspicuously absent from this forum of late, I'd really appreciate responses from you as well.
    Thank you for your thoughts.

    Hi BrownBear,
    I've been using JSF for about 6 months now and I'd be glade to help as much as I can.
    Concerning parameters, I'm not sure what your issue is but I use the f:param tag to pass them. If you could post an example of what you are trying to do, I could see exactly what your issue is. Maybe the f:param can't help you.
    As for best practice for populating backing beans, I personaly try to let JSF do as much as possible. For example, if I have a backing bean with five properties, I make sure that they all are on the JSP page the bean serves. If one of the property is just there as an Id like, lets say, a Person ID (DB row key), then I put it on my JSP page as a hidden input field. I do the same with the properties that only for display, if I want them to be back in my bean when request comesback.
    Hope this help some how. Please, feel free to ask specific questions related to your specific problem and I monitor this post and trnasfer to you the ;little JSF experience I have.
    I'm pretty happy with JSF as it is but it sure needs improvements. :) What the heck, it's version 1.01 after all, and the next release should be a great one with the integration of JSTL.
    Cheers

  • Conversion exit missing in BI - Best practice to install missing exits

    Hi,
      We are on BI 7.0 SP10.
      While doing mappings, I found two conversion Exits MATN2 & SCOPE missing from the BI box. Hence SAP was throwing error while trying to activate the 7.0 datasource.
    On more analysis, I found that the function groups are altogether missing.
    What is the best practice to install these missing objects (Func Groups, Func Mods) in the system.
    Our ABAP person suggested to create these objects as "Repair objects" in the system. Is that the right procedure?
    Please advise.
    Thanks
    Vishno

    I have been through the following steps:
    Entered this URL http://help.sap.com/bp/initial/index.htm
    Clicked on 'Cross-industry Packages'
    Clicked on 'CRM'
    Clicked on 'Englilsh'
    Then the following page is displayed:
    http://help.sap.com/bp_crm70/CRM_DE/HTML/index.htm displayed
    But now what?. How do I get the Best practice instructions for a CRM implemenation?.
    Jason

  • Best Practice On Taking Count in Bean

    Hi folks,
      Here i'm using Jdev 11.1.1.7.0. where I have a case take count on inserted rows in bean.
    here we go..
    Bean code
    developer way 1:
    button_click(){
    int count = voins.getRowcount();
    developer way 2:
    button_click(){
    int count = iteratorbind.getEstimatedRowcount();
    developer way 1: fetching view object in bean for purpose of taking row count.
      ---developer 1 says that best practice on taking count is using view object 'getRowcount()'.
    Note: developer 1 comment that developer 2 way is worst practice. it's a time taken process
    developer way 2: using iterator getting row count
      ---developer 2 says that for taking count we can use 'estimatedRowcount'.
    Note: developer 2 comment that developer 1 way is worst practice taking view object on bean.
    i.e developer 1 try catch the model layer directly from the code. we can use iterator to do all the stuff.
    which is best practice please suggest me... is there any other practice taking row count in bean.
    thanks.

    Dev way 1)
    A look into the java doc reveals
    Note that this method retrieves all rows from the database then returns the number of rows in the Row Set collection.
    So if your table contains a lot of rows calling getRowCount takes a lot of time and memory.
    Dev way 2)
    Calling getEstimatedRowCount executes a select count(*) from (your query) to get the count. This is fast but the task count may differ if many changes are done on the table. I personally had never a problem with this, but I can't speak for you.
    Timo

Maybe you are looking for