Reading non-xml data from session with scope-generator

Hi All,
In our application we use a filter which handles authentication etc. This filter makes use of session attributes which in turn can be read by the webapplication. Now the problem was that these session attributes do not contain xml data (eg. xml Document or xml formatted strings), but just String values. For this reason I wasn't able to read these values with the scope-generator, so I made a quick (and a little dirty...) fix to it. I replaced the following line (176 in ScopeGenerator.java):

        XMLUtils.stringToSAX((String) value, "", result, false, false);

with:

        if (XMLUtils.isWellFormedXML((String) value)) {
                XMLUtils.stringToSAX((String) value, "", result, false, false);
        } else {
                XMLUtils.stringToSAX("<document>"+XMLUtils.escapeXML((String) value)+"</document>", "", result, false, false);
        }

Rebuilt the processor as a custom processor in a different package and now use this one instead of the regular scope-generator...

I don't know if there's another way to archieve this, but if not, could you please add this (or something similar) to the next release of Orbeon?

Thanks in advance,
Jasper

--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Jasper,

On Thu, Sep 17, 2009 at 9:19 AM, Jasper Linthorst
<[hidden email]> wrote: I understand the rational, but think that this could be done a bit
differently. The issue with choosing whether to generate text or XML
based on the XMLUtils.isWellFormedXML() is that this function call is
expensive and that it could lead to unexpected results in the
(unlikely) case where you expect some text, but that text just happens
to be well-formed XML. I think it would be better to make this
explicit, adding an optional <content-type> element to the scope
generator config. Accepted value would be text/plain and
application/xml. If what in the scope is a SAX store or DOM, having
text/plain would throw an error. Specifying a <content-type> would
only be useful in the case where the scope has a string, and then that
string would be interpreted according to the <content-type>. When
text/plain is specified, the document would have the form of "text
document", as described on
http://www.orbeon.com/ops/doc/reference-formats#text-documents.

Would this make sense to you? Would you be interested in implementing
something along these lines?

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
My Twitter: http://twitter.com/avernet


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Hi Alex,
I agree with you on the solution, so I fixed it accordingly...
I added an optional element called 'content-type' which controls how the value is retrieved. I used ProcessorUtils.readText function to serialize the document (an extra function which takes a Reader/String would be preferred to the current Stream parameter, but I didn't bother to change this).
If you're interested I can send you the changes or commit it to some repository... Let me know!

Jasper


-----Oorspronkelijk bericht-----
Van: Alessandro Vernet [mailto:[hidden email]]
Verzonden: do 17-9-2009 23:52
Aan: [hidden email]
Onderwerp: [ops-users] Re: Reading non-xml data from session with  scope-generator
 
Jasper,

On Thu, Sep 17, 2009 at 9:19 AM, Jasper Linthorst
<[hidden email]> wrote: I understand the rational, but think that this could be done a bit
differently. The issue with choosing whether to generate text or XML
based on the XMLUtils.isWellFormedXML() is that this function call is
expensive and that it could lead to unexpected results in the
(unlikely) case where you expect some text, but that text just happens
to be well-formed XML. I think it would be better to make this
explicit, adding an optional <content-type> element to the scope
generator config. Accepted value would be text/plain and
application/xml. If what in the scope is a SAX store or DOM, having
text/plain would throw an error. Specifying a <content-type> would
only be useful in the case where the scope has a string, and then that
string would be interpreted according to the <content-type>. When
text/plain is specified, the document would have the form of "text
document", as described on
http://www.orbeon.com/ops/doc/reference-formats#text-documents.

Would this make sense to you? Would you be interested in implementing
something along these lines?

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
My Twitter: http://twitter.com/avernet



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Jasper,

On Fri, Sep 18, 2009 at 8:04 AM, Jasper Linthorst
<[hidden email]> wrote:
>
> Hi Alex,
> I agree with you on the solution, so I fixed it accordingly...
> I added an optional element called 'content-type' which controls how the value is retrieved. I used ProcessorUtils.readText function to serialize the document (an extra function which takes a Reader/String would be preferred to the current Stream parameter, but I didn't bother to change this).
> If you're interested I can send you the changes or commit it to some repository... Let me know!

Yes, definitely, we are interested in those changes if you can
contribute them to the project.

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
My Twitter: http://twitter.com/avernet


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Hi Jasper,

On Mon, Sep 21, 2009 at 6:56 PM, Alessandro Vernet <[hidden email]> wrote:
> Yes, definitely, we are interested in those changes if you can
> contribute them to the project.

I got your pull request on GitHut, reviewed the code, made a few minor
changes (in ProcessorUtils, we didn't have a readText() method taking
a string, which I added), and pushed all of this in the main
repository. Thank you for the contribution!

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
My Twitter: http://twitter.com/avernet


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Hi all,
I'm looking for the best way to have Orbeon generate custom XHTML for XFORMS controls. So, to illustrate:

An <xforms:output id="username" value="''"/> element by Orbeon is rendered to XHTML as:

<span id="username" class="xforms-control xforms-input xforms-invalid xforms-required xforms-required-empty">
<input id="username$xforms-input-1" type="text" name="username$xforms-input-1" value="" class="xforms-input-input" />
</span>

Or something similar.

Now, I want to have different XHTML output, for example:

<input id="username$xforms-input-1" type="text" name="username$xforms-input-1" value="" class="my-own-class" />

So, I want to loose the containing span element, override the orbeon classes and specify my own class.

I could, off course, rewrite the entire XHTML output using XSLT in a pipeline, but I don't think that's an elegant option. In my opinion it would be really cool if Orbeon had ways to register custom control handlers for xforms controls, so that I could write my own serialization function for each xforms control. Could you guys let me know if this would be something you're interested in? Or if I'm off the right track? ;)

Another possibilty to fix this might lay in the implementation of XBL, but for what I've seen of it, it is not possible to rewrite the xhtml produced by the XFORMS-TO-XHTML processor. Maybe an extension function would help out here, but I'm not sure...

I'd hope to hear what you guys think is the best way to do this. In case of the first option I'd be willing to try and fix this in the code. In case of the second option, please give me some pointers in how to fix this using XBL.

Thanks in advance!

Jasper

--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Jasper,

Some flexibility would be good, but it will be a while until we can
implement something like this. Recently, we have implemented a
modified, more consistent layout for the controls (this option is
still disabled by default), and we believe improved the client-side
code as well, but these particular changes wouldn't solve your
problem.

There are some snags that could easily show up especially because of
the client-side code. For example, the client (JavaScript) needs to be
able to identify a control by id, and place MIP classes somewhere.

And you are correct to say that XBL currently doesn't solve the issue
of native controls. In the future maybe!

-Erik

On Fri, Sep 25, 2009 at 3:59 AM, Jasper Linthorst
<[hidden email]> wrote:

--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Hi Erik,
Thank you for your reply. I understand that having custom Xform*handlers could easily break pretty much all functionality offered by Orbeon forms. However since we use Orbeon in no-script mode (and use custom css), my belief is that things (in our case) shouldn't necessarily have to be that hard...

A smaller feature, that would help us a great deal in styling our webapplications without entirely rewriting the XHTML output, would be the ability to specify custom classes on form elements. Say for example the implementation of xxforms:additional-class and xxforms:exclusive-class extension attributes on xforms elements. I did a quick fix in my own checkout of the Orbeon code and it would help us a great deal if functionality like this would ever make it to the official Orbeon distribution.

So, what i did:

<xforms:input id="username" value="''" xxforms:additional-class="singleline"/>

Now renders to something like:

<span id="username" class="xforms-control xforms-input xforms-invalid xforms-required xforms-required-empty">
<input id="username$xforms-input-1" type="text" name="username$xforms-input-1" value="" class="xforms-input-input singleline" />
</span>

And:

<xforms:input id="username" value="''" xxforms:exclusive-class="singleline"/>

Now renders to:

<span id="username" class="xforms-control xforms-input xforms-invalid xforms-required xforms-required-empty">
<input id="username$xforms-input-1" type="text" name="username$xforms-input-1" value="" class="singleline" />
</span>


Pls let me know how you feel about these changes, so that I can contribute them back through github if you're interested.

Regards,
Jasper


-----Oorspronkelijk bericht-----
Van: [hidden email] namens Erik Bruchez
Verzonden: di 29-9-2009 23:04
Aan: [hidden email]
Onderwerp: [ops-users] Re: Custom XHTML output for XFORMS elements
 
Jasper,

Some flexibility would be good, but it will be a while until we can
implement something like this. Recently, we have implemented a
modified, more consistent layout for the controls (this option is
still disabled by default), and we believe improved the client-side
code as well, but these particular changes wouldn't solve your
problem.

There are some snags that could easily show up especially because of
the client-side code. For example, the client (JavaScript) needs to be
able to identify a control by id, and place MIP classes somewhere.

And you are correct to say that XBL currently doesn't solve the issue
of native controls. In the future maybe!

-Erik

On Fri, Sep 25, 2009 at 3:59 AM, Jasper Linthorst
<[hidden email]> wrote:

--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Jasper,

On Thu, Oct 1, 2009 at 2:05 AM, Jasper Linthorst
<[hidden email]> wrote: If you just add a class attribute, say: <xforms:input class="gaga">,
than that class is carried to the span around the control. You can
then style the input with:

.gaga input {...}

Would that be good enough?

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
My Twitter: http://twitter.com/avernet


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Thanks Alex, for your reply, but this doesn't really suit our needs, since we have to comply with the html that's delivered by our interaction designers. This html does not contain span elements for form controls and so on... I'm afraid that we just have to conclude that it's not possible for now to have Orbeon deliver fully compliant xhtml.

Jasper

-----Oorspronkelijk bericht-----
Van: Alessandro Vernet [mailto:[hidden email]]
Verzonden: di 6-10-2009 3:24
Aan: [hidden email]
Onderwerp: [ops-users] Re: RE: Re: Custom XHTML output for XFORMS elements
 
Jasper,

On Thu, Oct 1, 2009 at 2:05 AM, Jasper Linthorst
<[hidden email]> wrote: If you just add a class attribute, say: <xforms:input class="gaga">,
than that class is carried to the span around the control. You can
then style the input with:

.gaga input {...}

Would that be good enough?

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
My Twitter: http://twitter.com/avernet



--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Jasper,

On Tue, Oct 6, 2009 at 2:08 AM, Jasper Linthorst
<[hidden email]> wrote:
>
> Thanks Alex, for your reply, but this doesn't really suit our needs, since we have to comply with the html that's delivered by our interaction designers. This html does not contain span elements for form controls and so on... I'm afraid that we just have to conclude that it's not possible for now to have Orbeon deliver fully compliant xhtml.

You are interested in this to make sure that the XHTML you produce is
compliant? Having a <span> around the <input> doesn't break
compliance, as far as I can tell.

(And <input> is in the "phrasing content" category [1], and the
content of a <span> can be "phrasing content" [2].)

[1] http://www.w3.org/TR/html5/forms.html#the-input-element
[2] http://www.w3.org/TR/html5/text-level-semantics.html#the-span-element

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
My Twitter: http://twitter.com/avernet


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Alex,
Sorry, you got me wrong. I didn't mean to say that the output isn't  
xhtml compliant. I meant that we're unable to fully comply with the  
xhtml that our interaction designers come up with. The way we work is  
that we have interaction designers to come up with a frontend/
prototype for the application, which we, as application developers,  
use to start off our development cycle. Right now, either css or  
Orbeon's resulting xhtml, has to be rewritten afterwards. Another  
advantage of having more control over the output would be the fact  
that our xhtml has to meet up with some additional guidelines (like  
wcag etc.), and we don't want to bother our application developers  
with these things.

Hope you see why this is important to us.

Anyway, thanks,
Jasper

On 9 okt 2009, at 21:13, "Alessandro Vernet" <[hidden email]> wrote:


--
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
OW2 mailing lists service home page: http://www.ow2.org/wws

Jasper,

Got it. Flexibility would be nice, but such a change would require
some extra thinking and work.

-Erik

On Sat, Oct 10, 2009 at 8:09 AM, Jasper Linthorst
<[hidden email]> wrote:

--
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
OW2 mailing lists service home page: http://www.ow2.org/wws