You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by oceatoon <t....@systheo.com> on 2005/02/25 18:43:27 UTC
JX generates weird NameSpace???
Hi everyone
Is anybody aware of such a thing as JX generating a weirds namespaces??
<head xmlns:%@$#^@#="%@$#^@#">
weird !! and blocking...grrrr
This seems to happen only on a cforms / jx mixed page, I tested simple jx is
ok.
Offcourse this is blocking all following transformations
I'd really appreciate any info on this coz this busts my forms ;-)
Best Regards
Tibor
Re: JX generates weird NameSpace???
Posted by Juan Jose Pablos <ch...@apache.org>.
Sylvain Wallez wrote:
> oceatoon wrote:
>
>> Hi everyone
>> Is anybody aware of such a thing as JX generating a weirds namespaces??
>> <head xmlns:%@$#^@#="%@$#^@#">
>> weird !! and blocking...grrrr
>>
>> This seems to happen only on a cforms / jx mixed page, I tested simple
>> jx is
>> ok.
>>
>>
>
> Fixed. The problem comes from the fact that including macros starts some
> prefix mappings and ends them with no elements inbetween, and this seems
> to confuse Xalan a lot. This was a blocker for Ajax-in-CForms as
> Firefox's parser was failing on error when encountering this namespace.
nice one!!!!
Re: JX generates weird NameSpace???
Posted by Sylvain Wallez <sy...@apache.org>.
Ben Pope wrote:
> Sylvain Wallez wrote:
>
>> oceatoon wrote:
>>
>>> Hi everyone
>>> Is anybody aware of such a thing as JX generating a weirds namespaces??
>>> <head xmlns:%@$#^@#="%@$#^@#">
>>> weird !! and blocking...grrrr
>>>
>>> This seems to happen only on a cforms / jx mixed page, I tested
>>> simple jx is
>>> ok.
>>>
>>>
>>
>> Fixed. The problem comes from the fact that including macros starts
>> some prefix mappings and ends them with no elements inbetween, and
>> this seems to confuse Xalan a lot. This was a blocker for
>> Ajax-in-CForms as Firefox's parser was failing on error when
>> encountering this namespace.
>>
>> I added a o.a.c.xml.RedundantNamespacesFilter class that filters the
>> output of JXTG to ensure namespaces are not mulitply declared and
>> that empty namespaces scopes are filtered out.
>
>
> Could this be made into a transformer and still used for it's given
> purpose?
>
> Or perhaps wrap it with a transformer?
>
> Seems to be that would make a pretty useful transformer... much of
> what I output as xhtml has redundant namespaces and fails validation.
>
> I've had a little look at the source, and it seems that it would not
> require much work to have that as a transformer.
IMO it shouldn't be made a transformer, but the underlying
NamespaceSupport class should be used in every transformer to handle
start/stop prefix mapping.
I plan to refactor it so that it's easier to use and also to filter out
namespaces a transformer is supposed to consume (e.g. i18n, ft,
xinclude, etc).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: JX generates weird NameSpace???
Posted by Ben Pope <be...@gmail.com>.
Sylvain Wallez wrote:
> oceatoon wrote:
>
>> Hi everyone
>> Is anybody aware of such a thing as JX generating a weirds namespaces??
>> <head xmlns:%@$#^@#="%@$#^@#">
>> weird !! and blocking...grrrr
>>
>> This seems to happen only on a cforms / jx mixed page, I tested simple
>> jx is
>> ok.
>>
>>
>
> Fixed. The problem comes from the fact that including macros starts some
> prefix mappings and ends them with no elements inbetween, and this seems
> to confuse Xalan a lot. This was a blocker for Ajax-in-CForms as
> Firefox's parser was failing on error when encountering this namespace.
>
> I added a o.a.c.xml.RedundantNamespacesFilter class that filters the
> output of JXTG to ensure namespaces are not mulitply declared and that
> empty namespaces scopes are filtered out.
Could this be made into a transformer and still used for it's given purpose?
Or perhaps wrap it with a transformer?
Seems to be that would make a pretty useful transformer... much of what
I output as xhtml has redundant namespaces and fails validation.
I've had a little look at the source, and it seems that it would not
require much work to have that as a transformer.
I did give it a go, but didn't know what to put in the setup method and
wound up with a NPE.
Ben
Re: JX generates weird NameSpace???
Posted by Sylvain Wallez <sy...@apache.org>.
oceatoon wrote:
>Hi everyone
>
> Is anybody aware of such a thing as JX generating a weirds namespaces??
><head xmlns:%@$#^@#="%@$#^@#">
>
>weird !! and blocking...grrrr
>
>This seems to happen only on a cforms / jx mixed page, I tested simple jx is
>ok.
>
>
Fixed. The problem comes from the fact that including macros starts some
prefix mappings and ends them with no elements inbetween, and this seems
to confuse Xalan a lot. This was a blocker for Ajax-in-CForms as
Firefox's parser was failing on error when encountering this namespace.
I added a o.a.c.xml.RedundantNamespacesFilter class that filters the
output of JXTG to ensure namespaces are not mulitply declared and that
empty namespaces scopes are filtered out.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: JX generates weird NameSpace???
Posted by oceatoon <t....@systheo.com>.
Thanks Jean-Baptiste
> * oceatoon:
>
>> Is anybody aware of such a thing as JX generating a weirds
>> namespaces?? <head xmlns:%@$#^@#="%@$#^@#">
>
> Yes, and this has already been reported.
>
> But AFAICT it is *not* blocking. You may be facing another
> problem without any relation to this namespace oddity.
Well not entireley blocking,
but I'm trying to do some cleaning up on the forms styling xsl files and
this causes my XSL transformation to bust, or at least to not go to the end
of thing in <head >
any ideas to how I could work around this by any chance?
Thanks
Tibor
Re: JX generates weird NameSpace???
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> Somewhat OT, but I really do't think we should do any work on the
>> original JXTG. It's better to remove it and focus on the refactored
>> one. Even if we not have finished the refactoring of the internal
>> APIs, that's no reason for keeping the original one.
>>
>> What's left to do for switching to the refactored one is to make the
>> environment handling back compatible. The environment in the
>> refactored is built above o.a.c.environment.TemplateObjectModelHelper
>> while the original is built on
>> o.a.c.components.flow.javascript.fom.FOM_Cocoon. What needs to be done
>> is basically to embed the Request object in the
>> TemplateObjectModelHelper with a FOM_Request from FOM_Cocoon etc.
>>
>> We should definately do something about the enviroment handling in
>> general in Cocoon, with Acessors or something similar, but for the
>> time being we should get rid of the original JXTG so no one feel
>> tempted to start parallel development on it.
>
> We could already do it in 2.2. I think there are so many samples out
> there that there will be not much work tracking the incompatibilities.
I added the FOM wrappers in the TemplateObjectModelHelper. It breaks two
test cases that uses #{$cocoon/request/protocol}, but these doesn't work
in the original JXTG either.
Now the question is if this is the correct behaviour, according to the
documentation
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#Expression+Languages,
it seem like the get methods in the request object should be accessible
as properties. In the refactored FOM_Cocoon in
AttributeHolderJavaObject.get (super class of FOM_Request etc), the
property access is explicitely turned of for methods. The old FOM_Cocoon
code before the refactoring behaved in the same way IIUC. Is the
documentation wrong?, has it been all the time?
I didn't add the request etc properties whithout Cocoon prefix, as these
according to the documentation has been deprecated for ever. And as we
have the same behaviour for flow and non flow use of the refactored JXTG
they are not needed any more. They are of course easy to add if anyone
find them important.
/Daniel
Re: JX generates weird NameSpace???
Posted by Leszek Gawron <lg...@apache.org>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>
>> oceatoon wrote:
>
> <snip/>
>
>>> Is this a difficult hack or have you done this ? I haven't really
>>> touched
>>> any core generators (no need :-) but it's never to late
>>>
>>> Thanks for the help
>>
>>
>> It shouldn't be that difficult to fix.
>>
>> Should we track all namespace redefinitions?
>
>
> Somewhat OT, but I really do't think we should do any work on the
> original JXTG. It's better to remove it and focus on the refactored one.
> Even if we not have finished the refactoring of the internal APIs,
> that's no reason for keeping the original one.
>
> What's left to do for switching to the refactored one is to make the
> environment handling back compatible. The environment in the refactored
> is built above o.a.c.environment.TemplateObjectModelHelper while the
> original is built on o.a.c.components.flow.javascript.fom.FOM_Cocoon.
> What needs to be done is basically to embed the Request object in the
> TemplateObjectModelHelper with a FOM_Request from FOM_Cocoon etc.
>
> We should definately do something about the enviroment handling in
> general in Cocoon, with Acessors or something similar, but for the time
> being we should get rid of the original JXTG so no one feel tempted to
> start parallel development on it.
We could already do it in 2.2. I think there are so many samples out
there that there will be not much work tracking the incompatibilities.
--
Leszek Gawron MobileBox
lgawron@apache.org http://www.mobilebox.pl
Re: JX generates weird NameSpace???
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> oceatoon wrote:
<snip/>
>> Is this a difficult hack or have you done this ? I haven't really touched
>> any core generators (no need :-) but it's never to late
>>
>> Thanks for the help
>
> It shouldn't be that difficult to fix.
>
> Should we track all namespace redefinitions?
Somewhat OT, but I really do't think we should do any work on the
original JXTG. It's better to remove it and focus on the refactored one.
Even if we not have finished the refactoring of the internal APIs,
that's no reason for keeping the original one.
What's left to do for switching to the refactored one is to make the
environment handling back compatible. The environment in the refactored
is built above o.a.c.environment.TemplateObjectModelHelper while the
original is built on o.a.c.components.flow.javascript.fom.FOM_Cocoon.
What needs to be done is basically to embed the Request object in the
TemplateObjectModelHelper with a FOM_Request from FOM_Cocoon etc.
We should definately do something about the enviroment handling in
general in Cocoon, with Acessors or something similar, but for the time
being we should get rid of the original JXTG so no one feel tempted to
start parallel development on it.
/Daniel
Re: JX generates weird NameSpace???
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
oceatoon wrote:
> Hi everyone
>
>>It shouldn't be that difficult to fix.
>
> I could do with a few pointers though ;-)
> is there a better place to start ?
>
>>Should we track all namespace redefinitions?
>
> Sorry Daniel but this would finally close quite a large bug in our
> production which allready off schedule. I haven't had the time for back
> compatibility tests so I haven't integrated the new stuff. But this really
> is usefull to me and I would really like to deal with it.
Sure, I didn't follow the previous discussion and just reacted on the
thought of supporting two versions of the same thing. But if it is
important for you to fix it right now, we would certainly apply your
patches.
/Daniel
Re: JX generates weird NameSpace???
Posted by oceatoon <t....@systheo.com>.
Thanks for the help,
> I cannot seem to reproduce the bug (although I already had it once
> myself). Could you provide an isolated test case - as simple as it can be?
well as Marco simply described it,
it's just the
<jx:import
uri="resource://org/apache/cocoon/forms/generation/jx-macros.xml"/>
where ever you put it, the tag that follows the import will carry the weird
NS.
one important thing is that to see the NS, you need to intercept it in the
generator, call the page_jx?cocoon-view=pretty (label="display" )
otherwise the serialiser removes it.
Regards
Tibor
here's the simple example:
****************
pipeline
*****************
a simple jx generator with display
<map:match pattern="**_jx">
<map:generate type="jx" src="{1}_jx.xml" label="display">
<map:serialize type="xml"/>
</map:match>
if you serialise to xml you wont see it, intercept the generator (display)
*************
page_jx.xml
*************
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
<jx:import
uri="resource://org/apache/cocoon/forms/generation/jx-macros.xml"/>
<head>
<title>Cocorico</title>
</head>
</page>
Re: JX generates weird NameSpace???
Posted by Leszek Gawron <lg...@apache.org>.
oceatoon wrote:
> Hi everyone
>
>>It shouldn't be that difficult to fix.
>
> I could do with a few pointers though ;-)
> is there a better place to start ?
>
>>Should we track all namespace redefinitions?
>
>
> Sorry Daniel but this would finally close quite a large bug in our
> production which allready off schedule. I haven't had the time for back
> compatibility tests so I haven't integrated the new stuff. But this really
> is usefull to me and I would really like to deal with it.
I cannot seem to reproduce the bug (although I already had it once
myself). Could you provide an isolated test case - as simple as it can be?
--
Leszek Gawron MobileBox
lgawron@apache.org http://www.mobilebox.pl
Re: JX generates weird NameSpace???
Posted by oceatoon <t....@systheo.com>.
Hi everyone
> It shouldn't be that difficult to fix.
I could do with a few pointers though ;-)
is there a better place to start ?
> Should we track all namespace redefinitions?
Sorry Daniel but this would finally close quite a large bug in our
production which allready off schedule. I haven't had the time for back
compatibility tests so I haven't integrated the new stuff. But this really
is usefull to me and I would really like to deal with it.
Thanks
Regards
Tibor
Re: JX generates weird NameSpace???
Posted by Leszek Gawron <lg...@apache.org>.
oceatoon wrote:
> Thanks Marco
>
>
>>this weird namespace issue is actually caused by a nested redefinition
>>of a prefix mapping; just look at what's before the <head> element in
>>the template.
>
> Indeed
> <jx:import
> uri="reource://org/apache/cocoon/forms/generation/jx-macros.xml"/>
> seems to be the source of the bug... nice one
>
>
>>the imported file redefines the jx namespace within the
>><page> element that originally defines it.
>
>
> You mean the definition
> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0" being done more than
> once is the cause to this... this is bizarre cause I use jx:import
> uri="direct path not resource" in which I also define jx and I don't have
> this.
> wouldn't it be linked with the fact it is a resource://... that is
> imported ?
>
>
>>solution would be to have JXT track the template's namespace mappings
>>and eat duplicate ones from imported templates.
>
> Is this a difficult hack or have you done this ? I haven't really touched
> any core generators (no need :-) but it's never to late
>
> Thanks for the help
It shouldn't be that difficult to fix.
Should we track all namespace redefinitions?
--
Leszek Gawron MobileBox
lgawron@apache.org http://www.mobilebox.pl
Re: JX generates weird NameSpace???
Posted by oceatoon <t....@systheo.com>.
Thanks Marco
> this weird namespace issue is actually caused by a nested redefinition
> of a prefix mapping; just look at what's before the <head> element in
> the template.
Indeed
<jx:import
uri="reource://org/apache/cocoon/forms/generation/jx-macros.xml"/>
seems to be the source of the bug... nice one
> the imported file redefines the jx namespace within the
> <page> element that originally defines it.
You mean the definition
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0" being done more than
once is the cause to this... this is bizarre cause I use jx:import
uri="direct path not resource" in which I also define jx and I don't have
this.
wouldn't it be linked with the fact it is a resource://... that is
imported ?
> solution would be to have JXT track the template's namespace mappings
> and eat duplicate ones from imported templates.
Is this a difficult hack or have you done this ? I haven't really touched
any core generators (no need :-) but it's never to late
Thanks for the help
Tibor
Re: JX generates weird NameSpace???
Posted by Marco Rolappe <m_...@web.de>.
this weird namespace issue is actually caused by a nested redefinition
of a prefix mapping; just look at what's before the <head> element in
the template. the imported file redefines the jx namespace within the
<page> element that originally defines it.
solution would be to have JXT track the template's namespace mappings
and eat duplicate ones from imported templates.
oceatoon schrieb:
> Thanks for the help
> here's a little forms sample of this weird namespace popping up in the
> <head> tag
> <head xmlns:%@$#^@#="%@$#^@#">
> after the generate type jx ( you can see it with a cocoon view)
> We are using Xalan now but we still have the same problem.
> Hope this helps the solving.
> Best regards.
>
> Tibor
>
>
> Flow
> *****************************
> var form = new Form("cocoon:/forms/login_model.xml"+rolepar);
> form.showForm("login-form.html");
> *****************************
>
> our pipe
> ****************************
> <map:match pattern="**-form.html">
> <map:generate type="jx" src="forms/{1}_template.xml" label="display"/>
> ***************************
>
> Login template
> **************************
> <?xml version="1.0" encoding="UTF-8"?>
> <page xmlns:ft="http://apache.org/cocoon/forms/1.0#template"
> xmlns:fi="http://apache.org/cocoon/forms/1.0#instance"
> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"
> xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
> <!-- Import the macros that define CForms template elements -->
> <jx:import
> uri="resource://org/apache/cocoon/forms/generation/jx-macros.xml"/>
> <head>
> <title>
> <i18n:text key="login">Login</i18n:text>
> </title>
> <css href="/css/forms.css"/>
> <css href="/css/login.css"/>
> <script>
> //pour la validation coté client repose ici pour
> l'internationalisation
> var validation_msg_validation_head = "<i18n:text key="valerrors"/>";
> var validation_exc_mandatory = "<i18n:text key="valmandatory"/>";
> var validation_exc_number_format = "<i18n:text key="valnumber"/>";
> var validation_exc_date_format = "<i18n:text key="valdate"/>";
> </script>
> <script language="javascript" src="/resources/javascript/date.js"/>
> <script language="javascript"
> src="/resources/javascript/clientside-validation.js"/>
> </head>
> <top>
> <p class="title">
> <i18n:text key="welcome"/>
> </p>
> </top>
> <content>
> <ft:form-template action="${cocoon.continuation.id}.continue"
> method="post" name="loginform">
> <p class="explain">
> <i18n:text key="parag_login"/>
> </p>
> <div class="contain-widget">
> <div class="form">
> <table>
> <tr>
> <td class="lbl">
> <label for="username">
> <i18n:text key="username"/>
> </label>
> </td>
> <td>
> <ft:widget id="username">
> <fi:styling/>
> </ft:widget>
> </td>
> </tr>
> <tr>
> <td class="lbl">
> <label for="password">
> <i18n:text key="password"/>
> </label>
> </td>
> <td>
> <ft:widget id="password">
> <fi:styling type="password"
> onkeypress="javascript:if(event.keyCode==13)validation_execute();"/>
> </ft:widget>
> </td>
> </tr>
> </table>
> </div>
> <div class="button">
> <a href="javascript:validation_execute();">
> <i18n:text key="login"/>
> </a><br/>
> <a href="/forgotpwd" title="hint_forgotpwd"
> i18n:attr="title">
> <i18n:text key="forgotpwd"/>
> </a>
> <a href="/${cocoon.request.role}_registerprocess"
> title="hint_register" i18n:attr="title">
> <i18n:text key="register"/>
> </a>
> </div>
> </div>
> <!-- <p class="explain">
> <i18n:text key="parag_createaccount"/>
> </p>
> <div class="div_createaccount button">
> <a href="/owner_registerprocess" title="hint_becomeowner"
> i18n:attr="title">
> <i18n:text key="addyourproperty"/>
> </a>
> <a href="/user_registerprocess" title="hint_becomeuser"
> i18n:attr="title">
> <i18n:text key="jointravelclub"/>
> </a>
> </div> -->
> <p class="explain">
> <span>
> <i18n:text key="securitynotice"/>
> </span>: <i18n:text key="parag_sessioncut"/>
> </p>
> <!-- <div id="waitdiv" class="wait">
> <p class="bold textbig">
> <i18n:text key="parag_wait1"/>
> <br/>
> <i18n:text key="parag_wait2"/>
> <br/>
> <i18n:text key="parag_wait3"/>
> <br/>Eurobba</p>
> </div> -->
> </ft:form-template>
> </content>
> </page>
>
>
> Login Model
> **********************************
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
> -->
> <fd:form xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
> xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
> <fd:widgets>
> <fd:field id="username" required="true">
> <fd:label>
> <i18n:text key="username"/>
> </fd:label>
> <fd:datatype base="string"/>
> </fd:field>
> <fd:field id="password" required="true">
> <fd:label>
> <i18n:text key="password"/>
> </fd:label>
> <fd:validation>
> <jx:choose>
> <jx:when test="${cocoon.parameters.role != ''}">
> <fd:auth username="username" password="password"
> handler="${cocoon.parameters.handler}" role="${cocoon.parameters.role}"/>
> </jx:when>
> <jx:otherwise>
> <fd:auth username="username" password="password"
> handler="${cocoon.parameters.handler}"/>
> </jx:otherwise>
> </jx:choose>
> </fd:validation>
> <fd:datatype base="string"/>
> <!--<fd:datatype base="digest">
> <fd:convertor>
> <fd:digest algorithm="" salt="" encode=""/>
> </fd:convertor>
> </fd:datatype>-->
> </fd:field>
> </fd:widgets>
> </fd:form>
>
>
> Sylvain Wallez wrote:
>
>
>>oceatoon wrote:
>>
>>
>>>>>>>Is anybody aware of such a thing as JX generating a weirds
>>>>>>>namespaces?? <head xmlns:%@$#^@#="%@$#^@#">
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>Yes, and this has already been reported. But AFAICT it is
>>>>>>*not* blocking. You may be facing another problem without any
>>>>>>relation to this namespace oddity.
>>>>>>
>>>>>>
>>>>>
>>>>>Do you have a bugid for this?
>>>>>
>>>>>
>>>>
>>>>I don't think so. This issue has been discussed on the list a
>>>>couple of months ago.
>>>>
>>>>
>>>
>>>Have there been any solutions emitted for this ?
>>>Because we have swapped to Saxon but we still have the weird namespace
>>>hanging around??
>>>on top of that Saxon verboses quite a lot about our xsl rules(especially
>>>ones for cforms) and is even bloquing to go through some of them. My idea
>>>was to fusion all the stylesheets together but this is impossible because
>>>of this namespace problem. The fact that the stylesheets are decomposed in
>>>three layers (page advanced and field) is a good hack to get around the
>>>namespace pb, but in our project we'll need to fusion all this together at
>>>one point or another.
>>>
>>>I am quite blocked on this problem
>>>If anybody has any other ideas I'd be gratefull to hear them.
>>>
>>>
>>
>>It would be useful if you could provide us with a simple sample that
>>shows the error. That would help to find who's producing this strange
>>thing and fix it.
>>
>>Sylvain
>>
>
>
>
>
Re: JX generates weird NameSpace???
Posted by oceatoon <t....@systheo.com>.
Thanks for the help
here's a little forms sample of this weird namespace popping up in the
<head> tag
<head xmlns:%@$#^@#="%@$#^@#">
after the generate type jx ( you can see it with a cocoon view)
We are using Xalan now but we still have the same problem.
Hope this helps the solving.
Best regards.
Tibor
Flow
*****************************
var form = new Form("cocoon:/forms/login_model.xml"+rolepar);
form.showForm("login-form.html");
*****************************
our pipe
****************************
<map:match pattern="**-form.html">
<map:generate type="jx" src="forms/{1}_template.xml" label="display"/>
***************************
Login template
**************************
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns:ft="http://apache.org/cocoon/forms/1.0#template"
xmlns:fi="http://apache.org/cocoon/forms/1.0#instance"
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"
xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
<!-- Import the macros that define CForms template elements -->
<jx:import
uri="resource://org/apache/cocoon/forms/generation/jx-macros.xml"/>
<head>
<title>
<i18n:text key="login">Login</i18n:text>
</title>
<css href="/css/forms.css"/>
<css href="/css/login.css"/>
<script>
//pour la validation coté client repose ici pour
l'internationalisation
var validation_msg_validation_head = "<i18n:text key="valerrors"/>";
var validation_exc_mandatory = "<i18n:text key="valmandatory"/>";
var validation_exc_number_format = "<i18n:text key="valnumber"/>";
var validation_exc_date_format = "<i18n:text key="valdate"/>";
</script>
<script language="javascript" src="/resources/javascript/date.js"/>
<script language="javascript"
src="/resources/javascript/clientside-validation.js"/>
</head>
<top>
<p class="title">
<i18n:text key="welcome"/>
</p>
</top>
<content>
<ft:form-template action="${cocoon.continuation.id}.continue"
method="post" name="loginform">
<p class="explain">
<i18n:text key="parag_login"/>
</p>
<div class="contain-widget">
<div class="form">
<table>
<tr>
<td class="lbl">
<label for="username">
<i18n:text key="username"/>
</label>
</td>
<td>
<ft:widget id="username">
<fi:styling/>
</ft:widget>
</td>
</tr>
<tr>
<td class="lbl">
<label for="password">
<i18n:text key="password"/>
</label>
</td>
<td>
<ft:widget id="password">
<fi:styling type="password"
onkeypress="javascript:if(event.keyCode==13)validation_execute();"/>
</ft:widget>
</td>
</tr>
</table>
</div>
<div class="button">
<a href="javascript:validation_execute();">
<i18n:text key="login"/>
</a><br/>
<a href="/forgotpwd" title="hint_forgotpwd"
i18n:attr="title">
<i18n:text key="forgotpwd"/>
</a>
<a href="/${cocoon.request.role}_registerprocess"
title="hint_register" i18n:attr="title">
<i18n:text key="register"/>
</a>
</div>
</div>
<!-- <p class="explain">
<i18n:text key="parag_createaccount"/>
</p>
<div class="div_createaccount button">
<a href="/owner_registerprocess" title="hint_becomeowner"
i18n:attr="title">
<i18n:text key="addyourproperty"/>
</a>
<a href="/user_registerprocess" title="hint_becomeuser"
i18n:attr="title">
<i18n:text key="jointravelclub"/>
</a>
</div> -->
<p class="explain">
<span>
<i18n:text key="securitynotice"/>
</span>: <i18n:text key="parag_sessioncut"/>
</p>
<!-- <div id="waitdiv" class="wait">
<p class="bold textbig">
<i18n:text key="parag_wait1"/>
<br/>
<i18n:text key="parag_wait2"/>
<br/>
<i18n:text key="parag_wait3"/>
<br/>Eurobba</p>
</div> -->
</ft:form-template>
</content>
</page>
Login Model
**********************************
<?xml version="1.0" encoding="UTF-8"?>
<!--
-->
<fd:form xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
<fd:widgets>
<fd:field id="username" required="true">
<fd:label>
<i18n:text key="username"/>
</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:field id="password" required="true">
<fd:label>
<i18n:text key="password"/>
</fd:label>
<fd:validation>
<jx:choose>
<jx:when test="${cocoon.parameters.role != ''}">
<fd:auth username="username" password="password"
handler="${cocoon.parameters.handler}" role="${cocoon.parameters.role}"/>
</jx:when>
<jx:otherwise>
<fd:auth username="username" password="password"
handler="${cocoon.parameters.handler}"/>
</jx:otherwise>
</jx:choose>
</fd:validation>
<fd:datatype base="string"/>
<!--<fd:datatype base="digest">
<fd:convertor>
<fd:digest algorithm="" salt="" encode=""/>
</fd:convertor>
</fd:datatype>-->
</fd:field>
</fd:widgets>
</fd:form>
Sylvain Wallez wrote:
> oceatoon wrote:
>
>>>>>>Is anybody aware of such a thing as JX generating a weirds
>>>>>>namespaces?? <head xmlns:%@$#^@#="%@$#^@#">
>>>>>>
>>>>>>
>>>>>Yes, and this has already been reported. But AFAICT it is
>>>>>*not* blocking. You may be facing another problem without any
>>>>>relation to this namespace oddity.
>>>>>
>>>>>
>>>>Do you have a bugid for this?
>>>>
>>>>
>>>I don't think so. This issue has been discussed on the list a
>>>couple of months ago.
>>>
>>>
>>
>>Have there been any solutions emitted for this ?
>>Because we have swapped to Saxon but we still have the weird namespace
>>hanging around??
>>on top of that Saxon verboses quite a lot about our xsl rules(especially
>>ones for cforms) and is even bloquing to go through some of them. My idea
>>was to fusion all the stylesheets together but this is impossible because
>>of this namespace problem. The fact that the stylesheets are decomposed in
>>three layers (page advanced and field) is a good hack to get around the
>>namespace pb, but in our project we'll need to fusion all this together at
>>one point or another.
>>
>>I am quite blocked on this problem
>> If anybody has any other ideas I'd be gratefull to hear them.
>>
>>
>
> It would be useful if you could provide us with a simple sample that
> shows the error. That would help to find who's producing this strange
> thing and fix it.
>
> Sylvain
>
Re: JX generates weird NameSpace???
Posted by Sylvain Wallez <sy...@apache.org>.
oceatoon wrote:
>>>>>Is anybody aware of such a thing as JX generating a weirds
>>>>>namespaces?? <head xmlns:%@$#^@#="%@$#^@#">
>>>>>
>>>>>
>>>>Yes, and this has already been reported. But AFAICT it is
>>>>*not* blocking. You may be facing another problem without any
>>>>relation to this namespace oddity.
>>>>
>>>>
>>>Do you have a bugid for this?
>>>
>>>
>>I don't think so. This issue has been discussed on the list a
>>couple of months ago.
>>
>>
>
>Have there been any solutions emitted for this ?
>Because we have swapped to Saxon but we still have the weird namespace
>hanging around??
>on top of that Saxon verboses quite a lot about our xsl rules(especially
>ones for cforms) and is even bloquing to go through some of them. My idea
>was to fusion all the stylesheets together but this is impossible because
>of this namespace problem. The fact that the stylesheets are decomposed in
>three layers (page advanced and field) is a good hack to get around the
>namespace pb, but in our project we'll need to fusion all this together at
>one point or another.
>
>I am quite blocked on this problem
> If anybody has any other ideas I'd be gratefull to hear them.
>
>
It would be useful if you could provide us with a simple sample that
shows the error. That would help to find who's producing this strange
thing and fix it.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: JX generates weird NameSpace???
Posted by oceatoon <t....@systheo.com>.
>> > > Is anybody aware of such a thing as JX generating a weirds
>> > > namespaces?? <head xmlns:%@$#^@#="%@$#^@#">
>
>> > Yes, and this has already been reported. But AFAICT it is
>> > *not* blocking. You may be facing another problem without any
>> > relation to this namespace oddity.
>
>> Do you have a bugid for this?
>
> I don't think so. This issue has been discussed on the list a
> couple of months ago.
Have there been any solutions emitted for this ?
Because we have swapped to Saxon but we still have the weird namespace
hanging around??
on top of that Saxon verboses quite a lot about our xsl rules(especially
ones for cforms) and is even bloquing to go through some of them. My idea
was to fusion all the stylesheets together but this is impossible because
of this namespace problem. The fact that the stylesheets are decomposed in
three layers (page advanced and field) is a good hack to get around the
namespace pb, but in our project we'll need to fusion all this together at
one point or another.
I am quite blocked on this problem
If anybody has any other ideas I'd be gratefull to hear them.
Regards
Tibor
Re: JX generates weird NameSpace???
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
* Juan Jose Pablos:
> Jean-Baptiste Quenot wrote:
> > * oceatoon:
> > > Is anybody aware of such a thing as JX generating a weirds
> > > namespaces?? <head xmlns:%@$#^@#="%@$#^@#">
> > Yes, and this has already been reported. But AFAICT it is
> > *not* blocking. You may be facing another problem without any
> > relation to this namespace oddity.
> Do you have a bugid for this?
I don't think so. This issue has been discussed on the list a
couple of months ago.
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
Re: JX generates weird NameSpace???
Posted by Juan Jose Pablos <ch...@apache.org>.
Jean-Baptiste Quenot wrote:
> * oceatoon:
>
>
>>Is anybody aware of such a thing as JX generating a weirds
>>namespaces?? <head xmlns:%@$#^@#="%@$#^@#">
>
>
> Yes, and this has already been reported.
>
> But AFAICT it is *not* blocking. You may be facing another
> problem without any relation to this namespace oddity.
Do you have a bugid for this?
Re: JX generates weird NameSpace???
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jean-Baptiste Quenot wrote:
> * oceatoon:
>
>
>>Is anybody aware of such a thing as JX generating a weirds
>>namespaces?? <head xmlns:%@$#^@#="%@$#^@#">
>
>
> Yes, and this has already been reported.
do you happen to know the bugzilla link? I had this once when using
views. I'll try to look into that.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: JX generates weird NameSpace???
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
* oceatoon:
> Is anybody aware of such a thing as JX generating a weirds
> namespaces?? <head xmlns:%@$#^@#="%@$#^@#">
Yes, and this has already been reported.
But AFAICT it is *not* blocking. You may be facing another
problem without any relation to this namespace oddity.
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/