struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 林 明 <aftermath_l...@hotmail.com>
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 ClayTemplateParser.java, comments inserted 
between lines.


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

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

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

                root.addChild(child);
                // 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.clear();
            roots = null;
            buffer.setLength(0);
            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 
            //container.
            config.checkTree(root);
            
           // here, you can merge those adjacent verbatim elements
            config.optimizeTree(root);
           // 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 
one.
           
            return root;
    }
    
    
>From: gvanmatre@comcast.net (Gary VanMatre)
>Reply-To: "Struts Developers List" <dev@struts.apache.org>
>To: "Struts Developers List" <dev@struts.apache.org>
>Subject: Re: [shale] some improvement proposal for performance
>Date: Thu, 25 May 2006 15:35:13 +0000
>
> >From: 林 明 <aftermath_lin2@hotmail.com>
> >
> > thanks much for comments.
> >
> > Now give some explaination from me.
> > To jsf component tree iterating, I only give a guess if we use treemap 
but
> > not arraylist to store children components. The disadvantage of that is
> > necessary space of component tree struture will be great larger. But we 
can
> > direct find corresponded component to the request data. for example if 
we
> > 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 
other
> > 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 
runtime.
>>From what I understand, JSF 1.2 will allow you to do partial handling of
>the component tree
>  
(http://weblogs.java.net/blog/jhook/archive/2006/02/new_feature_for.html).
>
>Clay creates a metadata layer that is used to create the component tree.  
Clay
>has a custom view handler for full html and xml views (defining the page 
entry
>point) that just adds the Clay component under the view root.  The 
component
>handles creating the subtree.  The Clay component is a naming container 
too.
>
>The metadata layer is defined by a graph of simple beans that is created 
from
>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 
type
>of metadata to build the component tree.
>
>So, if you are using Clay, besides having the overhead of large component 
trees,
>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 
they
>are not pushed to the client.  The have to be inserted back into the tree. 
 The
>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 
to
>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 
would
>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 
merge
> > 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.
>
>
>Gary
>
> > regards.
> >
> > aftermath :-)
> >
> >
> >

_________________________________________________________________
与联机的朋友进行交流,请使用 MSN Messenger:  http://messenger.msn.com/cn  


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message