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: modifiable source and .tmp files
FYI, I just committed what we discussed with Jorg as a TeeTransformer component. HTH, Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Source.zone: http://sourcezone.info/ Wine Food Blog: http://www.divinocibo.it/ smime.p7s Description: S/MIME cryptographic signature
Re: Reset cachingURI coplet
* 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,
--
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: Internationalis/zation of documentation
A more general question: what sort of demand do you think there is for translations of the documentation? Any particular languages? Being Dutch, and therefore used to use other people's language rather than my own to get in contact with someone, I'm probably not representative for the entire community. I however feel that there should be as little effort put into translation of documentation as possible. Cocoon itself is in English, the common language of the mailing lists is English (and therefore the documentation) and 99% of the documentation of the 'external' (i.e. non-Cocoon development) components are in English, 99.9% of any documentation on IT projects is in English. So, if you want to use Cocoon, you need to understand English. If you do, what benefit is there in a translated version of a document? I'm a Translator School graduate, so I know how much effort a good translation takes and it only adds up to the total number of documents to maintain. NOTE: there is no such thing as an automated translation of good quality, so all effort is manual. I'd rather have this effort put into writing good/better/missing English docs. Bye, Helma
Re: Internationalis/zation of documentation
Le 26 mai 05, à 09:36, Linden H van der ((MI)) a écrit : ...I'd rather have this effort put into writing good/better/missing English docs... Same here. If people want to provide translations somewhere else (while complying with the ASF license of course), fine. But our community has plenty of work to do with english docs before considering any translation. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Internationalis/zation of documentation
how easy is to keep up-to-date documents in more tha one language? lets say that we have now someone to translate docs to a particular language, are we sure that in few months any volunteer will exist to keep those docs up-to-date ? it will be greate for me (for example) to read cocoon's documentation in greek but out-of-date docs in greek are worst. --stavros On 5/26/05, Linden H van der (MI) [EMAIL PROTECTED] wrote: A more general question: what sort of demand do you think there is for translations of the documentation? Any particular languages? Being Dutch, and therefore used to use other people's language rather than my own to get in contact with someone, I'm probably not representative for the entire community. I however feel that there should be as little effort put into translation of documentation as possible. Cocoon itself is in English, the common language of the mailing lists is English (and therefore the documentation) and 99% of the documentation of the 'external' (i.e. non-Cocoon development) components are in English, 99.9% of any documentation on IT projects is in English. So, if you want to use Cocoon, you need to understand English. If you do, what benefit is there in a translated version of a document? I'm a Translator School graduate, so I know how much effort a good translation takes and it only adds up to the total number of documents to maintain. NOTE: there is no such thing as an automated translation of good quality, so all effort is manual. I'd rather have this effort put into writing good/better/missing English docs. Bye, Helma -- Stavros KounisOsmosis networks consulting http://tools.osmosis.gr/blog http://www.osmosis.gr
Re: Block builder and deployer
Hi again, On 25 May 2005, at 10:39, David Casal wrote: If you read this far, I owe you a beer. Please get creative with your answers, comic-book style. *tumbleweed* Any suggestions as to whether I should post these questions on a new thread, or perhaps in cocoon-users, or just not in the cocoon mailing lists at all, very welcome. Hope it didn't bother anyone :-) d -- David Plans Casal, Director of Research, Luminas Internet Applications Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web:www.luminas.co.uk Orixo alliance: http://www.orixo.com/
Re: Block builder and deployer
David Casal wrote: Hi again, On 25 May 2005, at 10:39, David Casal wrote: If you read this far, I owe you a beer. Please get creative with your answers, comic-book style. *tumbleweed* Any suggestions as to whether I should post these questions on a new thread, or perhaps in cocoon-users, or just not in the cocoon mailing lists at all, very welcome. Hope it didn't bother anyone :-) There is *really* no need to appologize for asking questions . Most questions get some kind of answer and questions that someone finds intersting gets better answers. Your questions are relevant for the list and IMO interesting. It takes some time to answer such a general question, and I hadn't that time yesterday, I'll try to give my view on the topic later. In general it is better to change subject line if one changes the subject, it increase the chance to reach the right audience and makes it easier to search the archive. In this particular case I guess that the right audience follow this thread anyway. /Daniel
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,
Location of cforms stylesheets
Ugo Cei wrote:
Il giorno 26/mag/05, alle 10:43, angeloimm ha scritto:
Hi; first of all thanks for your answer.
But if i exclude the samples blocks. how can i use cforms and
portal blocks?
Must i confogure anything or by escluding these blocks ant will build
all in the right way?
I thought you wanted to run *your* Cocoon application, not the samples,
right? By excluding samples, you get a clean slate upon which you can
build anything. The only thing you might want to reuse from samples are
the CForms stylesheets, probably, but you can copy those to your app.
Don't know about the portal.
Should we move the stylesheets
- forms-advanced-field-styling.xsl
- forms-calendar-styling.xsl
- forms-field-styling.xsl
- forms-htmlarea-styling.xsl
- forms-page-styling.xsl
into the JAR file and reference them from forms-samples-styling.xsl using the
jar:/ protocol?
WDOT?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Location of cforms stylesheets
On 5/26/05, Reinhard Poetz [EMAIL PROTECTED] wrote:
Ugo Cei wrote:
Il giorno 26/mag/05, alle 10:43, angeloimm ha scritto:
Hi; first of all thanks for your answer.
But if i exclude the samples blocks. how can i use cforms and
portal blocks?
Must i confogure anything or by escluding these blocks ant will build
all in the right way?
I thought you wanted to run *your* Cocoon application, not the samples,
right? By excluding samples, you get a clean slate upon which you can
build anything. The only thing you might want to reuse from samples are
the CForms stylesheets, probably, but you can copy those to your app.
Don't know about the portal.
Should we move the stylesheets
- forms-advanced-field-styling.xsl
- forms-calendar-styling.xsl
- forms-field-styling.xsl
- forms-htmlarea-styling.xsl
- forms-page-styling.xsl
into the JAR file and reference them from forms-samples-styling.xsl using the
jar:/ protocol?
WDOT?
this will help me a lot
if not into the JAR a common place will be helpfull too
--stavros
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
--
Stavros KounisOsmosis networks consulting
http://tools.osmosis.gr/blog http://www.osmosis.gr
Re: Location of cforms stylesheets
On Jue, 26 de Mayo de 2005, 5:07, Reinhard Poetz dijo: Ugo Cei wrote: Il giorno 26/mag/05, alle 10:43, angeloimm ha scritto: Hi; first of all thanks for your answer. But if i exclude the samples blocks. how can i use cforms and portal blocks? Must i confogure anything or by escluding these blocks ant will build all in the right way? I thought you wanted to run *your* Cocoon application, not the samples, right? By excluding samples, you get a clean slate upon which you can build anything. The only thing you might want to reuse from samples are the CForms stylesheets, probably, but you can copy those to your app. Don't know about the portal. Should we move the stylesheets - forms-advanced-field-styling.xsl - forms-calendar-styling.xsl - forms-field-styling.xsl - forms-htmlarea-styling.xsl - forms-page-styling.xsl into the JAR file and reference them from forms-samples-styling.xsl using the jar:/ protocol? WDOT? I think some people don't use them as they are in cocoon. Best Regards, Antonio Gallardo.
Re: Location of cforms stylesheets
Antonio Gallardo wrote:
On Jue, 26 de Mayo de 2005, 5:07, Reinhard Poetz dijo:
Ugo Cei wrote:
Il giorno 26/mag/05, alle 10:43, angeloimm ha scritto:
Hi; first of all thanks for your answer.
But if i exclude the samples blocks. how can i use cforms and
portal blocks?
Must i confogure anything or by escluding these blocks ant will build
all in the right way?
I thought you wanted to run *your* Cocoon application, not the samples,
right? By excluding samples, you get a clean slate upon which you can
build anything. The only thing you might want to reuse from samples are
the CForms stylesheets, probably, but you can copy those to your app.
Don't know about the portal.
Should we move the stylesheets
- forms-advanced-field-styling.xsl
- forms-calendar-styling.xsl
- forms-field-styling.xsl
- forms-htmlarea-styling.xsl
- forms-page-styling.xsl
into the JAR file and reference them from forms-samples-styling.xsl using
the
jar:/ protocol?
WDOT?
I think some people don't use them as they are in cocoon.
sorry, I don't understand this. Do you mean that some people complelty rewrite
the stylesheets?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Location of cforms stylesheets
On Jue, 26 de Mayo de 2005, 5:21, Reinhard Poetz dijo: Antonio Gallardo wrote: On Jue, 26 de Mayo de 2005, 5:07, Reinhard Poetz dijo: Ugo Cei wrote: Il giorno 26/mag/05, alle 10:43, angeloimm ha scritto: Hi; first of all thanks for your answer. But if i exclude the samples blocks. how can i use cforms and portal blocks? Must i confogure anything or by escluding these blocks ant will build all in the right way? I thought you wanted to run *your* Cocoon application, not the samples, right? By excluding samples, you get a clean slate upon which you can build anything. The only thing you might want to reuse from samples are the CForms stylesheets, probably, but you can copy those to your app. Don't know about the portal. Should we move the stylesheets - forms-advanced-field-styling.xsl - forms-calendar-styling.xsl - forms-field-styling.xsl - forms-htmlarea-styling.xsl - forms-page-styling.xsl into the JAR file and reference them from forms-samples-styling.xsl using the jar:/ protocol? WDOT? I think some people don't use them as they are in cocoon. sorry, I don't understand this. Do you mean that some people complelty rewrite the stylesheets? Yep. Maybe not a full rewrite, but changes some things to meet some criteria. Best Regards, Antonio Gallardo
Re: Reset cachingURI coplet
* 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,
--
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/
DO NOT REPLY [Bug 35076] - cinclude parameters remove namespaces
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35076. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35076 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 12:36 --- *** This bug has been marked as a duplicate of 35075 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35075] - cinclude parameters remove namespaces
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35075. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35075 --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 12:36 --- *** Bug 35076 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35074] - cinclude parameters remove namespaces
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35074. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35074 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 12:36 --- *** This bug has been marked as a duplicate of 35075 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35075] - cinclude parameters remove namespaces
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35075. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35075 --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 12:37 --- *** Bug 35074 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Location of cforms stylesheets
Reinhard Poetz wrote: Should we move the stylesheets - forms-advanced-field-styling.xsl - forms-calendar-styling.xsl - forms-field-styling.xsl - forms-htmlarea-styling.xsl - forms-page-styling.xsl into the JAR file and reference them from forms-samples-styling.xsl using the jar:/ protocol? While you're at it, why not move all default CForms resources as well like suggested here [1] ? Back then, the thread seemed to have reached a consensus that this was a good idea. Jorg [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/44373
Re: Location of cforms stylesheets
Antonio Gallardo wrote:
On Jue, 26 de Mayo de 2005, 5:21, Reinhard Poetz dijo:
Antonio Gallardo wrote:
I think some people don't use them as they are in cocoon.
sorry, I don't understand this. Do you mean that some people complelty
rewrite
the stylesheets?
Yep. Maybe not a full rewrite, but changes some things to meet some criteria.
Isn't this the idea? You use xsl:include (e.g. xsl:include
href=jar://org/apache/cocoon/forms/resources/stylesheets/forms-page-styling.xsl)
in your stylesheet and override all xsl:template rules with project specific
content.
ATM the relative include is a major PITA in my opinion because every Cocoon
update forces me to copy the stylesheets and too often I forget ...
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Location of cforms stylesheets
Jorg Heymans wrote:
Reinhard Poetz wrote:
Should we move the stylesheets
- forms-advanced-field-styling.xsl
- forms-calendar-styling.xsl
- forms-field-styling.xsl
- forms-htmlarea-styling.xsl
- forms-page-styling.xsl
into the JAR file and reference them from forms-samples-styling.xsl
using the jar:/ protocol?
While you're at it, why not move all default CForms resources as well
like suggested here [1] ? Back then, the thread seemed to have reached a
consensus that this was a good idea.
Which resources are you missing in the JAR? IIRC I moved all of them. Did I
forget anything?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Location of cforms stylesheets
Il giorno 26/mag/05, alle 12:21, Reinhard Poetz ha scritto: sorry, I don't understand this. Do you mean that some people complelty rewrite the stylesheets? They probably modify them (like me). If you have them in the jar, it becomes more difficult and you risk confusion over what files are actually used when you have a locally modified copy. In short, I don't think it's a good idea, but then again I would prefer some better way to customize those. I don't know how, though. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Source.zone: http://sourcezone.info/ Wine Food Blog: http://www.divinocibo.it/ smime.p7s Description: S/MIME cryptographic signature
Re: Location of cforms stylesheets
Antonio Gallardo wrote: On Jue, 26 de Mayo de 2005, 5:21, Reinhard Poetz dijo: sorry, I don't understand this. Do you mean that some people complelty rewrite the stylesheets? Yep. Maybe not a full rewrite, but changes some things to meet some criteria. Best Regards, Antonio Gallardo FWIW that's what we've done for our app (made changes, not a full rewrite). Vil.
Re: Location of cforms stylesheets
Ugo Cei wrote:
Il giorno 26/mag/05, alle 12:21, Reinhard Poetz ha scritto:
sorry, I don't understand this. Do you mean that some people complelty
rewrite the stylesheets?
They probably modify them (like me).
Why do you modify them directly and don't override templates in the file that
includes them? Direct modifications is a very bad idea IMO. If you want to know
what they look like you can either extract them from the JAR or have a look at
SVN. Ok, not as convinient as having them copied into your custom project but
I'm willing to pay this price.
If you have them in the jar, it
becomes more difficult
That's not a disadvantage as they shouldn't be modified.
and you risk confusion over what files are
actually used when you have a locally modified copy.
In short, I don't think it's a good idea, but then again I would prefer
some better way to customize those. I don't know how, though.
I know but I don't think that you'll like the answer (real blocks) ;-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Location of cforms stylesheets
Reinhard Poetz wrote: Ugo Cei wrote: Il giorno 26/mag/05, alle 10:43, angeloimm ha scritto: Hi; first of all thanks for your answer. But if i exclude the samples blocks. how can i use cforms and portal blocks? Must i confogure anything or by escluding these blocks ant will build all in the right way? I thought you wanted to run *your* Cocoon application, not the samples, right? By excluding samples, you get a clean slate upon which you can build anything. The only thing you might want to reuse from samples are the CForms stylesheets, probably, but you can copy those to your app. Don't know about the portal. Should we move the stylesheets - forms-advanced-field-styling.xsl - forms-calendar-styling.xsl - forms-field-styling.xsl - forms-htmlarea-styling.xsl - forms-page-styling.xsl into the JAR file and reference them from forms-samples-styling.xsl using the jar:/ protocol? jar:/? did you mean resource:/ ? Anyway +1. I did not understand why these were left in samples dir while every other cforms resource was moved. These stylesheets are far to complex to be just samples now. One would have had a very serious reason to rewrite them completely. We should provide a detailed description what to do in order to customize some parts. (I do not know it myself and have also some modifications done). -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65 smime.p7s Description: S/MIME Cryptographic Signature
Re: Location of cforms stylesheets
Leszek Gawron wrote:
into the JAR file and reference them from forms-samples-styling.xsl
using the jar:/ protocol?
jar:/? did you mean resource:/ ?
ahm, yes ;-)
Anyway +1. I did not understand why these were left in samples dir while
every other cforms resource was moved.
When I moved the resources I wasn't aware of that every protocol that is
supported by Cocoon can be used in XSLT.
These stylesheets are far to
complex to be just samples now.
yes
One would have had a very serious reason
to rewrite them completely.
We should provide a detailed description what to do in order to
customize some parts. (I do not know it myself and have also some
modifications done).
I will add a small example
--
Reinhard Ptz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Other default cocoon resources (was: Location of cforms stylesheets)
Reinhard Poetz wrote: Should we move the stylesheets I would help a lot to be able to deploy cocoon with no additional files at all. What do you say if we moved cocoon logo and default stylesheets (the ones styling error pages etc.) to some jar (either existing or a new one)? This way we can have cocoon that consists of: - bunch of .jar files - web.xml which hardly changes - a set of .xconf and logkit files. It's a pity we cannot move .xconf files into jars. This way cocoon would be much more friendly for dependency resolution tools like maven. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65 smime.p7s Description: S/MIME Cryptographic Signature
Re: Other default cocoon resources
Leszek Gawron wrote: Reinhard Poetz wrote: Should we move the stylesheets I would help a lot to be able to deploy cocoon with no additional files at all. What do you say if we moved cocoon logo and default stylesheets (the ones styling error pages etc.) to some jar (either existing or a new one)? A new one. IMO we should move away from the monolitic thinking and start to think in terms of pluggins/bundles/blocks. Making the minimal Cocoon really lean would help using it embeded in new and innovative contexts, http://marc.theaimsgroup.com/?t=11136640512r=1w=2. This way we can have cocoon that consists of: - bunch of .jar files - web.xml which hardly changes - a set of .xconf and logkit files. +1 It's a pity we cannot move .xconf files into jars. Why can't we? This way cocoon would be much more friendly for dependency resolution tools like maven. /Daniel
Re: Location of cforms stylesheets
Le 26 mai 05, à 12:07, Reinhard Poetz a écrit : Should we move the stylesheets ... into the JAR file and reference them from forms-samples-styling.xsl using the jar:/ protocol? +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Other default cocoon resources
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
Should we move the stylesheets
I would help a lot to be able to deploy cocoon with no additional
files at all. What do you say if we moved cocoon logo and default
stylesheets (the ones styling error pages etc.) to some jar (either
existing or a new one)?
A new one. IMO we should move away from the monolitic thinking and start
to think in terms of pluggins/bundles/blocks. Making the minimal Cocoon
really lean would help using it embeded in new and innovative contexts,
http://marc.theaimsgroup.com/?t=11136640512r=1w=2.
This way we can have cocoon that consists of:
- bunch of .jar files
- web.xml which hardly changes
- a set of .xconf and logkit files.
+1
It's a pity we cannot move .xconf files into jars.
Why can't we?
theoretically we can but soon we will have .cob files that *are* single files.
So for now *I* wouldn't invest too much work.
--
Reinhard Ptz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
[RT] Block usage
David Casal wrote: snip/ how do you see the common user approaching the development of new webapp, considering they might not have a senior level of development experience? Could you illustrate your ideal use case scenario? snip/ We haven't discussed use case scenarious in a more systematic way for quite some time. Bits and pieces have been discussed in technical threads although not in any way that have been easy to follow for those not involved in the specifics. What's described in http://wiki.apache.org/cocoon/BlockIntroduction and http://wiki.apache.org/cocoon/BlocksUseCases still holds. But Cocoon has changed since then, new technologies have appeared and we have learnt more by discussing and trying to implement the blocks so it could be worthwhile to discuss the user experience of blocks again. I'll mix up the use case with some technical details on how it might be implemented. The terms block, bundle and plugin are synonymes in this RT. Ok, here is my current view: A basic scenario 1. A soon to become Cocoon user, downloads the start kit distribution from our site. It contains the (OSGi) kernel, the Cocoon service block (containing the Cocoon core), a Cocoon servlet block, a (light weight) web server block, a block deployer block, a block depoyer webapp block, a get started tutorial block and some basic blocks (template, cforms, xslt, flow, ...) that the previous blocks depends on. 2. The user double clicks the distribution and answer where to install it and whether the tutorial webapp should be started. It is not certain that the distribution contains all the above physically, it might download its dependencies during this step. Those thinking about using Maven etc can probably give a better view on this. If the user chose to start the tutorial webapp, the kernel will be started and the blocks listed above will be installed into the kernel and started. The start page for the tutorial will be mounted at e.g. / and will be served through the call chain: web server block - Cocoon servlet block - Cocoon service block - Get started tutorial block. 3. The user points the browser at http://localhost:/ and start to follow the tutorial. Here we have IMO a lot to learn from Forrest. When you have dowloaded and installed Forrest you directly gets instructions about how to start use it. 4. The user can chose between following a number of different wizard like tutorials, e.g.: Minimal Cocoon app, documentation site (Forrest), portal, CMS site (Lenya or Daisy), Spring based webapp etc. In this step the needed blocks (including the specific tutorial/wizard) will be dowloaded, installed and started. A user block skeleton will be created. It should be noted that the created user block is much simpler than what is needed today. It is a directory with a description of what blocks the block depends on (wiring.xml and the Manifest file), a near to empty sitemap and that is all. 5. The user start to develop the new application from the skeleton one and have at all times a working app that can be used from the browser. I think polymorphic extension will be a key mechanism for making it easy for users to develop new apps. Let us say that you want to create a documentation site. Then your skeleton block extends the Forrest block, which allready contain an example documentation site. By extending the Forrest block, your new this far empty, block allready delivers content. The Forrest block is designed in such a way that everything that you might want to change or extend: content, menues, styling, configuration etc is available through the blocks sitemap (some of it only internally). By overiding the URLs of these things in your own sitemap with own content you can one step at the time adapt the default app to your own needs. For some of the inherited resources you just want to modify the original content. This can be done by applying a stylesheet on block:super:. Also components from the extended block can be overrided. 6. The new block contain some new and intersting stuff that is not available before. After a number of refactorings it consists of a number of blocks that are reusable and solves well defined concerns. Now the user puts the blocks in a new project in Sourceforge (or cocoondev.org etc). An important aspect of blocks is that they can make Cocoon development much more scalable and distributed. To make this possible we must, IMO, split the Cocoon core of today in a number of blocks. These blocks should have well defined concern areas, and in some cases own release cycles. We should also be much more carefull about what is external interfaces and classes and what is only for internal use. Above all we should have a lean, mean and rock stable core, containing the basic mechanisms for the sitemap and (possibly) component management and the minimal set of core interfaces. This is a must for
Re: [RT] Block usage
Daniel Fagerstrom wrote: David Casal wrote: snip/ how do you see the common user approaching the development of new webapp, considering they might not have a senior level of development experience? Could you illustrate your ideal use case scenario? snip/ We haven't discussed use case scenarious in a more systematic way for quite some time. Bits and pieces have been discussed in technical threads although not in any way that have been easy to follow for those not involved in the specifics. What's described in http://wiki.apache.org/cocoon/BlockIntroduction and http://wiki.apache.org/cocoon/BlocksUseCases still holds. But Cocoon has changed since then, new technologies have appeared and we have learnt more by discussing and trying to implement the blocks so it could be worthwhile to discuss the user experience of blocks again. I'll mix up the use case with some technical details on how it might be implemented. The terms block, bundle and plugin are synonymes in this RT. Ok, here is my current view: A basic scenario 1. A soon to become Cocoon user, downloads the start kit distribution from our site. It contains the (OSGi) kernel, the Cocoon service block (containing the Cocoon core), a Cocoon servlet block, ok a (light weight) web server block, you mean a block that contains e.g. Jetty or Tomcat? IMO this could only be an option but not a requirement. Cocoon must be deployable in a J2EE or servlet container. a block deployer block Basically the block deployer will be a stand-alone application (Ant task, Maven plug-in, Eclipse plug-in, ...). Of course somebody could write a web interface for it which could be a cocoon block. , a block depoyer webapp block, a get started tutorial block and some basic blocks (template, cforms, xslt, flow, ...) that the previous blocks depends on. ok 2. The user double clicks the distribution and answer where to install it and whether the tutorial webapp should be started. It is not certain that the distribution contains all the above physically, we can have different distributions it might download its dependencies during this step. Those thinking about using Maven etc can probably give a better view on this. If the user chose to start the tutorial webapp, the kernel will be started and the blocks listed above will be installed into the kernel and started. The start page for the tutorial will be mounted at e.g. / and will be served through the call chain: web server block - Cocoon servlet block - Cocoon service block - Get started tutorial block. 3. The user points the browser at http://localhost:/ and start to follow the tutorial. Here we have IMO a lot to learn from Forrest. When you have dowloaded and installed Forrest you directly gets instructions about how to start use it. 4. The user can chose between following a number of different wizard like tutorials, e.g.: Minimal Cocoon app, documentation site (Forrest), portal, CMS site (Lenya or Daisy), Spring based webapp etc. In this step the needed blocks (including the specific tutorial/wizard) will be dowloaded, installed and started. A user block skeleton will be created. It should be noted that the created user block is much simpler than what is needed today. It is a directory with a description of what blocks the block depends on called block.xml, no? (wiring.xml and the Manifest file), a near to empty sitemap and that is all. 5. The user start to develop the new application from the skeleton one and have at all times a working app that can be used from the browser. I think polymorphic extension will be a key mechanism for making it easy for users to develop new apps. Let us say that you want to create a documentation site. Then your skeleton block extends the Forrest block, which allready contain an example documentation site. By extending the Forrest block, your new this far empty, block allready delivers content. The Forrest block is designed in such a way that everything that you might want to change or extend: content, menues, styling, configuration etc is available through the blocks sitemap (some of it only internally). By overiding the URLs of these things in your own sitemap with own content you can one step at the time adapt the default app to your own needs. For some of the inherited resources you just want to modify the original content. This can be done by applying a stylesheet on block:super:. Also components from the extended block can be overrided. I remember one or two mails about this some months ago ;-) 6. The new block contain some new and intersting stuff that is not available before. After a number of refactorings it consists of a number of blocks that are reusable and solves well defined concerns. Now the user puts the blocks in a new project in Sourceforge (or cocoondev.org etc). An important aspect of blocks is that they can make Cocoon development much
Re: Speed of jx-macros compared to FormsTransformer
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Can you re-test with latest template transformer - just to confirm
that it did not got much slower after refactoring.
it's done with the refactored version (rev170868)
I meant FormsTemplateTransformer :-) r170923 (2.1 branch, r170933 for
trunk) or later.
ok, will have a look at it, hopefully at the weekend.
my recent tests show that your changes don't influence the performance, neither
positivly nor negativly. Or at least I can't measure it.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Planet Cocoon license and reuse of docs
On 24 May 2005, at 22:42, Upayavira wrote: If someone else can offer an existing CMS that has the features they need, and can be installed and operational within a reasonable amount of time, then we'd be asking different questions. I'm at a conference this week, so e-mail access is erratic. That said, next week I'll be back, and if we have our Solaris zone set up and I have access to it (Antonio?), I'll set up MySQL 4.1 + Daisy 1.3M2 on that zone. We don't have time currently to implement an xdocs importer or exporter, but I doubt this is an unachievable task. If anyone wants to beat us to it (and please do), there's the ancient JSPWiki importer in the Daisy SVN repo (which would need to be updated anyhow). An exporter however is a different beast altogether, but we make a sincere promise we'll try to get there in the foreseeable future. Not a question of do-a-bility, but rather time and priorities. I wouldn't bother too much with an importer, since IMHO we need a clean sheet to work with. OK? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [RT] Block usage
Reinhard Poetz wrote: Daniel Fagerstrom wrote: snip/ A basic scenario 1. A soon to become Cocoon user, downloads the start kit distribution from our site. It contains the (OSGi) kernel, the Cocoon service block (containing the Cocoon core), a Cocoon servlet block, ok a (light weight) web server block, you mean a block that contains e.g. Jetty or Tomcat? Yes, there is a standard http service api in the OSGi spec, and there are bundles based on both Jetty and Tomcat that implement that api. IMO this could only be an option but not a requirement. Cocoon must be deployable in a J2EE or servlet container. As we have discussed before we should support both cases. What I describe is a start kit distribution that helps a new user to get up to speed. Puting a http service block in the start kit distro coresponds to our current bundling of Jetty. All blocks should be separately downloadable so that the experienced users can mix and match as they want to. a block deployer block Basically the block deployer will be a stand-alone application (Ant task, Maven plug-in, Eclipse plug-in, ...). Of course somebody could write a web interface for it which could be a cocoon block. As you can see in my original message I proposed: a block deployer block, a block depoyer webapp block. Web interface and functinality should cleary be kept separately. snip/ called block.xml, no? (wiring.xml and the Manifest file), a near Yes, block.xml. snip/ One thing to add: It must be possible that one block depends on another block that is under development. I want my custom projects requiring the latest svn version of e.g. the forms block. If the forms block changes, this change takes effect immediatly on my project without explicit deployment. Absolutely! /Daniel
Re: Block builder and deployer
David Casal wrote: Do you see a point where they'll be able to put together semi-complex webapps in LEGO style? Dude, can you read? http://cocoon.apache.org/ [very first paragraph] :-) [nobody is responding because that's like asking: do you see a future of open source for this project? WTF man!?!] Secondly, if you were to think much further ahead in the future, do you see agent-driven applications calling containers which might or might not call Cocoon components into a user's 'Webapp Building' tool? Does the work Stefano is carrying out at MIT (Simile, PiggyBank) make you think of emergent people processing, whereby people might be able to use Firefox to build web applications, by having the browser enquire RDF repositories for the right components and their dependencies? Honestly, the whole thing has more the flavor of sci-fi or VC-oriented BS than any real technology (see below) If you read this far, I owe you a beer. Please get creative with your answers, comic-book style. I'd like to have your wildest dreams for cocoon, even if all I get is 'I'd like cocoon to run my house' or 'shut the fuck up you piano playing barbarian'. David, people are talking about agents, but how is an agent different than a program? My spam filter saves me hours every single day, it's a very complex beast and achieves impressive results (better than me, for sure). Is that an agent? In the it's working for you sense it is, if it's spamassassin, it's also downloading information from the network to fulfill its task. Agents and web services are fancy names to describe stuff that we have been doing since the days the concept of 'client-server' was born. We are moving into describing the borders of this concepts in a more precise way, mostly by specifying more on the data being transfered and the nature of the service interaction, but at the end, it's the same architectural concept. Firefox extensions contain RDF that indicates where they come from, their version and so on. So, in a sort of way, Firefox is a lego-like semantic agent. But again, that's BS, it's just the way they do things, not necessarely the only way to achieve the same functionality. We could write the cocoon blocks metadata in RDF (I would suggest we do so, but not now), but if the cocoon kernel doesn't support easy installation, that doesn't buy us anything. Your dream are not wild at all, btw, they are actually very moderate, the lego-like approach has been in my vision of cocoon since before cocoon even started (it was the vision behind avalon). As for automatic deployment of blocks, again, this was in our vision for avalon already in 1998, but never managed to get it bootstrapped (and we still struggle with that here for cocoon blocks). What I think it's pure BS is the idea that the general population will use Firefox to build web applications. There is a huge cognitive difference between seeing your client adapt to your needs, and instruct it to do so. The second approach is something only a small percentage of the general population has interest in doing. I *do* see the ability for a client to be able to download pieces of code that enable more powerful functionality, but this has to be transparent, unnoticed, seemless and less intrusive as possible. In such a sense, the embed/object/applet tags in HTML go in that direction already, as the iframe-based DHTML embedding used by some (ie. google maps). And the generation of that HTML might be a result (as in piggy-bank) of complex, client side operations on a more sofisticated memory model of the data. In fact, my next task for Piggy-bank is to find a way to allow 'user selectable' views of your data (we call those lenses), and there has been a huge discussion about the feasibility of this approach declaratively on the [EMAIL PROTECTED] mailing list about the Fresnel RDF presentation ontology (fresnel, lenses, got it?) (find more at http://simile.mit.edu/fresnel/) Yes, the vision is that the user will get more power having to do less, but this is the vision of pretty much any reasonable technology. Is not the what that counts here (that's the easy part), it's the how. And believe me, nobody really has any clue of what is going to work or what is going to fail miserably (that's why is called 'research') -- Stefano.
Re: Internationalis/zation of documentation
Hi Sébastien, That being said, this graph may shed light on the reality of the situation: http://dir.gmane.org/gmane.text.xml.cocoon.french Admittedly, the graph is similar here: http://dir.gmane.org/gmane.text.xml.cocoon.user It just goes to show, no initiative is safe from entropy. Mark On 26 May 2005, at 14:19, Sebastien Arbogast wrote: 2005/5/26, Mark Leicester [EMAIL PROTECTED]: One of the reasons I installed the i18n module into Planet Cocoon was that I noticed internationalisation mentioned as a feature the Doco proposal, which Antonio recently linked to at the end of this long thread about documentation (http://www.planetcocoon.com/en/node/1969): http://wiki.apache.org/cocoon/Doco I agree, it would be easier for everyone (who speaks good English) if we removed this requirement! Mark's initiative is fully coherent with our motivation at Planet Cocoon : making Cocoon documentation closer to its users (and once again, its users are not only its developers). We are trying to make a documentation platform which is simpler to use and write for. And now with this new i18n module we just opened the door to people who understand English enough to read, but not to write. The way I see it, we will mostly use that as another input, another potential source of documentation but we have to setup a converter on that input, translators to keep the documentation coherent and prevent the above mentioned maintenance problems. Of course I agree our priority is to get a good core English documentation. But it appears obvious to me that it's far easier to translate an existing documentation than to create one from scratch in a language that is not natural to you. It's just a matter of... separation of concerns : the author has the ideas, the translator has the language, reviewers have the knowledge to verify, etc. Finally the greatest advantage of this internationalization thing is that we will be able to eventually setup forums in other languages, which should help spread Cocoon community and get this tool closer to the user (always the same motivation). How did you guys react when the French mailing list was setup ? Let me just translate a small part of Sylvain's introduction in Cocoon French area... Why a French area ? On the occasion of the many contacts I had with Cocoon users in France, whether it was through French-speaking sites such as XMLfr or directly, it came to me that few of them were subsribed to the English-speaking mailing list, and that many of them weren't aware of the importance of the community in open source projects. That's why the French area has been created, to make it possible for French-speaking Cocoon users (and not only French ones) to join the great Apache community to share, discuss, and not to be alone anymore in front of the problems that occur when they use Cocoon. That area is likely to be limited to a few pages of general introduction and to the mailing list. Translating the whole documentation is a huge task that we are not ready to tackle on, unless some volunteer ! Nothing to add, that's exactly what we want to achieve : share widely, because Open Source should also mean Open Community, and not a community that just says we don't need them, we have enough work to do here... -- Sebastien ARBOGAST
Re: Planet Cocoon license and reuse of docs
Le 26 mai 05, à 15:35, Steven Noels a écrit : ...That said, next week I'll be back, and if we have our Solaris zone set up and I have access to it (Antonio?), I'll set up MySQL 4.1 + Daisy 1.3M2 on that zone... Cool. I cannot help ATM but this sounds good. ...I wouldn't bother too much with an importer, since IMHO we need a clean sheet to work with. OK? Yes - people can always copy and paste from legacy docs where it makes sense. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Internationalis/zation of documentation
Sebastien Arbogast wrote: Mark's initiative is fully coherent with our motivation at Planet Cocoon : making Cocoon documentation closer to its users (and once again, its users are not only its developers). We are trying to make a documentation platform which is simpler to use and write for. And now with this new i18n module we just opened the door to people who understand English enough to read, but not to write. Sort of. Most of these translators do a poor job at creating understandable translations. Furthermore, as was pointed out in another post, 99% of the documentation for the things Cocoon depends on is in English. So what's the point? However, you can do whatever you want at PlanetCocoon in this regard. Just don't expect the official docs to be in anything but English. The way I see it, we will mostly use that as another input, another potential source of documentation but we have to setup a converter on that input, translators to keep the documentation coherent and prevent the above mentioned maintenance problems. Of course I agree our priority is to get a good core English documentation. But it appears obvious to me that it's far easier to translate an existing documentation than to create one from scratch in a language that is not natural to you. It's just a matter of... separation of concerns : the author has the ideas, the translator has the language, reviewers have the knowledge to verify, etc. Finally the greatest advantage of this internationalization thing is that we will be able to eventually setup forums in other languages, which should help spread Cocoon community and get this tool closer to the user (always the same motivation). How did you guys react when the French mailing list was setup ? Let me just translate a small part of Sylvain's introduction in Cocoon French area... And serious reservations were expressed during that discussion about fragmenting the Cocoon community. Each list or forum needs to have committers actively participate. Furthermore, the same questions would tend to get asked on each list and searching for answers in the archives becomes a problem. The French list was allowed to be created to see how it goes and because Sylvain offered to take responsibility for it. Ralph
Re: Planet Cocoon license and reuse of docs
Bertrand Delacretaz wrote: Le 26 mai 05, à 15:35, Steven Noels a écrit : ...That said, next week I'll be back, and if we have our Solaris zone set up and I have access to it (Antonio?), I'll set up MySQL 4.1 + Daisy 1.3M2 on that zone... Cool. I cannot help ATM but this sounds good. +1 Also there seem to be a lot of activity at Lenya-dev in making Doco http://wiki.apache.org/cocoon/Doco happen on the zone http://thread.gmane.org/gmane.comp.cms.lenya.devel/11071. So one way or another we hopefully soon will be able to work on our documentation on a first class Cocoon based CMS on ASF hardware :) /Daniel
Re: Planet Cocoon license and reuse of docs
Steven Noels wrote: On 24 May 2005, at 22:42, Upayavira wrote: If someone else can offer an existing CMS that has the features they need, and can be installed and operational within a reasonable amount of time, then we'd be asking different questions. I'm at a conference this week, so e-mail access is erratic. That said, next week I'll be back, and if we have our Solaris zone set up and I have access to it (Antonio?), I'll set up MySQL 4.1 + Daisy 1.3M2 on that zone. We don't have time currently to implement an xdocs importer or exporter, but I doubt this is an unachievable task. If anyone wants to beat us to it (and please do), there's the ancient JSPWiki importer in the Daisy SVN repo (which would need to be updated anyhow). An exporter however is a different beast altogether, but we make a sincere promise we'll try to get there in the foreseeable future. Not a question of do-a-bility, but rather time and priorities. Forrest, with the Daisy plugin, provides most of the export already (need a little more work on it to make it complete). I wouldn't bother too much with an importer, since IMHO we need a clean sheet to work with. I agree, and using Forrest removes the need to create the importer. We can either migrate active and accurate documents gradually to Daisy, or we can just use them from their current location. This provides an *immediate* start on new documentation without forking content and without starting from a completely blank slate. In other words, exactly what was started with the documentation review. With respect to using Daisy with/without Forrest. Personally, I would never replace Forrest as it allows content from different sources to be integrated into the final documentation. In other words it allows us to leverage content from initiatives such as Planet Cocoon if they start to produce something worthwhile. OK? We have different views about the final publication stage, but we are in total agreement about using Daisy as the CMS, so yes, yes yes!!! Ross
Re: Location of cforms stylesheets
Il giorno 26/mag/05, alle 13:12, Reinhard Poetz ha scritto: Why do you modify them directly and don't override templates in the file that includes them? Direct modifications is a very bad idea IMO. If you want to know what they look like you can either extract them from the JAR or have a look at SVN. Ok, not as convinient as having them copied into your custom project but I'm willing to pay this price. Because sometimes the modification is small but must be done across numerous templates, like adding class attributes here and there. Probably those stylesheets should be designed for extensibility from the start, and not as samples. Right now, the situation is akin to having to extend a Java class by overriding method implementations, whereas it would be more effective to use a template method pattern with well-defined extension points. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Source.zone: http://sourcezone.info/ Wine Food Blog: http://www.divinocibo.it/ smime.p7s Description: S/MIME cryptographic signature
Re: CForms : multivaluefield
Hi Guys
I really think I have a bug . but before I escalate this, could
someone give me a sanity check ?
I have a bunch of Strings in an ArrayList in provider.resourceList :
function addInstrument(form) {
. . .
var unit = {
resources:provider.resourceList,
. . .
};
form.load(unit);
form.showForm(screen, {resources:getSimpleSelectionList
(provider.resourceList)});
form.save(unit);
. . .
}
// make a Selection List from a List of Strings
function getSimpleSelectionList(list) {
var out = new Array(list.size());
for (var i = 0; i list.size(); i++) out[i] = {value: list.get
(i)};
return out;
}
Model:
fd:multivaluefield id=resources
fd:labeli18n:text
i18n:catalogue=editorinstrument.resources.label/i18n:text/
fd:label
fd:datatype base=string/
fd:validationfd:value-count min=1//fd:validation
fd:selection-list type=flow-jxpath list-path=resources
value-path=value label-path=value/
/fd:multivaluefield
Binding :
fb:multi-value id=resources parent-path=. row-
path=resources direction=both/
Template :
ft:widget id=resourcesfi:styling list-type=checkbox//
ft:widget
So, you start off with a form with a list of Checkboxes, all selected.
eg.
X Item One
X Item Two
X Item Three
You uncheck Items Two and Three, your resulting list contains Item
One, Item Two.
Instead if you uncheck One and Two, your resulting list contains Item
Three, Item Two.
Instead you uncheck One and Three, your resulting list contains Item
Two, Item Two.
Is this as broken as it seems? Or have I done something stupid with
my binding (etc.) ?
Thanks for any suggestions.
regards Jeremy
On 25 May 2005, at 18:50, Jeremy Quinn wrote:
Hi All,
I am using a multivaluefield and I am having strange effects.
I have a form to edit a Bean. The Bean has an ArrayList which is
populated with a bunch of Strings. The form displays this ArrayList
in a multivaluefield, which has all entries initially selected by
having identical items in both the selectionlist and the Bean. You
use the Form to deselect some of the entries.
I found that I was getting deselected (and sometimes duplicated)
entries in the Bean after the form had been used.
What appears to be happening, is that when
o.a.c.forms.bindingMultiValueJXPathBinding calls
multiValueContext.removeAll(this.rowPath), not all entries are
removed.
I started with a Bean that had 4 items in it's ArrayList.
I counted the items in the ArrayList either side of the call to
removeAll :
multiValueContext.getValue(count( + this.rowPath + ));
The first time it is called it reports 4, after removeAll it
reports 3.
In fact removeAll in this case only ever seems to remove one entry.
So the reason that this does not show up in the form2_bind_bean
CForms Sample, appears to be that it has only 2 items in the Bean
to start with and has validation to only allow 2 to be submitted.
Looking at
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.removeAll I
do not see any obvious reasons why it is not working.
Any suggestions anyone ?
Can anyone else replicate this problem ?
Or am I barking up the wrong tree ?
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
RE: [RFE] Some enhancements to XSP
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 25. Mai 2005 20:47
To: dev@cocoon.apache.org
Subject: Re: [RFE] Some enhancements to XSP
3. A mechanism for expression replacement as in XSLT or JXTG, replacing
{expression} with a xsp:attribute element in attributes and with a
xsp:expr element in character data. This could be implemented in the
PreProcessFilter of XSPMarkupLanguage. The feature would be disabled by
default and enabled on a per-XSP-basis, maybe through a processing
instruction.
Example:
!-- Hey, this looks almost like JXTG :) --
img src={source} width={width} height={height}/
h1Hello {username}/h1
is more readable and easier to use than
img
xsp:attribute
name=srcxsp:exprsource/xsp:expr/xsp:attribute
xsp:attribute
name=widthxsp:exprwidth/xsp:expr/xsp:attribute
xsp:attribute
name=heightxsp:exprheight/xsp:expr/xsp:attribute
/img
h1Hello xsp:exprusername/xsp:expr/h1
Any comments?
I'm not in favour of h1Hello {username}/h1.
(I hope this hasn't been proposed already, but I
didn't find anything about it)
See [1].
Don't think in-text replacement is a good idea.
I think it's great idea, and, moreover, it is already implemented in another
XSP
implementation - AxKit [1]. So implementing the feature makes sense - it will
consolidate XSP standard.
The preprocess would
need too much knowledge about xsp markup in order not to try expanding
curlies inside xsp:logic, xsp:expr etc.
Curlies (should) are always expanded in the attribute values only - same as in
XSLT. No evaluation in any other place - so in this case it is very simple.
I think I was too terse to make myself understand. With in-text replacement
I meant
h1Hello {username}/h1
as shortcut for
h1Hello xsp:exprusername/xsp:expr/h1
I am against that because it risks to break too many existing XSP containing
curlies for whatever reason in text nodes. I am also -1 on activating that
feature on a per-page. Whilst I am all for improving XSPs I would want to
avoid creating a second dialect. (Of course a temporary safeguard as in [1],
with the intention to make it the default later, is okay.)
Also for the src={source} shortcut I am sceptic. It breaks when
you want to move your img content markup from XSP to logicsheet.
Please elaborate, what breaks and why?
I was just thinking of XSP as staging ground for code which later might be
moved to a logicsheet. One can move a sniplet like
img
xsp:attribute name=srcxsp:exprsource/xsp:expr/xsp:attribute
/img
unchanged from XSP and logicsheet whilst img src={source}/ needs to
be adaption.
But I had the misconception that there was the danger that in the logicsheet
it would silently generate img src=/. However, XSLT will signal source
as invalid expression to catch the error at compile time.
So I changed my mind and now, I am in favor of it.
But I agree that the xsp:attribute markup is too verbose. I'd rather
wish for the XSLT analogy:
xsp:attribute name=src value=source/
That can be trivially added - on top of what we have now. Not sure why it was
missing...
Vadim
Shall we add it then?
Here's my +1.
Cheers, Alfred.
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105783302326147
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please notify the sender urgently and then immediately delete the message and
any copies of it from your system. Please also immediately destroy any
hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this message are
those of the individual sender, except where the message states otherwise and
the sender is authorised to state them to be the views of the sender's company.
RE: [RT] Block usage
-Original Message- From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 26. Mai 2005 15:42 To: dev@cocoon.apache.org Subject: Re: [RT] Block usage a block deployer block Basically the block deployer will be a stand-alone application (Ant task, Maven plug-in, Eclipse plug-in, ...). Of course somebody could write a web interface for it which could be a cocoon block. As you can see in my original message I proposed: a block deployer block, a block depoyer webapp block. Web interface and functinality should cleary be kept separately. Having read the OSGi whitepaper but not having followed in detail the discussion about the vision of real blocks, I am confused now. Aren't OSGi bundles already what Cocoon blocks want to be? Just package each block into a bundle with the right dependencies and deploy it into the OSGi kernel. What am I missing? Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: [RT] Block usage
Nathaniel Alfred wrote:
-Original Message-
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 26. Mai 2005 15:42
To: dev@cocoon.apache.org
Subject: Re: [RT] Block usage
a block deployer block
Basically the block deployer will be a stand-alone application (Ant
task, Maven plug-in, Eclipse plug-in, ...). Of course somebody could
write a web interface for it which could be a cocoon block.
As you can see in my original message I proposed: a block deployer
block, a block depoyer webapp block. Web interface and functinality
should cleary be kept separately.
Having read the OSGi whitepaper but not having followed in detail the
discussion about the vision of real blocks, I am confused now.
Aren't OSGi bundles already what Cocoon blocks want to be? Just
package each block into a bundle with the right dependencies and
deploy it into the OSGi kernel.
true for the classloading part
What am I missing?
... but there needs some work to enable the blocks:/ protocol, component
management and block-aware flowscript (e.g. cocoon.blocks.blockA.myFunc())
Additionally we have to integrate Torsten's classloader to ease development and
we need to work on block building and deploying.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Planet Cocoon license and reuse of docs
Helma, I don't want to discourage the effort to create a or deploy a Cocoon based CMS. I think its important that it gets done. My point is that no mater how easy and automated the process becomes, good documentation requires a great deal of human collaborative effort. On May 25, 2005, at 8:30 AM, Linden H van der (MI) wrote: - pick a tool, any tool that meets the criteria I mentioned above and start a new set of documentation there. I suggest Daisy. What you should be concerned about is managing new and existing content. This includes some process for accepting vetting, editing/ correcting and publishing. In short a CMS type of tool LOL I'm a big believer in automation but I think its to much to ask of a CMS to vet, edit and correct documents. ;-) Let me be clear, a CMS is an important tool that needs to be in place to help manage the process. When a document is submitted someone must read it. Upon reading it, they make a judgement as to whether it meets some criteria of acceptability. If deemed acceptable it is then vetted by experts. The experts make suggestions concerning content. The author and her expert collaborators make changes to the content. At this point an editor will examine the document for readability, spelling and grammar. The editor in collaboration with the author corrects and improves the document. Once all corrections are made, the author, experts and editor sign off on it and the document is formated and published. Until the document is formated what we are dealing with is pure content. We shouldn't care about layout, formatting, hyperlinks or anything other then the documents content. It is at this point one may choose the editor provided by the CMS to convert the source document, but it is not the only choice. It can be done by hand or better yet, automated. Once the original document is published the role of the CMS is to manage and facilitate updates to the document. It is at this point that an online editor becomes useful for small changes. Substantial changes are best handled by the same process that created the original document. The role of the CMS is to facilitate this workflow. My argument is not with the need for a CMS but with the vision of how it will be used to improve the documentation but providing a simple single creation and editing entry point. Why require a particular tool? Is everyone who contributes code to Cocoon required to use Eclipse? Since documentation is best gathered in a CMS, because there will likely (hopefully) be more than one person working on it, this inevitably means that everyone should use THAT CMS to avoid scattering documentation all over the place (wiki, website, mailing list, blogs, own websites etc). I don't think a CMS will alleviate this problem. Wikies, websites, mailing lists, blogs etc. are the most suitable places for some forms of documentation. A CMS will allow the fromal Cocoon community to better manage the content which it owns. What if the new document is far superior to the existing in terms of Hurray for that. But if you've come up with something that replaces information in other places, do note that in both origin and destination to avoid others duplicating the effort. Yes, the human element creeps in again. Someone needs to decide that one document is superior to another and replace the old with the new. When such a change occurs the community should be notified as well. Depreciated documentation is documentation none the less. I believe the new improved documentation should provide a reference and a link to the documentation it replaces. content and clarity? Who decides this? Do we leave this decision to the author? Frankly if I'm going to write some documentation, I'm going to do it because I'm unhappy with what exists and I am likely to start from scratch or just completely rewrite what exists. Great! Go ahead. If you feel comfortable enough to write something about any aspect of Cocoon, please do. The only thing I ask from reviewers (aka Cocoon committers) is that they read your document and compare what you write to the actual working of Cocoon to see if there are discrepancies that might lead to false conclusions/understanding from other users. I certainly hope that they would. If they find errors I want to know about them and correct them. I really should get off may lazy ass and do it. This is an essential step in producing good documentation. It is also a very time consuming one. Experts are very useful when it comes to verifying the broad pictures and approaches but to often their knowledge of the field makes it easy for them to understand the intention of the author when a newbie will be completely lost. OTOH If you write down that CForms has a state 'readonly' when in fact it's 'disabled' that's something Sylvain e.g. will probably notice immediately while
Re: Planet Cocoon license and reuse of docs
Glen Ezkovich wrote: Since documentation is best gathered in a CMS, because there will likely (hopefully) be more than one person working on it, this inevitably means that everyone should use THAT CMS to avoid scattering documentation all over the place (wiki, website, mailing list, blogs, own websites etc). I don't think a CMS will alleviate this problem. Wikies, websites, mailing lists, blogs etc. are the most suitable places for some forms of documentation. A CMS will allow the fromal Cocoon community to better manage the content which it owns. I am in agreement with you both. We want to encourage a single place to edit documentations. However, the reality is that valuable content appears in many different places. It is for this very reason that I encourage the use of Forrest as the publishing engine for Cocoon docs (as is currently the case). Forrest can integrate content from many different sources into a single seemless publication. As for the human element of the workflow process that is the main topic of this part of a rather meandering thread. That has been discussed to death (see a recent mail I sent to this list with links to many of the proposals). We need to implement something not talk, there is enough overlap in all the different proposals to make it possible to proceed. Let get on with it. I'm tired of the discussion about tool vs. people. We need people to write docs, we need tools to help them write docs. It is not an either or argument, why are people so polarised? Ross
Re: [RT] Block usage
Reinhard Poetz wrote: ... but there needs some work to enable the blocks:/ protocol, component management and block-aware flowscript (e.g. cocoon.blocks.blockA.myFunc()) There is a block:/ protocol in OSGi. I haven't read OSGi specification though - I saw it in Knopperflesh-or-whats-its-name samples. Additionally we have to integrate Torsten's classloader to ease development and we need to work on block building and deploying. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65 smime.p7s Description: S/MIME Cryptographic Signature
Re: Other default cocoon resources
Reinhard Poetz wrote: Daniel Fagerstrom wrote: Leszek Gawron wrote: Reinhard Poetz wrote: Should we move the stylesheets I would help a lot to be able to deploy cocoon with no additional files at all. What do you say if we moved cocoon logo and default stylesheets (the ones styling error pages etc.) to some jar (either existing or a new one)? A new one. IMO we should move away from the monolitic thinking and start to think in terms of pluggins/bundles/blocks. Making the minimal Cocoon really lean would help using it embeded in new and innovative contexts, http://marc.theaimsgroup.com/?t=11136640512r=1w=2. This way we can have cocoon that consists of: - bunch of .jar files - web.xml which hardly changes - a set of .xconf and logkit files. +1 It's a pity we cannot move .xconf files into jars. Why can't we? AFAIR due to the fact that resource:/ protocol is not as functional as file:/ (no directiories?) and it would be quite intensive operation to find .xconf files. theoretically we can but soon we will have .cob files that *are* single files. So for now *I* wouldn't invest too much work. What will cocoon core consist of then? I mean file types.. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65 smime.p7s Description: S/MIME Cryptographic Signature
RE: Planet Cocoon license and reuse of docs
Glen and Ross, Before duplicating my thoughts in similar replies I want to state this (replies in random order): I work in a university department, doing research, so I'm fully aware what it takes to go through the process of putting an idea in writing until the moment it is accepted for publication (and by that I mean the final stage where it should be handed in camera-ready). I do agree with you on that Glen. Reading your explanation made me realise I wrote about the CMS as the actor while I meant the persons using the functionality of the CMS, which is what you wrote. Sorry about the confusion, but in essence we meant the same. Ross, you keep hammering on your idea of integrating multiple sources of documentation by using Forrest. I really don't mind/care what tools are used to end up with a documentation that is far superior than what we have now. If it takes Forrest or something that should still be built, fine by me. What I don't see right now is the additional sources of documentation AT THIS STAGE or the near future. In my point of view we better start with a clean slate in a CMS (or another agreed on tool) and add anything relevant from another source (whatever that maybe) to the CMS with the exception of the reference documentation that Upayavira and Ralph or Reinhard (keep forgetting which one) are working on. IIUC they generate Javadoc information from the actual code. If that's what you mean Ross by integrating different sources, then by all means I agree. Re the general TOC: I have started one about a year ago in the wiki. The idea was NOT that it would be the ultimate TOC but merely a sort of catalog of what information is/was available and what is missing. I've seen other attempts since then with equally valid separations. I would suggest that you Glen, since you offered it, will have a look at all of them, from a content POV, not tools POV, and either pick the most suitable or merge the best from every ideas into something workable. As Steven has already pointed out: navigation in Daisy can be done/ordered through queries so anything is possible. And Ross already pointed out that in Forrest a new/other kind of navigation is also feasible. Yes it will be a giant task and I'm sure it will not be finished by those that have started it. The only thing I hope/want to accomplish is to create enough documentation that it becomes noticed and attracks more writers. Let's keep the plan as simple as possible so that the actual writing gets the most attention. Besides, plans have a tendency to change, so KISS is in order. My weekends are horribly crammed with household chores, kids and family, but I'll see what I can do. Bye, Helma -Original Message- From: Glen Ezkovich [mailto:[EMAIL PROTECTED] Sent: Thursday, 26 May 2005 19:06 To: dev@cocoon.apache.org Subject: Re: Planet Cocoon license and reuse of docs Helma, I don't want to discourage the effort to create a or deploy a Cocoon based CMS. I think its important that it gets done. My point is that no mater how easy and automated the process becomes, good documentation requires a great deal of human collaborative effort. On May 25, 2005, at 8:30 AM, Linden H van der (MI) wrote: - pick a tool, any tool that meets the criteria I mentioned above and start a new set of documentation there. I suggest Daisy. What you should be concerned about is managing new and existing content. This includes some process for accepting vetting, editing/ correcting and publishing. In short a CMS type of tool LOL I'm a big believer in automation but I think its to much to ask of a CMS to vet, edit and correct documents. ;-) Let me be clear, a CMS is an important tool that needs to be in place to help manage the process. When a document is submitted someone must read it. Upon reading it, they make a judgement as to whether it meets some criteria of acceptability. If deemed acceptable it is then vetted by experts. The experts make suggestions concerning content. The author and her expert collaborators make changes to the content. At this point an editor will examine the document for readability, spelling and grammar. The editor in collaboration with the author corrects and improves the document. Once all corrections are made, the author, experts and editor sign off on it and the document is formated and published. Until the document is formated what we are dealing with is pure content. We shouldn't care about layout, formatting, hyperlinks or anything other then the documents content. It is at this point one may choose the editor provided by the CMS to convert the source document, but it is not the only choice. It can be done by hand or better yet, automated. Once the original document is published the role of the CMS is to manage and facilitate updates to the document. It is at this point that an online editor becomes useful for small
DO NOT REPLY [Bug 35094] New: - [PATCH] TeeTransformer refactoring
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35094. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35094 Summary: [PATCH] TeeTransformer refactoring Product: Cocoon 2 Version: Current SVN 2.1 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: core AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] - delegate to XMLTeePipe now - variable cleanup and recycle() fixes -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 35094] - [PATCH] TeeTransformer refactoring
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35094. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35094 --- Additional Comments From [EMAIL PROTECTED] 2005-05-27 00:53 --- Created an attachment (id=15180) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15180action=view) patch for refactored TeeTransformer -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Planet Cocoon license and reuse of docs
On Jue, 26 de Mayo de 2005, 8:35, Steven Noels dijo: On 24 May 2005, at 22:42, Upayavira wrote: If someone else can offer an existing CMS that has the features they need, and can be installed and operational within a reasonable amount of time, then we'd be asking different questions. I'm at a conference this week, so e-mail access is erratic. That said, next week I'll be back, and if we have our Solaris zone set up and I have access to it (Antonio?), I'll set up MySQL 4.1 + Daisy 1.3M2 on that zone. I believe, I am reading this mail with a time delay. What is clear to me is that I don't received a root password of the cocoon Solaris zone. And I don't know if the zone is already up. If I becomes the root of our zone, then I will be glad to provide all the necessary support to materialize this effort. As pointed before, I believe we can also setup there some cocoon demo sites. I know, this is OT here, but I think it will be good to have 3 demos: 1- Current released version 2- Daily SVN 2.1.x 3- Daily SVN 2.2.x Having up demo sites are a powerful marketing tool. And I am sure all of us know that. ;-) How to do that? I think we have 3 posibilities: A. On the same servlet container instalation. B. Virtual sites. Is this posible inside a zone? I believe yes, but not sure. C. Diferent containers using diferent ports for each instalation. Best Regards, Antonio Gallardo
[RT] Cforms selection-lists
Hi: Yesterday, I posted a simple RT on how to improve cforms dynamic selection list performance. After getting a huge responses and a lot interest from the cocoon dev list. :-) I am not sure if this was approved by a lazy consensus or simply people is happy with the current performance. I prefer to interpret that as it was approved by a lazy consensus. ;-) Seriously, before continuing I must admit I feel like a newbie inside this code. Yesterday, I was reviewing the current implementation of selections lists. And I will try to describe what I saw there: Current situation = In short, The world is black and white, there are no greys between. Why? Because, we have only 2 choices: 1- Static selection list (SSL): generated only once over the all life cycle of the servlet. Once it is generated it is served from the cache forever. There is no chance to change it. 2- Dynamic selection list (DSL), this is generated every time we need it. Over and over. This polarized selections list are missing the real nature of forms. Or perhaps we need only to improve the current implementation of them. I see the need of 1 additional selections lists: 3-Semi-static selection list (SSSL): generated every time the user request the form. Then it is served from the cache. This will allow us to change on-line a static selection list without the need to restart the servlet. I don't know if this should be called better semi-dynamic SL. Please comment. Also, in the previous mail, I tried to explain the current situation of DSL inside a repeater: http://marc.theaimsgroup.com/?t=11170678093r=1w=2 IMHO, it should improved too. The question is: Need it to be a user defined optional feature? Architecture If the above is approved - this mostly, why I am writing this mail. ;-) In order to improve that I see 2 posibilities: 1. The selection list widget (SLW) should know more about the status of his parent to know how to manage the current generation. SLW need to know: A. If his parent is a repeater or not. If yes, then need to know the repeater-row index to. Useful for DSL. B. Need to know if his parent is just initializating. Useful for SSSL. I know, this is posible by the initialization of the form. 2. The repeater-row widget, the repeater widget know what to do and call corresponding SLW methods to do the job. In this case the job is managed from the parent and the parent call the required methods. I see in this implementation an overhead, since the parent will need to know wich kind of widget it needs to generate. I am willing to implement this and I will be glad to hear opinions before starting to implement this. Also, need we a vote to do this? WDYT? Best Regards, Antonio Gallardo.
Re: Small AJAX bugs inside repeaters
On Mie, 25 de Mayo de 2005, 12:16, Sylvain Wallez dijo: Antonio Gallardo wrote: Hi: I tried to use AJAX inside a repeater. I have there 3 combos, but this does not matter. Everything works good, but now the Add row button does not work. I saw cocoon works, but the new line does not show. The same apply while trying to remove a row. Am I missing something? Thanks for the reply! Two important points: - update the stylesheets. For AJAX to work, every widget must translate to an element having the widget's full id. I added a few span and div in the XSLs to achieve this. Already done before posting. - you cannot use ft:repeater-widget with AJAX, but two new ft:repeater and ft:repeater-rows instructions (see e.g. dynamicrepeater_template.xml). Having an enclosing tag around the row iterator was needed to be able to produce the id mentioned below. Seems like this was the problem. :-) Thanks again. But, now, I am facing another problem: Inside a repeater there are 3 combo boxes. The current behavior is: 1- On a new row, we present only combo1. 2- When the user select a non-null value from combo1, then we show combo2. 3. When the user select a non-null value from combo2, then we show combo3. This seems to work good, but I found another weird problem there: 1-Select a valid value for combo1. = shows combo2 2-Select the null value for combo1 = invisible combo2. 3.Select the same value for combo1 as in step 1. = nothing happens! But combo2 mustr to be showed again. I wonder why I am getting this error. If in step 3. I select a diferent value (not equal as selected in step 1) then it works. I think this is really weird. Seems like for some reasons the value is not cleaned up in combo1. Maybe this is the reason of the trouble in this chain for combo1: null -- selectXposition -- null -- selectXposition But this works: null -- selectXposition -- null -- selectYposition (X != Y) It is weird, right? Am I missing something again? Best Regards, Antonio Gallardo.
Re: Planet Cocoon license and reuse of docs
On May 26, 2005, at 3:05 PM, Linden H van der (MI) wrote: Glen and Ross, Before duplicating my thoughts in similar replies I want to state this (replies in random order): I work in a university department, doing research, so I'm fully aware what it takes to go through the process of putting an idea in writing until the moment it is accepted for publication (and by that I mean the final stage where it should be handed in camera-ready). I do agree with you on that Glen. Reading your explanation made me realise I wrote about the CMS as the actor while I meant the persons using the functionality of the CMS, which is what you wrote. Sorry about the confusion, but in essence we meant the same. I had no doubt. I think its a bit of the academic left in me that pursues these pseudo arguments hoping to bring a bit of clarity. Sometimes it works, sometimes it doesn't. snip/ Re the general TOC: I have started one about a year ago in the wiki. The idea was NOT that it would be the ultimate TOC but merely a sort of catalog of what information is/was available and what is missing. I've seen other attempts since then with equally valid separations. I would suggest that you Glen, since you offered it, will have a look at all of them, from a content POV, not tools POV, and either pick the most suitable or merge the best from every ideas into something workable. As Steven has already pointed out: navigation in Daisy can be done/ ordered through queries so anything is possible. And Ross already pointed out that in Forrest a new/other kind of navigation is also feasible. I will do do this. I've seen some stuff on the wiki and I have seen most mail messages on the subject. If you know of any documents that I should check out please let me know. Yes it will be a giant task and I'm sure it will not be finished by those that have started it. The only thing I hope/want to accomplish is to create enough documentation that it becomes noticed and attracks more writers. Let's keep the plan as simple as possible so that the actual writing gets the most attention. Besides, plans have a tendency to change, so KISS is in order. Agreed. Enough talk, its time for action. If I've learned one thing its to plan for change, its inevitable. My weekends are horribly crammed with household chores, kids and family, but I'll see what I can do. Sounds like every day here. Enjoy the kids and family as they do the chores. ;-) Have a good weekend. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
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,
