Stefano Mazzocchi wrote:
if we had a unified sitemap+flowscript -> sitescript that used components *and* continuations as "native objects" of the language, would the need for separation be that high and the notion of merging the two so sinful?
I don't know.
But I would *love* to have such a "sitescript" and play with it so see how it feels... because, if you think about it, there is no way to reuse a sitemap without touching flowscript, they are interconnected... are we experiencing "overseparation of concerns" forced by the non-scriptable syntax of the sitemap?
Isn't this what httpd.conf is? If scripting is allowed, how far behind is something like mod_rewrite, setting global variables in one section to be read in another, etc.? I'm not talking about code in Cocoon core in SVN. I mean once it hits the real world and people start actually using it.
Basically, if someone on a Cocoon team doesn't get XML, they're basically useless. On the bright side, getting someone up to speed and giving them documentation on XML is trivial. The hardest part about the sitemap is just getting folks around the concepts of URI matcher->generator->transformer->serializer->back to client and URI matcher->flow function->processing->back to sitemap pipeline. This "hardest part" is not going to become substantially easier with any alternate syntax.
Explaining the XML syntax to someone has proven for me to be relatively trivial. If the person doesn't get XML, they're not touching Cocoon in the first place. Note: someone may not know XSLT but still grasp XML. Many of those same people I've been teaching Cocoon do not know how to program in Java (although they're learning). They do have a background in JavaScript though as it's hard to avoid learning it in web page development.
I like to think of the sitemap as an engine for "this is where the request goes in and here's where it comes out." Once you hit a Flow function, you've hit the first black box. (Just like components in Flow should remain a black box.) All you know is that it enters a logic segment and will "come out" in some pipeline you've specified. The fact that you are not intimately tied to what this logic does is IMHO a good thing. I do acknowledge that it would be nice to have easy access to the complete picture and easily enforce all of the possible outputs, but once you hit real logic (in any full programming language), your ability to lock things down diminishes. Currently, since the sitemap determines all outputs available to the sendPage* calls, I think this may be about as good as it's going to get. (Open to be proven wrong!)
I'm rambling now, I know. But before I finish, I just want to remind that XML is a given. It permeates everything in Cocoon. XML (well...structured content) is the pipeline. If the back-end implementation for caching, generators, transformers, serializers, etc. were ported to .Net and C#, XML would still be a given. If it were ported to C as an Apache module, XML would still be a given. One of the things I have always admired about Cocoon was this fact. Of course porting to something besides Java would be a major PITA -- especially for those of us with a few custom Java components, but I'd rather see the underlying model -- the public interface, the steering wheel, whatever you want to call it -- remain as XML. Let Flowscript be implemented in Java, JavaScript, Python, Groovy, Scheme, and whatever else a development team is used to (eventually...not necessarily right now), but leave the front door as XML.
Not because it is the most concise syntax in number of characters typed. Not because it can cover all future possibilities. Because it works. Because it's familiar. Because someone with the least skills necessary to use Cocoon, needs only know XML. Cocoon == XML. If it's not equal to XML, then why aren't we all jumping ship to Apache 2.0 filters?
My $0.02 for what they're worth. I could be wrong. I've been wrong before on many occasions...
- Miles Elam
