Re: cvs commit: AbstractWrappingModule.java

[Dave Brondsema <da...@brondsema.net>]

On Tue, 27 Jan 2004 nicolaken@apache.org wrote:

> nicolaken    2004/01/27 07:22:42
>
>   Added:       src/java/org/apache/cocoon/components/modules/input
>                         AbstractWrappingModule.java

>           logger.debug("Loading wrapped class:"+childClassName)

That's line 88.  No semicolon at the end of line.  Even after fixing that,
it can't resolve 'logger'.

I've been able to fix this locally, but I would expect that you have a
working version somewhere, right Nicola?  If not, I will apply my changes
to CVS.

-- 
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - Calvin club

RE: Generating files as part of the build process

[Peter Meggitt <pm...@eviasoft.com>]

Sorry for the lapse responding. I made changes so that images no longer need
to be generated statically. I have an xml file for describing images. Here
is an example:

<?xml version="1.0" encoding="UTF-8"?>
<?relaxng-compact external "svg-images-v10.rnc"?>
<svg-images>

 <corners name="tab_">
   <color foreground="#4C6C8F" background="#FFF" border="orange"/>
   <size width="9" height="10" border="2"/>
   <topleft height="70"/>
   <topright width="300" height="70"/>
 </corners>

 <corners name="tabmenu_">
   <color foreground="#CFDCED" background="#294563" border="green"/>
   <size width="9" height="10" border="2"/>
   <topleft width="300" height="70"/>
   <topright height="70"/>
 </corners>

 <corners name="table_">
   <color foreground="black" background="orange" border="#ff3311"/>
   <size width="20" height="20" border="0"/>
   <transform><scale x="20" y="10"/></transform>
 </corners>

 <rect name="rect" width="16" height="2" color="orange"/>
 <rect name="sidebar_bg" width="2" height="16" color="orange"/>

</svg-images>

A <corner> element by default generates 4 rounded corners with the names tl,
tr, bl, and br. So the name tab_tl is a reference to a left rounded corner
with the specified width, height, foreground, background, and border colors.
An xslt transformation converts this to svg which can be referenced in a css
file as (for example) skin/svg-images/tab_tl.png. I have another xslt
transformation that creates a diagnostic page containing the source svg and
image for each element generated. I have yet to publish a site so
unfortunately can't give you a URL to look at. I am working with a copy of
Marshall Roch's xhtml-css and plan to replace his gifs with pngs that can be
modified dynamically (ideally in skinconf.xml).

If you are interested in possibly using this soon let me know what to do
with the code as I am not sure how to obtain cvs privileges. Otherwise I
will provide a link when I have published a site and you can decide then.

Regards
Peter Meggitt
-----Original Message-----
From: news [mailto:news@sea.gmane.org]On Behalf Of Nicola Ken Barozzi
Sent: Friday, January 30, 2004 3:23 AM
To: forrest-dev@xml.apache.org
Subject: Re: Generating files as part of the build process


Peter Meggitt wrote:
> I have some code to generate svg files that can be used by skins as images
> for things like rounded corners on tabs and menus. In some ways this is
> easier to use than hard coding corner properties as part of the url as
used
> in the "read-svg2png-corner-resource" resource included in resources.xmap.
> The mechanism entails having an xml file (or generating one) in the skin
> that gets transformed into multiple svg (or png) files.

You mean that instead of inserting the rounded corner info in the
filename, you use a single descriptor for all corners?
You see, the CSS can be generated from an xslt file, and so that can use
your description, *without* having to do any change.
Could you please post it here so I can take a look?

> I would like to
> invoke these transformations statically as part of the build process. With
a
> previous version of forrest I would just create the files in
> build/webapp/skins/.... However now with webapp-local, I don't see any way
> of referencing generated resources (unless they are generated to a src
> location).

Correct.

> Would anyone be opposed to the introduction of an additional directory for
> the purposes of storing and referencing generated resources (images, xslt
> stylesheets, css, skins, etc) when running a forrest site created with
> webapp-local?

Yup ;-)

There is a mechanism that we will introduce to make source dirs
configurable, that is the _locationmap_. Each project can have it's own
locationmap that defines or augments the places where sources are
searched for, and the same for skins. It's slated for 0.7.

...
 > I was
> playing with a mechanism to dynamically generate a skin (including css)
from
> an enhanced version of skinconf.xml. It seemed (to me) to be much easier
to
> generate all the necessary files as part of the build than to add
additional
> complexity to sitemap transformations to enable changes to skinconf.xml to
> be rendered dynamically.

Well, Cocoon is our transformation engine. What makes it "easier" for
you to generate them before?

...
 > It is
> just a realization that there are certain transformations that are
difficult
> (or impossible) to perform dynamically and that there should be a standard
> way to punt (static rendering).

I don't see anything that has to be generated 'statically', as you say.
Can you post an example?

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

Re: Generating files as part of the build process

[Nicola Ken Barozzi <ni...@apache.org>]

Peter Meggitt wrote:
> I have some code to generate svg files that can be used by skins as images
> for things like rounded corners on tabs and menus. In some ways this is
> easier to use than hard coding corner properties as part of the url as used
> in the "read-svg2png-corner-resource" resource included in resources.xmap.
> The mechanism entails having an xml file (or generating one) in the skin
> that gets transformed into multiple svg (or png) files. 

You mean that instead of inserting the rounded corner info in the 
filename, you use a single descriptor for all corners?
You see, the CSS can be generated from an xslt file, and so that can use 
your description, *without* having to do any change.
Could you please post it here so I can take a look?

> I would like to
> invoke these transformations statically as part of the build process. With a
> previous version of forrest I would just create the files in
> build/webapp/skins/.... However now with webapp-local, I don't see any way
> of referencing generated resources (unless they are generated to a src
> location).

Correct.

> Would anyone be opposed to the introduction of an additional directory for
> the purposes of storing and referencing generated resources (images, xslt
> stylesheets, css, skins, etc) when running a forrest site created with
> webapp-local? 

Yup ;-)

There is a mechanism that we will introduce to make source dirs 
configurable, that is the _locationmap_. Each project can have it's own 
locationmap that defines or augments the places where sources are 
searched for, and the same for skins. It's slated for 0.7.

...
 > I was
> playing with a mechanism to dynamically generate a skin (including css) from
> an enhanced version of skinconf.xml. It seemed (to me) to be much easier to
> generate all the necessary files as part of the build than to add additional
> complexity to sitemap transformations to enable changes to skinconf.xml to
> be rendered dynamically. 

Well, Cocoon is our transformation engine. What makes it "easier" for 
you to generate them before?

...
 > It is
> just a realization that there are certain transformations that are difficult
> (or impossible) to perform dynamically and that there should be a standard
> way to punt (static rendering).

I don't see anything that has to be generated 'statically', as you say. 
Can you post an example?

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

Generating files as part of the build process

[Peter Meggitt <pm...@eviasoft.com>]

I have some code to generate svg files that can be used by skins as images
for things like rounded corners on tabs and menus. In some ways this is
easier to use than hard coding corner properties as part of the url as used
in the "read-svg2png-corner-resource" resource included in resources.xmap.
The mechanism entails having an xml file (or generating one) in the skin
that gets transformed into multiple svg (or png) files. I would like to
invoke these transformations statically as part of the build process. With a
previous version of forrest I would just create the files in
build/webapp/skins/.... However now with webapp-local, I don't see any way
of referencing generated resources (unless they are generated to a src
location).

Would anyone be opposed to the introduction of an additional directory for
the purposes of storing and referencing generated resources (images, xslt
stylesheets, css, skins, etc) when running a forrest site created with
webapp-local? In addition to project.home and forrest.home, there would be
an additional directory like (project.generate.home). In some ways this
might lead to a standardization of the different means of rendering (static
vs. dynamic) within forrest. For example if I change a projects skin in
forrest.properties the change will not take effect until I rebuild the site
(it is a statically rendered change). I only know this through trial and
error (or by closely looking at the code). The introduction of explicit
static rendering will result in improved debugging capabilities, a
simplification of certain transformations and additional flexibility. I was
playing with a mechanism to dynamically generate a skin (including css) from
an enhanced version of skinconf.xml. It seemed (to me) to be much easier to
generate all the necessary files as part of the build than to add additional
complexity to sitemap transformations to enable changes to skinconf.xml to
be rendered dynamically. This is not to say that it is not sometimes worth
the effort to enable changes to be rendered dynamically (in the case of
skinconf.xml it is definitely worth exerting a considerable effort). It is
just a realization that there are certain transformations that are difficult
(or impossible) to perform dynamically and that there should be a standard
way to punt (static rendering).

Re: cvs commit: AbstractWrappingModule.java

[Nicola Ken Barozzi <ni...@apache.org>]

Dave Brondsema wrote:

> On Tue, 27 Jan 2004 nicolaken@apache.org wrote:
> 
> 
>>nicolaken    2004/01/27 07:22:42
>>
>>  Added:       src/java/org/apache/cocoon/components/modules/input
>>                        AbstractWrappingModule.java
> 
> 
>>          logger.debug("Loading wrapped class:"+childClassName)
> 
> That's line 88.  No semicolon at the end of line.  Even after fixing that,
> it can't resolve 'logger'.
> 
> I've been able to fix this locally, but I would expect that you have a
> working version somewhere, right Nicola?  If not, I will apply my changes
> to CVS.

Oh, sorry. They were all System.out.println() messages, and I guess I 
made a mistake and committed the file after doing a manual substitution 
on them without rechecking. Sorry again, fixing.

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