I am developing a generic form in which contrls (textbox,dropdown,datefiled etc...) are created dynamically based on xml input given in xml file.
I could differenciate control based on type (input,select1,date etc..) . If the type is date I could not bind it in my xhtml body. As the binding is required at model itself.
Is there any way to bind dynamically xs:date to a node. In my xhtml I am displaying contols as
<xforms:repeat nodeset="instance('main-instance')/result/report/filters/filter" >
<xforms:group ref=".[type = 'input']"> <xforms:output ref="name"/> <xforms:input ref="name"/>
</xforms:group>
<xforms:group ref=".[type = 'select1']"> <xforms:output ref="name"/> <xforms:select1 ref="name">
............
............
</xforms:select1>
</xforms:group>
<xforms:group ref=".[type = 'date']">
<xforms:output ref="name"/> <xforms:input ref="name" />
</xforms:group>
</xforms:repeat>
In my model I tried
<xforms:bind id="filterdate" nodeset="instance('main-instance')/result/report/filters/filter/name" type="xs:date" relevant="//filters/filter/type = 'date'" />
but date filed appears for every control.
@relevant is relative to the bind statement
The first problem you have is that you are using a
@relevant;value that is based on the entire instance data, and not on each node you are processing. So although your@nodesetexpression is selecting all filters, you have said that each filter is relevant if there is any filter, anywhere in the instance data, that has atypevalue ofdate. In other words, you might as well have written this:<xf:bind id="filterdate" nodeset="instance('main-instance')/result/report/filters/filter/name" type="xs:date" relevant="true()" />(This is what Paul was getting at in his reply.)
However, since the
@relavantexpression is evaluated 'relative' to each iteration of@nodesetthen you can set the relevant value for each filter, based on its data type, like this:<xf:bind id="filterdate" nodeset="instance('main-instance')/result/report/filters/filter/name" type="xs:date" relevant="../type = 'date'" />Since the filter is separate from its name, it might be better to do this:
<xf:bind id="filterdate" nodeset="instance('main-instance')/result/report/filters/filter" type="xs:date" relevant="type = 'date'" />And then ensure that when you use the nodeset 'filterdate', you obtain the name:
<xf:repeat bind="filterdate"> <xf:output ref="name"> ... </xf:output> </xf:repeat>The second problem you have is that your
bindstatement is actually giving the date datatype to all of your filters, and then making only the date ones relevant. When something is non-relevant it is effectively hidden throughout the document, anywhere that it appears, so instead, you want to select only those filters that have a date type, give them thexs:datedatatype, and drop the relevance part altogether. Your current code would need to change to look like this:<xf:bind id="filterdate" nodeset="instance('main-instance')/result/report/filters/filter[type = 'date']/name" type="xs:date" />Or if you decided to use the filters themselves, rather than the filter names, then you would do this instead:
<xf:bind id="filterdate" nodeset="instance('main-instance')/result/report/filters/filter[type = 'date']" type="xs:date" />Regards,
Mark
--
Mark Birbeck, formsPlayer
http://www.formsPlayer.com | http://internet-apps.blogspot.com
standards. innovation.
thanks
hi Mark Birbeck ,
my problem got solved with your clarification
<xf:bind
id="filterdate"
nodeset="instance('main-instance')/result/report/filters/filter[type = 'date']/name"
type="xs:date"/>
thanks & regards
Subrahmanyam.
Use bind with nodeset and type
In order to bind a type to a node, without using a schema, you need to use the type attribute on the bind element, as you are doing, to specify the schema type you wish apply. and you need to specify an XPath expression in the corresponding nodeset attribute that specifies those nodes to which you wish to apply the schema type.
It may help if I describe what is happening in the example you give:
Selects all nodes in your instance document that can be found by the path: "instance('main-instance')/result/report/filters/filter/name", then, to each of these nodes, it does two things:
If that is not the desired behaviour, then you will need to modify your XPath expressions accordingly.
what are the changes required for dynamically binding nodes
Thanks for your reply.
I am getting dynamically nodes in which control name & type is specified. If the type is 'date' it should bind to a calendar(I am using orbeon calender) Its binding type xs:date. If it type is not date then it should be textbox or select1 based on type.
Where I have to change xpath.My input is
<filters> <filter> <name>Processes</name> <type>input</type> </filter>
<filter>
<name>Status</name>
<type>select1</type>
<data>
<value>Starated</value>
<value>Ended</value>
<value>Suspended</value>
</data>
</filter>
<filter>
<name>Starttime</name>
<type>date</type>
</filter>
</filters>
if i change mode like the following no control is displaying
<xforms:bind id="filterdate" nodeset="instance('main-instance')/result/report/filters/filter/name" type="xs:date" relevant="instance('main-instance')/filters/filter/type = 'date'" />
Subrahmanyam
dynamically binding nodes
Hi Subrahmanyam
I am working on XForms and calendar controls at this point of time. However I am planning to do exactly what you have achieved- which is using an xml file, eXist Database/Rest API. I am a newcomer to XForms and how did you achieve this? I am not sure of the approach I need to take. I would be very appreciative of your inputs on this issue. I am willing to share any source code that I have with you if that will help you further in your development efforts.
ilango
I found the limitations of
I found the limitations of using beta software for demonstrations in this tutorial. This time however, I decided not to wait for a more stable version of the Mozilla XForms plugin. Instead, I accept a little unstable behavior and a few bugs and promise to fix example code later when needed. The example in part 3 stopped working in the latest version of the XForms plugin. This is fixed when the final plugin is released. For now, I hope you'll understand the examples with a few shortcomings.
In part 3 you may have noticed this tutorial will never make it in the "XYZ for Dummies" series. I prefer to dive straight into the advanced concepts. Part 3 introduced grouping and repeating elements. By now, you should have a basic feeling of the XML oriented nature of XForms and the dynamic response of the user interface to changes in the source document.
In this part, part 4, dynamic behavior of XForms is pushed to the limits. This post demonstrates the use of the xf:bind element for declarative specification of business logic. We start using CSS style sheets to specify layout. Data sources are stored in separate XML files. Both the source document and the interface become bilingual. Resource bundles are used for translation, separating model and content and preventing duplication. Bindings are used for hiding irrelevant elements and constraining input values.
The more I work with XForms, the more I realize how complex they really are. Considering the fact that XForms are the replacement for classic HTML forms in XHTML 2, I have my doubts that XHTML 2 will ever replace HTML 4. I am curious whether companies like Macromedia will be able to offer easy and user friendly XForms editors in products like Dreamweaver. Nevertheless, I am convinced that software developers and professional web designers will appreciate the advantages of XHTML 2 and push XForms in major web sites just like AJAX is pushed right now. After all, AJAX is no easier than XForms but it is widely adopted to enhance rich user interfaces in many web sites.
The Eclipse Apogee XForms implementation
Another promising development is the adoption of XForms outside web browsers. I found a proposal for an XForms implementation in Eclipse, called Apogee. Eclipse is an IDE (integrated development environment) for Java developers. There is also a stripped version of Eclipse which serves as a platform for building Rich Client applications in Java using native GUI controls while remaining reasonably platform independent. The Eclipse GUI framework is called SWT. The Apogee project proposal intends to extend Eclipse RCP (rich client platform) with components like a calendar, rich text editors (Office, XHTML) and XML support (XSD, SOAP, XForms).
If this proposal is accepted by the Eclipse project, this means a great step forward in the development of client side business applications in Java. XForms provide major productivity improvements in the development of form based programs. An application providing both a rich client interface and a web based interface could use the same XForms document for both the web and the client. XML oriented interfaces are no longer limited to web based implementations. This could mean the end of one-on-one binding of GUI elements to database fields.
The current alpha implementation still lacks some key XForms concepts but looks promising. I hope the developers don't underestimate the effort required for a full and stable XForms implementation. But judging the quality of current official Eclipse subprojects, Apogee might become one of the best implementations available. If you're interested, take a look at the project page. For testing the first milestone, you need to connect to the Subversion code repository and compile the plugins yourself. Some Java experience is required to do this.
But enough with the introductions. Let's get to the real content...
Introduction to part 4
My employer wants me to keep my resume up to date in both Dutch and English. This means a lot of overhead, because every change should be processed in two documents. A large part of the documents are copies. The header texts are different. A few fields like function title and description are different. But many fields are the same in both languages. My name, birth date, company names and start and end dates are identical. Wouldn't it be nice if I could edit a single document to change my resume in both languages?
That's exactly what we're going to do in part 4 of the XForms tutorial. Header texts and list values are externalized to resource bundles. A few fields are duplicated so they can be filled out in both languages. Source documents are extracted to separate XML documents. Style and layout are specified in an CSS stylesheet. And there is a new button to switch between English and Dutch without using any server side code.
The example in part 3 had an annoying shortcoming. If you deleted all work experiences, the document was unable to create a new work experience. Part 4 demonstrates how XForms bindings can be used to work around this problem.
The example is available online under the following URL. If you want to experiment with the code and modify it, you can download a ZIP file containing all files required by the XForms document. In part 3, the complete example was contained in a single file. From now on, the examples are separated over a set of files. To run the examples, you require Mozilla 1.5 and the latest version of the Mozilla XForms plugin. The examples are not tested in other XForms implementations.
Specifying declarative binding logic
Classic programming paradigms require software developers to implement algorithms telling the computer exactly what to do. As applications grow, developers should find clever ways to support additional features without duplicating code. Code duplication harms maintainability of the software. The clever ways around duplication often harm readability of the code.
In modern software development, developers no longer specify *what* to do or *how* to do it. Instead, they specify a model of their problem and expect their software to interpret the model automatically and provide answers as they are queried. The *what* and *how* are preconfigured under the hood and may be replaced by an alternative implementation without affecting the model specification. An early effort in this direction was PROLOG. PROLOG allows users to input a set of logical constraints. The constraints are supposed to represent a simplified model of reality. The user can ask questions to PROLOG which are automatically answered given the constraints. Because PROLOG is designed to solve logical problems, it is easily capable of providing the answer to a logical quiz from a news paper. As the complexity of the logical model grows, there is a risk of run times for solving problems. After all, the user can only influence the model specification, not the solving algorithm.
After PROLOG, many other products were developed using declarative model specifications for both answering questions or describing the behavior of user interfaces. Most of these products are targeted at a very specific problem domain. Limiting the problem domain allows more adequate solutions for those specific problems.
XForms is an example of such a declarative solution. The domain is XML based Forms. It is very powerful as long as you are developing a form and as long as it is based on XML. As soon as you want to use the technique for any other purpose, it is nearly impossible to get a working result.
The declarative nature of XForms is recognized when you compare them to classical HTML forms. If you want to add any business logic to a classic HTML form, you are forced to implement tiny procedures in JavaScript. Where JavaScript code is error prone and differs between browsers, XForm models will be portable as XForms implementations mature.
The xf:bind tag
The xf:bind tag is one of the most versatile elements available in XForms. It is used for specifying almost any business logic in a form. A rough list of capabilities is:
item type specification
required element or attribute specification
disabled element or attribute specification
dynamic calculation of values
specification of relevance of an element or attribute
constraining values
binding nodes or nodesets to IDs
What makes the xf:bind tag even more powerful, is that each of these functionalities is not limited to a single node, but may involve a set of elements. These nodesets are not limited to sets of siblings but may consist of elements anywhere in the source document. XPath queries are used for referencing nodes or node sets. When your experience with XPath grows, you'll find it to be a very powerful way for accessing nodes even in the most complex XML structures.
As any other XForms element, xf:bind dynamically responds to changes in the source documents. In beta implementations of XForms you might find some quirks and bugs in this behavior, but I'm convinced these will be fixed in the final version.
Binding item types
When you're using xf:input elements referring to source document elements, you'll see text input fields in the resulting documents. For specific elements like a birth date, you would expect to use something like an xf:dateInput or an xf:input type="date". In XForms this is a little different. In your xf:model you specify an xf:bind ref="..." type="xs:date" and the input field automatically changes to a date chooser in the resulting document.
By binding elements to XSD item types, XForms decides which view is required for the input element. If the source document element is referenced by more than one input, the item type needs to be specified only once. This prevents duplication and therefore improves maintainability which is important in software development.
Talking about duplication, I was a little bit disappointed that XForms required me to specify the item type in an xf:bind tag. After all, I took the effort to provide a complete XSD XML Schema file for all source documents. XForms seems to offer additional tags to explicitly refer to such XSD files. In the current implementation I was unable to bind an item type without using the xf:bind tag though.
more info in : blog.adriaandejonge.eu/2006/05/xforms-tutorial-part-4-declarative.html
____________________________
Submited by : Caballos