On Thu, 25 Oct 2001, Sylvain Wallez wrote: > > > giacomo a écrit : > > > > 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 main purpose is to switch from a code-generation approach to an > interpreted one. IMO, code generation is most usefull when the language > offers an exit point to the target language like in JSP and XSP but > unlike sitemap. XSP also can be extended using logicsheets by people > with medium XSLT knowledge.
I don't see this as the main purpose. The main purpose IMHO is to switch from a sitemap approach as it is today with many concern overlaps to a more concern separated approach with URI-maps, flowmaps, statemaps (or whatever there will be next). This means we have to decide about the architecture first. If the implementation of it will be interpreted or compiled is a question of technology to be choosen and comes at second place. > Sitemap is a different problem. It's not an optional component like XSP, > but the main processor of incoming requests. If this processor isn't > pluggable in Cocoon, this strongly reduces the possibility of trying > other approaches. The first step is thus to update it to be a > first-class component like all others in cocoon.xconf. This was done > just today (see my commit this morning). I've seen it and I like it. Good work. But now we have to stop and discuss or vote if we need an additional interpreted version of the sitemap. I think we'd better discuss how a better approach will look like and implement that architecture instead of implementing the same sitemap with the same flaws again but with a different technology. > Also, sitemap.xsl is a wonderful demonstration of what can be done in > XSLT for generating code. I was really impressed when I discovered both > the power of the sitemap langage and the way it is implemented. But it > requires strong XSLT knowledge to anybody wanting to extend it. This > again restricts the possible experiments on new approaches. Yes, of course and I (as the creator of this implementation of the sitemap) always thought it was an experiment to see how good the markup2code engine is. Nobody else had further developed the interpreted version (and in the early beginnings of Cocoon version 2 there was a interpreted version from Pier). > Having > sitemap logicsheets would have allowed this a bit, but you told once > this wasn't encouraged even if the program generator infrastructure > supports it. Can you imagine what happened then? I wasn't in the mood to support that and I'm sure many people would need the support if we encouraged peoples to use logicsheets for tha sitemap. > All this to say that the interpreted sitemap can be considered as a > starting point for the implemention of others ways of processing > requests. And since it's now pluggable through cocoon.xconf, it can > smoothly co-exist with the current compiled sitemap. As I've said above let us have the sitemap as it is today and let us join our forces on a new approach instead of building the same sitemap semantics based on a different technology. I say that also because if we need to change semantics in the sitemap we have to change it in the interpreted as well as in the compiled version. We already know how often we missed to submit changes on the esql.xsl into version 1 and version 2 cvs repos. Can you imagine that someone willing to change the semantic of the sitemap is likely to change both sitemap techonolgy pieces? No, I definitively don't like the co-existance of two semantically the same achitecture implemented with different technologies into the same system. Giacomo > Sylvain. > > > > 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]
