[prev in list] [next in list] [prev in thread] [next in thread] 

List:       barracuda
Subject:    Barracuda: Barracuda, XForms, and XMLC...
From:       Barracuda () enhydra ! org (Christian Cryder)
Date:       2001-01-31 21:00:28
[Download RAW message or body]

Hi David!

Great to see you're looking at the Barracuda stuff! Any insights you have
will be appreciated...

>   The particular area I am interested in is the Form model. In d11e, we
> have hacked XMLC to do declerative form validation. Take the following
> form for example:

I'm assuming you've looked at the form model stuff in depth enough to know
how we're approaching it. Rather than embed validation logic into the HTML
(although that could still be done) we're defining it in the Java. It's
pretty straightforward, however, and it would not be difficult to either a)
assemble form constructs declaritively (ie. from XML descriptor) or b) embed
simple validation rules into the html itself (although for philosophical
reasons I'm not real wild about this).

The thing we haven't done with the forms stuff yet is make it so that we can
repopulate and XMLC structure. This will be a lot easier, however, once we
complete the component model stuff (since then we don't really even have to
deal with the DOM)...this type of functionality is definitely on the
roadmap.

> 1. Client side JavaScript generation
> 2. Interdependency checking
>
> For the 1, we are looking at PowerForms
> (www.brics.dk/bigwig/powerforms). For 2, we are looking at the xforms
> (http://www.w3.org/MarkUp/Forms/) model defined by W3C to support the
> declarative description of validation constraint.

I'm not familiar with either of these yet, although I've heard positive
things about powerforms. Its on my list of things to look at (when, though,
is another matter *sigh* ;-)

One of the thing that I would like to do (and this is where our component
strategy is headed), is to be able to create "Client Side Components" that
could be attached as listeners to other components (like a table, form,
button, etc). When those components render and see that they have a client
side component associated with them, they would take the necessary steps to
render the client side component as well. This would make it possible to
embed client side validations from the server side...

> We are thinking about moving the underlying form model to the one
> defined in Barracuda and make this compatible with Barracuda.

This would be a good idea, I think (although I am a little biased ;-)

Kepp talking! This is good stuff!

Christian


------------------------------------------------
Christian Cryder
Application Architect, Barracuda
Lutris Technologies, Inc.
christianc@lutris.com
------------------------------------------------
       "What a great time to be a Geek"
------------------------------------------------
http://www.lutris.com ~ http://xmlc.enhydra.org
        http://barracuda.enhydra.org


> -----Original Message-----
> From: owner-Barracuda@enhydra.org [mailto:owner-Barracuda@enhydra.org]On
> Behalf Of David Li
> Sent: Wednesday, January 31, 2001 4:48 AM
> To: barracuda@enhydra.org
> Subject: Barracuda: Barracuda, XForms, and XMLC...
>
>
> Hi,
>
>   I finally get arround to check out Barracuda and I think it's pretty
> cool.
>
>   The particular area I am interested in is the Form model. In d11e, we
> have hacked XMLC to do declerative form validation. Take the following
> form for example:
>
> <form>
> <input name="email"
>        ds:pattern="\w+@\w+\.\w+" ds:required="Y">
> <input name="name"
>        ds:required="Y">
> <input name="age"
>        ds:datatype="int">
> </form>
>
> the ds: prefixed attributed are used to declare the validation
> constraints of the element. ds:pattern is a regexp pattern for the
> field. ds:required means the field is required and ds:datatype is the
> datatype of the field.
>
> While compling the documenet with XMLC, a form class is generated to
> perform the form validation at run time. The following is some example
> codes.
>
> WelcomeHTMLForm whf =
>    (WelcomeHTMLForm)FormValidatorFactory.getFormValidator(comms);
> if(whf != null) {
>    whf.validate();
>    if (whf.isValid()) {
>      // do the stuffs
>    }
> }
>
> The validator also does the form refilling with the following codes:
>
> fv = (FormValidator)comms.sessionData.get("testvalidator", null);
> if (fv != null) {
>   fv.fillHTML(welcome);
> }
>
> XMLC is definitely the big reason why this can be done. The DOM access
> to the HTML document gives the oppurtunity to perform such analysis.
>
> We are planning on extending this form validation to support the
> following:
>
> 1. Client side JavaScript generation
> 2. Interdependency checking
>
> For the 1, we are looking at PowerForms
> (www.brics.dk/bigwig/powerforms). For 2, we are looking at the xforms
> (http://www.w3.org/MarkUp/Forms/) model defined by W3C to support the
> declarative description of validation constraint.
>
> We are thinking about moving the underlying form model to the one
> defined in Barracuda and make this compatible with Barracuda.
>
> I'd like to know what the list think of this idea.
>
> Thanks.
>
> David Li
> DigitalSesame
>
> P.S. If there are enough interest, we will post a copy of our hacked
> XMLC for the list to play with.
> ------------------------------------------------------------------
> -----------
> To unsubscribe from this mailing list, send email to majordomo@enhydra.org
> with the text "unsubscribe barracuda" in the body of the email.
> If you have other questions regarding this mailing list, send email to
> the list admin at owner-barracuda@enhydra.org.

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe barracuda" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-barracuda@enhydra.org.

[prev in list] [next in list] [prev in thread] [next in thread]