You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by christian bindeballe <ot...@gmail.com> on 2006/06/16 19:30:50 UTC

portal and forms - no script / styling

Hello everybody,

I have put my web-app in a CachingURICoplet in the portal. Odd thing is,
that the css and javascripts that are normally included in the pages
that are served, don't appear inside the portal. that means that for
example no calendar graphic is showing up next to date-widgets. also the
xsl which does the styling for e.g., required fields (the blue star)
doesn't work.

I don't see why this should happen as everything works fine when I call
my webapp from outside the portal. do I need to set different
resource-uri values when I use the forms inside a portal?

hints on how to resolve this are very much appreciated.

thanks in advance,

christian

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: portal and forms - no script / styling

Posted by christian bindeballe <ot...@gmail.com>.
Hi Carsten,

still having some problems with my coplets here.

Some of the CForms I call end up with showing nothing. Not even an
"coplet XYZ not available at the moment"-message.

In my Cocoon/Portal logs there is nothing that refers specifically to
those pages. I have attached my logs, maybe you can look at them,
because I don't really understand, if it says anything that could help
me. because, I get authenticated, in the cocoon.log there is no WARN
message about the role not authenticating, it says it is "caching new
response for
PK_G-file-file:/D:/_authoring/jakarta-tomcat-5.0.28/webapps/cocoon/samples/blocks/portal/resources/sunrise-user.xml_T-xslt-file:/D:/_authoring/jakarta-tomcat-5.0.28/webapps/cocoon/samples/blocks/portal/styles/authenticate.xsl;password=peter;name=Christian;use-request-parameters=true

but the portal.log has a WARN message, that it cannot find the profile
for a user of the role 'owner' (which is the user I am authenticating
with). I'm not using the cowarp authentication, but the
cocoon-authentication-framework.

and I looked at this again:

> Ah, yes, this is wrong :) With {1} you refer to values provided directly
> by the surrounding action. If you want to refer to the value of the
> matcher, you have to use {../../1}. 

could it be that it has to be "../../{1}" or am I missing something here?

sorry, for bothering you for so long with this, it's just soo weird that
everything works outside the portal, but inside it doesn't.

best regards and thanks in advance

christian

Re: portal and forms - no script / styling

Posted by Carsten Ziegeler <cz...@apache.org>.
christian bindeballe wrote:
> Hi, Carsten,
> 
> that was a very good hint, indeed it made it work as to styling :) thank
> you very much for taking the time to look into it.
> now, the only thing is, when I have entered data into the form, after
> submitting, I get the message "the coplet spmt-1 is currently not
> available". how, or where can I find out, what caused this error? there
> is nothing in the cocoon.log or portal.log that matches the time the
> error occurred. could it have to do with wrapping continuations in an
> action like this one?
> 
> <map:match pattern="*.continue">
>  <map:act type="auth-loggedIn">  <!-- check authentication -->
>   <map:parameter name="handler" value="managehandler"/>
>   <map:act type="auth-protect">  <!-- give access to the context -->
>    <map:parameter name="handler" value="managehandler"/>
>    <map:call continuation="{1}"/>
>   </map:act>
>  </map:act>
>  <map:redirect-to uri="login"/>
> </map:match>
> 
Ah, yes, this is wrong :) With {1} you refer to values provided directly
by the surrounding action. If you want to refer to the value of the
matcher, you have to use {../../1}. Or you can use named nodes:
<map:match pattern="*.continue" name="contmatch">
  ...
    <map:call continuation="{#contmatch:1}"/>
(I'm writing this just using my memory, so there might be a mistake/typo
in it).
I would prefer using named nodes as this is independent of the structure
of your pipeline. It still works if you add/remove some actions inbetween.

> By the way, is the caching URI coplet the right way to go for using
> CForms in the portal, or should I switch to an application-coplet?
The caching URI is the right coplet to use. The difference between those two
is basically if the app you're integrating is local or remote, so for
local ones you use caching uri while you use application-coplet for
remote ones.

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: portal and forms - no script / styling

Posted by christian bindeballe <ot...@gmail.com>.
Hi, Carsten,

that was a very good hint, indeed it made it work as to styling :) thank
you very much for taking the time to look into it.
now, the only thing is, when I have entered data into the form, after
submitting, I get the message "the coplet spmt-1 is currently not
available". how, or where can I find out, what caused this error? there
is nothing in the cocoon.log or portal.log that matches the time the
error occurred. could it have to do with wrapping continuations in an
action like this one?

<map:match pattern="*.continue">
 <map:act type="auth-loggedIn">  <!-- check authentication -->
  <map:parameter name="handler" value="managehandler"/>
  <map:act type="auth-protect">  <!-- give access to the context -->
   <map:parameter name="handler" value="managehandler"/>
   <map:call continuation="{1}"/>
  </map:act>
 </map:act>
 <map:redirect-to uri="login"/>
</map:match>

Without this one nothing works in the main sitemap, but putting it in
the sub-sitemap doesn't help.

By the way, is the caching URI coplet the right way to go for using
CForms in the portal, or should I switch to an application-coplet?

OK, that's enough questions for now,

if you have any suggestions or thoughts, let me know, I really
appreciate you helping out!

best regards,

christian

Carsten Ziegeler schrieb:
> CForms in coplets is working - we are using cforms a lot in our portals
> without any problems. Now, can you check how the <link> elements in the
> generated portal page for the cforms resources look like? Perhaps they
> have a wrong prefix or something like that.
> 
> Now, in our solutions we do not include the cforms stylesheets but just
> copy the important content (the link elements) from the cforms
> stylesheets to the portal-page.xsl. Of course, your solution is more
> general and should also still work if you upgrade Cocoon. Our solution
> requires manual steps each time we upgrade to a newer Cocoon version
> (and of course when the cforms stylesheets change). But we never had any
> problems with this.
> 
> HTH
> Carsten
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: portal and forms - no script / styling

Posted by Carsten Ziegeler <cz...@apache.org>.
christian bindeballe schrieb:
> 
> in all sitemaps down to the one that does the authentication, but the
> portal still does no styling on the widgets. this is really annoying, as
> I thought it would actually be possible to get CForms in Coplets to
> work. Now I start to doubt that it is, at least not with validation, but
> I hope that I am wrong and there is a way to make it happen.
> I'm quite at the end of my wits here, can someone please help me where
> to go on looking?
> 
CForms in coplets is working - we are using cforms a lot in our portals
without any problems. Now, can you check how the <link> elements in the
generated portal page for the cforms resources look like? Perhaps they
have a wrong prefix or something like that.

Now, in our solutions we do not include the cforms stylesheets but just
copy the important content (the link elements) from the cforms
stylesheets to the portal-page.xsl. Of course, your solution is more
general and should also still work if you upgrade Cocoon. Our solution
requires manual steps each time we upgrade to a newer Cocoon version
(and of course when the cforms stylesheets change). But we never had any
problems with this.

HTH
Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: portal and forms - no script / styling

Posted by christian bindeballe <ot...@gmail.com>.
Hi Carsten,

thanks for your help.

I included the call for the templates in the head section of my
portal-page.xsl as follows:

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:include
href="resource://org/apache/cocoon/forms/resources/forms-page-styling.xsl"/>
<xsl:include
href="resource://org/apache/cocoon/forms/resources/forms-advanced-field-styling.xsl"/>

<xsl:param name="user"/>
<xsl:param name="title"/>
<xsl:param name="base"/>
<xsl:param name="resources-uri">resources</xsl:param>

<xsl:template match="/">
 <html>
  <head>
  <!--xsl:apply-templates/-->
  <xsl:apply-templates select="." mode="forms-page"/>
  <xsl:apply-templates select="." mode="forms-field"/>
  <title><xsl:value-of select="$title"/></title>
  <link type="text/css" rel="stylesheet" href="{$base}css/page.css"/>
  <link type="text/css" rel="stylesheet" href="{$base}css/wsrp.css"/>
 </head>
<body>
 <xsl:apply-templates select="." mode="forms-page"/>
 <xsl:apply-templates select="." mode="forms-field"/>
 <!--xsl:apply-templates/-->

... rest of the portal-page.xsl omitted here ...
</body>
... rest of the stylesheet ...

I had to uncomment the two "<xsl:apply-templates/>", because otherwise I
would have had three times the portal opening page. without them I still
have the name of the coplets showing up above the whole portal page,
each name once for each "<xsl:apply-templates/>":
IntroductionLeftRightBottomIntroductionLeftRightBottom
IntroductionLeftRightBottomIntroductionLeftRightBottom

I included the call for the resources:

<map:match pattern="resources/*/**">
 <map:read src="resource://org/apache/cocoon/{1}/resources/{2}"/>
</map:match>

in all sitemaps down to the one that does the authentication, but the
portal still does no styling on the widgets. this is really annoying, as
I thought it would actually be possible to get CForms in Coplets to
work. Now I start to doubt that it is, at least not with validation, but
I hope that I am wrong and there is a way to make it happen.
I'm quite at the end of my wits here, can someone please help me where
to go on looking?

Thank you all in advance,

christian

Carsten Ziegeler schrieb:
> Hi,
> 
> the head section of the html page is "created" by the portal, so
> basically all head sections of the portlets (your cforms app) are
> ignored and not added to the output page.
> So, the easiest way is to add the head section to the portal-page.xsl of
> the portal, so the portal loads all required resources for your
> portlets. If you do this you might have to add some matchers to the
> sitemap of your portal for these resources.
> 
> HTH
> Carsten
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: portal and forms - no script / styling

Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,

the head section of the html page is "created" by the portal, so
basically all head sections of the portlets (your cforms app) are
ignored and not added to the output page.
So, the easiest way is to add the head section to the portal-page.xsl of
the portal, so the portal loads all required resources for your
portlets. If you do this you might have to add some matchers to the
sitemap of your portal for these resources.

HTH
Carsten

christian bindeballe wrote:
> Hi there,
> 
> since there has been no answer yet, maybe some more details would help
> you help me.
> 
> I looked into the xsl-scripts for forms for quite a while now and I
> compared the output of the forms page outside the portal with the output
> of the same forms page when inside the portal.
> it looks as if the URIs to all the xsl are properly resolved, as some
> elements in the included stylesheets are put in the data that is sent.
> 
> what is not included, are these references:
> 
> <script src="resources/ajax/cocoon.js" type="text/javascript"/>
> <script src="resources/forms/js/forms-lib.js" type="text/javascript"/>
> <script type="text/javascript">
>         dojo.addOnLoad(forms_onload);
>         dojo.require("cocoon.forms.*");
>     </script>
> <link rel="stylesheet" type="text/css"
> href="resources/forms/css/forms.css"/>
> <script src="resources/forms/mattkruse-lib/AnchorPosition.js"
> type="text/javascript"/>
> <script src="resources/forms/mattkruse-lib/PopupWindow.js"
> type="text/javascript"/>
> <script src="resources/forms/mattkruse-lib/OptionTransfer.js"
> type="text/javascript"/>
> <script src="resources/forms/mattkruse-lib/selectbox.js"
> type="text/javascript"/>
> <script src="resources/forms/mattkruse-lib/CalendarPopup.js"
> type="text/javascript"/>
> <script src="resources/forms/mattkruse-lib/date.js" type="text/javascript"/>
> <script type="text/javascript">
>       // Setup calendar
>       var forms_calendar = CalendarPopup();
>       forms_calendar.setWeekStartDay(1);
>       forms_calendar.showYearNavigation();
>       forms_calendar.showYearNavigationInput();
>       forms_calendar.setCssPrefix("forms_");
>     </script>
> <link rel="stylesheet" type="text/css"
> href="resources/forms/css/forms-calendar.css"/>
> <script type="text/javascript">
>       _editor_url = "resources/forms/htmlarea/";
>       _editor_lang = "en";
>     </script>
> <script type="text/javascript" src="resources/forms/htmlarea/htmlarea.js"/>
> 
> I stripped the output of some namespace declarations, it is just to
> show, what elements I mean.
> these are in template-matchers that have the mode set to "forms-field".
> obviously, none of these templates are called or matched, although in
> the forms-styling.xsl they are referenced:
> 
> <xsl:template match="head">
>     <head>
>       <xsl:apply-templates select="." mode="forms-page"/>
>       <xsl:apply-templates select="." mode="forms-field"/>
>       <xsl:apply-templates/>
>     </head>
>   </xsl:template>
> 
>   <xsl:template match="body">
>     <body>
>       <!--+ !!! If template with mode 'forms-page' adds text or elements
>           |        template with mode 'forms-field' can no longer add
> attributes!!!
>           +-->
>       <xsl:apply-templates select="." mode="forms-page"/>
>       <xsl:apply-templates select="." mode="forms-field"/>
>       <xsl:apply-templates/>
>     </body>
>   </xsl:template>
> 
> I don't know if the comment that is in the second template also applies
> to the head-template, but still I am confused, why, when I call the URI
> to my forms outside the portal, they all are properly styled and the
> JavaScript is included, and when I call them inside a coplet, the forms
> have no styling and no JavaScript is included.
> 
> I hope, I am not the only one with this kind of problem and that someone
> can help me out here.
> 
> thanks in advance,
> 
> christian
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 
> 


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: portal and forms - no script / styling

Posted by christian bindeballe <ot...@gmail.com>.
Hi there,

since there has been no answer yet, maybe some more details would help
you help me.

I looked into the xsl-scripts for forms for quite a while now and I
compared the output of the forms page outside the portal with the output
of the same forms page when inside the portal.
it looks as if the URIs to all the xsl are properly resolved, as some
elements in the included stylesheets are put in the data that is sent.

what is not included, are these references:

<script src="resources/ajax/cocoon.js" type="text/javascript"/>
<script src="resources/forms/js/forms-lib.js" type="text/javascript"/>
<script type="text/javascript">
        dojo.addOnLoad(forms_onload);
        dojo.require("cocoon.forms.*");
    </script>
<link rel="stylesheet" type="text/css"
href="resources/forms/css/forms.css"/>
<script src="resources/forms/mattkruse-lib/AnchorPosition.js"
type="text/javascript"/>
<script src="resources/forms/mattkruse-lib/PopupWindow.js"
type="text/javascript"/>
<script src="resources/forms/mattkruse-lib/OptionTransfer.js"
type="text/javascript"/>
<script src="resources/forms/mattkruse-lib/selectbox.js"
type="text/javascript"/>
<script src="resources/forms/mattkruse-lib/CalendarPopup.js"
type="text/javascript"/>
<script src="resources/forms/mattkruse-lib/date.js" type="text/javascript"/>
<script type="text/javascript">
      // Setup calendar
      var forms_calendar = CalendarPopup();
      forms_calendar.setWeekStartDay(1);
      forms_calendar.showYearNavigation();
      forms_calendar.showYearNavigationInput();
      forms_calendar.setCssPrefix("forms_");
    </script>
<link rel="stylesheet" type="text/css"
href="resources/forms/css/forms-calendar.css"/>
<script type="text/javascript">
      _editor_url = "resources/forms/htmlarea/";
      _editor_lang = "en";
    </script>
<script type="text/javascript" src="resources/forms/htmlarea/htmlarea.js"/>

I stripped the output of some namespace declarations, it is just to
show, what elements I mean.
these are in template-matchers that have the mode set to "forms-field".
obviously, none of these templates are called or matched, although in
the forms-styling.xsl they are referenced:

<xsl:template match="head">
    <head>
      <xsl:apply-templates select="." mode="forms-page"/>
      <xsl:apply-templates select="." mode="forms-field"/>
      <xsl:apply-templates/>
    </head>
  </xsl:template>

  <xsl:template match="body">
    <body>
      <!--+ !!! If template with mode 'forms-page' adds text or elements
          |        template with mode 'forms-field' can no longer add
attributes!!!
          +-->
      <xsl:apply-templates select="." mode="forms-page"/>
      <xsl:apply-templates select="." mode="forms-field"/>
      <xsl:apply-templates/>
    </body>
  </xsl:template>

I don't know if the comment that is in the second template also applies
to the head-template, but still I am confused, why, when I call the URI
to my forms outside the portal, they all are properly styled and the
JavaScript is included, and when I call them inside a coplet, the forms
have no styling and no JavaScript is included.

I hope, I am not the only one with this kind of problem and that someone
can help me out here.

thanks in advance,

christian

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org