cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject RE: [status & RT] design challenges
Date Sun, 07 Apr 2002 22:39:42 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
-- 
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message