On Sun, 2002-04-07 at 16:17, Uli Mayring wrote: > On 7 Apr 2002, Andrew C. Oliver wrote: > > > I still think a declarative approach can be prescribed. There are > > plenty of non-declarative approaches out there, and we don't really need > > one more. One should differentiate Cocoon is a "next-generation" > > approach. Don't dirty it with a kludge. Meaning don't add something > > that is to Cocoon what JSP is to Object Oriented Programming and Java. > > ;-) > > [...] > > > > 2) reduce the creation of 'multipaths' to a minimum (a 'multipath' is > > > created when there is "more than one way to do it". It's up to *us* to > > > identify the best way to do something, it's not the user's concern!) > > > > +1 > > How does this go together? Prescribing something and reducing multipaths > will automatically induce a procedural algorithm. Declarative semantics > mean that you declare a set of rules and let the data drive the > application. The data selects the rules and a high-level processor applies > them. Thus it is the nature of declarative semantics that multipaths exist > and that the application developer has no interest in dealing with them. > Even more, he has no power to prescribe a certain path, only the data and > the rules determine solution paths. >
That was stefano's recommendation -- I quoted it. The idea is to reduce multipaths not eliminate them. *shrug* -- I took this to mean that two commands/elements/syntactical devices that do the same thing but are syntactically different are generally to be avoided where possible. I take this as a given. > What's more, the rules processor will even backtrack. That means that if > along a certain path no solution is found, it will go back to the last > choice point and try a different path. I'm not sure how useful this > paradigm is for specifying flow in a web app and whether it is even > possible. > Not sure that has to be the case. > But if you really want a "next-generation", declarative thing, then you > have to stop trying to control everything. Declarative concepts mean that > as an application developer you cannot just say "do this now" at any > arbitrary point. If you want full control and pre-determined paths, you > are probably better of with a procedural approach. > Web apps are essentially event driven. SAX is essentially event driven. Given state and user input as data why is this so different that it necessitates a procedural approach? -Andy > Ulrich > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
