On Sat, 6 Oct 2001, Stefano Mazzocchi wrote: > Sylvain Wallez wrote: > > > > Peter Royal a écrit : > > > > > > At 12:31 PM 10/5/2001 +0200, you wrote: > > > >Here I have the feeling we are doing the same mistake over again: the > > > >sitemap was compiled when no hotspot tecnique was present and we had to > > > >avoid excessive use of esternal recurrent logic when we could "unroll" > > > >the tree traversal and let java execute it directly by transforming it > > > >in code. > > > > > > I think the sitemap is really metadata that configures the cocoon engine. > > > So in that respect are we mixing concerns by converting metadata into > > > program code? > > > > > > I took your previous words about the removal of hotspots and applied those > > > to our XSP pages in house. Before I was recreating the same java code > > > repeatedly. As an answer to the hotspot issue, I moved the code into a > > > separate class file with static methods, just like many of the internal > > > logicsheets. > > > > > > I mention this because maybe we could apply some of the same techniques to > > > the sitemap? Rather than generating a bunch of different methods, etc, > > > could we not just compile the sitemap to a bunch of static variables > > > (metadata) with method calls to do the actual work? Thus gaining some of > > > the benefits of hotspotting? That might provide a migration plan towards a > > > more radical design. It might also be > > > > > > As more and more people come on board using version 2, we need to protect > > > the investment people are making in the current sitemap model. At least > > > from the standpoint of providing a seamless transition to what is next, in > > > both functionality and brain power required to understand. > > > > The transition is assured by using the same syntax, and I'm not sure it > > would have to be changed with an interpreted engine. The only > > compatibility break would be for CodeFactory selectors and matchers : > > those ones would have to be rewritten as regular components. So I think > > an interpreted sitemap engine could integrate smoothly in the current > > architecture. > > Correct.
No, I don't think we should spent time and resources in an interpreted sitemap engine, but rather in a new approach for dealing with the concerns. > > > The problem is different for XSP : the language contains primitives such > > as <xsp:page language="xxx">, <xsp:logic>, <xsp:expr>, etc, which are > > inherently related to the notion of programming language. I use the same > > approach as yours for logicsheets (static methods), which along with > > XSP-code size reduction, eases debugging a lot ! > > Yes. XSP pages that contain <xsp:logic> tags will not be easily > interpretable and will remain there for back compatible issues until And <xsp:logic> are mixing concerns as well. > *everybody* agrees better solutions have emerged and all of them have > migrated to them. And thus componentizing those stuffs that might get replaced by or migrated over to other techniques is top. > > > There has been recently some long threads about alternatives to XSP, > > mostly based on introspection transformers (see also x:forge at > > opensource.bibop.it). Those may be easier to use than XSP (I wish java > > had a #LINE directive like good old C compilers to set line numbers in > > the generated class files !), but could hardly be as fast because of the > > use of introspection. > > I've worked with the people at Bibop (many of which are on this list and > one of them, Gianugo Rabellino, their former CTO, has already donated > code to us) and they showed me some numbers indicating that their > x:forge engine was actually faster than the XSP version. > > This showed me the evidence of the 'unrolled loop' thing I previously > explained. > > So, I'd remove this "hardly" and say that a component-based approach > (similar to taglibs) for dynamically created XML which uses runtime tree > traversal instead of precompilation *might well* be as faster than XSP. As faster than XSP ;) > > Ricardo, formerly senior engineer at Bibop, has already implemented an > evolution of X:Forge which is a similar approach but is entirely based > on namespace reaction. He's currently buzy doing some real-life work, > but I believe we'll have some XSP alternative (hopefully faster and > easier to use) in a short time, I'd shoot for Cocoon 2.1 Cool. Giacomo > > > > I have been enjoying the recent RT threads though. I do appreciate that > > > such discussions take place out in the openness of the dev list. Of course > > > that is what makes open source software so great :) > > > > Same here, even if time available for OSS isn't as big as I would like > > it to be :( > > :) > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
