Ron,

I didn't quite follow what you were trying to convey in your example.

But I do see a great need for XML document driven forms to be edited
in Tapestry, such that the page is not statically coded against a
particular XML Schema. And I also see a need for that XML document to
be persisted in a relational database.  I have been procrastinating
how to attack this problem in Tapestry for a while now.

Maybe by throwing around some ideas here, you might get the ball
rolling towards a solution.

Ben


On Thu, Mar 31, 2005 at 11:07:19AM +0200, Ron Piterman wrote:
> 
> I am spending nowadays some time in modeling a DB Schema and building
> some elementar CRUD for it.
> 
> I noticed however that this modelling, and the later application logic
> is much redundant what XML Schemas would cover and had a small crazy (?)
> idea:
> 
> Consider an XML Schema, an XML Component specification document which
> will result in generating Tapestry components which will each validate
> to a part of this Schema, and glue together to a valid XML Document.
> 
> Somthing like, when keeping it very simple:
> 
> Schema (in this case, keeping it simple, a DTD):
> 
> <!DOCTYPE person [
> <!ELEMENT person ( first_name, middle_name?, last_name)>
> <!ATTLIST person
>       gender (male|female|other) #REQUIRED>
> ...
> 
> Components definition:
> 
> <tag name="first_name" input="text"/>
> <tag name="middle_name" input="text"/>
> <tag name="last_name" input="text"/>
> <attribute name="gender" input="select"/>
> 
> resources:
> 
> first-name=First Name
> middle-name=Middle Name
> last-name=Last Name
> gender=Gender
> gender.male=Male
> gender.female=Female
> gender.other=Other
> 
> Tapestry :
> 
> <span jwcid="@xperson:Document">
>   <span jwcid="@xperson:first_name__caption"/>:
>   <span jwcid="@xperson:first_name"/>
>   <br/>
>   ...
>   <span jwcid="@Submit" .../>
> </span>
> 
> -------------------------------
> 
> Now, using an XML schema offers much complexity of data, which can 
> nicley be used.
> 
> In the above example, a xperson:Document is used.
> 
> consider we use an xperson:Tag tag="person".
> The nested form components will add tags (first_name aso) to this Tag, 
> the Tag will validate them, and can be used as part of a document, which 
> will result in an editable list of persons...
> 
> backed with an xml layer for a relational DB (some existing open source)
> 
> So what do you think? is this too complex? will someone join?

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

Reply via email to