On Fri, 5 Oct 2001, 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.
I'm not so enthusiastic about rewriting the sitemap engine from compiled to interpreted. Rather a new approach for the hole URIspace-/Flow-/resource-definition should be taken (as Berin proposed). > 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 ! > > 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. Yes, even for XSP I think new approaches will be better than rewrites. You know, code-to-java production was very popular those days but as with Cocoon 1.x vs. Cocoon 2.x (or better DOM vs. SAX) practice let you learn new lessons. 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 :( > > Sylvain > > > keep hacking. > > -pete > > > > -- > > peter royal -> [EMAIL PROTECTED] > > managing partners, inc. -> http://www.managingpartners.com > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
