[09:52:07 CST(-0600)] <EricDalquist> looks like we might be getting some more QA resources for uP4 
[10:16:01 CST(-0600)] <EricDalquist> athena: you there?
[10:26:17 CST(-0600)] <Arvids> EricDalquist, glad you´re here
[10:26:24 CST(-0600)] <EricDalquist> yeah, was out sick yesterday
[10:27:15 CST(-0600)] <Arvids> I rewrote that tab ID lookup - XPath did lookups in 1-50ms, but manual traversing does the same thing in 0.05-0.15ms
[10:27:37 CST(-0600)] <EricDalquist> wow nice
[10:27:44 CST(-0600)] <EricDalquist> +1 for that change
[10:27:45 CST(-0600)] <Arvids> that speeds up response times by 30-40%
[10:28:08 CST(-0600)] * EricDalquist cannot wait to have time to just re-write the layout manager/store layer
[10:28:25 CST(-0600)] <EricDalquist> xslt is find for the rendering pipeline but it would be nice to not treat the actual layouts as DOMs
[10:28:26 CST(-0600)] <Arvids> it turns out that those lookups are made at each URL building request
[10:28:38 CST(-0600)] <EricDalquist> ah ... yeah they would be
[10:28:56 CST(-0600)] <EricDalquist> one thing I've always wanted to write but never had time would be a @RequestCache annotation
[10:29:00 CST(-0600)] <EricDalquist> and supporting code
[10:29:07 CST(-0600)] <Arvids> btw, i can give you a patch, but I won´t have time to commit it today myself
[10:29:14 CST(-0600)] <EricDalquist> that will work
[10:29:28 CST(-0600)] <EricDalquist> being able to annotated a method with @RequestCache and have the method result be cached in a request attribute
[10:30:44 CST(-0600)] <Arvids> https://gist.github.com/1607350
[10:31:42 CST(-0600)] <EricDalquist> so have you tested this on mobile?
[10:31:54 CST(-0600)] <Arvids> no
[10:32:10 CST(-0600)] <EricDalquist> the way things work the UrlNodeSyntaxHelper impl is associated with the structure transform
[10:32:18 CST(-0600)] <EricDalquist> so the logic to find the correct tab needs to be in there
[10:32:57 CST(-0600)] <EricDalquist> since a different structure, like mobile, doesn't have the same url structure as the tab/column structure
[10:34:16 CST(-0600)] <Arvids> ok, i hope i will have some time to inspect that next week
[10:34:31 CST(-0600)] <EricDalquist> well at least we know that it is a problem
[10:35:03 CST(-0600)] <Arvids> yeah, i also did some search on google.. and it gave very little results, but there were some hints
[10:35:12 CST(-0600)] <Arvids> one is: https://issues.apache.org/jira/browse/XALANJ-2540
[10:36:13 CST(-0600)] <Arvids> http://stackoverflow.com/questions/6340802/java-xpath-apache-jaxp-implementation-performance
[10:36:43 CST(-0600)] <Arvids> the one question from stackoverflow is supporting my conclusions - XPath is slow
[10:36:47 CST(-0600)] <EricDalquist> uhg
[10:36:49 CST(-0600)] <EricDalquist> that sucks
[10:37:01 CST(-0600)] <Arvids> yes, it does
[10:37:39 CST(-0600)] <Arvids> it is very nice to write some delarative code that looks up the stuff you want... but the performance penalty is too great
[10:37:50 CST(-0600)] <Arvids> declarative*
[10:37:54 CST(-0600)] <EricDalquist> yeah
[10:38:06 CST(-0600)] <EricDalquist> the sad thing is it shouldn't be that expensive
[10:38:17 CST(-0600)] <EricDalquist> and there are alternative xpath impls for java that I'm betting are fast
[10:38:30 CST(-0600)] <EricDalquist> but last I looked jdom and dom4j are both essentially dead
[10:39:43 CST(-0600)] <Arvids> I also saw some comments saying that VTD-XML is fast, but last release was almost year ago
[10:39:50 CST(-0600)] <EricDalquist> yeah
[10:39:58 CST(-0600)] <EricDalquist> jdom looks like it just had a patch release
[10:40:19 CST(-0600)] <EricDalquist> and dom4j had its last release in april of 2010
[10:41:47 CST(-0600)] <EricDalquist> though due to cernunnous we have jdom 1.0 and dom4j 1.6.1 on the classpath
[10:42:20 CST(-0600)] * EricDalquist gets frustraited by having so many libraries that duplicate functionality in the classpath :/
[10:43:50 CST(-0600)] <Arvids> btw, do you have some ideas regarding new layout architecture?
[10:44:02 CST(-0600)] <EricDalquist> I do have some
[10:44:11 CST(-0600)] <Arvids> will it be XML-based or POJOs?
[10:44:20 CST(-0600)] <EricDalquist> pojo at the data level
[10:44:31 CST(-0600)] <EricDalquist> so create a pojo tree that stores the layout stucture
[10:44:46 CST(-0600)] <EricDalquist> layout nodes can then have true references to IPortletDefinition objects
[10:44:57 CST(-0600)] <EricDalquist> and the IPortletEntity object can be merged into the layout node
[10:45:51 CST(-0600)] <EricDalquist> the pojo structure will need to capture the different types of nodes that can exist in a DLM style
[10:46:17 CST(-0600)] <EricDalquist> folder, portlet, dlm:move, dlm:add, dlm:delete, dlm:edit
[10:46:28 CST(-0600)] <Arvids> btw, I also did some tinkering on JpaPortletEntityDao
[10:46:31 CST(-0600)] <Arvids> here´s diff: https://gist.github.com/1607439
[10:46:58 CST(-0600)] <EricDalquist> part of the goal with moving this to a pojo structure is to be able to more reasonably generate a "state key" for each layout
[10:47:00 CST(-0600)] <Arvids> it turns out that manual loop through user entities fastens the whole thing
[10:47:42 CST(-0600)] <EricDalquist> then the DLM merging logic would need to be re-written from XML based to work with the pojo setup
[10:48:22 CST(-0600)] <EricDalquist> though with the way the rendering pipeline works the DLM merging logic would hopefully become just a rendering pipeline component
[10:48:28 CST(-0600)] <Arvids> ok, i have to go now (it´s friday evening after all)
[10:48:47 CST(-0600)] <EricDalquist> heh
[10:49:05 CST(-0600)] <EricDalquist> I'll see if I can document some of these layout manager re-write ideas
[10:49:13 CST(-0600)] <Arvids> that would be nice
[10:49:30 CST(-0600)] <Arvids> we should somehow address XPath problem, too
[10:49:40 CST(-0600)] <Arvids> manual traversing is painful
[10:49:58 CST(-0600)] <EricDalquist> yeah
[10:50:53 CST(-0600)] <Arvids> ok, bye now... hope you´ll get some pull requests on monday