Joern,

I don't remember why I left with the impression that Chiba relies on
JavaScript. I am glad that it doesn't.

It is also good that both projects use JXPath for referencing the data model
(be it DOM, JavaBean or mixed).

XMLForm has a built in validation concept, currently through Schematron,
which is convenient for gradual validation (wizard type).

Timing seems to be good. Since you are planning on a new architecture for
Chiba 2, and the Cocoon community is always open for good ideas, we can
definitely help each other out.


As far as my attempts to work with Chiba people is concerned, below are some
past emails from the Cocoon mailing list. I don't have copies from the Chiba
list. This is of course irrelevant now. Let's try to see how can we work
together this time around.

http://www.mail-archive.com/cocoon-dev@;xml.apache.org/msg13653.html
http://www.mail-archive.com/cocoon-dev@;xml.apache.org/msg12676.html
http://www.mail-archive.com/cocoon-dev@;xml.apache.org/msg11174.html



Regards,

Ivelin


----- Original Message -----
From: "joern turner" <[EMAIL PROTECTED]>
To: "Ivelin Ivanov" <[EMAIL PROTECTED]>
Cc: "Ulrich Nicolas Lissé" <[EMAIL PROTECTED]>
Sent: Saturday, November 02, 2002 5:13 PM
Subject: Re: XForms contribution?


Hello Ivelin,

first of all, thanks for the quick response and your interest in Chiba.

But there are some statements in your mail that really astonished me:
you stated that you tried to contact us, but such a mail never reached
me or the mailinglist. I answer all requests and try to give anyone
feedback to whatever questions about Chiba. And, of course, i would have
been happy about such a request!

No criticism here, just try to clear this up.

Another statement of yours let me suspect that you eventually might have
mixed up Chiba with some other framework/project?: Chiba does *not* rely
on Javascript - in contrary, it lives in a pure server-side java
web-application and does not rely on any client intelligence.

But besides these misunderstandings i think that Cocoon (or better
XMLForm) and Chiba have a lot in common:
- Like XMLForm, Chiba is client-independent, although we currently only
support plain-html (without javascript) it's 'only' a matter of writing
XSLT stylesheets to transform for other clients.
- Like XMLForm Chiba does not support events, but it supports Actions
(as far as they make sense on serverside)
- we also try to adhere syntactically to the spec and by now have
updated to the last working draft
- we also take the freedom to leave out features that still feel 'weak'
namely Events and Dependency Graph evaluation. We try to build a
processor that behaves as defined by the spec without necessarily taking
the way the spec proposes.
- we build on common Apache libs like Xerces, Xalan, JXPath, Commons

The Schema2XForms generator is currently undergoing adaption to the
latest spec and comes with a supporting Ant task which allows to use it
in build scripts. I think it could be a very helpfull tool whenever you
have some existing XML Schemas and need a way to edit associated data.
It's developed under Chiba2 which is planned as a XForms processor
generator framework.

i've had no deep look at XMLForm up to now (have to change that
quickly). That may excuse my wrong term 'databean' here. i just had the
impression, that instance-data in XMLForm are normally JavaBeans that
hold the actual data (therefore 'databean').

Chiba uses DOM for instance-data but we plan to abstract this part to
support arbitrary datamodels.

I'm really looking forward to discussing things further on Cocoon-dev
and also would like to crosspost messages to our list if you don't mind.

Joern



Ivelin Ivanov wrote:
> Hi Joern,
>
> It is funny that when we started writing XMLForm for Cocoon,
> Chiba already existed. I tried to contact the Chiba group multiple times
for
> a possible cooperation, but apparently there wasn't much interest.
>
> You are correct that XMLForm is designed for client independence. It will
> work just as well for PDAs, PCs and cell phones, because it has no heavy
> requirements for the client.
> In fact there already is a contribution for VoiceXML.
>
> If I understand correctly Chiba heavily relies on JavaScript to simulate
> XForms events and actions.
>
> Cocoon XMLForm sacrifices XForms events and actions in favor of universal
> applicability.
> We simply try to comply with the XForms tagnames and model referencing,
> without going too far into implementing XForms features which have yet to
be
> proven.
> For example if you had XUL or XForms capable client you can easily
translate
> XMLForm documents into any of the two grammars.
>
>
> XML Schema -> XForms is an interesting idea which has been discussed on
the
> Cocoon list. Nothing has materialized though.
>
> Since XMLForm is much simpler of a framework than Chiba, I would like to
> hear your ideas of upgrading Cocoon to a better form handling framework.
>
> Oh, one more thing. I am not sure I understand the comment about the
> DataBean approach. XMLForm supports JavaBeans, DOM and mixed data models.
>
>
> And if you don't mind I will take this discussion to the cocoon-dev list.
I
> think others will be interested to participate.
>
>
> Looking forward to your ideas.
>
>
> Ivelin
>
>
>
> ----- Original Message -----
> From: "joern turner" <[EMAIL PROTECTED]>
> To: "Ivelin Ivanov" <[EMAIL PROTECTED]>
> Cc: "Ulrich Nicolas Lissé" <[EMAIL PROTECTED]>
> Sent: Thursday, October 31, 2002 6:38 PM
> Subject: XForms contribution?
>
>
>
>>Hello Ivelin,
>>
>>i'm very new to Cocoon but follow the development for quite a while and
>>after struggling for years with servers of all kinds i now feel to have
>>found the right one. Cocoon is really cool and i plan my future with it ;)
>>
>>please excuse that i took the direct way - wasn't sure if this topic
>>would be correctly addressed at the cocoon mailing-lists (which one?).
>> From following the discussions on the list i realized that you're
>>tightly involved with the XMLForm module in Cocoon, so i hope i bother
>>the right one ;)
>>
>>i am the founder of the Chiba project
>>(http://sourceforge.net/projects/chiba) which tries to implement a
>>XForms conformant processor for today browsers (even scriptless ones).
>>The intend is to provide a bean-like component which may be integrated
>>into arbitrary web-applications and supports a wide range of clients. It
>>uses a DOM/XSLT approach. Next release (0.7) is scheduled for November.
>>In paralell we work on a Schema2XForms generator which takes XML Schema
>>and generates complete XForms with sensible defaults for the UI.
>>
>>The idea to integrate Chiba into Cocoon is not new in our group and has
>>already successfully been done with a former version.
>>
>>XMLForm seems to have a different (DataBean) approach, but nevertheless
>>we would be happy to contribute our experience and code to the Cocoon
>>project. if you're interested, please have a look at our project page
>>and tell me what you think. Don't expect too much from the web-site but
>>i will be happy to answer all your questions.
>>
>>Regards,
>>
>>Joern Turner
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to