Hi Irfan,
I looked quickly at the code... it does appear that it should pass
through the rendered property. However, the DynamicTreeNode factory
creates the containing node and its children... and the rendered
property should be passed to the containing node. Is this what you are
seeing or not? Make sure the spelling is correct. If you need the
dynamic child nodes to contain a rendered property... then you'll need
to support this in your TreeAdaptor class.
If you are still stuck, send the part of the .jsf file that is causing
you the problem and I'll look at it more closely.
Thanks!
Ken
Irfan Ahmed wrote:
> Well Ken I did fix it as we discussed but this needs more work. Right
> now I am using the SipConfigBean to check if the sip backend is
> available.
>
> However I found one problem with this. The rendered property does not
> seem to have an effect for the dynamicTreeNode element in the peTree.jsf.
>
> To elaborate: lets say you have a sun:treeNode as a parent and two
> nodes of type dynamicTreeNode within it. Now if you set the rendered
> property of the sunTreeNode as false (dynamically), the treeNode as
> well as the two dynamicNodes are not shown. This is fine.
>
> Now lets say you have a sunTreeNode which has say 4 dynamicNode
> children within it. Now if I set the rendered property of two of these
> to false, the dynamicNode is still rendered.
>
> Is this a bug. It seems that the rendered property take effect only on
> the sunTreeNode and not the dynamicTreeNode
>
> Rgds
> Irfan
>
> Ken Paulsen wrote:
>>
>>
>> Irfan Ahmed wrote:
>>> Hi Ken,
>>>
>>> It seems that the "rendered" property of a treeNode is ignored while
>>> creating the root tree. Hence even if the rendered property is false
>>> the child components of a tree node will always be created.
>>>
>>> Now once the child components are created, the rendered property is
>>> used to display the node components on the page. I think the
>>> children should not be traversed if the rendered property of a
>>> parent component is false.
>> The problem is the value of the rendered property may not be correct
>> during tree creation time, so it cannot be used reliably at that
>> time. This may lead to portions of the page missing even when the
>> rendered property is true (at render time).
>>
>> However if you want to achieve this functionality, I may be able to
>> accommodate this via a new property... I don't think we should do
>> this via the "rendered" property, though.
>>
>> Ken
>>
>> (I cc'd the jsft developer list in case others have comments.)
>>> I made a code change in LayoutViewHandler.buildUIComponentTree
>>> function, that does exactly this. It will not recurse into building
>>> the children components of the parent component's rendered property
>>> is false. By default rendered property is true and hence for all
>>> other cases the UI tree will be built as normal.
>>>
>>> I have attached the diff.
>>>
>>> Comments.
>>>
>>> Rgds
>>> Irfan.
>>>
>>> Mark A. Basler wrote:
>>>> Hi Anissa,
>>>>
>>>> The Sailfin branch was merged into the FCS branch a couple of weeks
>>>> ago...
>>>>
>>>> Hope this helps - Thanks - Mark
>>>>
>>>>
>>>> Anissa Lam wrote:
>>>>> Hi Mike,
>>>>> Thanks for clarifying this. I don't remember seeing any email
>>>>> that tells us that SAILFIN_BRANCH has merged back to FCS_BRANCH
>>>>> and thats the branch we should work on for the 9.1.1 release. But
>>>>> you are right, i just checked the CVS log, and indeeed Irfan's
>>>>> checkin is to the FCS_BRANCH.
>>>>> thanks
>>>>> Anissa.
>>>>>
>>>>> Mike Wright wrote:
>>>>>> Hi Anissa,
>>>>>>
>>>>>> We're working on JBI deliverables intended for 9.1.1/SailFin,
>>>>>> which we have been told is now in the FCS branch
>>>>>> "SJSAS91_FCS_BRANCH" (not in the tip). My understanding is that
>>>>>> the private SailFin branch was already merged into FCS and, later
>>>>>> in November, the 9.1ur1 branch "SJSAS91_UR1_BRANCH" will be
>>>>>> merged into FCS (but we need to merge our changes before feature
>>>>>> freeze). I also took this to mean that no more work is being
>>>>>> done in the private SailFin branch.
>>>>>>
>>>>>>
>>>>>> The stack traces I'm seeing are after building the
>>>>>> SJSAS91_FCS_BRANCH, due to a missing resource bundle, used by the
>>>>>> SIP-related nodes in peTree.jsf.
>>>>>>
>>>>>>
>>>>>> Also, I believe that the V3 branch was just merged into the
>>>>>> tip, but my team is not working on V3 code yet (maybe early next
>>>>>> year). My team is currently working on only two GlassFish branches:
>>>>>>
>>>>>> 1. SJSAS91_UR1_BRANCH for a few pending bug (and findbugs) fixes
>>>>>> going into 9.1_01.
>>>>>> 2. SJSAS91_FCS_BRANCH for Sierra features going into 9.1.1 (some
>>>>>> already in 9.1ur1, some ready to commit, some to be finished by
>>>>>> feature freeze, 11/19; these are all pending approval)
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>> ---
>>>>>> Anissa Lam wrote:
>>>>>>>
>>>>>>> Hi Mike,
>>>>>>> Ken is out today and tomorrow.
>>>>>>>> I checked out the FCS (9.1.1/SailFin) branch
>>>>>>> I am confused. Do you checkout the SAILFIN_BRANCH or the tip ?
>>>>>>> I haven't built the sailfin branch for a while and not sure the
>>>>>>> status of it.
>>>>>>> I have cc'ed Irfan who has made changes to the console in the
>>>>>>> SAILFIN_BRANCH lately to plugin SIP related tree nodes. He
>>>>>>> should be able to tell you what you need to do to get this running.
>>>>>>> Yes, please file issue against 9.1.1 for SailFin release.
>>>>>>>
>>>>>>> thanks
>>>>>>> Anissa.
>>>>>>>
>>>>>>> Mike Wright wrote:
>>>>>>>> Hi Anissa,
>>>>>>>>
>>>>>>>> I haven't received any response from Ken. Are you able to
>>>>>>>> build/use the console using the SailFin branch?
>>>>>>>>
>>>>>>>>
>>>>>>>> Should I create a GF IT issue against 9.1.1?
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>> ---
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> Subject:
>>>>>>>> SJSAS91_FCS_BRANCH console broken
>>>>>>>> From:
>>>>>>>> Mike Wright <Michael.A.Wright_at_sun.com>
>>>>>>>> Date:
>>>>>>>> Wed, 10 Oct 2007 14:53:07 -0700
>>>>>>>> To:
>>>>>>>> Ken Paulsen <Ken.Paulsen_at_Sun.COM>
>>>>>>>>
>>>>>>>> To:
>>>>>>>> Ken Paulsen <Ken.Paulsen_at_Sun.COM>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Ken,
>>>>>>>>
>>>>>>>> I checked out the FCS (9.1.1/SailFin) branch and
>>>>>>>> built/started a developer-profile domain. When I log into the
>>>>>>>> console, the navigation tree has a stack trace due to a missing
>>>>>>>> extension Strings properties file for sip.
>>>>>>>>
>>>>>>>>
>>>>>>>> Is this a known problem? Do I need to do something to get
>>>>>>>> this file? (I've rebuilt the console with the sip-related tree
>>>>>>>> nodes commented-out for now).
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>> ---
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>> --
>>> Irfan Ahmed | Sun Microsystems Inc., Bangalore, India. |
>>> irfan_at_sun.com <mailto:irfan_at_sun.com%22> - 9180.66927726 - x27726
>>> ------------------------------------------------------------------------
>>>
>>> Index: com/sun/jsftemplating/layout/LayoutViewHandler.java
>>> ===================================================================
>>> RCS file: /cvs/jsftemplating/src/java/com/sun/jsftemplating/layout/LayoutViewHandler.java,v
>>> retrieving revision 1.33
>>> diff -u -r1.33 LayoutViewHandler.java
>>> --- com/sun/jsftemplating/layout/LayoutViewHandler.java 19 Sep 2007 18:44:14 -0000 1.33
>>> +++ com/sun/jsftemplating/layout/LayoutViewHandler.java 12 Oct 2007 12:46:04 -0000
>>> @@ -529,8 +529,10 @@
>>> // NOTE: functionality here will simply do the same thing
>>> // NOTE: automatically).
>>>
>>> - // Recurse
>>> - buildUIComponentTree(context, child, childElt);
>>> + // Recurse only if rendered is true
>>> + if (child.isRendered()) {
>>> + buildUIComponentTree(context, child, childElt);
>>> + }
>>> } else {
>>> buildUIComponentTree(context, parent, childElt);
>>> }
>>>
>
> --
> Irfan Ahmed | Sun Microsystems Inc., Bangalore, India. | irfan_at_sun.com
> <mailto:irfan_at_sun.com%22> - 9180.66927726 - x27726