Re: Possible threading issues with xsltc + BCEL ???

[Andy Lewis]

I've hit this - it only happens when compiling the stylesheet though. Concurrent 
requests right at
startup do not do wel...I had no workaround...but that would be a GOOD THING to have 
fixed...
> Hi Cocooners,
>
> Are their any other Cocoon users having Threading Issues with xsltc?
>
> Its seems that if you have a translat being compiled at the same time by two  or 
>more threads
> (instances of TraxTransformer) you will get issues because  BCEL is not (by design) 
>threadsafe
> as it users static methods and  variables which seem to be overwriting each other???
>
> Once the Translets get compiled however, such threading issues disappear.
>
> Does anyone have expirence with this?
>
> Regards,
> Michael Melhem
>
> Ps After locally patching org.apache.xalan.xsltc.trax.TemplatesHandlerImpl.java with 
>some synch
> code around the compile block, all seems OK.
>
>
>
>
> - To 
>unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


-- 
"The heights of genius are only measurable by the depths of stupidity."



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Photo Album sample?

[Andy Lewis]

> I have got a personal photo album that I have prepared using Cocoon. It uses the  
>ImageReader


I would also be interested in the if you have no objections...thanks!

-- 
"The heights of genius are only measurable by the depths of stupidity."



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: R: Strings to SAX events

[Andy Lewis]

This should really be a code snippet...


> Hi Damian,
>
> Perhaps it helps : If you are in XSP, the following tags resolve it without java 
>code :
>
> 
> http://apache.org/xsp";
> xmlns:util="http://apache.org/xsp/util/2.0";>
> ...
> 
> 
> yourXMLString
> 
> 
> ...
>
> Regards,
>
> Ludovic
>
> - Original Message -
> From: "Damian Chojna" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, November 14, 2002 6:02 PM
> Subject: Re: R: Strings to SAX events
>
>
>> Hi Reinhard,
>>
>> thanks for the last post. I also need to add a string as XML elements into an XSP 
>generator
>> and I used your suggestion (below). It seems to work well, but I have two questions:
>>
>> 1) I've noticed that the API states that the Parser is deprecated. I'm currently 
>using 2.0.3,
>> if I choose to use this method will it effect me being able to move to a newer 
>version of
>> cocoon at some time in the
> future?
>>
>> 2) When I generate my XML elements it seems that the parser is including the > version="1.0" encoding="UTF-8"?> header. Is there a way to get the parser not to 
>include it,
>> as it is causing me problems?
>>
>> Thanks in advance!
>> Damian.
>>
>>
>>
>>
>> [EMAIL PROTECTED] wrote:
>>
>> > Luca,
>> >
>> > In a generator I use flowing code within the generate()-Method. Maybe
> this
>> > helps:
>> >
>> > parser = (Parser)this.manager.lookup(Parser.ROLE);
>> > parser.setConsumer(super.xmlConsumer);
>> > parser.parse(new InputSource(new StringReader(sb.toString(;
>> >
>> > Regards,
>> > Reinhard
>>
>>
>>
>>
>> - Please check 
>that your
>> question  has not already been answered in the FAQ before posting.
>> 
>>
>> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For 
>additional commands,
>> e-mail:   <[EMAIL PROTECTED]>
>>
>>
>>
>
>
> - Please check 
>that your
> question  has not already been answered in the FAQ before posting.
> 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional 
>commands,
> e-mail:   <[EMAIL PROTECTED]>


-- 
"The heights of genius are only measurable by the depths of stupidity."



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon Portal - User Roles

[Andy Lewis]

We are doing this with XSPs to provide the XML, rather the the SQL transformer. But we 
are
actually part way through replacing all of the file-based pipelines for these 
componenets with XSP
driven database equivalents. so far, only a few problems have cropped up
> Hi Matthew,
>
> If I understand it right, I have to change the sunrise-newrole.xml into something 
>that the sql
> transformer would understand and remove the cinclude and writesource transformer on 
>the
> pipeline?
>
> In this case...
>
> Whats the advantage of using transformer than an action?
>
> In the end of this map:match pattern it is returning an xml like this...
>
> 
>-   - http://apache.org/cocoon/source/1.0";
>xmlns:session="http://cocoon.apache.org/session/1.0";> - 
>  success
>  content inserted at: roles
>  insert
>  overwritten
>  
>file:/C:/ApacheGroup/Tomcat4.1/webapps/cocoon/myportal/resources/sunrise-roles.xml>
>   xml
>  
>  
> If I'd use an action, do I have to serialized these kinds of xml?
>
> And can you tell me where the sunrise-newrole resource is being called and returned 
>to?
>
> Thanks again.
> Richard
>
>  - Original Message -
>  From: Matthew Langham
>  To: [EMAIL PROTECTED]
>  Sent: Tuesday, November 12, 2002 8:16 PM
>  Subject: RE: Cocoon Portal - User Roles
>
>
>  >>
>  Since the the "new role" function in the portal sample is mapped to   uri="cocoon:raw:/sunrise-newrole"/> uri, it is using this sitemap snippet right?
>
>  
>  
>  
>  
>  
>  
>  
>  
>
>  and the documentations says that
>
>  The new-role resource creates a new role in the system. It gets the parameters 
>"type" with the
>  value "role" and "role" with the new rolename.
>
>  Where is the "type" and "role" parameter?
>  and why does it have to serialized in an xml type in the end?
>  <<
>
>  You need to take a look at the file sunrise-newrole.xml. That file contains most of 
>the dirty
>  work. The transformers session, cinclude and writesource act on the information 
>contained in
>  there. Because sunrise-newrole.xml also flows through the pipeline it is then 
>formatted by the
>  stylesheet and returned to the browser. It is serialized to xml because it is being 
>used
>  inside the portal (in this case).
>
>  If you wanted to write this to a database you would need to change the 
>sunrise-newrole.xml and
>  use the sqltransformer instead of cinclude and write-source. In all this should 
>take you
>  around 5 minutes or less to adapt. :-)
>
>  So it really is quite simple really.
>
>  Matthew
>  --
>  Open Source Group   Cocoon { Consulting, Training, Projects }
>    Matthew Langham, 
>S&N AG,
>  Klingenderstrasse 5, D-33100 Paderborn Tel:+49-5251-1581-30  [EMAIL PROTECTED] -
>  http://www.s-und-n.de 
>- Cocoon
>  book:
>http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
>  Weblog:
>http://radio.weblogs.com/0103021/
>  
>-Original Message-
>From: Richard Reyes [mailto:seyer_drahcir@;hotmail.com]
>Sent: Tuesday, November 12, 2002 12:53 PM
>To: cocoon-users
>Subject: RE: Cocoon Portal - User Roles
>
>
>
>
>Hi Matthew / Guys,
>
>Just want to confirm some things
>
>Since the the "new role" function in the portal sample is mapped to uri="cocoon:raw:/sunrise-newrole"/> uri, it is using this sitemap snippet right?
>
>
>
>
>
>
>
>
>
>
>and the documentations says that
>
>The new-role resource creates a new role in the system. It gets the parameters 
>"type" with
>the value "role" and "role" with the new rolename.
>
>Where is the "type" and "role" parameter?
>and why does it have to serialized in an xml type in the end?
>
>Also, for the sunrise-newrole resource, the only thing this pipeline does is save 
>a new role
>in the xml file ( sunrise-roles.xml )? whose responsible for displaying the next 
>page after
>saving the new role?
>
>And since this sitemap snippet is called inside a map:pipeline internal only 
>clause I think
>it is being called by the portal generator or action.
>
>If in case I'd used custom actions over this pipeline, How would I know the 
>parameters that
>have been passed and are being expected by the caller of this pipeline?
>
>Thanks a lot
>Richard


-- 
"The heights of genius are only measurable by the depths of stupidity."



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mai

Re: Separation of concerns?

[Andy Lewis]

I have found it a great advantage to have someone who is a developer, not a designer, 
work with
the designer to create the XSLT to produce a particular design. Most designers 
struggle with
dynamic components and web-related efficiency concerns. The developer and designer 
working
together usually produces a good rendition of the design, but adapted in a way that 
makes sense.
Never let a pure designer produce your templates.
> I have a (multi-part) question about the suggested "separation of concerns"  that it 
>is
> proposed that Cocoon achieves.
>
> I would like to ask how Cocoon is being used in a production environment,  
>specifically how
> does separation of roles work out. Does it actually work  in practice? How easy is 
>it in
> production settings to find "graphics  designers" who are also fluent in XSLT?
>
> Aren't such bi-skilled people essential to achieve the implementation of  the 
>"style" concern?
> Or, in practice, are "real" designers and "real" XSLT  coders working together on 
>the XSLT
> stylesheets?
>
> I guess that the suspicion that is lurking at the back of my mind is that  the 
>"confusion of
> concerns" (to coin a phrase) is, to some extent, being  shuffled off into the 
>"style" box. Of
> course, that may be a signficant  improvement over other workflows.
>
> I can see pretty clearly the cleanness of the current approach for  
>programmers/administrators
> ... designers don't touch the content nor the  sitemaps ... but I do have slight 
>doubts about
> the cleanness of the style  concern. Or maybe my doubt is about the realisticness of 
>finding
> graphics  designers comfortable to code in XSLT.
>
> I notice, too, that style is little mentioned in the online documentation  and 
>doesn't appear
> as a term in the index of the Langham/Ziegeler book.  That makes me wonder if others 
>either
> have doubts too about the style  concern or, perhaps, haven't looked (yet?) in a 
>detailed way
> at how this  will work.
>
> I wonder if what has mostly been happening up to now is XSLT-coders  dabbling with 
>design? :)
>
> I would be interested in any stories about the reactions of "pure" graphics  
>designers in a
> production setting when first faced with the Cocoon approach  and how they and, I 
>suspect,
> XSLT-programmer colleagues actually worked out  a practical workflow.
>
> Andrew Watt
>
>
> - Please check 
>that your
> question  has not already been answered in the FAQ before posting.
> 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional 
>commands,
> e-mail:   <[EMAIL PROTECTED]>


-- 
"The heights of genius are only measurable by the depths of stupidity."



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

XSP Logicsheet Questions...

[Andy Lewis]

I am just starting to really get into XSP, having worked with various other parts of 
Cocoon
since 1.3  and I  have three questions regarding XPS Logicsheets:

First, it appears that a logicsheet must declared to be used and that the only place 
to declare a
logic sheet is in the xconf file. Is this correct?
Second, is the xconf file only reload at Cocoon restart time, or are there other 
events that
trigger a reload as well?
Third, are changes to a logicsheet picked up and used in a running Cocoon environment, 
or are they
only caught when the configuration is read? If changes are picked up, are they a 
dependancy of the
pipeline, or are they only picked up when the XSP itself is recompiled due to another 
trigger,
such as being updated.
Thanks!

-- 
"The heights of genius are only measurable by the depths of stupidity."



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>