You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by st...@outerthought.org on 2003/05/08 10:00:03 UTC

[WIKI-UPDATE] SamplesRefactor Thu May 8 10:00:02 2003

Page: http://wiki.cocoondev.org/Wiki.jsp?page=SamplesRefactor , version: 6 on Thu May  8 07:02:05 2003 by BertrandDelacretaz

- |hello-world/PDF-fop| |yes|yes|
+ |hello-world/PDF-fop| |yes|yes|bd
?                                ++

- |hello-world/RTF| |yes|yes|
+ |hello-world/RTF| |yes|yes|bd
?                            ++




Re: linking from main samples to block samples

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:

>on 5/8/03 3:28 PM Sylvain Wallez wrote:
>  
>
<snip/>

>>I haven't followed closely the discussion and so this may be a dumb 
>>idea, but we could move .xsamples files from the "conf" dir to the 
>>"samples" dir and aggregate them all through the directory generator :
>>
>><map:generate type="dir" src="samples">
>>  <!-- regexp to include only ".xsamples" files -->
>>  <map:parameter name="include" value=".*\.xsamples$">
>></map:generate>
>><map:transform src="dir2include.xsl"/>
>><map:transform type="xinclude"/>
>><map:transform src="samples2html.xsl"/>
>><map:serialize/>
>>
>>Does it make sense ?
>>    
>>
>
>Yeah, something like that.
>
>I really don't care how this is done as long as our build system is *KEPT THIN* and it's our sitemap that grows.
>
>Why? because this community is *MUCH* more focused on sitemaps that on huge build files.
>

And also because Cocoon samples should demonstrate Cocoon and not Ant ;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Re: linking from main samples to block samples

Posted by Stefano Mazzocchi <st...@apache.org>.
on 5/8/03 3:28 PM Sylvain Wallez wrote:

> Stefano Mazzocchi wrote:
> 
> 
>>on 5/8/03 4:58 AM Bertrand Delacretaz wrote:
>>
>> 
>>
>>
>>>Le Jeudi, 8 mai 2003, à 11:31 Europe/Zurich, Nicola Ken Barozzi a écrit 
>>>:
>>>
>>>
>>>   
>>>
>>>
>>>>...We can now style this with xslt in Ant or Cocoon to not show
>>>> items where @exclude="true"
>>>>     
>>>>
>>>
>>>Sounds interesting as a static way of knowing which blocks are present.
>>>
>>>Maybe there's another way, not too hard IIUC: how about an InputModule 
>>>that find out whether certain Roles are available? Might be more 
>>>generally useful.
>>>
>>>I assume a Composable InputModule can ask its component manager for any 
>>>sitemap component, is that correct?
>>>
>>>The module could be configured to check for the presence of specific 
>>>Roles, and report in the sitemap using something like
>>>
>>>  <map:transform src="someXslt.xsl">
>>>    <map:parameter name="fopBlockPresent" 
>>>value="{role-present:fopSerializer}"/>
>>>  </map:transform>
>>>
>>>Thoughts?
>>>   
>>>
>>
>>Yes, damn it! we have a super-function web publishing system and we
>>still are infected with those build-time staticisms.
>>
>>get over it: the future is dynamic.
>>
> 
> 
> I haven't followed closely the discussion and so this may be a dumb 
> idea, but we could move .xsamples files from the "conf" dir to the 
> "samples" dir and aggregate them all through the directory generator :
> 
> <map:generate type="dir" src="samples">
>   <!-- regexp to include only ".xsamples" files -->
>   <map:parameter name="include" value=".*\.xsamples$">
> </map:generate>
> <map:transform src="dir2include.xsl"/>
> <map:transform type="xinclude"/>
> <map:transform src="samples2html.xsl"/>
> <map:serialize/>
> 
> Does it make sense ?

Yeah, something like that.

I really don't care how this is done as long as our build system is
*KEPT THIN* and it's our sitemap that grows.

Why? because this community is *MUCH* more focused on sitemaps that on
huge build files.

Next time I hear people willing to have build properties in XML, I set
myself to kill.

You have been warned ;-)

-- 
Stefano.



Re: linking from main samples to block samples

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:

>on 5/8/03 4:58 AM Bertrand Delacretaz wrote:
>
>  
>
>>Le Jeudi, 8 mai 2003, à 11:31 Europe/Zurich, Nicola Ken Barozzi a écrit 
>>:
>>
>>
>>    
>>
>>>...We can now style this with xslt in Ant or Cocoon to not show
>>>  items where @exclude="true"
>>>      
>>>
>>Sounds interesting as a static way of knowing which blocks are present.
>>
>>Maybe there's another way, not too hard IIUC: how about an InputModule 
>>that find out whether certain Roles are available? Might be more 
>>generally useful.
>>
>>I assume a Composable InputModule can ask its component manager for any 
>>sitemap component, is that correct?
>>
>>The module could be configured to check for the presence of specific 
>>Roles, and report in the sitemap using something like
>>
>>   <map:transform src="someXslt.xsl">
>>     <map:parameter name="fopBlockPresent" 
>>value="{role-present:fopSerializer}"/>
>>   </map:transform>
>>
>>Thoughts?
>>    
>>
>
>Yes, damn it! we have a super-function web publishing system and we
>still are infected with those build-time staticisms.
>
>get over it: the future is dynamic.
>

I haven't followed closely the discussion and so this may be a dumb 
idea, but we could move .xsamples files from the "conf" dir to the 
"samples" dir and aggregate them all through the directory generator :

<map:generate type="dir" src="samples">
  <!-- regexp to include only ".xsamples" files -->
  <map:parameter name="include" value=".*\.xsamples$">
</map:generate>
<map:transform src="dir2include.xsl"/>
<map:transform type="xinclude"/>
<map:transform src="samples2html.xsl"/>
<map:serialize/>

Does it make sense ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Re: linking from main samples to block samples

Posted by Stefano Mazzocchi <st...@apache.org>.
on 5/8/03 4:58 AM Bertrand Delacretaz wrote:

> Le Jeudi, 8 mai 2003, à 11:31 Europe/Zurich, Nicola Ken Barozzi a écrit 
> :
> 
> 
>>...We can now style this with xslt in Ant or Cocoon to not show
>>   items where @exclude="true"
> 
> 
> Sounds interesting as a static way of knowing which blocks are present.
> 
> Maybe there's another way, not too hard IIUC: how about an InputModule 
> that find out whether certain Roles are available? Might be more 
> generally useful.
> 
> I assume a Composable InputModule can ask its component manager for any 
> sitemap component, is that correct?
> 
> The module could be configured to check for the presence of specific 
> Roles, and report in the sitemap using something like
> 
>    <map:transform src="someXslt.xsl">
>      <map:parameter name="fopBlockPresent" 
> value="{role-present:fopSerializer}"/>
>    </map:transform>
> 
> Thoughts?

Yes, damn it! we have a super-function web publishing system and we
still are infected with those build-time staticisms.

get over it: the future is dynamic.

-- 
Stefano.



Re: linking from main samples to block samples

Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 8 mai 2003, à 11:31 Europe/Zurich, Nicola Ken Barozzi a écrit 
:

> ...We can now style this with xslt in Ant or Cocoon to not show
>    items where @exclude="true"

Sounds interesting as a static way of knowing which blocks are present.

Maybe there's another way, not too hard IIUC: how about an InputModule 
that find out whether certain Roles are available? Might be more 
generally useful.

I assume a Composable InputModule can ask its component manager for any 
sitemap component, is that correct?

The module could be configured to check for the presence of specific 
Roles, and report in the sitemap using something like

   <map:transform src="someXslt.xsl">
     <map:parameter name="fopBlockPresent" 
value="{role-present:fopSerializer}"/>
   </map:transform>

Thoughts?
-Bertrand

Re: linking from main samples to block samples

Posted by Nicola Ken Barozzi <ni...@apache.org>.

Bertrand Delacretaz wrote, On 08/05/2003 10.51:
...
> Ok - detecting the presence of blocks or components dynamically is 
> certainly possible, but AFAIK there's no easy mechanism for relaying 
> this info to an XSLT page that would include links or not. I'd be glad 
> to be proven wrong though ;-)

If block.properties was blockprops.xml, both Ant and Cocoon could read 
it... ;-)

Ok, ok, here is how it can be done now:

  1 - use xslt to transform module.xml to a temp.xml file that shows
      all blocks, and that adds a ${exclude.xxx.block} element:

      <blocks>
        <block name="xxx" exclude="${exclude.xxx.block}">
          <description><description>
        <block>
        ...
      </blocks>

  2 - then load block.properties and filter the file to
      expand the propertirs with:

   <copy srcFile="temp.xml">
     ...
     <filterchain>
       <expandproperties/>
     </filterchain>
   </loadfile>

  3 - Now we have:

      <blocks>
        <block name="xxx" exclude="true">
          <description><description>
        <block>
        <block name="yyy" exclude="false">
          <description><description>
        <block>
        ...
      </blocks>

    We can now style this with xslt in Ant or Cocoon to not show
    items where @exclude="true"

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Re: linking from main samples to block samples

Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 8 mai 2003, à 10:39 Europe/Zurich, David Crossley a écrit :

> ...I see that these PDF samples are not linked from the Hello World
> page anymore. Is that because it is hard/impossible to link
> reliably from the main samples to the block samples?
> i.e. if the block is excluded then such links would be busted?

Yes, that's the reason.

> Perhaps it would be okay to just put a short note, e.g.
> "requires block-jfor". It would be good to have all the
> Hello World samples listed on the same page, as well as over
> in each block.

Ok - detecting the presence of blocks or components dynamically is 
certainly possible, but AFAIK there's no easy mechanism for relaying 
this info to an XSLT page that would include links or not. I'd be glad 
to be proven wrong though ;-)

So for now I agree that a notice like you mention is a good idea - as 
Tony mentioned it's good to have all helloworld samples listed in one 
place.

-Bertrand

linking from main samples to block samples

Posted by David Crossley <cr...@indexgeo.com.au>.
Hi Bertrand, thanks to all of us for helping with the samples.

I see that these PDF samples are not linked from the Hello World
page anymore. Is that because it is hard/impossible to link
reliably from the main samples to the block samples?
i.e. if the block is excluded then such links would be busted?

Perhaps it would be okay to just put a short note, e.g.
"requires block-jfor". It would be good to have all the
Hello World samples listed on the same page, as well as over
in each block.

--David
 
> - |hello-world/PDF-fop| |yes|yes|
> + |hello-world/PDF-fop| |yes|yes|bd
> ?                                ++
> 
> - |hello-world/RTF| |yes|yes|
> + |hello-world/RTF| |yes|yes|bd
> ?                            ++
>