date:20050620

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=29817.
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=29817


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
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.

FAQ and access to daisy documentation...

2005-06-20 Thread Thomas Lutz


Hi list !

What is the status of the new documenation site using daisy ?

Is there a public URL yet ?

One of the most frequently asked questions in the users list is ..how 
do I access request parameters in the sitemap... and I'd like to wikify 
or FAQ it, but as I read before on this list, all wiki pages have been 
converted to daisy ? So will my FAQ addon be lost, if I update 
http://wiki.apache.org/cocoon/FAQs?highlight=%28FAQ%29 ?


:-),
tom

DO NOT REPLY [Bug 35435] New: - [PATCH] New EnvironmentInputModule

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=35435.
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=35435

   Summary: [PATCH] New EnvironmentInputModule
   Product: Cocoon 2
   Version: 2.1.7
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: sitemap components
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Currently, there is no way to use properties of the environment in the sitemap.
The proposed module solves this. An interesting use is {environment:URIPrefix},
which gives an absolute URI to the bese of the current sitemap. This can be used
to make sitemaps relocatable, as it provides the 'mount point' of the sitemap.

-- 
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 35435] - [PATCH] New EnvironmentInputModule

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=35435.
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=35435





--- Additional Comments From [EMAIL PROTECTED]  2005-06-20 14:47 ---
Created an attachment (id=15479)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15479action=view)
EnvironmentInputModule code

This is the (extremely simple) code for the EnvironmentInputModule.
There is no copyright on it (it has only one interesting line anyway).

-- 
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: iCal


Andrew Franz wrote:


Has anyone thought about integrating iCal with Cocoon?



It would be great to have an iCal generator / iCal serializer!

Want to write it ?

Sylvain

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research  Technology Director

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

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=35435.
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=35435





--- Additional Comments From [EMAIL PROTECTED]  2005-06-20 15:26 ---
The Environment object is internal to the Cocoon engine and the
CocoonComponentManager is for internal use only (and BTW it no more exists in 
2.2).

So I'm -1 for this patch. If URIPrefix is something that proves to be useful,
then we may add it to the request interface.

-- 
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: [Ann/RFC] Sitemap Blocks

Stefano Mazzocchi wrote:

Yey!!

Daniel,

you rock! Thanks so much for your continuous work on this!

Thanks :)

See my comments inlined.

Daniel Fagerstrom wrote:

snip/

The super block of a block is identified by
/wiring/block/connections/connection/@name='super', see
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/wiring.xml?view=markup
for an example.

hmmm, I don't get this. why do you need to explicitly identify a super
block? don't you get it directly thru extension?

In block.xml you identify the super block with extension. But for the
wiring.xml you just list the connections (name and block) to the other
deployed blocks without any indication on what role they have (requires
or extends). For the required blocks you get a name from block.xml for
the extended block it doesn't have (or need to have) a name in block.xml
but it need a name in wiring.xml so I just introduced the special name
super.

Maybe it is not necessary to have the extended block at all in
wiring.xml, but I prefer to have all deployment info available in
wiring.xml. IMO it seem reasonable that if Í have a block that according
to its block.xml extends
http://cocoon.apache.org/blocks/another-block/1.0 it should be possible
to deploy it so that it extends
http://cocoon.apache.org/blocks/another-block/1.0.23.

The wiring file is used by the BlocksManager to set up all the blocks.
The BlocksManager is configured to point to the wiring.xml:

component role=org.apache.cocoon.components.blocks.BlocksManager
class=org.apache.cocoon.components.blocks.BlocksManager
file=wiring.xml/

All access to blocks goes through the BlocksManager.

Works for me.

blocks: protocol

The blocks mount paths from deployment should in principle be used
before the main sitemap in the (main) webapp is called. But at this
point I didin't want to touch the core classes e.g. o.a.c.Cocoon or let
any core components depend on the block infrastrucuture. Therefore I
instead created a blocks: protocol that can be used in the main sitemap
to connect to the blocks system:

map:match pattern=**
map:read src=blocks:/{1}/
/map:match

Great idea! I'd like to keep going with this, because sometimes, due to
legacy, you might want to keep the need to position the 'block subspace'
as you please.

I'm not certain that I actually supported relocation in the current
implementation, but it shouldn't be that hard to fix.

block-path: module
--

A block URI block:foo:/bar where the foo block is mounted at /test can
be absoultized to /test/bar by using the block-path input module,

{block-path:foo:/bar}

see example in
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test1/sub/.
This module can be used together with the LinkRewriterTransformer
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html
from Forrest fame to creta the block link rewriting behaviour described
in the end of http://wiki.apache.org/cocoon/BlocksDefinition.

this works, but I don't think it's the prettiest thing we could do.

It wasn't designed to be pretty, it was designed to get the job done
with a minimal amount of work ;)

A better way of achiving link translation would be to allow the
LinkRewritingTransformer to be aware of href= and src= attributes
(or configurable other attributes) and make them react on the same
block: protocol used above.

AFAIU, the LinkRewritingTransformer doesn't have any internal knowledge
about anything, all actual link transformation is done in imput modules
and connected to attributes and scemes in the configuration:
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html.
Highly flexible but not that easy to understand, but if we provide good
default configuration files it shouldn't be a problem for the users.

so the link transformer must be able to
access the block manager and obtain the relative URL of the given stuff.

Any component can find the current block and require it to absolutize
a block: URL
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/components/modules/input/BlockPathModule.java?view=markup,
so it wouldn't be a problemt to write a more a specialized block aware
link transformer.

I would also go a little further and say that this behavior could be
*transparent* and part of the pipeline implementation itself, but I have
no strong opinion about this and I'm generally against behind-your-back
black magic.

I prefer to avoid black magic in this case, link rewriting is hard
enough to understand without any helpfull automagics. I might change
my mind when we have got more experience about using block link
rewriting, maybe it is so natural so that we can make it automatic
without confusing ourselfes, but I'd rather wait and see.

Re: iCal


Sylvain Wallez wrote:

Andrew Franz wrote:


Has anyone thought about integrating iCal with Cocoon?




It would be great to have an iCal generator / iCal serializer!

Want to write it ?

Sylvain



http://www.ietf.org/rfc/rfc2445.txt

:D

Tony

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

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=35435.
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=35435





--- Additional Comments From [EMAIL PROTECTED]  2005-06-20 15:37 ---
(In reply to comment #2)
 The Environment object is internal to the Cocoon engine and the
 CocoonComponentManager is for internal use only (and BTW it no more exists in
2.2).

:-?

http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/apache/cocoon/environment/Environment.java

-- 
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: [GT2005] News, vote and more news


Steven Noels wrote:

Yes, I'm thinking of attending the Cocoon GetTogether 2005 in 
Amsterdam, preferably on


  [x]  3/4/5 October (Mon-Wed)
  [x]  5/6/7 October (Wed-Fri)


/Daniel

Re: [vote] gump-related stuff


Stefano Mazzocchi wrote:


We should try to make it easier for gump to work with us. Our build
system is a little hacky in that regard since it uses partial gump
information to build cocoon.

Gump strongly suggests people to move their gump descriptors over to the
gump repository, so that all apache committers have access to it, not
just cocoon committers. This increases the ability for others to fix the
problems that we might introduce. At the same time, this is not
possible, since our build depends on that *and* we can't svn:externalize
it because the gump metadata is not (yet!) in SVN (we could get it from
viewcvs, though, but it sounds hacky)

So, the easiest thing is to allow gump committers to modify our
'gump.xml' files.

So, issue #1: would you like to allow this?
 


+1


  - o -

There is another issue: cocoon has unique packages that we only depend
on and we place them in our gump.xml file, problem is that later on
other projects might start using those and collisions might happen. Gump
is not really happy when naming collisions happen (its datamodel is not
namespaced, yet) so one way to do it better is to ask the gump folks to
package the things we depend on directly. Means that its a little slower
turnover.

So, issue #2, would you like to ask the gump people to move our library
dependencies currently in gump.xml over in the gump metadata repository
instead?
 


+1

/Daniel

WURFL + Cocoon

2005-06-20 Thread Joerg Rasinger

Hello all!

We are building a webapplication with cocoon and want to not only change the
style/syntax of our application depending on the client used (pda/mobile
phone/browser), but we also would like to differantiate between existing
pda's/mobile phones. For this purpose we found the WURFL-project
(http://wurfl.sourceforge.net/) to be very convenient and would now like to
combine Cocoon with WURFL.
  
I already asked Sylvain Wallez for some advice. (Thanks for the answer!)
Here are some details to our question and the Sylvains reply:

--
To our problem he mentioned:

Do you know about the DELI block in Cocoon? It provides similar services
using CC/PP-UAProf. Now although not being a standard, WURFL is interesting
also as it seems to be more actively maintained.

--
Our question:

WURFL is a giant XML-file, mapping user-agent-strings with device 
capabilities. The project is dedicated to keep track of all changes in 
the mobile client-sector and incorporates more or less all 
client-versions (identified by their user-agent-string). In the first 
step we would like to discriminate between devices that are capable of 
displaying just wml, xhtml-mp, and (x)html, so we can distinguish three 
general types for our application. For this purpose we would need to 
extract all user-agent-strings from the wurfl-file and map them to the 
technology the client could take, respectively. Then an incoming 
request could be identified by the user-agent-string extracted from the 
wurfl-file and a simple variable (e.g. wap/xhtml-mp/html) could be 
returned, so the the sitemap could take a decision which
application-track to choose.

Our question is, which is the best way to incorporate this idea into
cocoon?
Our idea would have been, to write an own 
WURFLBrowserSelector/WURFLNamedPatternsSelector - pair. Am I on the 
right track, or is there a better/easier way, to accomplish this?

--  
Sylvains answer:

That's a good approach, although it may not leverage all the information
that's contained in the WURFL. You may want the selector to test against
particular capabilities rather than just the user agent string.

Looking again at the WURFL, a weird idea comes to my mind to use at its best
all the information that's in this file. We could write a Javascript class
whose properties are directly mapped to WURFL capabilities. Combined with a
matcher and/or a selector, this can give powerful constructs like:

map:match type=wurfl pattern=wurlf.screenWidth  200 
wurlf.screenHeight  300
  map:transform type=large-screen.xsl/ /map:match

--


We definitely agree, that this would be a powerful construct. Another way
could be, to pass the relevant wurfl-capabilities to the xsl as parameters
and let itsself decide, what to do with it. 

Thanks for any help!

Joerg Rasinger
-- 
ECCA - eTourism Competence Center Austria 
Technikerstrasse 21a
A-6020 Innsbruck
[EMAIL PROTECTED]

Re: FAQ and access to daisy documentation...

2005-06-20 Thread Bruno Dumon

On Mon, 2005-06-20 at 14:34 +0200, Thomas Lutz wrote:
 Hi list !
 
 What is the status of the new documenation site using daisy ?
 
 Is there a public URL yet ?

http://cocoon.zones.apache.org/daisy/

 
 One of the most frequently asked questions in the users list is ..how 
 do I access request parameters in the sitemap... and I'd like to wikify 
 or FAQ it, but as I read before on this list, all wiki pages have been 
 converted to daisy ?

nope, it is the normal xdoc documentation which has been converted, not
the wiki.

  So will my FAQ addon be lost, if I update 
 http://wiki.apache.org/cocoon/FAQs?highlight=%28FAQ%29 ?

no, it won't be lost.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

[ Daisy ] Registration broken?


Error
Could not setup pipeline.
Fatal error parsing 
file:/home/daisy/daisy-rev2070-20050617/daisywiki/webapp/daisy/resources/form/userregistration_template.xml 
(line 52 col. 37): Element type ft:widget must be followed by either 
attribute specifications,  or /.
Element type ft:widget must be followed by either attribute 
specifications,  or /.


I get this when I click the link for registration.  Can anyone with zone 
access check this out and fix it, pretty please? :) I'd scope it out 
myself, but I don't have access.


Regards,
Tony

Re: iCal


Tony Collen wrote:


Sylvain Wallez wrote:


Andrew Franz wrote:


Has anyone thought about integrating iCal with Cocoon?




It would be great to have an iCal generator / iCal serializer!

Want to write it ?



http://www.ietf.org/rfc/rfc2445.txt



Yeah, but that's not XML ;-)

Sylvain

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research  Technology Director

Re: [ Daisy ] Registration broken?

2005-06-20 Thread Bruno Dumon

On Mon, 2005-06-20 at 10:41 -0500, Tony Collen wrote:
 Error
 Could not setup pipeline.
 Fatal error parsing 
 file:/home/daisy/daisy-rev2070-20050617/daisywiki/webapp/daisy/resources/form/userregistration_template.xml
  
 (line 52 col. 37): Element type ft:widget must be followed by either 
 attribute specifications,  or /.
 Element type ft:widget must be followed by either attribute 
 specifications,  or /.
 
 I get this when I click the link for registration.  Can anyone with zone 
 access check this out and fix it, pretty please? :) I'd scope it out 
 myself, but I don't have access.

fixed. I had copied one character too less when copying over the
IP-agreement change.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: iCal


Sylvain Wallez wrote:

Tony Collen wrote:


Sylvain Wallez wrote:


Andrew Franz wrote:


Has anyone thought about integrating iCal with Cocoon?





It would be great to have an iCal generator / iCal serializer!

Want to write it ?



http://www.ietf.org/rfc/rfc2445.txt




Yeah, but that's not XML ;-)



Yepp... I was assuming that was that was the Serialized version of the 
iCal files.. but that just goes to show I haven't dived into it much ;)


Tony



Sylvain

Re: [ Daisy ] Registration broken?


Bruno Dumon wrote:


fixed. I had copied one character too less when copying over the
IP-agreement change.



Awesome, thanks!

Tony

Re: iCal

2005-06-20 Thread Andrew Franz


Sylvain Wallez wrote:


Tony Collen wrote:


Sylvain Wallez wrote:


Andrew Franz wrote:


Has anyone thought about integrating iCal with Cocoon?





It would be great to have an iCal generator / iCal serializer!

Want to write it ?



http://www.ietf.org/rfc/rfc2445.txt




Yeah, but that's not XML ;-)

Sylvain



I was tempted enough to read the RTF - all 148 pages!!

But no, I have a day job, no expertise in this area  the extent of my 
cocoon knowledge is writing *one* generator


Thanks for the suggestion though ;-)

Re: iCal

2005-06-20 Thread Andrew Franz


Andrew Franz wrote:


Sylvain Wallez wrote:


Tony Collen wrote:


Sylvain Wallez wrote:


Andrew Franz wrote:


Has anyone thought about integrating iCal with Cocoon?






It would be great to have an iCal generator / iCal serializer!

Want to write it ?



http://www.ietf.org/rfc/rfc2445.txt





Yeah, but that's not XML ;-)

Sylvain



I was tempted enough to read the RTF - all 148 pages!!


RFC (!)



But no, I have a day job, no expertise in this area  the extent of my 
cocoon knowledge is writing *one* generator


Thanks for the suggestion though ;-)

XSLSerializer, XSLGenerator, XSLReader

2005-06-20 Thread BURGHARD Éric

Hi,

By looking at the XMLSerializer source code, i just realized that the
serialization was driven in fact by an xsl transformation (with no
stylesheet). So i wondered, why not giving this serialization a real
stylesheet ? That way i could overcome all the limitations of the actual
XMLSerializer.

I quickly hack the file, and end up with the XSLSerializer.

The main advantages are
- i can get rid of namespaces without another step
- generate real xhtml (dispite the name the actual xhtml transformer
contract all empty tags like textarea, div, script, ..., which makes all
browsers really mad)
- use directly all xslt2.0 serialization enhancements (character-maps) with
saxon8.
- perhaps performance improvement, because the stylesheet is precompiled and
reused with the component, and because we save one step in the pipeline
(even if a plain serialization should be really fast). The stylesheet is
XSL precompiled, whereas with conventional pipeline and cache activated,
only its structure is precompiled (SAX).

For now, i configure the serializer with a
xsltpath_of_the_stylesheet/xslt

and use it with no parameters, but why not a

map:serializer type=xslt src=path_of_the_stylesheet
  map:parameter name=cpath value={contextpath:}
/map:serializer

to absolutise path, delete namespaces, change and; to  (for javascript
snippets), and serialize to xhtml (method=xhtml) all in one step ?

By extension, why not having an XSLGenerator and an XSLReader ?

WDYT ?

RE: [GT2005] News, vote and more news

2005-06-20 Thread Nathaniel Alfred

Yes, I'm thinking of attending the Cocoon GetTogether 2005 in 
Amsterdam, preferably on

   [X]  3/4/5 October (Mon-Wed)
   [ ]  5/6/7 October (Wed-Fri)

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.

[OT] Cost to develop Cocoon


http://www.koders.com/info.aspx?c=ProjectInfopid=TLBCDUNU1ZAA9FXVPZ8758NBLC

via Matt Raible [1]

Regards,
Tony

[1] http://raibledesigns.com/page/rd/20050620

Re: [Ann/RFC] Sitemap Blocks

2005-06-20 Thread Stefano Mazzocchi

Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:

Yey!!

Daniel,

you rock! Thanks so much for your continuous work on this!

Thanks :)

See my comments inlined.

Daniel Fagerstrom wrote:

snip/

for an example.

hmmm, I don't get this. why do you need to explicitly identify a super
block? don't you get it directly thru extension?

gotcha. I don't have a problem with this.

The wiring file is used by the BlocksManager to set up all the blocks.
The BlocksManager is configured to point to the wiring.xml:

component role=org.apache.cocoon.components.blocks.BlocksManager
class=org.apache.cocoon.components.blocks.BlocksManager
file=wiring.xml/

All access to blocks goes through the BlocksManager.

Works for me.

blocks: protocol

map:match pattern=**
map:read src=blocks:/{1}/
/map:match

Great idea! I'd like to keep going with this, because sometimes, due to
legacy, you might want to keep the need to position the 'block subspace'
as you please.

I'm not certain that I actually supported relocation in the current
implementation, but it shouldn't be that hard to fix.

block-path: module
--

A block URI block:foo:/bar where the foo block is mounted at /test can
be absoultized to /test/bar by using the block-path input module,

{block-path:foo:/bar}

see example in
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test1/sub/.

This module can be used together with the LinkRewriterTransformer
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html

from Forrest fame to creta the block link rewriting behaviour described
in the end of http://wiki.apache.org/cocoon/BlocksDefinition.

this works, but I don't think it's the prettiest thing we could do.

It wasn't designed to be pretty, it was designed to get the job done
with a minimal amount of work ;)

so the link transformer must be able to
access the block manager and obtain the relative URL of the given stuff.

I prefer to avoid black magic in this case, link rewriting is hard
enough to understand without any helpfull automagics. I might change
my mind when we have got more experience about using block link

Re: [Ann/RFC] Sitemap Blocks


Stefano Mazzocchi wrote:

Daniel Fagerstrom wrote:

snip/

Now, to continue the work on the sitemap aspect of blocks we really need
to apply it in a non trivial application. By doing that we will get more
experience of the involved concepts. It would also make it easier for
the rest of the community to see what the sitemap aspect of blocks can
be used for. There seem to be a large community interest in the
component aspect of blocks, but not yet in the sitemap aspect. Actually
using it in a real use case would also increase my and others motivation
to polish the implementation.

I think that the Linotype would make an excelent use case for
introducing the current block mechanism in. Are you interested?



In fact, I am.


Cool!


Give me a 3 lines description of where to start looking and I'll get going.


A good starting point is the BlocksManager and sitemap component 
configurations in the test cases: 
src/test/org/apache/cocoon/test/components/blocks/BlocksManagerTestCase.xconf.


/Daniel

Re: XSLSerializer, XSLGenerator, XSLReader


BURGHARD Éric wrote:


Hi,

By looking at the XMLSerializer source code, i just realized that the
serialization was driven in fact by an xsl transformation (with no
stylesheet). So i wondered, why not giving this serialization a real
stylesheet ? That way i could overcome all the limitations of the actual
XMLSerializer.

I quickly hack the file, and end up with the XSLSerializer.

The main advantages are
- i can get rid of namespaces without another step
- generate real xhtml (dispite the name the actual xhtml transformer
contract all empty tags like textarea, div, script, ..., which makes all
browsers really mad)
- use directly all xslt2.0 serialization enhancements (character-maps) with
saxon8.
- perhaps performance improvement, because the stylesheet is precompiled and
reused with the component, and because we save one step in the pipeline
(even if a plain serialization should be really fast). The stylesheet is
XSL precompiled, whereas with conventional pipeline and cache activated,
only its structure is precompiled (SAX).
 



- handle the ?xml-stylesheet? processing instruction by serializing 
straight XML for those browsers that do support it, and process on the 
server for others.




For now, i configure the serializer with a
xsltpath_of_the_stylesheet/xslt

and use it with no parameters, but why not a

map:serializer type=xslt src=path_of_the_stylesheet
 map:parameter name=cpath value={contextpath:}
/map:serializer
 



+1


to absolutise path, delete namespaces, change and; to  (for javascript
snippets), and serialize to xhtml (method=xhtml) all in one step ?

By extension, why not having an XSLGenerator and an XSLReader ?
 



Hmm... you're starting to build pipelines-in-one-component. This doesn't 
seem to have the same kind of benefits than the serializer.


Sylvain

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research  Technology Director

Re: XSLSerializer, XSLGenerator, XSLReader

2005-06-20 Thread BURGHARD Éric

 
 - handle the ?xml-stylesheet? processing instruction by serializing
 straight XML for those browsers that do support it, and process on the
 server for others.


great idea !

By extension, why not having an XSLGenerator and an XSLReader ?
  

 
 Hmm... you're starting to build pipelines-in-one-component. This doesn't
 seem to have the same kind of benefits than the serializer.


Right, i thought that for simple pipelines that are only
generator + xslt transformer + xml serializer

read type=xslt src={xmldb:///} xslt=stylesheets/site2xhtml.xsl/

would be more readable, but i'm not convinced in fact. As i must use the
sourceResolver here, there's no obvious benefit over
generator src={xmldb:///}
serialize type=xslt src=stylesheets/site2xhtml.xsl

For the precompiled xslt, it's better perhaps to modify the TraxTransformer
to cache the Templates object.

For the generator, i think that the use must be limited to simplified
stylesheets. Xsl try to be a template and a transform language (the root of
the stylesheet itself can be xsl:transform or xsl:stylesheet). For
templating, sometimes you don't need an input document, so you generally do

generate src=empty.xml/
transform src=mypage.xsl
 param/
 ...
/transform
transform src=site2xhtml.xsl/
serialize/

i would prefer here

generate type=xslt src=mypage.xsl
 param
 ...
/generate
transform src=site2xhtml.xsl/
serialize/

that way, the difference between templating and transforming xsl appear soon
on the sitemap side, and because there's no xslt attribute, bad habits are
not possible.

Regards.

Re: XSLSerializer, XSLGenerator, XSLReader


BURGHARD Éric wrote:


- handle the ?xml-stylesheet? processing instruction by serializing
straight XML for those browsers that do support it, and process on the
server for others.

   



great idea !

 


By extension, why not having an XSLGenerator and an XSLReader ?


 


Hmm... you're starting to build pipelines-in-one-component. This doesn't
seem to have the same kind of benefits than the serializer.

   



Right, i thought that for simple pipelines that are only
generator + xslt transformer + xml serializer

read type=xslt src={xmldb:///} xslt=stylesheets/site2xhtml.xsl/

would be more readable, but i'm not convinced in fact.



:-)


As i must use the
sourceResolver here, there's no obvious benefit over
generator src={xmldb:///}
serialize type=xslt src=stylesheets/site2xhtml.xsl
 



Exactly.


For the precompiled xslt, it's better perhaps to modify the TraxTransformer
to cache the Templates object.
 



Templates *are* cached already. This is done by the XSLTProcessor component.


For the generator, i think that the use must be limited to simplified
stylesheets. Xsl try to be a template and a transform language (the root of
the stylesheet itself can be xsl:transform or xsl:stylesheet). For
templating, sometimes you don't need an input document, so you generally do

generate src=empty.xml/
transform src=mypage.xsl
param/
...
/transform
transform src=site2xhtml.xsl/
serialize/

i would prefer here

generate type=xslt src=mypage.xsl
param
...
/generate
transform src=site2xhtml.xsl/
serialize/

that way, the difference between templating and transforming xsl appear soon
on the sitemap side, and because there's no xslt attribute, bad habits are
not possible.
 



Have a look in trunk at 
src/blocks/scratchpad/trunk/java/org/apache/cocoon/generation/TraxGenerator. 
It's already there :-)


It's probably time to promote this to the core.

Sylvain

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research  Technology Director

DO NOT REPLY [Bug 35440] New: - [PATCH] enhancement to {global:} input module: return all sitemap globals