Return-Path: 
 <cocoon-dev-return-15658-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 59585 invoked by uid 500); 23 Jul 2001 16:55:02 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 59572 invoked from network); 23 Jul 2001 16:55:01 -0000
From: "Torsten Curdt" <tcurdt@dff.st>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [RT] forms [long]
Date: Mon, 23 Jul 2001 18:54:37 +0200
Message-ID: <CHEGLKNOIJHFNDNBCIAJGEDCCBAA.tcurdt@dff.st>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <p04330102b781c8b0c33b@[10.0.1.123]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

> >> The problem I see is that people have developed different languages for
> >> different storage mediums, hence we have esql -> SQL DB, fp -> XML File,
> >> crudlet -> JavaBeans/JavaSpace, and many others.
> >>
> >> How do we provide a way to make a generic form handling and verification
> >> system that can easily deal with different storage?
> 
> I still think this is an important issue, that any generic form-handling
> mechanism
> for Cocoon2 should be savvy with, not everybody uses databases!!!

Well, I hear you... I see two different approaches:

1. Right now DOMObject is a class. I guess we should change
   this into an interface and a class AbstractDOMObject or DOMObjectImpl
   anyway. Now you write your own e.g. BeanDOMMapper implementing
   DOMObject. This mapper would need to specify a way to your bean
   attributes via XPath.

2. As Christian proposed we could put the binding into the instance
   data. By having different namespaces or elements we could have
   different types of mappers - something like that:

   <xform:instance>
     <order>
       <firstname><mapper:bean name="MyBean" attribute="Firstname"/></firstname>
       <lastname><mapper:fp ref="root/order/lastname"/></lastname>
     </order>
   </xform:instance>
      
> >> I am convinced XSP Actions would help.
> >
> >I was always voting for makeing the XSPEngine a component that can be
> >used not just for the generation of cocoon serverpages. I would have
> >used this engine to create some classes for my application via XSP
> >as well!! And of course it could be used easily to create XSP based
> >Actions! Just a different stylesheet and a different class name
> >convention - maybe a different output dir.
> >
> >Undreamed-of possibilities!
> 
> I cannot judge at the moment how much work it would be to implement this, I
> do not know the codebase well enough.

Me either... AFAIR Berin once stated he was thinking about redesigning the
whole compilation architecture...

Berin, maybe you already have a clue?

> >> BTW. The other big problem I am wrestling with is the thorny issue of
> >> content-logic; where the content that is displayed is intricately tied to
> >> the condition of runtime and static parameters, often in our case up to
> >> four or five levels of nested if-then-else 'statements'. We find this
> >> content-logic to be in a different realm to the underlying business-logic
> >> of the Beans, it needs to be accessible to the Content Authors as they are
> >> the ones who understand the logic and the content at the display level.
> >> This does not map nicely into the Cocoon "cleanroom" model.
> >
> >I can have a slight idea but could you give an example what type of
> >cascading logic this would be?
> 
> 
> I will give you an idea of this by showing what our StyleSheets looked
> like, then what we are replacing them with (sorry, but this is VERY
> verbose, and will be horribly wrapped!):
> 
> 
> 
> This is a snippet from our old approach, where we had to have one
> stylesheet per page (to contain content-selection logic)
> 
[snip]

AFAIU the xform spec is supposed to address this with
"8.1 Conditional Constructs For Dynamic User Interfaces".
So this will be the problem of the client or our XSLT
xform2html stylesheet.

regards
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org