Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: <snip/>
> > know what? you really suck at ASCII drawing ;-) Hah, I just don't have time for it these days... > Seriously, I don't see the difference between a presentation > and a view. Well, in our world, a view tells you things like, I want these 10 objects in this order arranged in a table. A presentation converts them into HTML format X or HTML format Y or PDF or whatever. > Besides, the flow of the above is really not understandable. > If you care to elaborate more, I'm all ears. Yes, sorry about that, but I think you got the gist of it. Don't have time to elaborate much... > > Though that's a quick approximation, the two main points are that > > controlling the model and controlling the presentation are two > > separate issues and the "adaptation" of the data to fit the view > > should be independent of the presentation. > > Yep, the reason for this, for example, is locale adaptation. > something > like the I18Ntransformer perfectly fits in the adaptation stage. > > > We've been able to keep conditionals and > > iterations out of the view templates. Instead there are > triggers in > > the templates that cause differing evaluations of the template > > dependant on the data and iteration is done by data > inspection: if the > > data that matches a portion of the template occurs multiple > times then > > iteration over the data is required. Our views are pretty > much dead > > simple XML. The "adaptor" is some heavyweight XSLT. > > I more and more concerned about heavyweight XSLT stuff. As much as I > would be if my core adapting technology was something > cryptical like Perl. I can understand that and I'm not necessarily big on XSLT for this kind of thing. However: it's standard, it's currently supported by Cocoon, it gets the job done. Personally, I'd prefer Lisp or Haskell, but I don't think that's going to happen! <snip/> > > Note: I keep asking for work flow capabilities above and beyond the > > Cocoon flow capabilities. The reason falls out of the > above diagram: > > for may things I want a _simple_ way of getting back and forth from > > the flow controller to the BL controller (right now it's Cocoon > > actions and business logic encoded in the sitemap). > > Why doesn't flowscript fit your needs? Well once I get to 2.1 I imagine that flowscript will manage presentation flow just fine. What I also want to do is separate work flow from presentation flow (and maybe then business process from work flow, but that's getting ahead of the game). We have different levels of concerns: how to manage a set of screens to implement a function such as "process an order" vs. "send the completed order to the boss for review". I'd like to be able to have a nice way to manage the second level of problem. Conceptually it's handled by continuations with realllllllly long life times, but you want to keep it separate from flow since you don't want continuations with realllllllly long life times hanging around in flow; you need a way to handle them like guaranteed message delivery streams (ie; persisted somewhere if need be). <snip/> > c'mon, Peter. I'm not meaning to insult everyone, but to > solve an issue > I'm having about the fact that I want a template engine that is SAX > based and works with some velocity-like syntax and XSLT fits the need > perfectly if it wasn't for the stynax. Sorry about that, I've just been around too long not to get cynical when I see new language proposals... I think Pier hit the nail on the head: XSLT isn't a templating language, it's a transformation language. Take your suggestion and invert it as has been suggested elsewhere in this thread: static templates interpreted by XSLT. <snip/> > XSLT is the right tool for what kind of person? a programmer. And not many of them either, but at least I've got more of them hanging around then I do for your new language (at the moment, maybe you'll prove me wrong)... > But it's also the tool that we suggest for creating the presentation. > And who's concer is that? the designer's! Well yes, that's a problem. So don't let the designer anywhere near XSLT, just give them a template language and let the XSLT continue to hang out on the other side of the problem... No you're going to say "that's what I just said", but there's one big difference: the template is consumed by XSLT not converted into XSLT. > What I'm advocating is: > > - XSLT as a transformer for programmers > - XSLT as a generator (templates) for designers > > This keeps concerns well separate, and shares the same > underlying engine. Ok, I finally see what you're trying to do. I'd rather have: - XSLT for programmers - static templates with Xquery like language for designers It's subtle, but I'm not drawing a distinction between generation and transformation and I'm not giving the designers a procedural/functional hybrid, (I'm giving them as little programming language as I can)... <snip/> > > Maybe you personally need to start another W3C working > > group to do this (hah!) > > nop, that's not possible. I'm not a W3C member so I can't propose any > notes, unless I'm an invited expert. > > And I think I managed to piss off too many people on the XSL WG, so > don't count on me getting invited anywhere near them :-) > > > but let's not complicate Cocoon with it until you've got a > standard to shoot at.... > > Nah, that's for whimps ;-) > Sigh, I think I'm going to take up something simple like biogenetic engineering...
