FlowJXPathSelectionListBuilder selected item
Hi, Hope i'm not wrong, but i seems to me that the FlowJXPathSelectionListBuilder (/src/blocks/forms/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListBuilder.java) is missing something to add the html tag selected for the item selected in a selection-list. Then we could do: fd:selection-list type=flow-jxpath list-path=foo value-path=value label-path=label *selected-path=selected*/ Should i open a bugzilla? Phil
AJAX in CForms for response
Hi, I checked the AJAX samples today : Great for use with repeater/unions/selction-lists. I also understand i get there some cform validation before submit!. I have another case in mind: A lightweight form may contain a few simple fields, and often the response page would be nothing more than this : OK, successfully saved!. That would be the perfect use case of another XHR call... I detected the point in cforms.js where the form has been validated and a response header X-cocoon-ajax=continue is received. There i could add another request that could launch the continuation, then flow would process things and end with a cocoon.sendPage() rendering XML or even text response. I'd like to know what people here think about this, specially because i don't see if it would be a good practice to launch the continuation from a XHR call, though it should work if it contains the right continuation. Regards, Phil
Reset cachingURI coplet
Hi all,
I try there since i get no answer on the user-list. My question is also
the same as this old mail
http://www.mail-archive.com/users@cocoon.apache.org/msg12028.html.
I'm looking for some idea/solution to refresh a cachingURI coplet
content after a form in portal has been submitted. Then a user going to
other tabs and going back would not see the success page again.
This may explain better my need:
function show(form) {
populate(form);
form.showForm(display-pipeline);
saveToDB(form);
cocoon.sendPage(success-pipeline);
resetCoplet(instance_name);
}
function resetCoplet() {
// this is pseudo code remember!
thisCoplet.resetTemporaryURI();
thisCoplet.invalidateCache();
// Now next time this coplet will be generated from scratch
}
This is what i have written at the moment. I see no exceptions, but with
no effect at all:
function resetCoplet(instanceName) {
var service = null;
try {
// get portal service
service =
cocoon.getComponent(org.apache.cocoon.portal.PortalService.ROLE);
service.setPortalName(portal);
// get profile manager
var componentManager = service.getComponentManager();
var profileManager = componentManager.getProfileManager();
var cid = profileManager.getCopletInstanceData(instanceName);
var event = null;
var path = temporaryAttributes/application-uri;
var value = cocoon://portal/coplets/profiler/profile;
if ( cid != null ) {
// create event
event = new
Packages.org.apache.cocoon.portal.event.impl.CopletJXPathEvent(cid,
path, value);
// subscribe it
service.getComponentManager().getEventManager().getPublisher().publish(event);
// invalidate cache
var cachingURICopletAdapter = new
Packages.org.apache.cocoon.portal.coplet.adapter.impl.CachingURICopletAdapter();
cachingURICopletAdapter.setCacheInvalid(cid);
}
} catch ( e ) {
cocoon.log.info(Error, e);
}
finally {
cocoon.releaseComponent( service );
}
}
Somebody can help?
PHIL
Re: Reset cachingURI coplet
Thanks Jean-Baptiste,
Looks really good. Unfortunately it does the same for me, no errors and
the succes page is still displayed!
It seems i do not cache the response, the coplet temporaryURI is still
with the continuation, so the response is regenerated because flowscript
starts again at the continuation point.
(cocoon://portal/coplets/mycoplet/xxx.continue)
I suppose you added something else, but can't get what!?
Regards,
Phil
Jean-Baptiste Quenot wrote:
* Philippe Guillard:
I'm looking for some idea/solution to refresh a cachingURI
coplet content after a form in portal has been submitted. Then a
user going to other tabs and going back would not see the
success page again.
Here is what we do:
showForm()
doNotCacheCopletResponse(copletId);
cocoon.sendPage(success-page);
And here is the magic function:
function doNotCacheCopletResponse(copletId)
{
cocoon.log.debug(doNotCacheCopletResponse: coplet=+copletId);
var service = cocoon.getComponent(org.apache.cocoon.portal.PortalService.ROLE);
var profileManager = service.getComponentManager().getProfileManager();
var coplet = profileManager.getCopletInstanceData(copletId);
// tells the coplet not to cache the his content
// Note : this code comes from CachingURICopletAdapter
coplet.setAttribute(org.apache.cocoon.portal.coplet.adapter.impl.CachingURICopletAdapter.DO_NOT_CACHE,
true);
}
This prevents caching for the success page.
HTH,
Re: Reset cachingURI coplet
Thanks a lot!
I finally get i didn't invalidate the coplet cache correctly and used
your way.
Below is what i have all-in-one, if others are interested...
Regards,
Phil
function resetCoplet(copletId, tempURI) {
var service = null;
try {
// get portal service/profile manager/coplet
service =
cocoon.getComponent(org.apache.cocoon.portal.PortalService.ROLE);
service.setPortalName(portal);
var componentManager = service.getComponentManager();
var profileManager = componentManager.getProfileManager();
var coplet = profileManager.getCopletInstanceData(copletId);
var path = temporaryAttributes/application-uri;
var value = tempURI;
var cachingURICopletAdapter = new
Packages.org.apache.cocoon.portal.coplet.adapter.impl.CachingURICopletAdapter();
if ( coplet != null ) {
// invalidate cache
coplet.setAttribute(org.apache.cocoon.portal.coplet.adapter.impl.CachingURICopletAdapter.DO_NOT_CACHE,
true);
cocoon.log.debug(cache invalidated for coplet=+copletId);
// create event and suscribe it
var event = new
Packages.org.apache.cocoon.portal.event.impl.CopletJXPathEvent(coplet,
path, value);
service.getComponentManager().getEventManager().getPublisher().publish(event);
cocoon.log.debug(tempURI changed for coplet=+copletId);
} else {
cocoon.log.error(This coplet doesn't exist=+copletId);
}
} catch ( e ) {
cocoon.log.info(Error, e);
}
finally {
cocoon.releaseComponent( service );
}
}
Jean-Baptiste Quenot wrote:
* Philippe Guillard:
Looks really good. Unfortunately it does the same for me, no
errors and the succes page is still displayed! It seems i do
not cache the response, the coplet temporaryURI is still
with the continuation, so the response is regenerated because
flowscript starts again at the continuation point.
Theform actionpointstoa pipelinecalled
invalidateCacheForCoplet, and in turn calling a flowscript
to invalidate the coplet upon form submission. And finally
the request is forwarded to portal. We don't use this
temporary:application-uri hack.
Here is what it looks like:
function invalidateCacheForCoplet(copletId)
{
// Get the coplet
var service = cocoon.getComponent(org.apache.cocoon.portal.PortalService.ROLE);
var profileManager = service.getComponentManager().getProfileManager();
var coplet = profileManager.getCopletInstanceData(copletId);
// Set the cache of the coplet as invalid
// Note : this code comes from CachingURICopletAdapter
coplet.setAttribute(org.apache.cocoon.portal.coplet.adapter.impl.CachingURICopletAdapter.CACHE_VALIDITY,
org.apache.cocoon.portal.coplet.adapter.impl.CachingURICopletAdapter.CACHE_INVALID);
cocoon.sendPage(portal);
}
Cheers,
XMLHTTPRequest
Hi I was happy/surprised to discover the xhr_carselector in 2.1.7 samples, and just want to get news about it (Sorry i can't access Bugzilla today, and before didn't find much on bug 34077). I imagine this feature needs lots of work, maybe CForms re-work, so i just wonder what is the situation. Regards, Phil
Re: Enctype + CachingURI Coplet
Hi,
I startedthis thread before without success, here i try to describe it
better : i still can't use the upload widget in a cachingURI coplet of
the portal. (I'm in 2.1.6Release)
When i submit the form i get back with the same form and loose my
inputs. I seems to me there is a problem handling other form attributes
like cocoon-portal-event as soon as i introduce the enctype attribute.
Hope somebody can help. Below some details.
Regards,
Phil
In my CForm template :
__
ft:form-template action= method=POST enctype=multipart/form-data
ft:continuation-id/
Before i made it work (was on a 2.1.5 cvs before 2.1.5rls) :
_
form xmlns:coplet=http://apache.org/cocoon/portal/coplet/1.0;
method=POST enctype=multipart/form-data onsubmit=forms_onsubmit();
action=portal
input type=hidden name=cocoon-portal-event value=13input
type=hidden name=cocoon-portal-action value=4
input name=forms_submit_id type=hidden
input value=8554468513292720183b3511558b4372455a4727 type=hidden
name=continuation-id
Now on rls2.1.6 (and maybe something i did wrong...)
___
form xmlns:coplet=http://apache.org/cocoon/portal/coplet/1.0;
method=POST enctype=multipart/form-data onsubmit=forms_onsubmit();
action=portal?cocoon-portal-event=3page=group.Profile
input name=forms_submit_id type=hidden
input value=1d811e2d7b1d01456276098053273c3f61413582 type=hidden
name=continuation-id
If i remove enctype attribute i get the things look better to me:
_
form xmlns:coplet=http://apache.org/cocoon/portal/coplet/1.0;
method=POST onsubmit=forms_onsubmit(); action=portal
input type=hidden name=cocoon-portal-event value=3input
type=hidden name=page value=group.Profile
input name=forms_submit_id type=hidden
input value=8b851d7e3a153157001c7d295a8d534f38417322 type=hidden
name=continuation-id
Philippe Guillard wrote:
It seems Revision *27956*
http://svn.apache.org/viewcvs.cgi?rev=27956view=rev was fixing the
enctype problem, this was removed in Revision *28123*
http://svn.apache.org/viewcvs.cgi?rev=28123view=rev to handle more
generally attributes. I builded with last revision ( Revision *122957*
http://svn.apache.org/viewcvs.cgi?rev=122957view=rev), adding :
final String encType = attributes.getValue(enctype);
if ( encType != null ) {
newAttributes.addCDATAAttribute(enctype, encType);
}
Now i get the continuation but form.lookupWidget(upload).getValue()
seems always null. At the same time i discovered the file uploaded is
only available in the same pipeline.
Any advice welcomed !
Phil
Philippe Guillard wrote:
Hi,
I know that portal-html-eventlink doesn't delete enctype attribute
anymore (http://issues.apache.org/bugzilla/show_bug.cgi?id=28095)
Anyway i can't make my upload form work anymore in a cachingURI
coplet, cocoon2.1.6, (I updated HTMLEventLinkTransformer.java to last
revision 122957 that i found.)
I get visually no continuation and the form is submitted again,
loosing my input.
The point is, when i suppress the part 'enctype=multipart/form-data
', i have continuation ok!!
My Template
ft:form-template action= method=POST enctype=multipart/form-data
ft:continuation-id/
(tried also ft:form-template action=#{$continuation/id}.continue
method=POST enctype=multipart/form-data with stemap equivalent)
Rendered html, that seems ok to me
form xmlns:coplet=http://apache.org/cocoon/portal/coplet/1.0;
method=POST onsubmit=forms_onsubmit(); action=portal
input type=hidden name=cocoon-portal-event value=3input
type=hidden name=page value=group.Photos
input name=forms_submit_id type=hidden
input value=471a230555871e150852245c031e67725c6e406c type=hidden
name=continuation-id
Anybody any idea ??
Regards,
Phil
Re: Enctype + CachingURI Coplet
It seems Revision *27956*
http://svn.apache.org/viewcvs.cgi?rev=27956view=rev was fixing the
enctype problem, this was removed in Revision *28123*
http://svn.apache.org/viewcvs.cgi?rev=28123view=rev to handle more
generally attributes. I builded with last revision ( Revision *122957*
http://svn.apache.org/viewcvs.cgi?rev=122957view=rev), adding :
final String encType = attributes.getValue(enctype);
if ( encType != null ) {
newAttributes.addCDATAAttribute(enctype, encType);
}
Now i get the continuation but form.lookupWidget(upload).getValue()
seems always null. At the same time i discovered the file uploaded is
only available in the same pipeline.
Any advice welcomed !
Phil
Philippe Guillard wrote:
Hi,
I know that portal-html-eventlink doesn't delete enctype attribute
anymore (http://issues.apache.org/bugzilla/show_bug.cgi?id=28095)
Anyway i can't make my upload form work anymore in a cachingURI
coplet, cocoon2.1.6, (I updated HTMLEventLinkTransformer.java to last
revision 122957 that i found.)
I get visually no continuation and the form is submitted again,
loosing my input.
The point is, when i suppress the part 'enctype=multipart/form-data
', i have continuation ok!!
My Template
ft:form-template action= method=POST enctype=multipart/form-data
ft:continuation-id/
(tried also ft:form-template action=#{$continuation/id}.continue
method=POST enctype=multipart/form-data with stemap equivalent)
Rendered html, that seems ok to me
form xmlns:coplet=http://apache.org/cocoon/portal/coplet/1.0;
method=POST onsubmit=forms_onsubmit(); action=portal
input type=hidden name=cocoon-portal-event value=3input
type=hidden name=page value=group.Photos
input name=forms_submit_id type=hidden
input value=471a230555871e150852245c031e67725c6e406c type=hidden
name=continuation-id
Anybody any idea ??
Regards,
Phil
Enctype + CachingURI Coplet
Hi,
I know that portal-html-eventlink doesn't delete enctype attribute
anymore (http://issues.apache.org/bugzilla/show_bug.cgi?id=28095)
Anyway i can't make my upload form work anymore in a cachingURI coplet,
cocoon2.1.6, (I updated HTMLEventLinkTransformer.java to last revision
122957 that i found.)
I get visually no continuation and the form is submitted again,
loosing my input.
The point is, when i suppress the part 'enctype=multipart/form-data ',
i have continuation ok!!
My Template
ft:form-template action= method=POST enctype=multipart/form-data
ft:continuation-id/
(tried also ft:form-template action=#{$continuation/id}.continue
method=POST enctype=multipart/form-data with stemap equivalent)
Rendered html, that seems ok to me
form xmlns:coplet=http://apache.org/cocoon/portal/coplet/1.0;
method=POST onsubmit=forms_onsubmit(); action=portal
input type=hidden name=cocoon-portal-event value=3input
type=hidden name=page value=group.Photos
input name=forms_submit_id type=hidden
input value=471a230555871e150852245c031e67725c6e406c type=hidden
name=continuation-id
Anybody any idea ??
Regards,
Phil
Client side validation for CForms
Hi all, My idea is to systematically use server-side validation as it is necessary, + some client-side to be confortable for the user. I used the (great) patch found in http://issues.apache.org/bugzilla/show_bug.cgi?id=32419. Anyway i get trouble when i think about string lenght limitation. The main hack in this patch is this: xsl:for-each select=..//fi:field validation_register_widget( 'xsl:value-of select=@id/', xsl:if test=@required='true'true/xsl:if, 'xsl:value-of select=fi:datatype/@type/', 'xsl:value-of select=fi:datatype/fi:convertor/@pattern/' ); /xsl:for-each Problem: fi:validation/fd:length/@max seems not to be disponible in output of the CForm transformer. that part is a big one! So i ask if somebody has another idea/did it/ or can give me hints to do it. Regards, Phil
Re: [Poll] Portal deployment / Cocoon portal usage
Responses inside. 1. Are you currently using the Cocoon Portal Framework? A) Yes we are using it for our Website under development 3. Why did you choose the Cocoon portal framework? A) We were already using Cocoon B) A strategic decision was made to use Open Source 4. What do you think is currently missing from the Portal framework? D) Better Documentation : Like any cocoon block new users would need more, but the code is there open :-). 5. How do you get support for the framework A) Through the mailing lists B) Reading the documentation and other publications 6. Details/Comments (Optional) As i said i can't compare to other portals, i believe it is today the biggest and most difficult block in cocoon, so i still lack experience. Still, i think it misses some flexibility concerning Layout and renderers. For example : - Change the disposition of tab,link-tab layout, put some coplets over the menus (Actually this is my question today on users-list: i don't think we can do much change there) - Access to the request and session inside the renderers - Possibilities to pass sitemap-parameters to the layout stylesheets Regards, Phil
Re: Navigation and Cocoon Portal
Hi, I suggest you adapt the portal stylsheets with a dynamic parameter passed from sitemap and then show or not show your extra tab. (In /portal/skins/common/styles/tab.xsl or /portal/skins/common/styles/linktab.xl) Phil On Sun, 2004-08-15 at 23:58, Jennifer Yip wrote: Hi guys, Quick question as I struggle through work on a Sunday afternoon. I have spent a week or two now looking at Cocoon and the new portal block - loving it to death - you guys are doing a great job. ok quick question for newbie (but learning quick) I am trying to work out how to be able to add a tab containing a portlet to a users config dynamically - ie I have a popup tree of things and when selected each thing should be displayed in a coplet window - ie popup contains - Sheep, Cow, Dog User selects and this somehow make a new tab appear in portal with a mapped Coplet.. is that possible? or do I modify the pipeline that supplies the initial layout to be dynamic and somehow do it that way? layout-user-load uri=cocoon:raw:/load-user-profile?profile=layout/ kind regards Jenny _ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger
RE: [portal] Implementing Login coplet with CForms
I try again if somebody succeded or has any suggestion how to process for that topic ? Phil On Fri, 2004-07-02 at 16:48, Philippe Guillard wrote: Hi, Is there some fresh news about that topic ? I mean somebody succeded ? Regards, Phil On Thu, 2004-05-27 at 03:33, Alex Romayev wrote: --- Carsten Ziegeler [EMAIL PROTECTED] wrote: Alex Romayev wrote: Ok, I'm a bit confused and not sure where to start. This is what I'm trying to achieve. I'd like to replace portal login form with CForm (using actions, not flow), to use its validation. So the most interesting use case is: 1. User does not enter username/password 2. The form is re-displayed with error messages 3. User enters correct username/password 4. The form calls do-login url, which then redirects to portal using authentication-fw. Questions. 1. Initially I assumed that if I just configured the coplet with handleParameters = true, CForms would have access to request parameters. Not true. Does this mean that handleParameters only works in conjunction with html-event-link transformer? Yes (unfortunately I think). :-( I actually find that having request parameters directly available to coplets would simplify things quite a bit in general. However, come to think of it, it probably wouldn't have helped my case, since I would still need to do the redirect to do-login inside my portlet pipeline. 2. I switched to using html-even-link trasformer configuration. Now could get through steps 1-3. However, in step 4, calling do-login results in portal being displayed *inside* my login coplet. I've looked at HTMLEventLinkTransformer code, and it makes external = true/false distinction only for links, not for forms. At the same time, event if it did, I don't see how it would work in my case anyway, since in step 2 I would need to have external=true and in step 4, external= false for the same form? Am I making sense here at all? Yes, makes sense to me :) Seems like I'm just missing some basic information, but ATM completely lost :-) Hmm, no the problem is that your call to do-login happens inside the coplet. So it's the content of your coplet that you change with the call - not the whole portal itself. I'm not sure if this is possible at all - at least I don't see a solution right now (which doesn't mean that there isn't). I've been thinking about this for a while, let me see if I can collect my thoughts and make a separate post on this topic. Thanks, -Alex For the current login coplet in the demo portal we used a hack. The form is not processed by the coplet itself but directly in the sitemap *before* the portal is rendered. This allows us to do what you need. You could do the evaluation before the portal is rendered and put some error messages in the session and retrieve it later on when your coplet is rendered. HTH Carsten
RE: [portal] Implementing Login coplet with CForms
Hi, Is there some fresh news about that topic ? I mean somebody succeded ? Regards, Phil On Thu, 2004-05-27 at 03:33, Alex Romayev wrote: --- Carsten Ziegeler [EMAIL PROTECTED] wrote: Alex Romayev wrote: Ok, I'm a bit confused and not sure where to start. This is what I'm trying to achieve. I'd like to replace portal login form with CForm (using actions, not flow), to use its validation. So the most interesting use case is: 1. User does not enter username/password 2. The form is re-displayed with error messages 3. User enters correct username/password 4. The form calls do-login url, which then redirects to portal using authentication-fw. Questions. 1. Initially I assumed that if I just configured the coplet with handleParameters = true, CForms would have access to request parameters. Not true. Does this mean that handleParameters only works in conjunction with html-event-link transformer? Yes (unfortunately I think). :-( I actually find that having request parameters directly available to coplets would simplify things quite a bit in general. However, come to think of it, it probably wouldn't have helped my case, since I would still need to do the redirect to do-login inside my portlet pipeline. 2. I switched to using html-even-link trasformer configuration. Now could get through steps 1-3. However, in step 4, calling do-login results in portal being displayed *inside* my login coplet. I've looked at HTMLEventLinkTransformer code, and it makes external = true/false distinction only for links, not for forms. At the same time, event if it did, I don't see how it would work in my case anyway, since in step 2 I would need to have external=true and in step 4, external= false for the same form? Am I making sense here at all? Yes, makes sense to me :) Seems like I'm just missing some basic information, but ATM completely lost :-) Hmm, no the problem is that your call to do-login happens inside the coplet. So it's the content of your coplet that you change with the call - not the whole portal itself. I'm not sure if this is possible at all - at least I don't see a solution right now (which doesn't mean that there isn't). I've been thinking about this for a while, let me see if I can collect my thoughts and make a separate post on this topic. Thanks, -Alex For the current login coplet in the demo portal we used a hack. The form is not processed by the coplet itself but directly in the sitemap *before* the portal is rendered. This allows us to do what you need. You could do the evaluation before the portal is rendered and put some error messages in the session and retrieve it later on when your coplet is rendered. HTH Carsten
RE: portal-html-eventlink transformer and req-params ?
Thanks a lot Carsten!
Just one more quick question : It seems to me that portal-html-eventlink
transformer doesn't transform html anchors to eventsaction on
2.1.5release, as it was doing before (2.1.5dev) and after (head cvs). Am
i right?
Regards,
Phil
On Mon, 2004-06-28 at 21:33, Carsten Ziegeler wrote:
If I understand you correctly, the problem is in the pipeline calling
your coplet pipeline (calling page2?a=1).
The statement is in the sitemap in coplets/html/sitemap.xmap:
map:generate
src={coplet:temporaryAttributes/application-uri}?copletid={coplet:#}/
{coplet:temporaryAttributes/application-uri} should be replaced with the
original URI: page2?a=1, so the src for the generator will be
BASEURL/page2?a=1?copletid=something
which is obviously not a valid URL. If you don't need the coplet id in your
pipeline, you could remove the ?copletid={coplet:#} from the statement.
If this is your problem, we could solve it by either using a different
approach
to build the uri or by always including the copletid in the uri. This could
be done by the html-eventlink transformer.
HTH
Carsten
-Original Message-
From: Philippe Guillard [mailto:[EMAIL PROTECTED]
Sent: Monday, June 28, 2004 6:42 AM
To: [EMAIL PROTECTED]
Subject: portal-html-eventlink transformer and req-params ?
Hi,
On last cvs 2.1, with cachingURI coplet adapter and
portal-html-eventlink transformer, links like a
href=page2?a=1page2/a are transformed in action=xevent=y
I discovered the original request-params like a are put
before the question mark in the query string :
a=1?copletid=app-test-1cocoon-portal-action=1cocoon-portal-event=21
I get the request param a that is before ? from sitemap
or XSP Ok, but i don't know which method i should use to get
it directly from the servlet, i can only get what is behind
the ?. Any idea?
Regards,
Phil
portal-html-eventlink transformer and req-params ?
Hi, On last cvs 2.1, with cachingURI coplet adapter and portal-html-eventlink transformer, links like a href=page2?a=1page2/a are transformed in action=xevent=y I discovered the original request-params like a are put before the question mark in the query string : a=1?copletid=app-test-1cocoon-portal-action=1cocoon-portal-event=21 I get the request param a that is before ? from sitemap or XSP Ok, but i don't know which method i should use to get it directly from the servlet, i can only get what is behind the ?. Any idea? Regards, Phil
portal-html-eventlink transformer and req-params ?
Hi, On last cvs 2.1, with cachingURI coplet adapter and portal-html-eventlink transformer, links like a href=page2?a=1page2/a are transformed in action=xevent=y I discovered the original request-params like a are put before the question mark in the query string : a=1?copletid=app-test-1cocoon-portal-action=1cocoon-portal-event=21 I get the request param a that is before ? from sitemap or XSP Ok, but i don't know which method i should use to get it directly from the servlet, i can only get what is behind the ?. Any idea? Regards, Phil
