select1 vanishing

I'm trying to render a select1 control, but whenever I load the view  
it briefly shows my radio buttons, but then they vanish in less than  
a second.  The only thing I can detect different about my usage from  
the standard xforms-control example is that I have multiple  
instances.  Below is the code I'm using:

       <xforms:instance id="controls-instance">
         <controls xmlns="">
           <import>url</import>
         </controls>
       </xforms:instance>

....

         <xforms:group ref="instance('controls-instance')">
           <xforms:select1 ref="import" appearance="full">
             <xforms:item>
               <xforms:label>Upload File</xforms:label>
               <xforms:value>upload</xforms:value>
             </xforms:item>
             <xforms:item>
               <xforms:label>URL to XML</xforms:label>
               <xforms:value>url</xforms:value>
             </xforms:item>
           </xforms:select1>
         </xforms:group>

If it helps to know what I'm trying to do, my intent is to set up two  
radio buttons where the user may choose between editing a file from  
their local file system (upload) or editing a remote file (url).  
When one is selected, the appropriate related controls for upload or  
url loading will be enabled.  Can anyone see why my radio button  
controls vanish?

Duane Gran



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 4/4/06, Duane Gran <[hidden email]> wrote:
> If it helps to know what I'm trying to do, my intent is to set up two
> radio buttons where the user may choose between editing a file from
> their local file system (upload) or editing a remote file (url).
> When one is selected, the appropriate related controls for upload or
> url loading will be enabled.  Can anyone see why my radio button
> controls vanish?

Duane,

Multiple instances should not have an impact here. Could it be that
the node the select1 or the enclosing group is bound to becomes
non-relevant?

Alex
--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On Apr 4, 2006, at 9:34 PM, Alessandro Vernet wrote:
Alex,

I wrote too soon.  I reloaded the page (shift-reload) and now the  
radio buttons appear.  On my earlier attempts I had the the ref  
attribute incorrect and it appeared to be a browser cache issue.

Duane



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi,

I have been looking at different ways to integrate OPS with Java
code. We would basically like to produce the xforms:instance XML from
either a plain class or servlet which has the HTTP request parameters
available to it.

This is what I have been trying so far; we are using page flow
controller with the default-submission to
pass along HTTP request parameters:

    <page path-info="/alerts"
             model="oxf:/xhtml/alerts/alerts-model.xpl"
             default-submission="oxf:/xhtml/alerts/alerts-submission.xml"
             view="oxf:/xhtml/alerts/alerts.xhtml">
        <setvalue ref="/submission/patientId" parameter="patientId"/>    
     
    </page>

So this means I have the submission.xml describing the parameters:
    <submission>
        <patientId/>
    </submission>

And in the view I use xinclude
    <xf:instance id="alerts-instance" xmlns="">
        <xi:include href="input:data"/>
    </xf:instance>

In the XPL file I have experimented with a few different processors:

    <p:processor uri="oxf/processor/xslt-2.0">
         <p:input name="data" href="#instance"/>
        <p:input name="config">
            <result xmlns="" xsl:version="2.0">
                <delegation:execute service="alerts-command"
operation="execute">
                    <param1 xsi:type="xs:string"><xsl:value-of
select="/submission/patientId"/></param1>
                </delegation:execute>
            </result>          
        </p:input>
        <p:output name="data" id="call"/>
    </p:processor>

    <p:processor name="oxf:delegation">
        <p:input debug="true" name="interface">
            <config>
                <service id="alerts-command" type="javabean"
class="AlertsCommand"/>
            </config>
        </p:input>
        <p:input debug="true" name="call" href="#call"/>
        <p:output debug="true" name="data" ref="data"/>
    </p:processor>

This isn't quite right because the result from my method call is an
XML String but this value gets escaped '<alerts/>' => 'lt;alertsgt;' I
would rather just have verbatim xml string returned. I tried the
style="document" but I think this only works for web service delegations?

I have also tried the servlet-include-generator, which your
documentation page has called 'servlet-include' (doesn't work as the name).

    <p:processor uri="oxf/processor/xslt-2.0" >
         <p:input name="data" href="#instance"/>
        <p:input name="config">
            <config xsl:version="2.0">
                <path>/alerts/alerts.xml?<xsl:value-of
select="/submission/patientId"/></path>
            </config>
        </p:input>
        <p:output name="data" id="path"/>
    </p:processor>
   
    <p:processor name="oxf:servlet-include-generator">
        <p:input name="config" href="#path"/>
        <p:output name="data" ref="data"/>
    </p:processor>

Is there a better way to manage the HTTP parameters? I would
prefer passing off the HTTP request that page flow controller recieves
straight to the servlet that generates the model. Feels like I'm
missing something, turning the parameters into XML just to XSL them
back into a HTTP request?

What's the most straightforward/standard way of handling request
parameters with page flow controller and generating the XML model with
servlets or plain classes?

Would it be better to directly serve the parameter driven request with a
servlet which then redirects to
page flow controller with an external xml submission and then basically
link the submission instance directly to the model?
But that doesn't sound like the standard way to do it with page flow
controller.

Appreciate any feedback.

thanks,
Gary




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Gary Moselen wrote:
I just realized I don't need to include the request parameters on the
path with the servlet-include generator. I don't know how I missed this...

    <p:processor name="oxf:servlet-include-generator">
        <p:input name="config">
            <config xsl:version="2.0">
                <path>/alerts/alerts.xml</path>
            </config>
        </p:input>
        <p:output name="data" ref="data"/>
    </p:processor>

public class AlertsServlet extends OrdersServlet {

    public void doGet(HttpServletRequest request, HttpServletResponse
response) throws IOException {
       
        System.out.println("SERVLET" + request.getParameter("patientId"));
        System.out.println("SERVLET" + request.getParameter("foo"));

This seems to work fine without messing around with default-submission
documents and parameters.

Gary






--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 4/5/06, Gary Moselen <[hidden email]> wrote:
> I just realized I don't need to include the request parameters on the
> path with the servlet-include generator. I don't know how I missed this...
> [...]

Hi Gary,

Using the servlet-include-generator looks like a good solution.
Another solution, which is not necessarily better, is to use XForms to
do the initial request to your servlet:

1) You keep the default-submission in your page flow.
2) You remove the model XPL and keep only the view.
3) In the view, you insert an instance with the patientId. The
alerts-instance instance initially contains a "dummy" document:

    <xforms:instance id="alerts-submission">
        <xi:include href="input:instance"/>
    </xforms:instance>

    <xforms:instance id="alerts-instance">
        <dummy/>
    </xforms:instance>

4) On XForms initialization, you submit alerts-submission to your
servlet and put the result in alerts-instance:

<xforms:submission id="init-submission" action="url to servlet"
method="get" ref="instance('alerts-submission')" replace="instance"
instance="alerts-instance"/>
<xforms:send ev:event="xforms-ready" submission="init-submission"/>

This submission will happen on the server side, before the page is
first sent to the user, so the end result from the user's perspective
will be the same.

Alex
--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws