Re: FirstFriday July 2 - Wiki migration
Are other people having trouble with editing the Wiki? I go to UserPreferences, add name and password, login it seems to accept me. However, when i visit a page then i need to login again. -- David Crossley
[portal] bookmarks to portlets
Hi, is there any solution how to make a bookmark in PortalEngine to JSR168 portlet? I need to pass a parameter in the bookmark to portlet via url. I know how to do this with coplets (using custom bookmark event that stores parameter to coplet attributes), but I am not sure how to handle this within pure JSR168portlet. 1.) Is there any way how to access coplet (that wraps the portlet) attributes within portlet? Will input module "coplet:attributes" work? 2.) Is there any way how to send a request parameter to selected JSR168portlet via portal url so portlet would be able to read it using portletRequest.getParameter()? This would probably need to engage the same mechanism as the one that is responsible for portlet link generation (PortletURLProviderImpl) - but looking closer at the implementation I wonder if this is possible. Thanks, Michal
Re: CIncludeTransformer issues
Having a strip-root parameter on the CInclude transformer makes sense IMO. I have a patch. It works only with cinclude:include tag. caching-include and includexml is way to much complicated for me to change it. Could you please add it to bugzilla? cheers -- Torsten
Re: FirstFriday July 2 - Wiki migration
On 02 Jul 2004, at 13:57, David Crossley wrote: But we are currently dealing with some glitches: * doing redirect from cocoondev.org I already dropped Wiki notification mails coming from wiki.cocoondev.org. -- 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: FirstFriday July 2 - Wiki migration
David Crossley wrote: > We are doing FirstFriday on IRC as usual > if you care to join. > > We are doing the Wiki migration at the moment. > > The conversion is done. So you can go to the new wiki. > http://wiki.apache.org/cocoon/FirstFriday > > But we are currently dealing with some glitches: > * doing redirect from cocoondev.org > * UserPreferences is not working on wiki.apache.org > so you cannot log in and edit yet. Okay go for it. Upayavira fixed the UserPreferences thing. Start at http://wiki.apache.org/cocoon/ create yourself an account via UserPreferences, log in, and you will be able to edit. See tasks at: http://wiki.apache.org/cocoon/FirstFriday and how to join IRC. -- David Crossley
Re: FirstFriday July 2 - Wiki migration
We are doing FirstFriday on IRC as usual if you care to join. We are doing the Wiki migration at the moment. The conversion is done. So you can go to the new wiki. http://wiki.apache.org/cocoon/FirstFriday But we are currently dealing with some glitches: * doing redirect from cocoondev.org * UserPreferences is not working on wiki.apache.org so you cannot log in and edit yet. ... will report back soon. -- David Crossley
Re: Why Cocoon Stops processing all Requests URI the moment one of them has an exception;CInclude
Hi Leszek, Thanks very much for your help. We were stuck in a very critical stage of our project and your views really helped us. Thanks And Best Regards, Arnab Sengupta IBM Global Services Plot X1-7, Block - EP/GP, Saltlake Kolkata - 700 091 Telephone: +91 33 23579110 extn 3460(office) Email: [EMAIL PROTECTED] Leszek Gawron <[EMAIL PROTECTED]> 07/02/2004 04:09 PM Please respond to dev To [EMAIL PROTECTED] cc Subject Re: Why Cocoon Stops processing all Requests URI the moment one of them has an exception;CInclude Arnab Sengupta wrote: > > Hi All, > > I have a Cocoon pipeline that takes a huge xml as input. The stucture of > xml is: > > > > > > > > > > > > > > Now I have an xsltc transformer taking an xsl, internally calls same > *cocoon URI*, based on occurance of "**" tag. > > *cocoon://labData?messageNo= > select="position()"/>* > > > > > Now when any one of these URI's fired through CInclude gets an > exception, other URI's are never processed at all. I mean i am not very > sure whether other URI's gets fired or they are aborted. Can someone > please tell me what will happen, if URI fired by the occurance of 2nd > gets an exception. Will the URI for 3rd Message be fired at > all? Or if fired it will be aborted in middle..? ignoreErrors attribute is only taken into account when using cinclude:includexml tag. -- Leszek Gawron [EMAIL PROTECTED]
Re: CIncludeTransformer issues
Torsten Curdt wrote: 2. If not would you accept the path that allows to do strip-root in CIncludeTransformer - it would also be much faster than select="/root/*" The PATCH not the path big +1 ...see the archives: I wanted to add this feature but worked around due to time constraints. Having a strip-root parameter on the CInclude transformer makes sense IMO. I have a patch. It works only with cinclude:include tag. caching-include and includexml is way to much complicated for me to change it. -- Leszek Gawron [EMAIL PROTECTED]
Re: Why Cocoon Stops processing all Requests URI the moment one of them has an exception;CInclude
Arnab Sengupta wrote: Hi All, I have a Cocoon pipeline that takes a huge xml as input. The stucture of xml is: Now I have an xsltc transformer taking an xsl, internally calls same *cocoon URI*, based on occurance of "**" tag. *cocoon://labData?messageNo=* Now when any one of these URI's fired through CInclude gets an exception, other URI's are never processed at all. I mean i am not very sure whether other URI's gets fired or they are aborted. Can someone please tell me what will happen, if URI fired by the occurance of 2nd gets an exception. Will the URI for 3rd Message be fired at all? Or if fired it will be aborted in middle..? ignoreErrors attribute is only taken into account when using cinclude:includexml tag. -- Leszek Gawron [EMAIL PROTECTED]
Why Cocoon Stops processing all Requests URI the moment one of them has an exception;CInclude
Hi All, I have a Cocoon pipeline that takes a huge xml as input. The stucture of xml is: Now I have an xsltc transformer taking an xsl, internally calls same cocoon URI, based on occurance of "" tag. cocoon://labData?messageNo= Now when any one of these URI's fired through CInclude gets an exception, other URI's are never processed at all. I mean i am not very sure whether other URI's gets fired or they are aborted. Can someone please tell me what will happen, if URI fired by the occurance of 2nd gets an exception. Will the URI for 3rd Message be fired at all? Or if fired it will be aborted in middle..? Also can anyone tell me whether CInclude waits for response of the URL fired by it to return an xml ? Thanks And Best Regards, Arnab Sengupta IBM Global Services Plot X1-7, Block - EP/GP, Saltlake Kolkata - 700 091 Telephone: +91 33 23579110 extn 3460(office) Email: [EMAIL PROTECTED]
SVN conversion (was Re: Overwrote/removed jakarta-commons website files)
Brian W.Fitzpatrick wrote: On Jul 2, 2004, at 12:42 AM, William A. Rowe, Jr. wrote: I chatted with Fitz very recently, and he's hoping folks wait to adopt his next release (coming -very- soon) of the cvs2svn tool. He's made massive improvements in the speed of conversion and resulting svn dataset. I expect he will give a yell as soon as it's ready. (He was actually hacking on the last few bugs as we were chatting a week or two ago.) While it's not 1.0 yet (a few non-correctness bugs left), it's ready. I'm planning on converting httpd-1.0 and cocoon next week, and then it's open season. -Fitz Above from Infrastructure. So it seems we can expect a conversion soon, then! Upayavira
Re: Why has XMLForms been removed
Hello, I have just noticed that XMLForms has been removed from Cocoon. May I ask why? From 2.1.4 I got the impression that there is a real effort to include a XForms (or close to) implementation in Cocoon. But obviously, XForms is no longer considered to be of interest. For us, this is rather unfortunate, so, if possible, I'd like to know why it has been dropped. There were several reasons. The most important ones are: * lack of community support - it was no community effort * we decided to focus on a single forms framework (former woody) IIRC also some security issues popped up. Besides trying to implement a client side spec on the server side has always been questionable. ...that's why we deprecated XMLForms a while ago and moved on. Please have a look into "forms" block. You will find a pretty mature form handling implementation that's been used and well supported by the cocoon community. You won't burn your hands again if you go for it. Hope I summarized this correctly, folks? cheers -- Torsten
Why has XMLForms been removed
Hello, I have just noticed that XMLForms has been removed from Cocoon. May I ask why? From 2.1.4 I got the impression that there is a real effort to include a XForms (or close to) implementation in Cocoon. But obviously, XForms is no longer considered to be of interest. For us, this is rather unfortunate, so, if possible, I'd like to know why it has been dropped. Regards, Michael
RE: [portal] Implementing Login coplet with CForms
Hi, Is there some fresh news about that topic ? I mean somebody succeded ? Regards, Phil On Thu, 2004-05-27 at 03:33, Alex Romayev wrote: > --- Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > Alex Romayev wrote: > > > > > > Ok, I'm a bit confused and not sure where to > > start. > > > > > > This is what I'm trying to achieve. I'd like to > > replace > > > portal login form with CForm (using actions, not > > flow), to > > > use its validation. So the most interesting use > > case is: > > > > > > 1. User does not enter username/password 2. The > > form is > > > re-displayed with error messages 3. User enters > > correct > > > username/password 4. The form calls do-login url, > > which then > > > redirects to "portal" using authentication-fw. > > > > > > Questions. > > > > > > 1. Initially I assumed that if I just configured > > the coplet > > > with handleParameters = true, CForms would have > > access to > > > request parameters. Not true. Does this mean > > that > > > handleParameters only works in conjunction with > > > html-event-link transformer? > > > > > Yes (unfortunately I think). > > :-( I actually find that having request parameters > directly available to coplets would simplify things > quite a bit in general. However, come to think of it, > it probably wouldn't have helped my case, since I > would still need to do the redirect to do-login inside > my portlet pipeline. > > > > > > 2. I switched to using html-even-link trasformer > > > configuration. Now could get through steps 1-3. > > > However, in step 4, calling do-login results in > > portal being > > > displayed *inside* my login coplet. I've looked > > at > > > HTMLEventLinkTransformer code, and it makes > > external = > > > true/false distinction only for links, not for > > forms. At the > > > same time, event if it did, I don't see how it > > would work in > > > my case anyway, since in step > > > 2 I would need to have external=true and in step > > 4, external= > > > false for the same form? Am I making sense here > > at all? > > > > > Yes, makes sense to me :) > > > > > Seems like I'm just missing some basic > > information, but ATM > > > completely lost :-) > > > > > Hmm, no the problem is that your call to do-login > > happens inside > > the coplet. So it's the content of your coplet that > > you change > > with the call - not the whole portal itself. > > I'm not sure if this is possible at all - at least I > > don't see > > a solution right now (which doesn't mean that there > > isn't). > > I've been thinking about this for a while, let me see > if I can collect my thoughts and make a separate post > on this topic. > > Thanks, > -Alex > > > For the current login coplet in the demo portal we > > used a "hack". > > The form is not processed by the coplet itself but > > directly in > > the sitemap *before* the portal is rendered. This > > allows us > > to do what you need. You could do the evaluation > > before the > > portal is rendered and put some error messages in > > the session > > and retrieve it later on when your coplet is > > rendered. > > > > HTH > > Carsten > > > >
Re: Compile error: JMSEventMessageListener
Andreas Hartmann wrote: Hi Cocoon developers, I get a compile error with the current HEAD: D:\Development\src\apache\cocoon-2.1-cvs\src\blocks\eventcache\java\org\apache\cocoon\caching\impl\JMSEventMessageListener.java:90: cannot resolve symbol symbol : method getLogger () location: class org.apache.cocoon.caching.impl.JMSEventMessageListener Is this related to the latest JMS changes? Yes, the eventcache block now depends on JMS to build. -- Unico
Compile error: JMSEventMessageListener
Hi Cocoon developers, I get a compile error with the current HEAD: D:\Development\src\apache\cocoon-2.1-cvs\src\blocks\eventcache\java\org\apache\cocoon\caching\impl\JMSEventMessageListener.java:90: cannot resolve symbol symbol : method getLogger () location: class org.apache.cocoon.caching.impl.JMSEventMessageListener Is this related to the latest JMS changes? Thanks in advance! -- Andreas Here's my local.blocks.properties: #include.block.authentication-fw=false #dependency: fop needs batik #include.block.batik=false include.block.bsf=false #include.block.chaperon=false #include.block.databases=false #include.block.deli=false include.block.linotype=false #include.block.fop=false #include.block.hsqldb=false #include.block.html=false include.block.itext=false include.block.jfor=false include.block.jms=false include.block.jsp=false include.block.jxforms=false #include.block.linkrewriter=false include.block.lucene=false #include.block.naming=false include.block.paranoid=false include.block.php=false include.block.poi=false include.block.portal-fw=false #include.block.profiler=false include.block.python=false #dependency: authentication-fw needs session-fw #include.block.session-fw=false #dependency: webdav needs slide include.block.slide=false include.block.swf=false include.block.velocity=false include.block.web3=false # TODO: Including the xmldb block might cause a conflict with the patched xmldb libraries lib/xmldb-common-2003-09-02.jar and lib/xmldb-xupdate-2003-10-14.jar include.block.xmldb=false # Unstable blocks -- # unstable blocks are currently under development and do not guarantee the # contracts they expose (API, xml schema, properties, behavior) will remain # constant in time. Developers are not committed to back-compatibility just yet. # This doesn't necessarily mean the blocks implementation is unstable or # the code can't be trusted for production, but use with care and watch # its development as thing might change over time before they are marked # stable. include.block.apples=false include.block.asciiart=false include.block.axis=false #dependency: scratchpad needs cron include.block.cron=false #include.block.eventcache=false include.block.javaflow=false include.block.mail=false include.block.midi=false include.block.ojb=false include.block.petstore=false include.block.portal=false include.block.precept=false #include.block.proxy=false include.block.qdox=false include.block.repository=false include.block.scratchpad=false include.block.serializers=false include.block.slop=false include.block.stx=false include.block.taglib=false include.block.webdav=false include.block.woody=false # Deprecated blocks # Although these blocks are stable they have been deprecated in favour of other # blocks. include.block.xmlform=false
