struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 林 明 <>
Subject Re: [shale] some improvement proposal for performance
Date Fri, 26 May 2006 03:09:24 GMT
thanks for your explaination and let me know more about clay details.
here, I borrow the clay template parser code to expand the my advice of 
where and how merge verbatim component children.

because the template parsing usually runs only once and then generated meta 
bean tree will be placed in cache for latter using, the performance of 
template parsing isn't bottleneck and not important. so , parsing work is 
inclined to hava an clear and extendable structured design. however, the 
parsed results (that meta bean tree) are used over and over again, so, 
optimizing results is meaningful.

the following code are from, comments inserted 
between lines.

protected ComponentBean generateElement(URL templateURL, String 
templateName) throws IOException {
        if (log.isInfoEnabled())
  "loading.template",  new Object[] 
            ComponentBean root = new ComponentBean();   
            // generate the document
            InputStream inputStream = null;
            StringBuffer buffer = null;
            try {
               inputStream = templateURL.openStream();
               buffer = loadTemplate(inputStream, templateName);
            } finally {
               if (inputStream != null)
            List roots = new Parser().parse(buffer);
            // here, the whole node tree already generated. To string 
            // "<html><head></head><body><h1>a</h1><body></html>",
tree will be
            // html
            //   -- head
            //   -- body
            //   -- -- h1
            //   -- -- -- a

            Iterator ri = roots.iterator();
            while (ri.hasNext()) {
                Node node = (Node);
                Builder renderer = node.getBuilder();

                ElementBean child = renderer.createElement(node);
                // to first node "html", child's componentType will be 

                // then "html" elementbean added to ComponentBean root

                if (renderer.isChildrenAllowed()) {
                    renderer.encode(node, child, child);
                } else {
                    renderer.encode(node, child, root);
                    // because "HtmlOutputText" not isChildrenAllowed, In 
"renderer.encode(node, child, root), elementbeans made from children "head" 
and "body" nodes also directly be added to the root.  for this analysis, 
"h1" and "a" also directly be added to the root.

            roots = null;
            buffer = null;
            ri = null;

            // here , root has children elementbean list in which every 
bean's type is "HtmlOutputText"
           // root  NamingContainer
           //   --  <html>   HtmlOutputText
           //   --  <head>   HtmlOutputText
           //   --  </head>  HtmlOutputText
           //   --  <body>   HtmlOutputText
           //   --  <h1>     HtmlOutputText
           //   --  a        HtmlOutputText
	   //   --  </h1>    HtmlOutputText
	   //   --  </body>  HtmlOutputText
	   //   --  </html>  HtmlOutputText
            //verify there is not a duplicate component id within a naming 
           // here, you can merge those adjacent verbatim elements
           // in optimizeTree, you can traverse elementbean tree, and 
iterate children treeset of every element.
           // while meeting continuous HtmlOutputText and it's value is not 
valuebinding reference, you can merge them into one
           // HtmlOutputText.  Further, in fact , JSF EL can evaluate value 
binding string like " abcd#{bean.value}efg#{bean2.value2}hi",
           // so, you probably can merge more verbatim elementbean into 
            return root;
>From: (Gary VanMatre)
>Reply-To: "Struts Developers List" <>
>To: "Struts Developers List" <>
>Subject: Re: [shale] some improvement proposal for performance
>Date: Thu, 25 May 2006 15:35:13 +0000
> >From: 林 明 <>
> >
> > thanks much for comments.
> >
> > Now give some explaination from me.
> > To jsf component tree iterating, I only give a guess if we use treemap 
> > not arraylist to store children components. The disadvantage of that is
> > necessary space of component tree struture will be great larger. But we 
> > direct find corresponded component to the request data. for example if 
> > find "id0:id8:subview:clay:id19", we can quickly use treemap to find it
> > like viewroot.children("id0").children("id8").children("subview")... 
and so
> > on. Because except restoreview and render phase or broadcast event of 
> > phases, actually we only need get few components from tree for
> > applyrequest,validating or updatemodel. Current, myfaces uses visitor
> > pattern to traverse the whole tree. In our project , some page may have
> > tens of form inputs components, but have many other layout components ,
> > component instances easily come up hundreds. so, if we only process
> > components needed, jsf will not burden with not good reputation of
> > performance.
> >
>This is really more of a JSF runtime issue.  Shale uses an existing 
>>From what I understand, JSF 1.2 will allow you to do partial handling of
>the component tree
>Clay creates a metadata layer that is used to create the component tree.  
>has a custom view handler for full html and xml views (defining the page 
>point) that just adds the Clay component under the view root.  The 
>handles creating the subtree.  The Clay component is a naming container 
>The metadata layer is defined by a graph of simple beans that is created 
>an XML or HTML source.  Both the HTML parser and the digested XML create
>the same type of beans.   The Clay component only has to know about one 
>of metadata to build the component tree.
>So, if you are using Clay, besides having the overhead of large component 
>you will also have the overhead of the POJO's that define the tree.
>When the view is restored and then rendered, and if you are using client 
side state
>saving, the verbatim components must be recreated from the metadata since 
>are not pushed to the client.  The have to be inserted back into the tree. 
>CreateComponentCommand looks for an existing component by id before
>creating a new one.  This search is done from the parent and not the
>view root - parent.findComponent(id).  So the sequential search is only 
for the
>children of the active parent.
>If you are trying to get the best performance out of JSF, you might want 
>just create the component tree from java code and not even use templating.
>You could create a view handler that maps the view id to a builder.  This 
>be more like servlet programming but the only thing you would have to 
handle is
>building the component tree.  This would give you the best performance.
> > To merge adjacent verbatim components, because those components usually
> > stand in the same
> > children list and already not in hierarchical node tree after you
> > processing and creating ComponentBean Tree, you can at this point to 
> > them.
> >
>Only looking at merging children would be simpler than trying to 
reorganize the tree.
>It will require processing the entire (metadata) tree again which may not 
be any faster
>than creating some extra components.
> > regards.
> >
> > aftermath :-)
> >
> >
> >

与联机的朋友进行交流,请使用 MSN Messenger:  

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message